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