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

[Coleen Phillimore]

On 3/18/2013 7:00 PM, Vladimir Kozlov wrote:
> On 3/18/13 3:30 PM, Coleen Phillimore wrote:
>> On 3/18/2013 1:32 PM, Vladimir Kozlov wrote:
>>> 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."
>>
>> Yes, that sounds better than what I wrote.
>>
>>>
>>> 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.
>>
>> I don't understand this comment.   Does it mean make it 32G and 2G in
>> globals.hpp rather than in the globals_os_cpu.hpp files?  I don't have
>> good experiences with special case code in arguments.cpp and the
>> complexity we keep adding to it, and want to avoid that.
>
> If you had different values on different Linux flavors then setting in 
> globals_os_cpu.hpp is good. But you have the same value. If you need 
> to change 2G value later you will need to change again all these files.

This is true.  You convinced me.   I'd rather code in the declaration 
than these #ifdefs in arguments.cpp.  There are too many #ifdefs in 
arguments.cpp:

   product(uintx, SharedBaseAddress, NOT_LP64(SOLARIS_ONLY(0) 
NOT_SOLARIS(3*G))\
LP64_ONLY(32*G),                                                  \
           "Address to allocate shared memory if OS default doesn't 
work")   \
\
On my Linux 32 bit machine 3G doesn't work (java -version doesn't get 
back the address).  If I let Linux 32 bit default, it picks an address 
close to 3G, and Java -version does work.

Maybe it's better that Linux and Windows pick an address, which is the 
way they used to work (or not) before I happened to test them with 
NPG.   I'd have to retest Windows with this because I don't remember 
what the results there were.   What do you think?

thanks,
Coleen


>
> There is Arguments::set_shared_spaces_flags() method where you can do 
> it (at the end of the method):
>
> #ifndef _LP64
>   if (UseSharedSpaces && FLAG_IS_DEFAULT(SharedBaseAddress)) {
> #ifdef LINUX
>     // set CDS archive address to 2Gb on Linux in 32bit VM
>     FLAG_SET_DEFAULT(SharedBaseAddress, 2*G);
> #else
>     // let other OSs pick the address
>     FLAG_SET_DEFAULT(SharedBaseAddress, 0);
> #endif
>   }
> #endif
>
>>
>>>
>>> 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.
>>>
>>
>> I was wondering what a better address than 2G would be for Linux. Which
>> is why I put the settings in the different os_cpu files.  If I let Linux
>> default, it picks a high address for -Xshare:dump but then cannot get
>> this higher address when ute tests are run.   2G is sort of in the
>> middle which always seems to work, and with 32 bit, the Java heap
>> shouldn't be that large anyway because otherwise people would be using
>> 64 bits.   Maybe 3G might be better, or 3.5G.
>> I didn't dare try to use lower addresses because some other application
>> specific data would be more likely to want these addresses. So, that's
>> another reason I made it an option and split their settings out.
>
> I think you should go as high as possible to leave more space for java 
> heap. It would be nice to determine the address dynamically if 
> possible. I think the problem with UTE is testing is done in Virtual 
> Machines and not on hardware.
>
> I am concern about escalations from customers later that they can't 
> specify big heap any more with 32bit VM. I would suggest to ask our 
> embedded group to look on this.
>
> Thanks,
> Vladimir
>
>>
>> Thanks,
>> Coleen
>>
>>> 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
>>>>
>>