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

[Thomas Stüfe]

On Tue, Mar 27, 2018 at 3:30 PM, Claes Redestad <claes.redestad at oracle.com>
wrote:

>
>
> 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
> > 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"
>
>
Sure that makes more sense!


>
> 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.
>
>
Okay.

..Thomas


> /Claes
>
>