When creating a KernelProgramInfo, we create several logical views into the kernel buffer. These are fresh ExternalTypedDatas, rather than proper TypedDataViews, so they do not automically keep the original ExternalTypedData alive. Create an explicit reference to the orginal ExternalTypedData in the KernelProgramInfo. When creating snapshots, this reference is ignored/null'd and the views are turned into copies, effectively dropping the parts of the original buffer that do not have views.
Fixes a leak with reload and a use-after-free with eval.
Bug: https://github.com/dart-lang/sdk/issues/33973
Bug: https://github.com/dart-lang/sdk/issues/39610
Change-Id: I09d3830133314ccbaa0341d904127c2b6925c4ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/126825
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Previously, KernelIsolate::CompileExpressionToKernel was called
with is_static == false and klass == nullptr, which doesn't make sense:
this call requested to compile expression inside instance method context but
without enclosing class. This results in a malformed kernel AST and crash
in bytecode generator.
Fixes vm/cc/LinkedHashMap and vm/cc/Service_* tests in bytecode mode.
Change-Id: I121b0cb0e149d378d6b12e9861ef941513e1e199
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/112024
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@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>
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>
Threads in the native or blocked states don't prevent safepoints, so they may run concurrently with a safepoint operation like GC. It is not safe for handles to be allocated while the GC is visiting them, so these threads must not allocate handles. Assert only threads in the VM or generated states, which prevent safepoints until they check in, may allocate handles. (Generated code does not allocate handles, but leaf runtime entries remain in the generated state.)
Bug: https://github.com/dart-lang/sdk/issues/34883
Change-Id: I1a211778f7ef96b53a2405f0ee9dde7871b122b6
Reviewed-on: https://dart-review.googlesource.com/c/81540
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This reverts commit e76ea5b604.
1. Remove unused dart debugger API entrypoints which are not used anymore
as this API has been deprecated and dartium was the last user.
2. Some unit tests are using some of these API entrypoints, so moved them
over to a test file which will be linked into run_vm_tests
Change-Id: I5a486b98e4b97eb4df2e58d9cc0ba603e96c2e32
Reviewed-on: https://dart-review.googlesource.com/11180
Reviewed-by: Siva Annamalai <asiva@google.com>
as this API has been deprecated and dartium was the last user.
2. Some unit tests are using some of these API entrypoints, so moved them
over to a test file which will be linked into run_vm_tests
Change-Id: I3343b23d082400da3c803cf81ea80dfaa5e426cf
Reviewed-on: https://dart-review.googlesource.com/7942
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
In Debug mode we have assertions checking that we don't attempt OSR when
FLAG_use_osr is disabled - however app-jit snapshots are compiled with OSR
enabled and still contain countining and OSR attempting code, which causes
assertions to fail.
Refactor how getters for isolate flags are defined, consolidate all flags into
a single list.
Update test expectations and switch -c dartk configuration to use app-jit snapshot.
BUG=
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2728163002 .
This should help least-upper-bound computations to not think of EfficientLength
as completely separate from Iterable even though they are always used together.
It doesn't solve all problems with the least-upper-bound computation,
but at least some of the more often occuring ones.
R=floitsch@google.com
Review URL: https://codereview.chromium.org/2467113003 .
fields in a thread (i.e fields that are not Dart VM related)
- Split the Thread structure to be a pure Dart per thread structure and add
a pointer to os_thread which points to the OSThread structure
- Change Schedule/UnSchedule to set the Dart Thread structure as the TLS of
the thread when it is inside the Dart world and reset the TLS back to the
OSThread strcuture when is exits the Dart World.
- Moved the stack_base and few stack size related functions to OSThread from Isolate
R=johnmccutchan@google.com, zra@google.com
Review URL: https://codereview.chromium.org/1439483003 .
. Disables isolate spawning during Dart_Cleanup.
. Adds a static call Isolate::KillAllIsolates, which sends the
OOB Kill message to all isolates when called from
Dart_Cleanup.
. Modifies thread pool shutdown to block until all threads have
exited.
. Fixes tests.
BUG=
R=turnidge@google.com
Review URL: https://codereview.chromium.org//1177153005 .
It's still not a good solution for detecting an Iterable with an efficient
length. It's not inherited by, e.g., a DelegatingIterable wrapper or similar
generic Iterable transformers.
Keep this as an internal optimization for quickly detecting the most common
efficient-length Iterable classes (List, Set, Queue, Map.keys/values), but
don't make it public.
A *real* solution would be adding a hasEfficientLength getter to Iterable, or
adding an efficientLength getter that may return null if it's not efficient.
This would something that a wrapper can attach to.
R=sgjesse@google.com
Review URL: https://codereview.chromium.org//1154263003
Ryan Macnak