RFR (S) 8008217: CDS: Class data sharing limits the malloc heap on Solaris

[Vladimir Kozlov]

Coleen,

First, your description is not accurate. Should be something like this:

"In 64bit VM move CDS archive address to 32G on all platforms using new 
flag SharedBaseAddress.
In 32bit VM set CDS archive address to 2Gb on Linux and let other OSs 
pick the address."

I think you need to always set SharedBaseAddress to 32G with the flag 
description that it is default for 64-bit VM. Special flag setting for 
Linux in 32bit VM could be done in VirtualSpaceNode() or in 
arguments.cpp (where CDS values are set) under #ifdef if the value is 
default.

Also setting in 32bit VM the CDS address on Linux to 2G may limit 
ability to specify large java heap size since 2G is in the middle of 
virtual space. Can it be somewhere at the top of virtual space (4G - 
cds_size)? Or at the bottom? Did you look on heap mapping in that case? 
Note, HeapBaseMinAddress was never used in 32bit VM before NPG.

Thanks,
Vladimir

On 3/18/13 7:51 AM, Coleen Phillimore wrote:
>
> Adding in some more potential reviewers...  please review!
> Thanks,
> Coleen
>
> On 03/15/2013 02:25 PM, Coleen Phillimore wrote:
>> Summary: Don't use HeapBaseMinAddress on solaris, let the OS pick the
>> CDS archive address on solaris.  Move all CDS archive addresses up to
>> 32G on 64 bit.
>>
>> On Linux, this still uses 2*G address because running ute, we can't
>> seem get the same address that -Xshare:dump choses. Solaris chooses a
>> higher address which seems to work fine.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8008217/
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8008217
>>
>> Tested manually with gc/gctests/ManyObjects on all platforms.  To add
>> a jtreg test, we'd have to introduce a new flag to change the location
>> of the shared archive because we don't have write access to JAVA_HOME
>> while testing.   Do people think this is worth doing?
>>
>> Thanks,
>> Coleen
>