Blackhole user instantiation

[Radim Vansa]

On 07/12/2016 09:34 PM, Aleksey Shipilev wrote:
> On 06/29/2016 11:14 AM, Radim Vansa wrote:
>> I'd like to reuse Blackhole in project aimed at benchmarking distributed
>> systems (RadarGun [1]), but rather than just being tricky bastard [2]
>> I'd like to ask if there's any info what black magic does JMH use to
>> instantiate Blackhole properly and where be the dragons.
> First, you have to understand that Blackhole evolves along with JVM and
> our understanding of JVMs. Blindly copying Blackhole code to a separate
> project detaches the implementation from updates.

I'd be ok with adding a maven dependency, though there's the 
code-generation step (fine, I could wire something like that into build 
as well). But mostly I am asking what trickery is employed there. I 
understand BlackholeL1+3 as padding, I could imagine that L0+4 use the 
markers to assert the offsets (haven't peeked where exactly), but I have 
no idea what are the Blackhole_jmh_B2 mutexes for (and why are these 
padded from the L2 fields though not separated from each other - that 
would probably be clearer once I know what are these used for).

>
> Current Blackhole needs to avoid DCE-ing itself. That is, this runs into
> danger of not working:
>
>    @Benchmark
>    public void test() {
>      new Blackhole().consume(someOp());
>    }
>
> ...because some Blackhole implementations may choose to store the
> consumed argument in the field. Inlining the BH instance runs at the
> risk of DCEing that part of BH mechanics, which breaks the contract.

So you prevent inlining by storing the BH in a field of the test-class - 
great, that's one thing that needs to be taken care of. Others?

>
> This is one realistic failure scenario, but there might be other bad
> ones. For example, at some point we would have to split Blackhole
> implementations on per-JVM/compiler version (e.g. Graal), trying to
> accommodate different compiler details. Injecting Blackhole to JMH users
> provide a simple and performant way to substitute BH implementations
> without forcing users to recompile.

I agree, that's very convenient for JMH users. But when reusing JMH 
code, there could be a factory method that would provide the correct 
implementation for given VM. I am not asking to add it to the API ATM - 
when the need comes, I am sure something like that will appear in codebase.

Thanks for your insights

Radim

>
> Thanks,
> -Aleksey
>
>
>
>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team