Running hotspot with valgrind to detect memory leak?

[steve goldman]

Sandeep Konchady wrote:
> Neo,
> 
>    I have not done any extensive work on Valgrind, so I am not sure how 
> best to interpret the logs. That said the one interesting thing is that 
> there is a leak listed in nmethod call just before it crashed. However 
> the overall leak was not that significant. Let me know if you want to 
> take a peek at the complete log.
> 
> ==00:00:17:26.750 6946== 3,587,249 bytes in 2,672 blocks are still 
> reachable in loss record 264 of 264
> ==00:00:17:26.750 6946==    at 0x4021620: malloc (vg_replace_malloc.c:149)
> ==00:00:17:26.750 6946==    by 0x6328E96: os::malloc(unsigned) (in 
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
> 
> ==00:00:17:26.750 6946==    by 0x61A7FD8: 
> CodeBlob::set_oop_maps(OopMapSet*) (in 
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 

The humorous thing here is the comment in that piece of code:

   // Danger Will Robinson! This method allocates a big
   // chunk of memory, its your job to free it.

However the _oop_maps are freed by CodeBlob::flush() which is called by 
nmethod::flush() when we finally remove an nmethod. So I don't see the 
leak directly and unfortunately the log is only showing the allocation 
site not where it leaks. Since nmethods are coming out of the codeCache 
which isn't malloc'd memory I have to wonder if valgrind is being 
tricked here. I have no experience with valgrind so I don't know if that 
might be the case.

-- 
Steve