Current heap layout of generational mark-sweep GC

Jon Masamitsu Jon.Masamitsu at Sun.COM
Wed May 16 13:43:33 UTC 2007



Neo Jia wrote:

> On 5/15/07, Jon Masamitsu <Jon.Masamitsu at sun.com> wrote:
>
>> Regarding "PrintMallocFree" it is broken in the sense that not
>> all malloc()/free() calls are wrapped inside the corresponding
>> AllocateHeap()/FreeHeap().  I've used it maybe once.   I don't
>> know what to say about why it's gone stale.
>
>
> Jon,
>
> Not only not catching all the malloc/free but also crashing the strlen
> function on JDK7. This is what I found several days before.


Well that's bad.  Does running just anything with "PrintMallocFree"
cause this crash?

>
> So, is GC people in charge of detecting memory leak? Because after
> running valgrind with hotspot, it reports lots memory lost.


No, each group (GC, runtime, compilers, and serviceability)
manages its own usage of the CHeap with regard to leaks.

>
> Thanks,
> Neo
>
>
>>
>> Neo Jia wrote:
>>
>> > On 5/14/07, Jon Masamitsu <Jon.Masamitsu at sun.com> wrote:
>> >
>> >> Neo,
>> >>
>> >> If by "generational mark-sweep GC" you mean the UseSerialGC
>> >> or UseParNewGC,
>> >
>> >
>> > I mean the UseSerialGC.
>> >
>> >  yes the storage you listed are the major
>> >
>> >> pieces that we allocate in the CHeap.   There are many smaller
>> >> data structures that are allocated out of the CHeap.  For example,
>> >> performance counters are CHeap allocated.  Or just the storage
>> >> for various subclasses of Generation that the GC uses.
>> >>
>> >> I believe the largest piece of the CHeap that the compilers
>> >> use is the CodeCache and it is allocated before the Java
>> >> heap is allocated.
>> >
>> >
>> > The current "PrintMallocFree" seems broken already. Do you still use
>> > this to check the
>> > CHeap usage?
>> >
>> > Thanks,
>> > Neo
>> >
>> >>
>> >> Jon
>> >>
>> >> Neo Jia wrote:
>> >>
>> >> > On 5/14/07, Jon Masamitsu <Jon.Masamitsu at sun.com> wrote:
>> >> >
>> >> >> Neo,
>> >> >>
>> >> >> Are you asking specifically about CHeap usage by the
>> >> >> garbage collector (i.e., you're not interested in the
>> >> >> compiler's use CHeap space)?
>> >> >
>> >> >
>> >> > Jon,
>> >> >
>> >> > Although my question is about the CHeap usage by GC, I am also
>> >> interested
>> >> > in knowing the CHeap space usage of compiler.
>> >> >
>> >> > Thanks,
>> >> > Neo
>> >> >
>> >> >>
>> >> >> Jon
>> >> >>
>> >> >>
>> >> >> Neo Jia wrote:
>> >> >>
>> >> >> > hi,
>> >> >> >
>> >> >> > I am wondering that for the generational mark-sweep GC, if the
>> >> block
>> >> >> > offset shared array is the last allocated object on the CHeap.
>> >> >> >
>> >> >> > The following is my understanding of the current heap layout:
>> >> >> >
>> >> >> > 1. The nursery space is on the lowest address
>> >> >> > 2. The mature space is following the nursery address.
>> >> >> > 3. The permanent space is following the nursery address at a 
>> higher
>> >> >> > address.
>> >> >> > 4. The card table is allocated from the end of the permanent 
>> space,
>> >> >> > the regions inside it will be mapped to these previous three 
>> spaces
>> >> >> > sequentially, from lower address to higher address.
>> >> >> > 5. The block offset shared array used by the mature space 
>> will be
>> >> >> > allocated at the end of the card table area, which is used by
>> >> mature
>> >> >> > space. And the virtual space size of this area will be set
>> >> according
>> >> >> > to the mature space and word bits.
>> >> >> >
>> >> >> > So, is there any space allocated following?
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Neo
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>



More information about the hotspot-gc-dev mailing list