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

Claes Redestad claes.redestad at oracle.com
Tue Mar 27 13:30:02 UTC 2018



On 2018-03-27 14:37, Thomas Stüfe wrote:
>
> On Tue, Mar 27, 2018 at 2:31 PM, Claes Redestad 
> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>
>     Hi Thomas,
>
>     On 2018-03-27 14:17, Thomas Stüfe wrote:
>
>         Hi Claes,
>
>         change looks ok, although I would prefer a different, clearer
>         name for this variable. How about
>         "suppress_primordial_thread_recognition" ?
>
>
>     not sure I find that any clearer... how about
>     "primordial_thread_detached"?
>
>
> Hmm.. I find that actually worse than "might_be_primordial_thread".

The word I found odd in your example was "recognition", I think of it 
more that we're resolving whether we're on the primordial thread or not,
so maybe "suppress_primordial_thread_resolution"

>
> Okay, I am fine with the original name.
>
> I often use an int in these cases to have a trinary value, with -1 
> being the default value meaning "uninitialized", so that I can assert 
> that initialization ran before using the value the first time. But I 
> leave it up to you if you want this.

If we'd somehow have initialized "suppress..." to false without having 
initialized the primordial stack bounds on init, we'd hit other asserts 
in is_primordial_thread. So I think we're good as is.

/Claes



More information about the hotspot-runtime-dev mailing list