RFR: 8252505: C1/C2 compiler support for blackholes [v11]

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Wed Dec 2 18:42:59 UTC 2020


On 02.12.2020 21:35, Aleksey Shipilev wrote:
> On 12/2/20 7:26 PM, Vladimir Ivanov wrote:
>>
>>> Unfortunately, not. In JMH, `Blackhole` methods are instance methods 
>>> (they have state), and that plays nicely with compatibility: when JIT 
>>> fails to provide blackholing, it would naturally fall back to old 
>>> behavior. I think null check for receiver is the fair behavior here, 
>>> as subsequent optimization may expect receiver null-checked after the 
>>> call. I have not seen null-checks in my `perfasm` runs with C1, though.
>>
>> It will "consume" and keep it alive the receiver, but have you
>> considered passing receiver explicitly as an argument?
> 
> I cannot parse what you are saying here. Please elaborate?
T
urn instance method into a static one and explicity pass receiver into 
it as an argument. You can still use it to extract state inside the 
method if intrinsification fails.

The only difference I see is receiver becomes treated as an ordinary 
argument which is consumed by a blackhole while in the current 
implementation you ignore receiver.

Best regards,
Vladimir Ivanov

>> If you want to keep instance method support, please, double-check that
>> null check stays there for correctness.
> 
> OK, that looks empirically verifiable (i.e. with the jtreg test), will od.
> 


More information about the hotspot-dev mailing list