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

[Vladimir Kozlov]

On 2/1/19 9:53 AM, Vladimir Ivanov wrote:
> 
>>> 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.

I think this is better idea than trying to inline all callees into <clinit>.

Vladimir K

> 
> Such checks can be either coded directly or wrapped into nmethod barrier.
> 
> Best regards,
> Vladimir Ivanov