MaxBCEAEstimateSize and inlining clarification

[Vladimir Ivanov]

Vitaly,

> The default max size is 150, nearly half the size of FreqInlineSize. Is
> EA eligibility performed on a method before it's inlined then? I can't
> imagine that 150 is the limit after inlining. If it's before inlining,
> how exactly does this work after the method is inlined since the inlined
> call graph may have quite a bit of code and thus EA may take a while? My
> understanding is EA is run after inlining to maximize its effectiveness.
> Or is the MaxBCEAEstimateLevel used as pseudo inlining for the analysis?

Yes, it's sort of "pseudo inlining". EA happens after inlining is over 
(both parse & post-parse phases). For calls with known target, EA 
performs static analysis to compute escape info for arguments. It 
happens for methods smaller than MaxBCEAEstimateSize. 
MaxBCEAEstimateLevel limits the inlining depth during analysis.

> I'm seeing some code that iterates over a ConcurrentHashMap's entrySet
> that allocates tens of GB of CHM$MapEntry objects even though they don't
> escape. I'm also seeing some other places where EA ought to be kicking
> in but isn't. So I'd like to understand the nuances of it a bit better.

I wish -XX:+PrintEscapeAnalysis & -XX:+PrintEliminateAllocations were 
available in product binaries, but they aren't, unfortunately. You can 
build an "optimized" JVM though. It's close to product binaries w.r.t. 
speed, but contains also provides most of diagnostic logic (e.g., all 
nonproduct flags are available).

If autoboxing is involved, you can try -XX:+AggressiveUnboxing.

Best regards,
Vladimir Ivanov