When VirtualMemory object for the whole compressed pointers heap
region is destroyed in VirtualMemory::~VirtualMemory(), it tests
if the reservation address belongs to a compressed heap via
VirtualMemoryCompressedHeap::Contains(reserved_.pointer())
If the heap region happens to be reserved at the 4GB aligned address
by the O/S, then reservation address would match base address of
the compressed pointers heap, and this check would pass and
the whole reserved heap region would be passed to
VirtualMemoryCompressedHeap::Free.
However, the reservation size of the whole heap region is
(8GB - 1 page) which is not aligned to kCompressedPageSize (512K).
This would trigger assertion
ASSERT(Utils::IsAligned(size, kCompressedPageSize));
inside VirtualMemoryCompressedHeap::Free.
The fix is to detect when the whole compressed heap region is being
destroyed and avoid calling VirtualMemoryCompressedHeap::Free
as the region reserved for the whole heap is not managed by
the compressed heap itself.
TEST=python3 tools/test.py -n vm-win-debug-x64c --repeat 10000 co19/LibTest/typed_data/Uint32List/Uint32List.view_A01_t01
Fixes https://github.com/dart-lang/sdk/issues/51170
Change-Id: Icdf02eb0e2e3f39e435cba76fa647726bb383928
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352962
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Liam Appelbe <liama@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
We are no longer using Dart VM in a setting where this
matters as a security measure and it just complicates
portability for no benefit.
There is an indication that it is causing problems when
running Linux build of Dart VM under Docker on Mac OS X.
Fixes https://github.com/dart-lang/sdk/issues/54446
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-fuchsia-release-arm64-try,vm-fuchsia-release-x64-try
Change-Id: I11bdaa8faebaca1df6fd59097049bdaea9cb8e12
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/344581
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Some cleanups factored out of a larger CL (which refactors enter/exit of threads):
* remove unused `#include "vm/thread_registry.h"`
* remove unused/unnecessary fields from [Thread] object
* rename IsMutator() -> IsDartMutator()
* make tests using setjmp() drain the sticky error
=> to ensure there's no sticky error on isolate shutdown
TEST=ci
Change-Id: I53935e8bd0628ab3768627d6d5e01c3f0e3a57ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296582
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This region is mostly unused after loading, but it may be accessed again if
- Isolate.spawn is invoke with isolate groups disabled
- A secondary snapshot produced by splitting is loaded
- An external typed data in the snapshot is accessed (usually a kernel file)
- Likely other cases
Even if these cases did not exist, the region is often part of a shared library and so unable to be released independently.
madvise(DONT_NEED) on this region will cause the OS to release the memory in this region but keep the address space reservation and mapping. If it is touched again, it will be brought back in from the file. If it is not backed by a file, such as malloc memory, it will be brought back in as zeros and the program will likely fail.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/44019
Bug: https://github.com/flutter/flutter/issues/92120
Change-Id: I315a049b0f7d440e181d0a5e87fa6770a2fd4f79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216580
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Don't allocate zones, timeline events or profile samples in the compressible region, since these allocations don't yeild compressed pointers and are competing for a limited resource.
TEST=ci
Bug: b/196510517
Change-Id: I4fc2f0d67060f927fa10d241b15b1cae3b73d919
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212400
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
iOS appears not to allow any single virtual memory allocation to exceed ~700MB.
iOS appears to limit the total amount of allocated virtual memory to amount of physical memory available, even virtual memory that is reserved by not committed.
So instead of trying to allocate the full 4GB region for compressed pointer, allocate the largest power-of-two that succeeds, and speculate that further allocations to into the same 4GB region.
TEST=none
Change-Id: Ib45f7ece59e1adb96d175ae861b984c0c6737549
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210640
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This relands https://dart-review.googlesource.com/c/sdk/+/205633
but without renaming TARGET_OS_IPHONE to DART_TARGET_OS_IPHONE.
It also changes uses of TARGET_OS_IOS to
DART_TARGET_OS_MACOS_IOS to be consistent with the rest of the
VM.
TargetConditionals.h for XCode 13 defines several
TARGET_OS_* preprocessor symbols that confuse the
Dart build. There is probably a more targeted fix
for this, but renaming the symbols that Dart uses
will also prevent this problem if more symbols
are added to the platform headers in the future.
See: https://github.com/dart-lang/sdk/issues/46499
TEST=It builds.
Change-Id: Ie775c19dd23cfdf5f65e5ebc6ee4ec3a561676fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205860
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
TargetConditionals.h for XCode 13 defines several
TARGET_OS_* preprocessor symbols that confuse the
Dart build. There is probably a more targeted fix
for this, but renaming the symbols that Dart uses
will also prevent this problem if more symbols
are added to the platform headers in the future.
See: https://github.com/dart-lang/sdk/issues/46499
TEST=It builds.
Change-Id: I3b33a03b4a9a14b76d55fe12f8cdefec4b3c3664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205633
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
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>
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>
Fixes#27505
This relands fc775b3e9b with a fix to
VirtualMemory::~VirtualMemory: on Windows the only way to release
virtual address mapping is to invoke VirtualFree(..., MEM_RELEASE) with the
original base pointer returned by VirtualAlloc - that is why we need to call
VirtualFree is size of the reservation is 0: the whole reservation might have
been decommitted by VirtualFree(MEM_DECOMMIT) but it is still present.
Change-Id: I7d1d444693c523b327d44266d5fe70f7a5d8f803
Reviewed-on: https://dart-review.googlesource.com/52642
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@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 .
Ryan Macnak