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

[Vladimir Kozlov]

So this is the case for OSR compilation of <clinit> with hot loop (iterations > 10000). Should we care about such cases?
We want people to write simple <clinit> so we can serialize results - this case is opposite direction.
I understand that JITed code should perform better than Interpreter. And we should fix regression in jdk 9.

There are several conditions for inlining. What if a called method is not inlined even with your relaxed condition? We 
will still deoptimize it on each iteration. Right?

I am fine to allow access to static fields from <clinit> code but I am not sure about allowing to inline general methods 
when class is not fully initialized. Can we limit what methods should be inlined? Leaf methods? Small code? No loops?

I would prefer to not compile such <clinit> at all (if it has hot calls).

Thanks,
Vladimir

On 1/31/19 11:29 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8188133/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8188133
> 
> 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.
> 
> Testing: hs-precheckin-comp, tier1-5
> 
> Best regards,
> Vladimir Ivanov