[13] RFR (S): 8188133: C2: Static field accesses in clinit can trigger deoptimizations

[Vladimir Ivanov]

>> The test case in the bug demonstrates a pathological case with 
>> long-running static initializer: though it's allowed to access static 
>> fields from the thread performing the initialization, C2 can't prove 
>> that in general.
>>
>> While solving the general problem doesn't seem worth the effort 
>> (requires barriers on method entries), I propose to extend the logic 
>> to cover simple cases: when static initializer is the root of the 
>> compilation, all accesses to static fields of the corresponding class 
>> are allowed. It extends the coverage to all inlinees from OSR 
>> compilation of clinit.
> 
> What about the nmethod barriers for cuncurrent class/nmethod unloading? 
> Would they help in solving the general problem? Or is there another kind 
> of barrier you have in mind?

Yes, nmethod barriers are good candidates for implementing proper checks.

If we consider solving general case, I had the following idea in mind: 
compile special versions for method of not-yet-initialized classes and 
throw them away once the class is fully initialized.

Special versions would contain 2 guards:
   (1) if holder_klass is initialized, then deoptimize and recompile;
   (2) if current_thread != thread_running_clinit, then deoptimize and 
recompile;

The former eliminates initialization check once it becomes redundant and 
the latter blocks invocations from other threads until the class is 
fully initialized.

Both holder_klass and thread_running_clinit and known to JIT and can be 
embedded into the code, making both checks very simple.

Such checks can be either coded directly or wrapped into nmethod barrier.

Best regards,
Vladimir Ivanov