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

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Feb 1 18:20:08 UTC 2019

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

More information about the hotspot-compiler-dev mailing list