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

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Mar 18 16:00:33 PDT 2013


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.

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


More information about the hotspot-runtime-dev mailing list