It's not perfect. But its pretty cool! false positive: Let's say you have a very long running open connection on a web server (comet or some such) and it's been almost a day since the last update or access. Its occupying memory for a purpose, and assuming the OS is still tracking the connection properly (i.e. the OS isn't buggy), the TCP/IP session is still valid, but no references are being made to it. This is presuming that the connection object is in charge of notifying the server when there's action to be taken (vs. the server framework pinging the connection object every so often, which would be a reference), and that the connection management object is set to wait indefinitely until the socket object reports some sort of traffic.
false negative: A buggy JVM or OS TCP/IP stack has somehow failed to notify a Socket object that its socket has disappeared. Instead, the socket will act as if no data is waiting, and any sent data is stuck, or worse, is relegated to the bit bucket. As far as the JVM server app knows, this connection is still valid, so it keeps a Connection object around (in addition to the Socket). The server will periodically ping every Connection object to ask if it needs to do stuff, but this particular Connection object is configured to never time out, and it falsely thinks there's still a reason for its continued existence. The number of such 'dead' Connection objects grows steadily, but everything is periodically referenced and thus not detected as a memory leak, even though by any sane definition of the concept, this really should be classified as a leak. A bit of an esoteric memory leak, perhaps, but then, in JVM applications, memory leaks almost always are, because there's no manual deconstruction. But, still, it's a good heuristic. If a certain type (class) of object has a large number of 'unreferenced' objects lieing about, where there is a time T so that enumerating all objects of that type which have been unreferenced for at least T milliseconds or more, so that the objects in this pool is (A) a significant number, growing steadily over time, and (B) no object that has showed up in the pool ever leaves it (by being GCed or referenced by a thread someplace), it is virtually guaranteed to be a leak. 'automagically' indeed, that's some serious voodoo. There's also the issue of missing leaks: What if you have a connection that is permanently 'stuck', for example because the OS stack has lost a 'this connection has been terminated' someplace somehow, but the server framework keeps periodically asking the connection object if it needs to do stuff. The reference tracker would say that this is not a memory leak, while in fact it IS a memory leak. Cool stuff. Hadn't thought of it! On Jan 1, 10:11 pm, kirk <kirk.pepperd...@gmail.com> wrote: > Actually... I've written about how one should be able to automagicly > detect memory leaks. Leaked objects are never accessed so if you track > access, you can find them. I had some discussions with the guy working > on the G1 collector and while there are some performance issues with > tracking references, the scheme was workable. While sorting through > details, a couple of papers came to light that detail similar schemes > for automatic leak detection. If I can work out the issue with write > barriers, this is something that could be dropped into OpenJDK.> FACT C: Its > possible to do a complete garbage collect, but this takes > > precious CPU cycles. This is worth it to avoid swapping, but it is a > > complete waste of time if the host computer has real memory to spare. > > It's not like unused memory saves power or some such. It's effectively > > a free resource, if its there. > > swap is an archaic optimization where disk is traded to create more > memory. Out machines now have more memory than one can shake a stick at. > If you've got 2-4 gigs on your machine, I'd turn swap off. I've done > this for my windows machines for a couple of years now. They have 2 gigs > of ram. Occasionally I have to turn swap back on when I'm doing > something that requires a lot of ram. However I normally use less than > 2gigs so turning off swap is no big deal. The performance boost it gives > is worth it. It also keeps my disk drive quiet which is a blessing for > the batteries in my laptops. > > 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 javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
