RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.

[Vladimir Kozlov]

Hi Goetz,

It is very significant rewriting and it takes time to evaluate it.
And I would not say it is simpler then before :)
These is what I found so far.

The idea to try to allocate in a range instead of just below 
UnscaledOopHeapMax or OopEncodingHeapMax is good. So I would ask to do 
several attempts (3?) on non_PPC64 platforms too.

It is matter of preference but I am not comfortable with switch in loop. 
For me sequential 'if (addr == 0)' checks is simpler.

One thing worries me that you release found space and try to get it 
again with ReservedHeapSpace. Is it possible to add new 
ReservedHeapSpace ctor which simple use already allocated space?

The next code in ReservedHeapSpace() is hard to understand ():

(UseCompressedOops && (requested_address == NULL || 
requested_address+size > (char*)OopEncodingHeapMax) ?

may be move all this into noaccess_prefix_size() and add comments.
Why you need prefix when requested_address == NULL?

Remove next comment in universe.cpp:

// SAPJVM GL 2014-09-22


Again you will release space so why bother to include space for classes?:

+          // For small heaps, save some space for compressed class pointer
+          // space so it can be decoded with no base.

virtualspace.cpp

With new code size+noaccess_prefix could be requested. But later it is 
not used if WIN64_ONLY(&& UseLargePages) and you will have empty 
non-protected page below heap.

matcher.hpp

Universe::narrow_oop_use_implicit_null_checks() should be true for such 
case too. So you can add new condition with || to existing ones. The 
only condition you relax is base != NULL. Right?

arguments.* files

Why you need PropertyList_add changes.

Do you have platform specific changes?

Thanks,
Vladimir

On 11/10/14 6:57 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I need to improve a row of things around compressed oops heap handling
> to achieve good performance on ppc.
> I prepared a first webrev for review:
> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.00/
>
> A detailed technical description of the change is in the webrev and according bug.
>
> If requested, I will split the change into parts with more respective less impact on
> non-ppc platforms.
>
> The change is derived from well-tested code in our VM.  Originally it was
> crafted to require the least changes of  VM coding, I changed it to be better
> streamlined with the VM.
> I tested this change to deliver heaps at about the same addresses as before.
> Heap addresses mostly differ in lower bits.  In some cases (Solaris 5.11) a heap
> in a better compressed oops mode is found, though.
> I ran (and adapted) test/runtime/CompressedOops and gc/arguments/TestUseCompressedOops*.
>
> Best regards,
>    Goetz.
>
>