RFR: JDK-8203157: Object equals abstraction for BarrierSetAssembler

Roman Kennke rkennke at redhat.com
Tue Jun 5 14:16:32 UTC 2018


Am 04.06.2018 um 14:38 schrieb Erik Österlund:
> Hi Roman,
> 
>  42
>  43   virtual void obj_equals(MacroAssembler* masm, DecoratorSet
> decorators,
>  44                           Register obj1, Register obj2);
>  45
> 
> I don't think we need to pass in any decorators here. Perhaps one day
> there will be some important semantic property to deal with, but today I
> do not think there are any properties we care about, except possibly
> AS_RAW, but that would never propagate into the BarrierSetAssembler anyway.
> 
> On that topic, I noticed that today we do the raw version of e.g.
> load_heap_oop inside of the BarrierSetAssembler, and to use it you would
> call load_heap_oop(AS_RAW). But the cmpoop stuff does it in a different
> way (cmpoop_raw in the macro assembler). I think it would be ideal if we
> could do it the same way, which would involve calling cmpoop with AS_RAW
> to get a raw oop comparison, residing in BarrierSetAssembler, with the
> usual hardwiring in the corresponding macro assembler function when it
> observes AS_RAW.
> 
> So it would look something like this:
> 
> void cmpoop(Register src1, Address src2, DecoratorSet decorators =
> AS_NORMAL);
> 
> What do you think?

cmpoop_raw() is not the AS_RAW base implementation. It's only there to
help BarrierSetAssembler to implement the base
obj_equals(Address|Register, jobject). We cannot access cmp_literal32()
from outside the MacroAssembler.

The mentioned hardwiring to call straight to BSA is probably going away too:
https://bugs.openjdk.java.net/browse/JDK-8203232
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-May/032240.html

Thanks, Roman



More information about the hotspot-dev mailing list