Request for review(XL): 6985015: C1 needs to support compressed oops

Tom Rodriguez tom.rodriguez at
Fri Nov 19 13:18:44 PST 2010

The cpu_reg_range_reduction stuff is pretty gross.  Can we just make nof_caller_save_cpu_regs a method on FrameMap.  The existing enum would become _max_nof_caller_save_cpu_regs so it could continue to be a constant for declarations.


what is slr and why would you use it instead of sllx?


use load_klass instead.

In general if you can use load_heap_oop and store_heap_oop instead that would be preferable.  It's possible you'll need to add an alternate temp argument to them since they always assume it's ok to kill the oop value.

in const2mem, init offset to -1 and assert that it's been set at before using it.

sometimes the argument ordering is wide then unaligned and other times it's reversed which seems like asking for trouble.  Why is it like this?

I guess the arraycopy guards were fairly broken on 64 bit since they were still using br instead of brx in a few places.  Oops.

You're loading the klasses as 32 bit but comparing them using the 64 bit condition code which I know will work in this case but it's a bad practice.  loads always produce safe values but it's not clear that our constant construction code does.  Maybe we need a br variant that allows specifying the condition codes? bp lets you but that's v9 only.

+ #ifdef _LP64
+     if (UseCompressedOops) {
+       __ encode_heap_oop(tmp, tmp);
+       __ lduw(dst, oopDesc::klass_offset_in_bytes(), tmp2);
+     } else
+ #endif
        __ ld_ptr(dst, oopDesc::klass_offset_in_bytes(), tmp2);

Could you put some comments on this?  I know this code is assert only but is there a need for a jobject2reg that produces the encoded oop directly?  The relocs support it.  Doing the type checks by producing wide oops will be much more expensive.


what happening with the alignment?  Why isn't it aligned from compressed oops?

Other it looks fine.


On Nov 18, 2010, at 7:12 PM, Igor Veresov wrote:

> This change implements compressed oops for C1 for x64 and sparc.
> The changes are mostly on the codegen level, with a few exceptions when we do access things outside of the heap that are uncompressed from the IR.
> Webrev:
> Thanks,
> igor

More information about the hotspot-compiler-dev mailing list