MaxBCEAEstimateSize and inlining clarification

[Vitaly Davidovich]

On Tuesday, September 13, 2016, Cheremin Ruslan <cheremin at gmail.com> wrote:

> > 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 a bit confused: I was sure BCEA-style params do affect EA, but don't
> affect scalar replacement. With bcEscapeAnalyser you can get (sort of)
> inter-procedural EA, but this only allows you to have more allocations
> identified as ArgEscape instead of GlobalEscape. But you can't get more
> NoEscape without real inlining. ArgEscape (afaik) is used only for
> synchronization removals in HotSpot, not for scalar replacements.
>
> Am I incorrect?

That's my understanding as well (and matches what I'm seeing in some
synthetic test harnesses).

I'm generally seeing a lot of variability in scalar replacement in
particular, all driven by profile data.  HashMap<Integer, ...>::get(int)
sometimes works at eliminating the box and sometimes doesn't - the
difference appears to be whether Integer::equals is inlined or not, which
in turn depends on whether the lookup finds something or not and whether
the number of successful lookups reaches compilation threshold. It's pretty
brittle, sadly, and more importantly, unstable.



> ----
> Ruslan



-- 
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160913/01b5f83d/attachment.html>