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>
wrote:
> 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