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