RFR (XS) 7901097: Blackhole methods should be non-inlined

[Sergey Kuksenko]

Hi,

I'd like to emphasize forth assumption/requirement:
(c') there is a way to prohibit inlining of particular method

If JVM doesn't satisfy (c') the we can do - to rely on (a) and pray that 
(b) is also working.
I agreed with suggested idea to force Blackhole to be non-inlinable.

But I'd like to get further evolution of that. If I know that my JVM is 
strictly satisfied to (c) and (c') I'd prefer to make Blackhole.consume 
empty - because of that is enough and will bring lesser noise. Of course 
it will make my results incomparable with other JVMs where I can't rely 
on (c'), but how frequently do we compare different JVMs?
Conclusion, ability to choose Blackhole implementation from the 
following list may be useful:
1) non-inlineable full Blackhole (as the most defensive)
2) full Blackhole (where there is no way to do (c')
3) non-inlineable empty Blackwhole (where I know (c) & (c') are exist)





On 11/13/2014 04:56 PM, Aleksey Shipilev wrote:
> Hi,
>
> Our current Blackhole code relies on the a few assumptions:
>   a) compilers do not reorder operations around volatiles a lot; it also
> does not speculate about their values.
>   b) compilers does not do partial escape analysis; it also does not
> re-materialize the objects once they are scalarized.
>
> These assumptions may be broken at any time (I think Graal had already
> broken (b)), and therefore we might want to add another assumption:
>   c) compilers do not do inter-procedural optimizations without inlining
>
> That is, if we force Blackhole methods to be non-inlineable, we will
> have a defense-in-depth from the compiler that does violate either of
> (a), (b), or (c). We are still in danger of the compiler that violates
> all three, but this risk is miniscule at this point.
>
> This change is very simple:
>    http://cr.openjdk.java.net/~shade/7901097/webrev.01/
>    https://bugs.openjdk.java.net/browse/CODETOOLS-7901097
>
> ...but it obviously has an impact on Blackhole performance:
>    http://cr.openjdk.java.net/~shade/7901097/performance.txt
>
> On ARM, the method calls costs quite a lot, and we can do nothing about
> it. On x86, we have 3x slower Blackholes, but still in vicinity of 2-3ns
> per consume. I think this is a fair price to pay for "defense-in-depth"
> on dead-code elimination front.
>
> Thanks,
> -Aleksey.
>

-- 
Best regards,
Sergey Kuksenko