These GCs usually did not free very much memory but did consume a lot of CPU. They would on low-powered, low-memory devices often take ~1s, during which time the OS might decide the OOM signal wasn't working and kill us before the compaction can complete and free pages. Instead, only release pooled memory.
Also use more appropriate GCReasons in calls of CollectMost/AllGarbage.
TEST=ci
Bug: b/216333343
Change-Id: Ia56b9ca409410f17d40508c69fb1bc9df0ce4028
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235300
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This reverts commit b5922e6db4.
Reason for revert: vm/cc/AllocateZone fails on Mac
Original change's description:
> [vm] Streamline Zones.
>
> - Don't put a HANDLESCOPE right after a StackZone, as there's no state worth restoring
> - Remove remaining zone bookkeeping dead since e3a9d70591.
> - Remove unnecessary resetting of handle blocks before zone deletion.
> - Shrink initial chunk size to make Zone's overall size fit in a faster malloc size class.
>
> TEST=ci
> Change-Id: I920e12f5af93aa71fb876435764c60df485215f9
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212261
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Commit-Queue: Ryan Macnak <rmacnak@google.com>
TBR=rmacnak@google.com,asiva@google.com
Change-Id: Id23dcebb781791616e48e54d2dcd7e58159178bc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215943
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
- Don't put a HANDLESCOPE right after a StackZone, as there's no state worth restoring
- Remove remaining zone bookkeeping dead since e3a9d70591.
- Remove unnecessary resetting of handle blocks before zone deletion.
- Shrink initial chunk size to make Zone's overall size fit in a faster malloc size class.
TEST=ci
Change-Id: I920e12f5af93aa71fb876435764c60df485215f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212261
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@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>
HashTable<..., GrowableArrayStorageTraits> passes the zone to placement-new of GrowableArrayStorageTraits::Array. Because this class did not extend ZoneAllocated, the default placement-new interpreted the zone as the allocated address and clobbered the beginning of the zone.
TEST=build
Change-Id: I95805e00b3012f5282f11cfb6da1567f00d56c46
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208982
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
tcmalloc and jemalloc have both been observed to hold onto lots of free'd zone segments (jemalloc to the point of causing OOM), so instead of using malloc to allocate segments, we allocate directly from mmap/zx_vmo_create/VirtualAlloc, and cache a small number of the normal sized segments.
flutter doctor at exit ("idle")
Process::MaxRSS() 261009408 -> 258756608 (-0.86%)
Process::CurrentRSS() 252932096 -> 205881344 (-18.6%)
Bug: https://github.com/dart-lang/sdk/issues/38820
Change-Id: I319069678b9d44383a9921ec03a963517991dd11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121264
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
- Introduce a slimmed down version of thread.h, which just depends on the
Zone and StackResource.
- Introduce a layering check that would prevent the coupling in the future.
This is the first step towards decoupling compiler from runtime.
There are multiple reasons to introduce the decoupling but the main
reason currently is to introduce a controlled surface through which
compiler reaches into runtime to catch any places where runtime word size
might influence the compiler and then enable building compiler that
targets 32-bit runtime but is embedded into a 64-bit runtime.
Issue https://github.com/dart-lang/sdk/issues/31709
Change-Id: Id63ebbaddca55dd097298e51c90d957a73fa476e
Reviewed-on: https://dart-review.googlesource.com/c/87182
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This is a fixed version of c84f30741c90d040254767ff769a40d2cba3fb1a that
resolves issues with comparing uint and intptr_t.
Original Commit Message:
Added tracking of memory usage inside of threads. In addition, the max memory usage is kept track of using a high watermark for both the threads and the isolates. Isolate high watermark information is updated when a thread exits the isolate. The isolate high watermark consists of the sum of all thread high watermarks (including the high watermark of the exiting thread). High watermark information for both threads and isolates is now visible in the isolate view in the Observatory.
BUG=
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2610253002 .
Added tracking of memory usage inside of threads. In addition, the max memory usage is kept track of using a high watermark for both the threads and the isolates. Isolate high watermark information is updated when a thread exits the isolate. The isolate high watermark consists of the sum of all thread high watermarks (including the high watermark of the exiting thread). High watermark information for both threads and isolates is now visible in the isolate view in the Observatory.
BUG=
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2609253002 .
Added tracking of memory usage inside of threads. In addition, the max memory usage is kept track of using a high watermark for both the threads and the isolates. Isolate high watermark information is updated when a thread exits the isolate. The isolate high watermark consists of the sum of all thread high watermarks (including the high watermark of the exiting thread). High watermark information for both threads and isolates is now visible in the isolate view in the Observatory.
BUG=
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2608463002 .
This unburdens users of StackZone from needing to include handles_impl.h. A new use of StackZone was recently added to heap.cc without a include of handles_impl.h, and this caused link-time errors on some versions of gcc.
R=asiva@google.com
Review URL: https://codereview.chromium.org/2362573002 .
Adds Dart_DefaultCanonicalizeUrl() to the dart embedding api.
Motivation:
As we try to get source reloading working for the standalone embedder, things get simpler if an isolate doesn't run Dart code while it is loading Dart code. We intend to solve this by moving the embedder tag handler calls to the service isolate. But making a blocking rpc into the service isolate whenever a url needs to be canonicalized during parsing seems like it would slow things down and make things complicated. By moving canonicalization into C++, we avoid this.
R=ahe@google.com, fschneider@google.com, johnmccutchan@google.com
Review URL: https://codereview.chromium.org/2011543002 .
- Add PRODUCT define and build mode to gyp configurations.
- Add product mode to test harness.
- Start to unify list of flags.
- Allow flags to be constant for particular build configurations.
R=fschneider@google.com
Review URL: https://codereview.chromium.org/1663863002 .
- This CL only adds support for synchronous blocks of time. A follow up CL will add asynchronous blocks of time.
- Reports true thread id to tracing system. This is an improvement over Mojo's tracing helper.
- Dart events are included in individual isolate traces and global traces obtained via the embedders API.
- Dart events are included in the write to disk path (--timeline_dir).
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1377663002 .
I was able to convert 49 SNPrint(NULL, 0, ...) patterns to use the
macro. I had to use a #define for the format string 5 times due to
uses that didn't fit the macro.
2 occurences of SNPrint(NULL, 0, ...) had >=2 possibilities for the
format string based on runtime values, and I didn't try to convert
them.
Fixed ~10 format strings.
BUG=
R=iposva@google.com
Review URL: https://codereview.chromium.org//1331623002 .
- Add TimelineEventBlockIterator - iterate over TimelineEventBlocks.
- Add TimelineAnalysisThread - All events for a specific thread.
- Add TimelineAnalysis - Utility for analyzing timeline events.
- Add unit test for TimelineAnalysis thread discovery and block sorting.
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1284263002 .
This is needed to enable parallel marking/sweeping (and in the future, compilation) tasks to have their own zone allocations and to safely call code that relies on various scoped constructs (stack resources).
The next step is to migrate the scopes like NoSafepointScope, NoHandleScope, etc. from isolate- to thread-based interfaces.
NOTE: This is a copy of issue 1204303003.
BUG=
Review URL: https://codereview.chromium.org//1226403003 .
where possible without having to invoke Isolate::Current()
- Modified lookupWrapper to accept DartDOMData as a parameter so that the return to Dart functions
won't invoke Isolate::Current()
Some Dromaeo numbers before this change:
CONSOLE MESSAGE: RESULT: Dromaeo-drt dartium-dart dom-attr getAttribute runs-per-second 1162.2
CONSOLE MESSAGE: RESULT: Dromaeo-drt dartium-dart dom-attr element_property_access runs-per-second 1255.6
after this change:
CONSOLE MESSAGE: RESULT: Dromaeo-drt dartium-dart dom-attr getAttribute runs-per-second 1237.6
CONSOLE MESSAGE: RESULT: Dromaeo-drt dartium-dart dom-attr element_property_access runs-per-second 1385.4
R=rmacnak@google.com, vsm@google.com
Review URL: https://codereview.chromium.org//24376005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27789 260f80e4-7a28-3924-810f-c04153c831b5