RFR: 8189170: Add option to disable stack overflow checking in primordial thread for use with JNI_CreateJavaJVM
David Holmes
david.holmes at oracle.com
Tue Nov 14 10:39:24 UTC 2017
Bug: https://bugs.openjdk.java.net/browse/JDK-8189170
webrev: http://cr.openjdk.java.net/~dholmes/8189170/webrev/
There are three parts to this which made it somewhat more complicated
than I had envisaged:
1. Add the flag and disable the guards.
This is relatively straight-forward:
void JavaThread::create_stack_guard_pages() {
if (!os::uses_stack_guard_pages() ||
_stack_guard_state != stack_guard_unused ||
(DisablePrimordialThreadGuardPages && os::is_primordial_thread())) {
log_info(os, thread)("Stack guard page creation for thread "
UINTX_FORMAT " disabled",
os::current_thread_id());
return;
with a tweak in JavaThread::stack_guards_enabled as well.
2. Promote os::XXX::is_initial_thread to os::is_primordial_thread()
We have three platforms that already implement this functionality:
Linux, Solaris and AIX. For BSD/OSX and Windows we don't attempt to do
anything different for the primordial thread, and we don't have a way to
detect the primordial thread - so is_primordial_thread() just returns false.
I also tidied up some comments regarding terminology.
3. Thomas noticed that we unconditionally subtract 2*page_size() from
the rlimit stack size, without checking it was bigger than 2*page_size()
to start with. I was unsure how to tackle this. It's no good leaving
stack_size at zero so I opted to ensure we would have at least one page
left. Of course in such cases we would hit the bug in libc (if it still
exists, which seems unlikely but time consuming to establish).
Testing:
- Tier 1 (JPRT) testing with a modified launcher that uses the
primordial thread
- with guard pages enabled
- with guard pages disabled
- Tier 1 (JPRT) normal JDK build (which should be unaffected by this
change)
The testing was primarily to ensure that disabling the stack guards on
the primordial thread wasn't totally broken. A number of tests fail:
- setting -Xss32m fails for the primordial thread when guards are
enabled and the rlimit is 8m
- tests that would hit StackOverflowError crash the VM when guards are
disabled (as you would expect).
- runtime/execstack/Testexecstack.java crashes when the guards are disabled
Thanks,
David
More information about the hotspot-runtime-dev
mailing list