RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Feb 6 10:29:38 PST 2014

On 2/6/14 10:13 AM, Roland Westrelin wrote:

Hi Vladimir,

In general I am comfortable to have inlinedepth as additional type's attribute. But only for speculative types when it make sense.

So why you keep inlinedepth in removespeculative()? Because it’s never used in practice with non speculative types (it should always be InlineDepthBottom for a non speculative type). The only place where it changes the behavior of compilation is in GraphKit::recordprofileforspeculation() where it’s used only for speculative types. Anyway, I can reset it to InlineDepthBottom in removespeculative() if you like. Yes, please, set to InlineDepthBottom. It will be consistent with types without speculative types. Actually, that’s not possible. Because then, that code: 2589 if (resoopptr->removespeculative() == resoopptr->speculative()) { 2590 return resoopptr->removespeculative(); in TypeOopPtr::xmeet() doesn’t trigger if resoopptr has an inline depth of InlineDepthTop. removespeculative() transforms it to InlineDepthBottom. And the type system is no longer symmetric. Do you know why it is top? The default value is InlineDepthBottom, how it is converted to top? It’s top because it’s a join and for a join the dual of the inlinedepth is used.

Sorry, I misunderstood the code in remove_speculative(). I thought you replacing type's _inline_depth with one from speculative type but you simple preserving original _inline_depth of this type. The original code you had is good.

Thanks, Vladimir

Roland.

Instead shouldn’t I assert in removespeculative() that if speculative is non NULL then inlinedepth is InlineDepthTop or InlineDepthBottom? To have assert is good but we need to understand why in such case inlinedepth could be top. Thanks, Vladimir Roland.

More information about the hotspot-compiler-dev mailing list