memory leaks?
Sunny Chan
openjdk at sunnychan.hk
Sun May 27 22:14:16 PDT 2012
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
More information about the hotspot-dev
mailing list