RFR: 8245098: Make SafeFetch32/N available earlier

[David Holmes]

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.

Thanks,
David

> Please note that this patch touches platforms I can't easily test 
> (x86-32, arm, ppc, s390). If you have access to one of those machines, I 
> would appreciate if you could do some light verification.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8245098
> Webrev: http://cr.openjdk.java.net/~pliden/8245098/webrev.0
> Testing: Tier1-3 on all Oracle supported platforms.
> 
> /Per
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8245106