RFR: 8245098: Make SafeFetch32/N available earlier

[Per Liden]

On 5/18/20 2:50 AM, David Holmes wrote:
> On 17/05/2020 1:48 am, Kim Barrett wrote:
>>> On May 16, 2020, at 12:27 AM, David Holmes <david.holmes at oracle.com> 
>>> wrote:
>>>
>>> Hi Per,
>>>
>>> On 15/05/2020 10:03 pm, Per Liden wrote:
>>>> We have a need for SafeFetch32 during initializing of ZGC (see [1]). 
>>>> However, the SafeFetch32/N stubs are currently generated too late, 
>>>> in the stubRoutines_init2() phase, which is after the GC has been 
>>>> initialized. I propose we move the initialization of these stubs to 
>>>> the stubRoutines_init1() phase, which is before the GC has been 
>>>> initialized, to make them available during GC initialization.
>>>
>>> generate_safefetch includes use of a StubCodeMark. And its destructor 
>>> contains:
>>>
>>>   Forte::register_stub(_cdesc->name(), _cdesc->begin(), _cdesc->end());
>>>   if (JvmtiExport::should_post_dynamic_code_generated()) {
>>>     JvmtiExport::post_dynamic_code_generated(_cdesc->name(), 
>>> _cdesc->begin(), _cdesc->end());
>>>   }
>>>
>>> It is not at all obvious that these actions are still okay at an 
>>> earlier stage of the initialization sequence. I don't know what tests 
>>> we may have for this, nor in what tier they may run, but I suggest 
>>> running more extensive JVM TI testing, and try to determine how the 
>>> Forte code is used.
>>
>> There are lots of other stub generators called earlier in 
>> generate_initial and which also
>> include uses of StubCodeMark.
> 
> Yep - my bad. I looked at generate_throw_exception as a close-by 
> non-trivial example and noticed it did not. I should have checked some 
> of the others.

Thanks for reviewing, David!

/Per