RFR (S) 8239492: [x86] Turn MacroAssembler::verify_oop into macro recording file and line

Aleksey Shipilev shade at redhat.com
Fri Feb 21 17:56:51 UTC 2020


On 2/21/20 6:32 PM, Reingruber, Richard wrote:
>> Suggested fix:
>>   https://cr.openjdk.java.net/~shade/8239492/webrev.02/
> 
> The RFE is worth the (small) effort and the proposed change looks good to me.

Thanks.

>> I was a little confused as now the verify_oop() calls in TemplateTable get dispatched directely to
> MacroAssembler, but that's what InterpreterMacroAssembler::verify_oop() used to do there anyway,
> because all the call sites got the default argument state = atos.

Yes. Sometimes interp_verify_oop is called with the actual "state", but otherwise it is called with
atos. We could, in principle, introduce two separate macro definitions to simulate that default
argument, but I'd prefer not to go overly crazy with macros.

> I assume you deliberately did the renaming in zVerify.cpp instead of undefining verify_oop as in
> shenandoahVerifier.cpp. That's good for me too.

Ah, hm. Actually, maybe we should indeed do it Shenandoah-way by undef-ing the macro in the
problematic compilation unit.

> You should update the years in the copyright headers.

Updated.

New webrev:
  https://cr.openjdk.java.net/~shade/8239492/webrev.03/

-- 
Thanks,
-Aleksey



More information about the hotspot-dev mailing list