RFR (S): 8188133: C2: Static field accesses in clinit can trigger deoptimizations
vladimir.kozlov at oracle.com
Fri Feb 1 05:44:47 UTC 2019
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).
On 1/31/19 11:29 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.
> Testing: hs-precheckin-comp, tier1-5
> Best regards,
> Vladimir Ivanov
More information about the hotspot-compiler-dev