- Dump per thread timing information when an isolate shuts down.
DeltaBlue(RunTime): 3654.6660583941607 us.
Timing for isolate DeltaBlue.dart$main-109078706 (from 2 threads)
Thread 0 (f68f8b40):
HandleMessage : 2163.455 ms total on stack; 940.038 ms total executing; 2114.231 ms max on stack; 930.085 ms max executing.
CompileFunction : 81.020 ms total on stack; 81.020 ms total executing; 7.745 ms max on stack; 7.745 ms max executing.
CompileOptimizedFunction : 109.817 ms total on stack; 109.817 ms total executing; 10.443 ms max on stack; 10.443 ms max executing.
CollectNewGeneration : 1032.580 ms total on stack; 1032.580 ms total executing; 7.677 ms max on stack; 7.677 ms max executing.
Thread 1 (f7419700):
InitializeIsolate : 12.121 ms total on stack; 0.418 ms total executing; 12.121 ms max on stack; 0.418 ms max executing.
ObjectStore::Init : 0.002 ms total on stack; 0.002 ms total executing; 0.002 ms max on stack; 0.002 ms max executing.
Object::Init : 0.268 ms total on stack; 0.268 ms total executing; 0.268 ms max on stack; 0.268 ms max executing.
IsolateSnapshotReader : 11.433 ms total on stack; 11.433 ms total executing; 11.433 ms max on stack; 11.433 ms max executing.
CompileFunction : 111.849 ms total on stack; 111.849 ms total executing; 10.798 ms max on stack; 10.704 ms max executing.
Totals:
HandleMessage : 2163.455 ms total on stack; 940.038 ms total executing; 2114.231 ms max on stack; 930.085 ms max executing.
CompileFunction : 192.869 ms total on stack; 192.869 ms total executing; 10.798 ms max on stack; 10.704 ms max executing.
CompileOptimizedFunction : 109.817 ms total on stack; 109.817 ms total executing; 10.443 ms max on stack; 10.443 ms max executing.
CollectNewGeneration : 1032.580 ms total on stack; 1032.580 ms total executing; 7.677 ms max on stack; 7.677 ms max executing.
InitializeIsolate : 12.121 ms total on stack; 0.418 ms total executing; 12.121 ms max on stack; 0.418 ms max executing.
ObjectStore::Init : 0.002 ms total on stack; 0.002 ms total executing; 0.002 ms max on stack; 0.002 ms max executing.
Object::Init : 0.268 ms total on stack; 0.268 ms total executing; 0.268 ms max on stack; 0.268 ms max executing.
IsolateSnapshotReader : 11.433 ms total on stack; 11.433 ms total executing; 11.433 ms max on stack; 11.433 ms max executing.
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1296353002 .
This enables thread-safe logging (e.g., ISL_Print, which will soon be renamed to THR_Print), which is needed for concurrent
marking (DetachCode) and compilation.
Make finalization of GC marking tasks concurrent, now that it's thread-safe.
BUG=
R=iposva@google.com
Review URL: https://codereview.chromium.org//1314673008 .
deprecated isolate based API.)
- Update all code impacted by this change. E.g. DARTSCOPE
- TEST_CASE now passes the current thread as a parameter to the unit test.
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org//1310463005 .
- Display paused time as tooltip over "paused" word.
- Send a timestamp with every ServiceEvent.
- Unit tests verifying that paused on start, exit, and breakpoint timestamps are stable.
- Remember the pause time in DebuggerEvent.
- Remember the pause time in MessageHandler.
- Updated service protocol documentation.
R=turnidge@google.com
Review URL: https://codereview.chromium.org//1311503004 .
- InterruptableThreadState is gone.
- Moved InterruptableThreadState fields directly into Thread.
- Iterate over all threads in an isolate when profiling.
- Still only sample the mutator thread.
Fix ThreadRegistry leak
- When deleting a Thread, iterate over all isolates and remove it from the isolate's thread registry.
R=iposva@google.com
Review URL: https://codereview.chromium.org//1293253005 .
- Initialize and shutdown timeline recorder with VM.
- Allocate global blocks for timeline events without an isolate.
- Stop storing the Stream pointer inside a TimelineEvent.
- Store category name in TimelineEvent.
- Store isolate pointer in TimelineEvent.
- TimelineEventRecorder::WriteTo is full VM dump.
- Allow JSONStream to be used without an isolate.
- When a ThreadRegistry is deleted, Finish all open timeline blocks.
- PrintJSON takes a filter.
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1294023009 .
Remove potentially dangerous (but currently unused) Isolate::stack_limit() accessor.
Add method to test whether interrupts are scheduled, using relaxed memory ordering.
Document and test correct usage by adding a new unit test.
This will be used to periodically check for safepoints in C++ (which will then be equivalent to our generated code).
BUG=
R=iposva@google.com
Review URL: https://codereview.chromium.org//1277473004 .
Move the field from Isolate to Thread::state_ to allow using a single thread local key.
Profiling is still only enabled for the Dart mutator thread.
The next step is to migrate the VM tags.
BUG=
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org//1261923008 .
. 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 .
Cache a pointer to the isolate's Heap in the Thread object
and use it in generated code for allocation.
Change generated allocation code to load allocation-top and
end via THR (THR->heap.top). This is slightly slower than
embedding the address, but faster than loading it
via the Isolate (THR->isolate->heap.top)
BUG=
R=koda@google.com
Review URL: https://codereview.chromium.org//1263513002 .
Add infrastructure to enable all threads in an isolate to rendezvous at GC-safe points, and exercise it through unit tests.
* Use existing interrupt mechanism for Dart threads, but a cooperative approach for non-Dart threads (concurrent compiler, etc.): they must periodically call CheckSafepoint (may block).
* Add unit tests to exercise and verify various scenarios: organizing the rendezvous from helper/main thread, with/without Dart code executing, etc.
The next step is to use this interface in old-space allocation and garbage collection, respectively, to allow helper threads to perform allocations that potentially trigger GC (needed for concurrent compiler).
Limitations:
* A thread that is executing a long-running native function is currently not considered at a safepoint, and will delay the rendezvous until it returns to Dart or indirectly calls CheckSafepoint. In a future CL, we can use the saved stack pointer to detect and support this case, and intercept the thread if/when it re-enters Dart or the VM.
BUG=
R=iposva@google.com
Review URL: https://codereview.chromium.org//1259223005 .
This allows to make the last explicitly named stubs shared between isolates.
When sharing code stubs, we can't do patching at their entry anymore.
Therefore, I had to remove patching support of the array allocation stub.
Is this a functionality we want to keep?
The change is mostly performance-neutral because optimized code has an inlined fast
path for array allocation and only uses the stub for the slow-case.
The only isolate-specific stubs left are object allocation stubs which are
associated with their Class are per-isolate.
Since this CL removes any isolate-specific stubs from StubCode, it becomes AllStatic.
BUG=
R=koda@google.com
Review URL: https://codereview.chromium.org//1247783002 .
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 .
Address issue 21620, by sharing code to wait for concurrent sweeper to finish, and freeing the caller from this responsibility. The new public interface is Heap::Iterate*, and the old Heap::Visit* are made private, for GC use only.
(Eventually, we'll want to support iterating over the heap while concurrent GC runs, but that will have to wait until all header accesss is synchronized.)
BUG=21620
R=asiva@google.com
Review URL: https://codereview.chromium.org//1212943010 .
Keep cache of empty blocks shared among all isolates, limited in size.
Change overflow threshold check to include partially filled blocks.
Make Isolate::store_buffer_ a pointer, now that it's less frequently accessed, to keep the offsets of other fields small
BUG=
R=iposva@google.com
Review URL: https://codereview.chromium.org//1173043002.
If null is not initialized before the VM Isolate's ObjectStore, the
ObjectStore's fields are initialized to kHeapObjectTag, which causes
a crash in VM Isolate shutdown.
There is also a crash when the VM Isolate is signaled with the
shutdown event, so this CL removes adding a Debugger to the
VM Isolate, so that there is no need to shut it down, and send
the signal.
NB: This change does *not* actually enable shutdown. It just fixes
crashes that would happen if it were enabled.
BUG=
R=iposva@google.com, johnmccutchan@google.com
Review URL: https://codereview.chromium.org//1168933002.
- Each isolate has its own TimelineEventBuffer
- Each isolate has TimelineEventStreams for API, Compiler, Embedder, Isolate, and GC
- Compiler, Isolate, Embedder, and GC are being inserted into the stream
- Basic unit tests
- Dart API for injecting timeline events
- Arbitrary number of native and Dart arguments can be attached to each event
- JSON printing
- Output can be loaded by about://tracing
- Add --timeline-trace-dir flag
Short term follow up CLS:
- Service protocol requests to enable / disable tracing and retrieve a trace
- UI for Observatory
- Dart code EventStreams and Events
R=asiva@google.com
Review URL: https://codereview.chromium.org//1170503004.
- Complete revamp of isolate-specific flags.
- Associate flags with the isolate on creation.
- Dart_CreateIsolate and associate callback do take an
extra flags argument.
- Make sure to clear IC data array when clearing code.
BUG=23578
Review URL: https://codereview.chromium.org//1162033005
Add THR register that caches the current thread in generated code.
Shuffle some registers around as needed to free one up.
Note: Assembler::LoadIsolate now always loads the *current* isolate whenever the code is executed, rather than the isolate in which the code was compiled (no existing code was affected by this slight change in semantics).
Rewrite some ia32 stubs to use one less register, and for some ia32 bigint intrinsics, explicitly save THR (like CTX in the past, see r44699).
Next steps:
- pass current thread rather than isolate in NativeArguments
- ditto for exception handler jump
- migrate fields vm_tag, top_exit_frame_info, etc. to thread
R=srdjan@google.com
Review URL: https://codereview.chromium.org//1156593002
* Use real isolate in concurrent sweeper rather than shallow copy.
The only part of the isolate, other than the page being swept, used by the sweeper is the class table (via RawObject::Size), which is now safe to read concurrently (copy-on-write).
* Do not eagerly destroy a VM thread whenever it exits an isolate.
This extends the lifetime of a VM thread across entering/exiting multiple isolates. This is necessary in case an embedder callback executes during
compilation and switches/spawns isolates.
For embedder threads, since there is no API to signal "I'm done using the VM in this thread", this means we leak the (small) Thread structure.
For our own ThreadPool threads, we explicitly clean up.
BUG=23153
R=iposva@google.com
Review URL: https://codereview.chromium.org//1136143003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45810 260f80e4-7a28-3924-810f-c04153c831b5
- Add ServiceIdZone interface for getting temporary ids.
- Add RingServiceIdZone which uses the isolate's object id ring.
- Add GrowableServiceIdZone which uses a growable array.
- Unit tests for ServiceIdZones.
- JSONStream has a service id zone.
- Default service id zone is ring with eager id allocation.
- All service RPCs can include a _serviceIdZone parameter.
- Value of _serviceIdZone can be Ring.NewId or Ring.ExistingId.
- All ObjectIdRing usage in object.cc has been replaced with `jsobj.AddServiceId("id", *this);`
- Add a policy for id reuse to ObjectIdRing::GetIdForObject
- ObjectIdRing can dump its contents to JSON.
- Add _dumpRingRequests RPC which dumps the isolate's ring.
- _getCrashDump includes complete object id ring.
R=turnidge@google.com
Review URL: https://codereview.chromium.org//1132323002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45754 260f80e4-7a28-3924-810f-c04153c831b5
Since the Thread structure is currently cleared on Enter/ExitIsolate,
there is a risk that CHA is cleared if an embedder callback executes during
compilation and switches/spawns isolates. This CL eliminates that risk.
However, Isolate is still not a good long-term place for CHA,
since it doesn't fit with a concurrent compilation model. Issue 23153 tracks
the work towards a permanent solution that couples its life cycle with
compilation.
R=fschneider@google.com, iposva@google.com
Review URL: https://codereview.chromium.org//1061243003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45121 260f80e4-7a28-3924-810f-c04153c831b5
- Add the "isolate" command which allows the user to switch isolate by name or number. Supports completion.
- Add the "isolate name" command which allows the user to rename an isolate. Add the "setName" method to the service protocol to support this. Isolates now have a debugger_name() in the vm.
- The new IsolateUpdate event notifies the client when an isolate name changes.
- When an isolate is updated, update the page's isolate too, so the navbar is accurate.
- Update isolate summary to display isolate number.
- Rework how the isolate's name is computed because we were getting garbagey names in the IsolateStart event (SpawnState was not yet set).
- Make sure that the debugger doesn't subscribe to events multiple times.
- "info isolates" is now "isolate list".
- Rework reporting of vm and isolate startTime in the service protocol and in Observatory.
- Fix bug in command completion when subcommands and other completions share common prefixes.
- Rework isolate accounting in the VM object in Observatory. We now create Isolates in getFromMap rather than from IsolateStart events, per se. Rewrite the isolate updating code.
- IsolateStart and IsolateExit events are now owned by the Isolate itself, rather than the vm.
- Return the actual result in pause/resume/etc.
- Add assertion in JSONStream::PrintProperty64 that the result fits in a javascript double. Sigh.
- Stop sending GC events for the service isolate. Add assertions to guard against this happening in the future.
- Misc improvements in error reporting.
Review URL: https://codereview.chromium.org//1007863003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44718 260f80e4-7a28-3924-810f-c04153c831b5
The life cycle of Thread is still coupled with the life cycle of Isolate, but the added indirection allows the migration work to proceed, at negligible performance impact.
This is a small step towards making Thread different from Isolate and allow a many-to-one relationship. In particular, in prepares for being able to have the sweeper have some minimal separate state from the main thread (eliminating the current fake-isolate hack).
Concretely, it moves the thread-local storage key into the Thread class, but for now, keeps a "main_thread" in Isolate for quick access in native/runtime_entry.
Also moves cha_ field to Thread (the first of many fields that will move).
To summarize, this CL enables the next steps:
- moving other fields from Isolate to Thread without circular include-dependencies
- replacing sweeper's fake Isolate with a helper Thread (referencing the original Isolate)
Also add 'volatile' to local variables that clang thinks could be clobbered.
R=asiva@google.com
Review URL: https://codereview.chromium.org//1037453002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44703 260f80e4-7a28-3924-810f-c04153c831b5