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