Calculation of Class::NumTypeArguments() is reimplemented so that it does
no require separate calculation of Class::NumOwnTypeArguments().
Number of own type arguments is no longer stored in Class, and has_pragma
bit is moved into state_bits.
This simplifies overall calculation and does not require to keep both
num_type_arguments and num_own_type_arguments. This also allows us to add
up to 15 more flag bits to Class.
Change-Id: Iac7a751145fea7adb673ab9369eeb8eea5c5794d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105544
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The Dart_KernelCompilationResult type is clumsy to use because it has
multiple owning pointers, and TestCase needs to be better about
remembering to release memory in all code paths. But adding this
free() call at least fixes the reported leak.
Fixes#37154.
Change-Id: I075ccfd20c55026f2443c3d0aef3d2d62192ab3b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105406
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Matthew Dempsky <mdempsky@google.com>
TransferableTypedData instances are one-use kind of thing: once receiver materializes it, it can't be used
again, once sender sends it out to an isolate, sender can't send it to different isolate.
Example of use:
sender isolate:
```
Future<TransferableTypedData> consolidateHttpClientResponseBytes(HttpClientResponse response) {
final completer = Completer<TransferableTypedData>();
final chunks = <Uint8List>[];
response.listen((List<int> chunk) {
chunks.add(chunk);
}, onDone: () {
completer.complete(TransferableTypedData.fromList(chunks));
});
return completer.future;
}
...
sendPort.send(await consolidateHttpClientResponseBytes(response));
```
receiver isolate:
```
RawReceivePort port = RawReceivePort((TransferableTypedData transferable) {
Uint8List content = transferable.materialize().asUint8List();
...
});
```
31959[tr] and 31960[tr] tests were inspired by dartbug.com/31959, dartbug.com/31960 that this CL attempts to address:
```
╰─➤ out/ReleaseX64/dart 31960.dart
sending...
163ms for round-trip
sending...
81ms for round-trip
sending...
20ms for round-trip
sending...
14ms for round-trip
sending...
20ms for round-trip
sending...
14ms for round-trip
```
(notice no "since last checking" pauses") vs
```
╰─➤ out/ReleaseX64/dart 31960.dart
sending...
154ms since last checkin
174ms for round-trip
sending...
68ms since last checkin
9ms since last checkin
171ms for round-trip
sending...
13ms since last checkin
108ms for round-trip
sending...
14ms since last checkin
108ms for round-trip
sending...
14ms since last checkin
107ms for round-trip
```
Change-Id: I0fcb5ce285394f498c3f1db4414204531f98199d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99623
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This way, the new type information can be used immediately by
this and following passes instead of only passes after the next
type propagation phase.
Change-Id: Id27c3789c7c32f5775da5ef933bc56cb58c2a203
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101826
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
In cases where the same target function is used for multiple
CID ranges, we only perform the inlining once. However, if the
CID range used for the initial inlining is a single CID, we will
set the type of the redefinition to that CID.
Detect this case and clear the concrete type associated with
the redefinition if it was given one.
Change-Id: I9f9bdd7c21e0dc1ac537f8facece0010630bd9aa
Cq-Include-Trybots: luci.dart.try:vm-kernel-win-debug-x64-try,vm-kernel-win-release-ia32-try,vm-kernel-win-product-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105221
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The list of bytecodes that are checked for debug breaks and single stepping
can be tuned later (as well as performance if needed).
Fix identification of Dart top activation frame in debugger.
Change-Id: Ieab804ba25f84efe173531431c6d311005163433
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104922
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This change renames Class::is_cycle_free to Class::is_declaration_loaded
and under the hood replaces cycle_free and type_finalized bits with
class loading state enum.
Also, added new assertions to check is_declaration_loaded().
Change-Id: Ib43e12731d0dc782e273be8e55912494e102cd79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104920
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
In cases where the same target function is used for multiple
CID ranges, we only perform the inlining once. However, if the
CID range used for the initial inlining is a single CID, we will
set the type of the redefinition to that CID.
Detect this case and clear the concrete type associated with
the redefinition if it was given one.
Change-Id: I3c27c46c71e10e71624ce3b969cb741eb9b2915f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104781
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
A number of places in the code will free `Dart_KernelCompilationResult.kernel`
if non-nullptr even if `Dart_KernelCompilationResult.error` is non-nullptr.
Normally the two are mutually exclusive (either `error` is set or `kernel` is set) but
some code frees both if they are non-null.
This issue has caused free() of uninitialized memory which in return
caused some of our benchmarks to break.
Change-Id: Ie65a0c51a32a3616361f3852c13c859e560285b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104563
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This reverts commit ab6aeaa106.
Revert "[vm/compiler] Speed up the compiler part which deals with kernel reading up in DEBUG mode"
This reverts commit b316210d94.
Reason for revert: regression of snapshot sizes (DNO-599).
Original change's description:
> [vm/kernel] Use GC-tracked ExternalTypedData/TypedDataView for kernel buffers
>
> Until now we often leaked kernel buffers (e.g. hot reload buffers) because various
> objects were referencing ExternalTypedData objects pointing into the middle of
> c-allocated memory. This made it impossible for the GC to determine when the last
> reference is gone.
>
> This CL ensures that the actual buffers are *always* made available via
> ExternalTypedData and any inner pointers into it are created via TypedDataViews.
>
> The embedder guarantees to the free kernel buffers it has provided to:
> - Dart_CreateIsolateFromKernel
> - Dart_LoadScriptFromKernel
> - Dart_LoadLibraryFromKernel
> - Dart_SetDartLibrarySourcesKernel
> on isolate shutdown.
>
> All other kernel buffers will get a finalizer attached, which ensures the
> kernel buffers get freed by the GC once they are no longer referenced:
> - Kernel blobs for expression evaluation
> - Kernel blobs for Hot-Reload
> - Kernel blobs for cc tests
>
> Fixes https://github.com/dart-lang/sdk/issues/33973
> Fixes https://github.com/dart-lang/sdk/issues/36857
> Issue https://github.com/dart-lang/sdk/issues/37030
>
> Change-Id: I1cc410c94c0f4b229413e793728a261afcb10aaf
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103130
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
> Commit-Queue: Martin Kustermann <kustermann@google.com>
TBR=kustermann@google.com,rmacnak@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I49715d2400f4a5c8806b7d6a2912b7258f671a0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104343
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
In rare circumstances we can generate a complete monomorphic
PolymorphicInstanceCall targeting a method of Smi class.
In this case we don't need to check anything - we can simply emit a
static call.
(This fixes a bug in the incorrect fix submitted earlier as
c67b9f2331 - even if call is complete
we still need to check for a smi receiver if there are more possible
receiver classes)
Fixes#37019
Bug: 37019
Change-Id: If0250ba2811f00cc4fe595bf7cd03a7c0d820076
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103809
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Alexander Markov