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. That said, very surprising 'cos both VMs come from a common code base and the variants are very well isolated and well regression tested. But.... there are still a ton of bugs in the JVM so it might be worth a troll through the bug database... One thing, JNI based leaks generally come with a leak in C heap. You might want to check this overall growth in the process size over time. If it doesn't stabilize... bug in JVM. But first use the generational counts to identify the leak. It's more likely to be something in your code and the technique you're currently using isn't a reliable way of finding a leak where as the generational count is a perfect measure of a leak. Regards, Kirk -- 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.
