RFR: 8245098: Make SafeFetch32/N available earlier

[Kim Barrett]

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