RFR: 8199717: Avoid calculating primordial thread stack bounds on VM startup

Thomas Stüfe thomas.stuefe at gmail.com
Tue Mar 27 12:17:26 UTC 2018

Hi Claes,

change looks ok, although I would prefer a different, clearer name for this
variable. How about "suppress_primordial_thread_recognition" ?

Thanks, Thomas

On Tue, Mar 27, 2018 at 12:02 PM, Claes Redestad <claes.redestad at oracle.com>

> Hi,
> on linux, we scan /proc/self/maps to be able to tell if the current thread
> is the "primordial" one.
> However, when initializing the VM, all the java launchers spawn a new
> thread rather than initializing the VM on the primordial thread, so we can
> deduce that none of the threads we'll run on will be the primordial thread
> if started by one of the standard java launchers. This enables us to skip
> reading the /proc/self/maps entirely.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199717
> Webrev: http://cr.openjdk.java.net/~redestad/8199717/open.00/
> This patch uses the Arguments::created_by_java_launcher(), which checks
> is the sun.java.launcher property has been set or not. There is a small
> risk third party launchers sets the sun.java.launcher property even when
> not conforming to the behavior of the standard java launchers; if so the
> existing created_by_java_launcher() method might need to be re-examined in
> a follow up.
> This shaves ~0.7ms off of startup on my linux machine.
> Thanks!
> /Claes

More information about the hotspot-runtime-dev mailing list