Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New (revolutionary?) solution for Java memory leak discovery: Plumbr explained

plumbr.eu

Post reply on HN
Print view View original

11–20 of 23 posts

Re: New (revolutionary?) solution for Java memory leak discovery: Plumbr explained

#11

Post by riffraff »

mvanga wrote: post #4
white_devil wrote: post #3

Earlier quoted context omitted.

How and how often do Java memory leaks actually happen? It's never stricken me as a problem. I guess some kind of global variables are involved.

You might, for example, insert an entry into a hashtable and forget to remove it. The garbage collector can't go and clean it up because it can't know whether you plan to use it or not. This way, over time, the memory usage keeps growing.

also, as grandparent guessed, static and thread local variables do not have the same lifecycle of the "normal" objects, I've been bitten more than once by some "clever" optimization caching stuff in those places.

Re: New (revolutionary?) solution for Java memory leak discovery: Plumbr explained

#12

Post by Ubersoldat »

ivoivo wrote: post #6
Ubersoldat wrote: post #5

Detecting memory leaks is easy: run some stress tests before deploying to production! I mean, I don't see the use of this tool. Attach it to a live JVM to detect leaks which shouldn't be there?

It tends to be more complex than this for several reasons: a) you usually cannot simulate the exact behavior of users in production environment. Users tend to be quite creative in ways they approach your workflows and your artificial tests might not catch it b) Your dev/test/staging environment is usually not a 100% replica of the production site - you might lack access to some integrated systems, have different data…

Totally agree and this tool might help in this situations but still I find it more suitable to simply watch the memory usage, which in a sane application, should have a pattern.

Re: New (revolutionary?) solution for Java memory leak discovery: Plumbr explained

#13

Post by antonyh »

Neat idea, but not working for me. I tried with with Day CQ5 CMS, and Plumbr starts but it looks like it stops while loading the Lucene indices.

This would have been useful 9 months ago when we were tracking an object leak. Stress tests with AB and monitoring with jconsole combined with reading the code were sufficient to find the problem.

I advise caution, particularly with false-positives (objects with long lifecycles). If it was so easy to find the leaks, the GC would be able to resolve the leak itself.

Re: New (revolutionary?) solution for Java memory leak discovery: Plumbr explained

#14

Post by yxhuvud »

Ubersoldat wrote: post #5

Detecting memory leaks is easy: run some stress tests before deploying to production! I mean, I don't see the use of this tool. Attach it to a live JVM to detect leaks which shouldn't be there?

Finding out that you have a memory leak is a lot easier than to find what part of the code is responsible for that leak, for nontrivial code sizes.

Re: New (revolutionary?) solution for Java memory leak discovery: Plumbr explained

#15

Post by priitp »

Scotchy wrote: post #10

Everytime I open a report, it hits http://app.plumbr.eu/decrypt_report with an encrypted version of the report. Even if you don't store that information, and even if it is not really useful, you should maybe note somewhere that all the "leak" information is sent to Plumbr servers.

RTFM ;)

The info is sent when you click the Decrypt button, and there is an explanation right above the button: "You are running Plumbr with evaluation license, which means that all Plumbr reports need to be submitted to our server to see full details. /---/"

Re: New (revolutionary?) solution for Java memory leak discovery: Plumbr explained

#17

Post by spacemanaki »

white_devil wrote: post #3
DanielRibeiro wrote: post #2

Really nice. I've used Yourkit profiler quite a few times to solve java memory leaks, but this automated detection seems awesome. Thanks for sharing.

How and how often do Java memory leaks actually happen? It's never stricken me as a problem. I guess some kind of global variables are involved.

Here's a rather complicated example from Android: http://developer.android.com/resources/articles/avoiding-mem...

It's pretty Android specific, but the general idea probably can happen in other contexts (pun intended), when some framework or other retains a reference to something you expect to be garbage collected.

Re: New (revolutionary?) solution for Java memory leak discovery: Plumbr explained

#18

Post by raganwald »

white_devil wrote: post #3
DanielRibeiro wrote: post #2

Really nice. I've used Yourkit profiler quite a few times to solve java memory leaks, but this automated detection seems awesome. Thanks for sharing.

How and how often do Java memory leaks actually happen? It's never stricken me as a problem. I guess some kind of global variables are involved.

Speaking as a fellow who won a Jolt Award for JProbe, ( shoots cuffs), there are lots of ways memory leaks can happen. A "Lapsed Listener" occurs when an object is no longer active but is pinned by another object observing it for changes. The infrastructure should have removed the observer's reference of used a weak reference.

A "Lingerer" is an object that should be garbage collected when it is no longer needed, but is not garbage collected until another object replaces it. For example, if you have some sort of process pool like a pool of database connections or request handlers, you might have memory that is needed to handle a request. Many naïve programs free that memory when creating another request by overwriting references to it. However, it should be freed when the request has completed. Although the memory is not permanently pinned, performance suffers by having it "linger" unecessarily.

These types of memory leak anti-patterns apply to all garbage-collected languages.

Re: New (revolutionary?) solution for Java memory leak discovery: Plumbr explained

#20

Post by Scotchy »

priitp wrote: post #15
Scotchy wrote: post #10

Everytime I open a report, it hits http://app.plumbr.eu/decrypt_report with an encrypted version of the report. Even if you don't store that information, and even if it is not really useful, you should maybe note somewhere that all the "leak" information is sent to Plumbr servers.

RTFM ;) The info is sent when you click the Decrypt button, and there is an explanation right above the button: "You are running Plumbr with evaluation license, which means that all Plumbr reports need to be submitted to our server to see full details. /---/"

True that, sorry for being blind.

Nonetheless, people upvoting my comment probably shows that many people missed that.

Post reply on HN