RFR: 8245098: Make SafeFetch32/N available earlier

[David Holmes]

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,
David