RFR: JDK-8203157: Object equals abstraction for BarrierSetAssembler

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

Thanks,
/Erik

On 2018-05-14 21:19, Roman Kennke wrote:
> Similar to what's done in the runtime already, GCs might need a say
> about object equality (e.g. Shenandoah GC). This adds the required
> abstraction to x86 and aarch64 assembler code.
>
> In x86 it ends up a bit ugly because of the existing variations of
> cmpoop() which take several combinations of Register, Address and
> jobject as argument, and even worse, varies between 64 and 32 bit builds.
>
> In aarch64, I added the MacroAssembler::cmpoop() indirection to make it
> more like the x86 implementation.
>
> http://cr.openjdk.java.net/~rkennke/JDK-8203157/webrev.00/
>
> Passes hotspot/tier1 tests for x86_64/x86_32/aarch64
>
> Can I please get a review?
> Thanks, Roman
>