Previously there were places in the code where an API accepted a
`bool validate_frames` and call sites passed an enum value (which
implicitly got converted to a bool).
By changing the APIs to require an enum, the compiler will tell us if a
caller doesn't pass one.
Change-Id: I29fcd0b018e6cdd7e00b5bb03e83b9636d1345d4
Reviewed-on: https://dart-review.googlesource.com/57823
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
The safestack stack pointer is cached when invoking Dart code, and
manually restored when jumping over C++ frames for Dart exceptions
in Exceptions::JumpToFrame().
fixes#31356
Change-Id: I71c2e86d1d4f24571dd618a5db06fd1277339ebc
Reviewed-on: https://dart-review.googlesource.com/23141
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
I collected statistics for the sizes and capacities of growable arrays which are promoted to old-space or survive an old-space gc when running dart2js and Fasta. For these applications, the vast majority of arrays stay empty. More than half of the total object size of promoted backing arrays is backing for empty growable arrays.
Furthermore, since the overhead for an array is 3 words (header, type parameters and length), and object sizes are rounded up to an even number of words, we waste one word for all even-sized arrays.
This CL changes the growth strategy so that empty growable arrays are created with a shared, zero-sized array as backing, avoiding the allocation of a backing array if no elements are added. When the array needs to grow, it starts out at 3 and grows to double size plus one each time: 7, 15, 31, ...
A few places in the VM code need to handle these shared, zero-sized arrays specially. In particular, the Array::MakeArray function needs to allocate a new, empty array if its result is to be returned to Dart code.
Benchmarks suggest that the change improves memory usage by a few percent overall and does not significantly affect run time.
BUG=
R=erikcorry@google.com
Review-Url: https://codereview.chromium.org/2949803002 .
The assertions which tried to assert that we only use
StackFrameIterator to walk frames of the current thread was incorrect.
We already have cases where other threads will walk the stack of the
mutator thread, see below for an example where this can happen.
Thread::VisitObjectPointers was incorrectly passing Thread::Current() to
the StackFrameIterator instead of 'this'. (Code in thread_registry.cc will
loop over a number of threads and calls VisitObjectPointers on them)
Mutator thread:
0 pthread_cond_wait@@GLIBC_2.3.2
1 dart::Monitor::WaitMicros
2 dart::Monitor::Wait
3 dart::MonitorLocker::Wait
4 dart::ThreadBarrier::Sync
5 dart::GCMarker::MarkObjects
6 dart::PageSpace::MarkSweep
7 dart::Heap::CollectOldSpaceGarbage
8 dart::Heap::CollectNewSpaceGarbage
9 dart::Heap::CollectGarbage
10 dart::DN_HelperObject_<native>
11 dart::BootstrapNatives::<native>
<dart frames>
MarkTask thread:
1 dart::EntryFrame::VisitObjectPointers
2 dart::Thread::VisitObjectPointers <---- Walks mutator thread stack
3 dart::ThreadRegistry::VisitObjectPointers <---- Iterates over a number of threads
4 dart::Isolate::VisitStackPointers
5 dart::Isolate::VisitObjectPointers
6 dart::GCMarker::IterateRoots
7 dart::MarkTask::Run
8 dart::ThreadPool::Worker::Loop
9 dart::ThreadPool::Worker::Main
10 dart::ThreadStart
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2845053003 .
Use that to sync variables to predefined stack
slots inside of exception handler, not before
each MayThrow() instruction.
In JIT mode we can avoid storing extra metadata
by using deopt info instead.
Introduce caching of metadata and
exception handler based on PC.
R=fschneider@google.com, vegorov@google.com
Review-Url: https://codereview.chromium.org/2734323003 .
Use that to sync variables to predefined stack
slots inside of exception handler, not before
each MayThrow() instruction.
In JIT mode we can avoid storing extra metadata
by using deopt info instead.
Introduce caching of metadata and
exception handler based on PC.
R=fschneider@google.com
Review-Url: https://codereview.chromium.org/2640853002 .
use of Bigint (see issue #28595).
A RangeError with the message "Integer operand requires conversion to Bigint" is
thrown when a Bigint gets allocated. However, parsing a Bigint literal in Dart
source will not throw the RangeError (as long as the literal is not used).
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2708213004 .
This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.
Tracking causal stack traces:
- [x] Upon entry to an async function, capture the synchronous stack trace prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix into the Thread.
- [x] Filter stack traces to remove async machinery.
Service protocol changes:
- [x] Send causal async stack trace.
Observatory changes:
- [x] Display causal async stack trace below async functions.
Fixes https://github.com/dart-lang/sdk/issues/27661R=asiva@google.com, rmacnak@google.com
Comparisons: https://docs.google.com/a/google.com/document/d/10r6jEqr8OCiDZ4y9SYU_uOimcHiOGAZMly2ghTErALI/edit?usp=sharing
Review-Url: https://codereview.chromium.org/2646443005 .
With custom zones and async code we may end up invoking rethrow
with an error object where the stacktrace is not initialized.
In that case we can just use the stacktrace passed into rethrow
explicitly.
Fixes#27839.
R=kustermann@google.com
Review URL: https://codereview.chromium.org/2511573003 .
- Refactor the JumpToExceptionHandle code so that it is now built from
two pieces: JumpToFrame and RunExceptionHandler.
- Refactor the Simulator::Longjmp() code so that it is no longer
exception-specific. Instead it uses the RunExceptionHandler stub.
This makes it so that the JumpToFrame stub and Simulator::JumpToFrame
have the same semantics. This will make it easier to land the Rewind
changes I am working on.
There are some oddities for dbc.
BUG=
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/2503653002 .
When throwing to a frame scheduled for lazy deopt, update the continuation pc for that frame to be the catch handler.
Weaken new assert that the deopt pc belongs to the frame's code as the deopt pc for the last eager deopt in a function lies outside the code, after the call to the deopt stub.
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2392613002 .
- fixed an inadvertant flip in the safepoint check in this cl
https://github.com/dart-lang/sdk/commit/e72c1fb47
- return (IsMutatorThread() ||
- (isolate_ != NULL && !isolate_->thread_registry()->AtSafepoint()));
+ return (IsMutatorThread() || IsAtSafepoint());
- increase the scope of CanCollectGarbage in Heap::AllocateOld to also
account for the tasks lock as checking for tasks inside a safepoint
scope can lead to deadlocks
- fix an aggressive assertion in compiler for expected errors being only
LanguageErrors to allowing UnhandledExceptions (OOM, stack overflows etc.)
- fix an aggressive assert in exception handler (handler pc can be 0 even in the mutator thread.
- workaround issue 27413 in PageSpace::CanIncreaseCapacityInWords
BUG=27380
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2363823002 .
If an error happens during the compilation of a function body, an Error is thrown which can be intercepted, and ensures that finally blocks are executed before the isolate is terminated.
The language spec is vague about compilation errors. A doc describing the intentions behind this CL is at
https://docs.google.com/document/d/1_MWOgwJadLCQSBps0zD6Rj5dG4iP1UBuiDvTMH-WMzI/edit#
Example:
1 void bad() {
2 return 5
3 }
4
5 void main(args) {
6 bad();
7 }
Before this CL:
$ dart ~/tmp/e.dart
'file:///Users/hausner/tmp/e.dart': error: line 2 pos 11: semicolon expected
return 5
^
$
After this change:
$ dart ~/tmp/e.dart
Unhandled exception:
'file:///Users/hausner/tmp/e.dart': error: line 2 pos 11: semicolon expected
return 5
^
#0 main (file:///Users/hausner/tmp/e.dart:6:3)
#1 _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:259)
#2 _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:148)
$
Notice that the stack trace points to the call site of bad(), not the text location of the syntax error. That's not a bug. The location of the syntax error is given in the error message.
BUG= https://github.com/dart-lang/sdk/issues/23684R=asiva@google.com, lrn@google.com
Review URL: https://codereview.chromium.org/2044753002 .
Don't expect to find a Dart frame on the stack when an exception
occurs in background compilation. Propagate OOM error as an
unhandled exception, and disable optimization for the function
where it occurred.
BUG=#27206
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/2341523002 .
The call sequence is very similar to a classic IC call, except the guarded class and the target are loaded indirectly from the constant pool instead of as immediates. In the monomorphic case, we call directly to the expected target with a class check in the callee. In the unlinked, polymorphic and megamorphic cases, we call a stub; these case are now call-through instead of call-and-return.
Every code, except stubs involved in switchable calls, includes the class check sequence at the beginning. So we now distinguish between a checked and an unchecked entry point. Generated code except the switchable call continues to use the unchecked entry point.
PC offsets are calculated relative to the beginning of the instruction stream, rather than either entry point.
BUG=
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2226893002 .
Régis Crelier