[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFE (m) (Prelminary): JDK-7197666: java -d64 -version core dumps in a box with lots of memory
From:       Thomas Schatzl <thomas.schatzl () oracle ! com>
Date:       2013-03-29 9:33:45
Message-ID: 1364549625.2821.34.camel () cirrus
[Download RAW message or body]

Hi,

On Thu, 2013-03-28 at 23:09 +0100, Bengt Rutisson wrote:
> 
> Hi all,
>
> Sending this to both runtime and GC since I think it concerns both
> areas.
>
> I'd like some feedback on this preliminary change. I still want to do
> some more testing and evaluation before I ask for final reviews:
>
> http://cr.openjdk.java.net/~brutisso/7197666/webrev.00/
>
> In particular I would like some feedback on these questions:
>
> - The class I am adding, ArrayAllocator, wants to choose between doing
> malloc and mmap. Normally we use ReservedSpace and VirtualSpace to get
> mapped memory. However, those classes are kind of clumsy when I just
> want to allocate one chunk of memory. It is much simpler to use the
> os::reserve_memory() and os::commit_memory() methods directly. I think
> my use case here motivate using these methods directly, but is there
> some reason not to do that?

The *Space classes are heavily geared to be used as virtual memory
management helpers for a two-generation heap, so I'm not sure if they
are appropriate here.

Not sure why you chose to use AllocateHeap(), I always thought that the
use of the corresponding macros (NEW_C_HEAP_ARRAY etc.) is recommended.

The error messages of ArrayAllocator give very little information, maybe
add the requested block size that lead to the failure in the message.

There is a typo in the comment "uses malpped memory" -> "uses mapped
memory".

While it is not strictly necessary, you could initialize all member
variables in the constructor's initialization list.

Maybe there is a common name for such type of objects, i.e. cleanup
helpers that are "stack allocated" only to be automatically called
during destructor of the enclosing class in c++ jargon.
It seems to be a common pattern.

If that is not the case, maybe rename it to LargeArrayAllocator to
better indicate the purpose in addition to the comment.
> 
> Some background on the change:
> 
> The default implementation of malloc on Solaris has several limitation
> compared to malloc on other platforms. One limitation is that it can
> only use one consecutive chunk of memory. Another limitation is that
> it always allocates in this single chunk of memory no matter how large
> the requested amount of memory is. Other malloc implementations
> normally use mapped memory for large allocations.
> 
> The Java heap is mapped in memory and we try to pick a good address
> for it. The lowest allowed address is controlled by
> HeapBaseMinAddress. This is only 256 MB on Solaris x86 (other
> platforms have at least 2 GB). Since the C heap ends up below the Java
> heap it means that in some cases it is limited to 256 MB.

256 MB seems to be very low in any case. Maybe in addition to that, make
HeapBaseMinAddress dependent on the OS?

Is there some documentation/FAQ that tells solaris/x86 users to consider
increasing HeapBaseMinAddress if they run out of C heap?
> 
Thomas

[prev in list] [next in list] [prev in thread] [next in thread]