This CL:
* Moves [Heap]/[SharedClassTable] from [Isolate] to [IsolateGroup], which
will make all isolates in the group use the same heap. The GC will use
the shared class table for object size information.
* Adds support for entering/leaving an isolate group as a helper thread
(e.g. via [Thread::EnterIsolateGroupAsHelper]). The current active
isolate group can be accessed via TLS `IsolateGroup::Current()` or
`Thread::isolate_group_`. When entering as a helper thread there will be
no current isolate.
* Changes the GC to use the above mechanism and ensures GC works without
a currently active isolate. The GC will use information purely available via
[IsolateGroup]. The GC will iterate all isolates within an isolate
group e.g. for scanning roots.
* Makes spawning of new isolates start in their own isolate group.
Once the isolate is fully functional it's heap will be merged into
the original isolate group
* Moves ApiState, containing persistent and weak persistent handles,
from [Isolate] to [IsolateGroup], plus adds appropriate locking.
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: Ia8e1d8aa78750e8400864200f4825395a182c004
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/126646
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Also switch some CQ bots using blobs to ELF. Once all embedders have migrated, we will remove blobs
support entirely.
Change-Id: Ie5e8c1187ad6c1af362b5715daafd3641bc8cc0e
Cq-Include-Trybots:luci.dart.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-bare-linux-release-simarm-try,vm-kernel-precomp-mac-debug-simarm_x64-try,vm-kernel-precomp-mac-release-simarm64-try,vm-kernel-precomp-win-release-x64-try,vm-kernel-precomp-android-release-arm-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116620
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Currently the initial mapping for the executable mapping is read-only.
Once the first instruction object was allocated into an OS page we would
map that page as RX. Any further allocations of instructions objects
into the same page would just end up mapping it to RX again (even though
it is already that way).
To avoid those additional protection calls we can map the executable
mapping RX from the beginning (it will be filled with zeros after
allocation).
Issue https://github.com/dart-lang/sdk/issues/37739
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: Ib83f0be8ea8dacc86646c0a3c0335f4886516caa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/112244
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Instead of implementing separate aligned and unaligned memory
allocation primitives for each OS, just change the unaligned allocator
into a wrapper around the aligned primitive.
While here, we can optimize the AllocateAligned logic slightly: if we
want an N-page-aligned allocation, we only need to increase the
allocation size by N-1 pages instead of N.
Notably, this means 1-page-aligned allocations don't require any extra
alignment pages, so the new logic behaves identically as before on
Android, Fuchsia, Linux, and macOS.
On Windows, it behaves slightly differently only in that unaligned
requests used to be handled as a single VirtualAlloc call with
MEM_RESERVE | MEM_COMMIT, but now they're handled as two separate
calls (reserve *then* commit). Naively, I don't expect this matters in
practice, but if it does, we can always add a fast path for
alignment==page_size_ without affecting the OS-independent API.
Change-Id: I42b2cf5dfc6e137546d8acfb6cc8939a01687948
Reviewed-on: https://dart-review.googlesource.com/c/91081
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
In W^X mode (i.e., FLAG_write_protect_code), the Dart VM allocates
code memory with is_executable==false and then later makes it
executable with Protect(kReadExecute). However, on Fuchsia, this will
require a VMO with ZX_RIGHT_EXECUTE (which soon will not be the
default).
This CL takes the approach of always adding ZX_RIGHT_EXECUTE when in
W^X mode. This is suboptimal because it means all VM allocated memory
can be changed to executable, but currently the OS-independent
VirtualMemory::Allocate API doesn't provide us a way to identify
memory that doesn't need to be executable now but will in the future.
(Note that ZX_RIGHT_EXECUTE only *allows* mapping the memory as
executable; the memory is still initially mapped by
VirtualMemory::Allocate as non-executable.)
Extending the VirtualMemory::Allocate API is tracked in FL-172.
Bug: SEC-42
Change-Id: I20555c546c5ab1798c4c36b7394f6221d3993c9e
Reviewed-on: https://dart-review.googlesource.com/c/90882
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
In the future, newly created VMOs on Fuchsia will not be mappable as
executable by default. In preparation for that, start using
zx_vmo_replace_as_executable to mark Fuchsia's VMOs as executable as
needed.
SEC-42
TEST=CQ
Change-Id: I9df86bbb33b02042260727d64e74b7146eb1d1a6
Reviewed-on: https://dart-review.googlesource.com/76304
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
These were left out of order by the mechanical changes that were part
of Fuchsia's Magenta->Zircon rename.
Change-Id: I41c81eb889c6076ffe82102018721e5abc74e7ac
Reviewed-on: https://dart-review.googlesource.com/6165
Reviewed-by: Zach Anderson <zra@google.com>
This CL assigns names to vmos formatted as "isolate space type" where
isolate is the name of the isolate, space is "oldspace" or "newspace",
and type is "code" or "data".
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2929203002 .
Like HOST_ARCH_*, HOST_OS_* describes the OS the VM is running on, which may be different from the OS the VM is generating code for during AOT compilation.
Currently we conflate the two when emitting AOT as assembly, and we get away with it because Flutter only uses assembly for targeting iOS and one can only target iOS from a Mac, but we expect to use assembly for Android as well so native tools can unwind Dart frames.
R=zra@google.com
Review-Url: https://codereview.chromium.org/2750843003 .
Liam Appelbe