RFR (S): 8188133: C2: Static field accesses in clinit can trigger deoptimizations
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
>> 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
I think this is better idea than trying to inline all callees into <clinit>.
> Such checks can be either coded directly or wrapped into nmethod barrier.
> Best regards,
> Vladimir Ivanov
More information about the hotspot-compiler-dev