This reverts commit 0203243381.
Reason for revert: breaking several bots
Original change's description:
> [vm] Prevent access to non-annotated members through native API.
>
> We will issue warnings and throw an API error when the native API is used to access members which were not appropriately
> annotated as entry-points, if the flag "--verify-entry-points" is passed.
>
> Also, fixes Class::Invoke against fields (isn't allowed through native API but
> could be allowed with mirrors, and is inconsistent with Library::Invoke behavior).
>
> I've checked locally that this would have caught the bug in
> "Wrap the user entrypoint function in a zone with native exception callback. (#7512)".
>
> Change-Id: I617c71e1965457c956c97761359765bb9bb18c1c
> Cq-Include-Trybots: luci.dart.try:vm-kernel-optcounter-threshold-linux-release-x64-try, vm-kernel-precomp-linux-debug-x64-try, vm-kernel-precomp-linux-release-simarm-try, vm-kernel-precomp-linux-release-simarm64-try, vm-kernel-precomp-linux-release-x64-try, vm-kernel-precomp-mac-release-simarm64-try, vm-kernel-precomp-win-release-x64-try
> Reviewed-on: https://dart-review.googlesource.com/c/90060
> Commit-Queue: Samir Jindel <sjindel@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
TBR=alexmarkov@google.com,sjindel@google.com
Change-Id: I554b389780e4ba652183c044b040b0c524beb5c2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.dart.try:vm-kernel-optcounter-threshold-linux-release-x64-try, vm-kernel-precomp-linux-debug-x64-try, vm-kernel-precomp-linux-release-simarm-try, vm-kernel-precomp-linux-release-simarm64-try, vm-kernel-precomp-linux-release-x64-try, vm-kernel-precomp-mac-release-simarm64-try, vm-kernel-precomp-win-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/90841
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
We will issue warnings and throw an API error when the native API is used to access members which were not appropriately
annotated as entry-points, if the flag "--verify-entry-points" is passed.
Also, fixes Class::Invoke against fields (isn't allowed through native API but
could be allowed with mirrors, and is inconsistent with Library::Invoke behavior).
I've checked locally that this would have caught the bug in
"Wrap the user entrypoint function in a zone with native exception callback. (#7512)".
Change-Id: I617c71e1965457c956c97761359765bb9bb18c1c
Cq-Include-Trybots: luci.dart.try:vm-kernel-optcounter-threshold-linux-release-x64-try, vm-kernel-precomp-linux-debug-x64-try, vm-kernel-precomp-linux-release-simarm-try, vm-kernel-precomp-linux-release-simarm64-try, vm-kernel-precomp-linux-release-x64-try, vm-kernel-precomp-mac-release-simarm64-try, vm-kernel-precomp-win-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/90060
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This reverts commit b10f179608.
Reason for revert: failed service/* tests
Original change's description:
> [vm] Cleanup Dart_Get/Set/HasStickyError API and use isolate's sticky error only as a backup for thread's sticky error
>
> Both thread and isolate have sticky error fields. Dart API was using
> isolate's sticky error, while Dart code was using thread's sticky error.
> There was a one-way move of a thread's sticky error into isolate
> when thread was unscheduled.
>
> This causes a problem as error in the isolate may go unnoticed and
> repeated unscheduling/re-scheduling might end up overwriting the error
> in the isolate (which triggers the assertion).
>
> To solve this problem, this CL:
> * Cleans up Dart API which manipulates isolate's sticky error, so
> isolate's sticky error is never set directly.
> * When sceduling an isolate to a thread, sticky error is moved back from
> isolate (if any).
>
> With this changes, thread's sticky error is always used if thread is running,
> and isolate's sticky error is only used to hold sticky error while
> isolate has no thread.
>
> Fixes https://github.com/dart-lang/sdk/issues/35590
>
> Change-Id: I99b128cac363ca2df75f6e64c083b1ec36c866ce
> Reviewed-on: https://dart-review.googlesource.com/c/89442
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
TBR=rmacnak@google.com,alexmarkov@google.com,zra@google.com,asiva@google.com
Change-Id: I15874575b6b8ddca618741c59c21d4e692c4dcab
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/90127
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Both thread and isolate have sticky error fields. Dart API was using
isolate's sticky error, while Dart code was using thread's sticky error.
There was a one-way move of a thread's sticky error into isolate
when thread was unscheduled.
This causes a problem as error in the isolate may go unnoticed and
repeated unscheduling/re-scheduling might end up overwriting the error
in the isolate (which triggers the assertion).
To solve this problem, this CL:
* Cleans up Dart API which manipulates isolate's sticky error, so
isolate's sticky error is never set directly.
* When sceduling an isolate to a thread, sticky error is moved back from
isolate (if any).
With this changes, thread's sticky error is always used if thread is running,
and isolate's sticky error is only used to hold sticky error while
isolate has no thread.
Fixes https://github.com/dart-lang/sdk/issues/35590
Change-Id: I99b128cac363ca2df75f6e64c083b1ec36c866ce
Reviewed-on: https://dart-review.googlesource.com/c/89442
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
In Dart2, the type relation "is more specific than" is no different than "is
subtype of". Since Dart1 is not supported anymore, type checking in the runtime
can be simplified and cleaned up.
Change-Id: I8e95b9e47146315c9a6f6c29b732ecbeb4e9ae97
Reviewed-on: https://dart-review.googlesource.com/c/88221
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This API does not work in CFE world because CFE does not see classes
created dynamically.
Fix UseDartAPI benchmark that was using this API and was broken as a result.
Change-Id: If691373d32ac5b8ff23e350ce2eb5ed44045b1f1
Reviewed-on: https://dart-review.googlesource.com/c/87183
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Auto-Submit: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
In Dart2, mixin application classes are generated by kernel and type resolution
is performed by kernel. In Dart1, using the VM parser, these tasks were done
during class and type finalization.
Change-Id: I927b1446d906ffd76ed9591c96e0d974df09f3bf
Reviewed-on: https://dart-review.googlesource.com/c/87025
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
In Dart2, type bounds checking is either performed by the common front-end or
by explicitly generated code, but not by type finalization or runtime anymore,
as it was done in Dart1.
Consequently, the class BoundedType is not needed anymore, and malbounded or
malformed types are not seen by the runtime either.
Change-Id: I5d6e4c68d153d6730fa7ff7f6d9dcfa611299c16
Reviewed-on: https://dart-review.googlesource.com/c/86687
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Samir Jindel <sjindel@google.com>
Currently the @pramga('vm:exact-result-type') annotation only works if
the function is a recognized method. This change changes that to make
the VM just look if a function has the annotation (no matter if it's
also in the list of recognized methods or not).
Furthermore this CL lets the type propgagator use
@pragma('vm:exact-result-type') annotations to narrow the [CompileType]
set on [LoadFieldInstr]s.
Since the @pragma is a general feature, this CL moves the
`Function::FindPragma()` to `Library::FindPragma` (which is where any
other metadata lookup happens). We also let the `FindPragma` accept any
of Class/Function/Field objects.
Furthermore the `FindPragma()` function is fixed to handle the case
when the evaluation of the metadata results in an error.
In this case we simply claim to not have found a pragma annotation.
Issue https://github.com/dart-lang/sdk/issues/31954
Change-Id: If03f566e334cd53549985823ee3dd6b5e9672969
Reviewed-on: https://dart-review.googlesource.com/c/85163
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This reverts commit 2de63ac01c.
Reason for revert: This triggers shutdown deadlocks for some reason:
#0 0xf7782cd9 __kernel_vsyscall
#1 0xf7753d0b pthread_cond_wait@@GLIBC_2.3.2
#2 0x0108a515 dart::Monitor::WaitMicros(long long)
#3 0x0108a467 dart::Monitor::Wait(long long)
#4 0x00fe9048 dart::KernelIsolate::Shutdown()
#5 0x00f99ae4 dart::Dart::Cleanup()
#6 0x01278fce Dart_Cleanup
#7 0x00dd347e dart::bin::main(int, char**)
#8 0x00dd3d64 main
#9 0xf745caf3 __libc_start_main
#10 0x00dd2021 _start
TID 30443:
#0 0xf7782cd9 __kernel_vsyscall
#1 0xf7531ee6 epoll_wait
#2 0x00ddab61 dart::bin::EventHandlerImplementation::Poll(unsigned int)
#3 0x00dfb2d4 dart::bin::ThreadStart(void*)
#4 0xf774ff72 start_thread
#5 0xf753143e __clone
TID 30444:
#0 0xf7782cd9 __kernel_vsyscall
#1 0xf7753d0b pthread_cond_wait@@GLIBC_2.3.2
#2 0x0108a515 dart::Monitor::WaitMicros(long long)
#3 0x0108a467 dart::Monitor::Wait(long long)
#4 0x012484d8 dart::BackgroundCompiler::Run()
#5 0x01248a37 dart::BackgroundCompilerTask::Run()
#6 0x0112203a dart::ThreadPool::Worker::Loop()
#7 0x01121efe dart::ThreadPool::Worker::Main(unsigned int)
#8 0x01089e73 dart::ThreadStart(void*)
#9 0xf774ff72 start_thread
#10 0xf753143e __clone
Original change's description:
> [VM] Add @pragma annotations on Field, make @pragma annotations work generally
>
> Currently the @pramga('vm:exact-result-type') annotation only works if
> the function is a recognized method. This change changes that to make
> the VM just look if a function has the annotation (no matter if it's
> also in the list of recognized methods or not).
>
> Furthermore this CL adds a "has_pragma" bit to [Field] objects, similar
> to how we have it on [Function]/[Class]es. This allows annotating
> fields with types, as we do with function return types.
>
> Furthermore this CL lets the type propgagator use
> @pragma('vm:exact-result-type') annotations to narrow the [CompileType]
> set on [LoadFieldInstr]s.
>
> Since the @pragma is a general feature, this CL moves the
> `Function::FindPragma()` to `Library::FindPragma` (which is where any
> other metadata lookup happens). We also let the `FindPragma` accept any
> of Class/Function/Field objects.
>
> Furthermore this CL adds a bailout if we try to evaluate metadata in
> the background compiler, since the background compiler is not allowed
> to execute generated code. The bailout should trigger a re-compilation
> on the mutator thread.
>
> Furthermore the `FindPragma()` function is fixed to handle the case
> when the evaluation of the metadata results in e.g. a language error.
> In this case we simply claim to not have found a pragma annotation.
>
> Issue https://github.com/dart-lang/sdk/issues/31954
>
> Change-Id: I0900a80d5ae0f3e8d09baf13cba1b20dd974df31
> Reviewed-on: https://dart-review.googlesource.com/c/84037
> Commit-Queue: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,kustermann@google.com,alexmarkov@google.com,sjindel@google.com
Change-Id: Ic0d22d32b0eea3a76ec245cabab0006f97ca1b05
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/84622
Reviewed-by: Martin Kustermann <kustermann@google.com>
Currently the @pramga('vm:exact-result-type') annotation only works if
the function is a recognized method. This change changes that to make
the VM just look if a function has the annotation (no matter if it's
also in the list of recognized methods or not).
Furthermore this CL adds a "has_pragma" bit to [Field] objects, similar
to how we have it on [Function]/[Class]es. This allows annotating
fields with types, as we do with function return types.
Furthermore this CL lets the type propgagator use
@pragma('vm:exact-result-type') annotations to narrow the [CompileType]
set on [LoadFieldInstr]s.
Since the @pragma is a general feature, this CL moves the
`Function::FindPragma()` to `Library::FindPragma` (which is where any
other metadata lookup happens). We also let the `FindPragma` accept any
of Class/Function/Field objects.
Furthermore this CL adds a bailout if we try to evaluate metadata in
the background compiler, since the background compiler is not allowed
to execute generated code. The bailout should trigger a re-compilation
on the mutator thread.
Furthermore the `FindPragma()` function is fixed to handle the case
when the evaluation of the metadata results in e.g. a language error.
In this case we simply claim to not have found a pragma annotation.
Issue https://github.com/dart-lang/sdk/issues/31954
Change-Id: I0900a80d5ae0f3e8d09baf13cba1b20dd974df31
Reviewed-on: https://dart-review.googlesource.com/c/84037
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This fixes an issue where service RPCs are not answered by the
vm-service.
Currently new isolates are visible via the service protocol immediately
after creation. This means a vm-service client can start doing service
RPCs to a particular isolate. If the embedder has not-yet installed a message
handler the OOB messages will be queued up.
Once the embedder installs an isolate message notify handler, that
handler needs to be invoked if there are pending messages.
Change-Id: Ie75878daf55a3b380e2b2ec7930e15b002f3f520
Reviewed-on: https://dart-review.googlesource.com/c/83680
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Clement Skau <cskau@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This makes the ImageWriter remember at which offsets it wrote
RawInstructions.
This is preparation work for allowing the ImageWriter write the
instructions in a specific order (currently instructions are written
"on-demand" when the object serializer encounters references to them)
Issue https://github.com/dart-lang/sdk/issues/33274
Change-Id: Ie50cf8a600dd4e9ce0413fe4189d4f2211f0325e
Reviewed-on: https://dart-review.googlesource.com/c/82065
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@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 change allows devs embedding the VM in e.g. a server to e.g. export VM metrics as part of their server health metrics.
Change-Id: I7a86a3ad98b900d30d9b7f5d19fa77f1705610c6
Reviewed-on: https://dart-review.googlesource.com/c/74723
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Clement Skau <cskau@google.com>
Script snapshots no longer exist, so there is no need to distinguish them from kernel files via Dart_IsSnapshot. All snapshots are Dart 2 snapshots, so there is no need to distinguish them via Dart_IsDart2Snapshot.
Change-Id: I996ec4b4e63da6dbebbe05515392f067aa13f578
Reviewed-on: https://dart-review.googlesource.com/c/77942
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This shifts the bump allocation scope up to the Dart_ API
implementation so that an IsolateReloadContext won't try
to enter one. It also disables reload during the scope.
Change-Id: I3ca52f35c3a43f58e447e88b4fa91a84d3eacdd9
Reviewed-on: https://dart-review.googlesource.com/77522
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
- use core snapshot when initializing an isolate (CorelibIsolateStartup benchmark moves from 39s to 2s)
- remove use_dart_frontend flag from the isolate specific flags
- the script snapshot API functions now return an error
Change-Id: Ia562e007fdbfd1d3ebd8e1a0c8feee238bada00b
Reviewed-on: https://dart-review.googlesource.com/76709
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
- Add generation of AppJIT snapshots (from a trace rather than a training run).
- Add generation of AppJIT snapshots under the constraint of not generating a new instructions segment.
- Remove generation of script snapshots (no longer used by Flutter).
Change-Id: I2a7cb4b7cd681fae5d33bc896107b3ea903f35d1
Reviewed-on: https://dart-review.googlesource.com/75390
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Stanislav Baranov <sbaranov@google.com>
Régis Crelier