Interesting timing: yesterday I was helping someone on #scala figure out a similar retention problem. He was only using local variables and yet seeing a constant increase in memory.
It turns out he was using the REPL all along, which stores each result in a private variable as a convenience for the user, and the corresponding object was, of course, never released. -- Cédric On Wed, May 4, 2011 at 4:21 AM, Jan Goyvaerts <[email protected]>wrote: > Found the culprit ! > > The memory leak is caused by the debugger of IntelliJ. I'm using break > points to print a String expression about the progress on the default > output. Apparently the objects (ie. Foo) used in the expression are not > released. When disabling the breakpoints no additional Foo's remain in > memory. So I guess the native code was IntelliJ. > > And moving code to a sub-method seemed to stop the leak because the > breakpoint was removed. I used a patch to get the windows code to the Linux. > IntelliJ merged the patch but kept the breakpoints. Hence the Linux was > leaking while the windows wasn't. :-) > > Now, there's nothing older than two generations. That's a huge relief. > > On Tue, May 3, 2011 at 21:44, Kirk <[email protected]> wrote: > >> >> On May 3, 2011, at 9:29 PM, Jan Goyvaerts wrote: >> >> I was really wondering whether I missed something about garbage >> collection. Thanks guys ! >> >> It's the windows JVM it's working on. It's happily ploughing through all >> the data and regularly collecting. The Linux version doesn't. :-) >> >> Tomorrow I'll double-check the setup to make sure they're as similar as >> possible. And have a go with Kirk's advice. Didn't though about allocation >> stack traces indeed... >> >> >> You always want a profiler to provide you with a casual execution path. In >> this case you want to know how the leaking objects are being created. >> >> >> But I'm positive I had a memory leak on windows with the code in the loop. >> And no more leak when it was put into a method. So whether it's on Linux or >> windows - in both cases there's something weird. >> >> >> weird.. my sense is not to trust anything you're saying and perform the >> memory leak analysis as I've outlined. If the leak is technical, it will >> show as that. If it's application, it will show up as that. >> >> >> I've been trying on Linux with JDK 1.6 builds 23-25, the latest JDK7 and >> G1 garbage collection. Same result. >> >> I agree the JDBC driver will contain native code - but how on earth can it >> get a reference to an entity class ? >> >> >> The JDBC driver will use native code but a type IV driver doesn't contain >> native code. >> >> Regards, >> Kirk >> >> >> >> >> 2011/5/3 Cédric Beust ♔ <[email protected]> >> >>> On Tue, May 3, 2011 at 9:44 AM, Kirk <[email protected]> wrote: >>> >>>> >>>> On May 3, 2011, at 6:13 PM, Cédric Beust ♔ wrote: >>>> >>>> > Hi Jan, >>>> > >>>> > Nice job trimming down the list of potential suspects! >>>> > >>>> > I think that focusing on locals is a red herring. Locals do get >>>> collected and I can't imagine a JVM bug in that area, regardless of the OS, >>>> but I have a suspicion your loop is doing some side effects which are >>>> causing some other bigger objects to be retained. Sadly, this hypothesis >>>> seems to be invalidated by the fact that your code works properly on >>>> non-Windows JVM's, but it's not a 100% certainty yet. >>>> > >>>> >>>> Well, having the same code leak in Windows and not in Linux is very much >>>> smells like a bug. >>> >>> >>> Yes, but I was going with Occam's razor here: the bug is more likely to >>> be in applicative code (e.g. native JDBC drivers, like you suggested) than >>> in the JVM. >>> >>> Obviously, you need to keep both in mind until you've ruled one out. >>> >>> -- >>> Cédric >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "The Java Posse" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
