memory leaks?

[Srinivas Ramakrishna]

Hi Sunny -- good to know. I had suspected these might be from libc's
malloc; thanks for confirming.
We still need to see if it's a real native memory leak or just an artifact
of the malloc implementation.

thanks for the very useful pointers!
-- ramki

On Sun, May 27, 2012 at 10:14 PM, Sunny Chan <openjdk at sunnychan.hk> wrote:

> Srinivas Ramakrishna <ysr1729 at ...> writes:
>
> >
> >
> > Just a quick question in case any one might remember off the top of their
> head...Are there any native memory leaks that may have been fixed in JDK 7
> and 8
> that haven't yetbeen backported to JDK 6uXX?No need for any research...
> just a
> quick check to see if anyone recalls anything recently thatfixed native
> leaks...
> i'll go check the hg logs momentarily to see if anything jumps out.I am
> suspecting some 64 M segments that I see in pmap, and am yet to figure out
> when
> and where
> > these are coming from... The leak is abrupt and likely the result of a
> rather
> rare/infrequent event.I'll see if I can find a DTrace that works on Linux
> and
> log mmap/munmap calls to get more info.thanks for any (even very vague)
> pointers.
>
>
> Are you using RHEL 6 or equivalent? RHEL 6's GLIBC has a new malloc
> implementation that create specific malloc arena to improve threaded malloc
> (similar to TLAB in Hotspot). These appears as lumps of 64M blocks with a
> couple
> of page in front, like this:
>
>
> 7f99c0021000-7f99c4000000 ---p 00000000 00:00 0 (132k)
> 7f99c4000000-7f99c4021000 rw-p 00000000 00:00 0 (64M)
> 7f99c4021000-7f99c8000000 ---p 00000000 00:00 0 (132k)
> 7f99c8000000-7f99c8021000 rw-p 00000000 00:00 0 (64M)
> 7f99c8021000-7f99cc000000 ---p 00000000 00:00 0 (132k)
> 7f99cc000000-7f99cc021000 rw-p 00000000 00:00 0 (64M)
>
> You can switch off the malloc Arena by setting MALLOC_ARENA_MAX to 1 or 4 -
> there are a couple of team tested this and seems to have no negative
> performance
> in general Java workload - but there will be impact if you do multithreaded
> native malloc.
>
> see
>
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/kevgrig/entry/linux_gl
> ibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120528/89411c6d/attachment.html