And done - reported to Jetbrains. We'll see what comes out of it. For once I think this is a simple problem: The breakpoints of IntelliJ can be used to actually do logging without recompiling the code. You simply define a breakpoint which won't pause the execution; but that will print a String expression to the console. Something like *"This is Foo " + foo*. No state is modified - just a print statement is done. I hope it's not difficult to release the objects used in the expression.
But then again, the apparently simplest problems were often the hardest to solve. :-) On Wed, May 4, 2011 at 22:19, phil swenson <[email protected]> wrote: > gotcha... nm > > On Wed, May 4, 2011 at 2:13 PM, Kirk <[email protected]> wrote: > > I'd report it but I'm not sure that there is much that they can do about > it. They need to keep references to a lot of this stuff to support debugging > operations. The profiling stuff is the same. Very difficult to figure out > what is going on without injecting some tooling which starts hanging onto > things of interest. > > > > Kirk > > > > On May 4, 2011, at 10:04 PM, phil swenson wrote: > > > >> I hope you are submitting a bug report to JetBrains :) They are very > >> responsive.. > >> > >> On Wed, May 4, 2011 at 5: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. > >> > > > > -- > > 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.
