OSThread::GetCurrentThreadId() is used in many places throughout
the vm, particularly in facilities that are used heavily, such as
SafepointRwLock. The high frequency of invocations means that the
runtime overhead of getting the current thread id has a significant
impact on the overall performance of the vm.
The current Fuchsia implemention of OSThread::GetCurrentThreadId()
makes a syscall to get the koid of the current thread's handle,
resulting in hundreds of nanoseconds of unnecessary overhead per
invocation.
This patch changes to using the thread's handle as the id, which is
guaranteed to be unique for the lifetime of the thread, unless it
is closed prematurely (nothing in the vm does this). This approach
is similar to what MUSL libc (the libc used by Fuchsia) does for
the same purpose and has significant mileage.
Bug: b/182183059
TEST=existing ci test suite; manually deployed into Fuchsia build.
Change-Id: I274a793a823a717c8dd206b396001c6acb897b9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193643
Reviewed-by: Chase Latta <chaselatta@google.com>
Commit-Queue: Chase Latta <chaselatta@google.com>
Fuchsia is about to turn on ShadowCallStack for ARM64. Once this is enabled, we need to treat R18 like a preserved register. Generated Dart has not accessed this register because it is reserved on iOS, and in the absence of Dart exceptions this would be sufficient for us to be ShadowCallStack compatible. However, our exception handling mechanism jumps past all the C++ frames between the Dart exit frame and Exceptions::JumpToFrame, skipping code that would pop from R18.
Add save/restore of R18 in the invocation stubs, and restore of R18 in the jump stub. The latter prevents the ShadowCallStack from overflowing for code that has lots of exceptions without a native call.
Bug: https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=37449
Change-Id: I2ce6e46624c8d72507e7afa7a44839b1f0def556
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119481
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@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>
This reverts commit af251ddfec.
Reason for revert: Crashes on Windows.
Original change's description:
> [vm] Prefer stack bounds from the system thread library for overflow checks.
>
> Before this change, we would assume all stacks have the size the VM specifies for threads it creates, but this won't be accurate for the initial thread or threads created by the embedder.
>
> Change-Id: I6605a88d6666a6f9d47fbe047d3fdd02aa22c80a
> Reviewed-on: https://dart-review.googlesource.com/10209
> Reviewed-by: Zach Anderson <zra@google.com>
TBR=rmacnak@google.com,zra@google.com
Change-Id: I96eaccdc8edf6e3d319827a63d168534bad0518e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/13106
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Before this change, we would assume all stacks have the size the VM specifies for threads it creates, but this won't be accurate for the initial thread or threads created by the embedder.
Change-Id: I6605a88d6666a6f9d47fbe047d3fdd02aa22c80a
Reviewed-on: https://dart-review.googlesource.com/10209
Reviewed-by: Zach Anderson <zra@google.com>
For example, this will cause thread pool threads to be named
"Dart ThreadPool Worker" in the system trace.
FL-25
Change-Id: I929ca51daef58217042a2f64491fee6fe8112ad5
Reviewed-on: https://dart-review.googlesource.com/9002
Reviewed-by: Ryan Macnak <rmacnak@google.com>
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 .
Currently it relies on OSThread::stack_base_ which is explicitly set.
However if we encounter a crash or assertion failure early we don't have stack_base_ set yet.
This CL allows us to get correct stack dump even if OSThread::stack_base_ is not set yet by falling back to low-level APIs:
* On Linux and Android we fallback to pthread_attr_getstack
* On Mac OS X we use pthread_get_stackaddr_np/pthread_get_stacksize_np.
* On Windows we read limits from TIB.
This code is mostly a port of the battle tested thread limits code from Oilpan GC inside Blink. The only differences is that we don't fallback to __libc_stack_end for the main thread.
We also cleanup GetAndValidateIsolateStackBounds a bit to avoid duplication there.
(This change is motivated by https://github.com/dart-lang/sdk/issues/28692 where crash in bootstrapping does not produce any useful stack trace)
BUG=
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2680123004 .
Corey Tabaka