Blackhole user instantiation

[Aleksey Shipilev]

On 07/13/2016 11:05 AM, Radim Vansa wrote:
> 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).

<class>_jmh_B* classes are the autogenerated for each @State class and
keep the scaffolding needed for supporting @State functionality. Those
mutexes guard @Setup/@TearDown methods.


>> 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?

Yes, we understand it works _now_. We cannot guarantee it will work forever.

-Aleksey