[PJUG Javamail] Java Memory Management

[Douglas Bullard]

Pretty easy:
Have a large, complex data structure (like a catalog of items, with  
many items and components, for a complex object structure)
Put that in a database.  Have thousands of these things.  The same  
item can be in multiple catalogs.
Now, modify an item (for example, drop it).  Write your Hibernate  
stuff poorly so that this process retrieves only entire catalogs (big  
mistake number 1), not just the affected items.  Even worse, make sure  
all the objects are detached, so there's no lazy instantiation (bigger  
mistake number 2).  And, to completely fubar it up, each "master"  
catalog can have many "children" - a sparse matrix was used to  
represent this.  Turns out the assumptions of what was "sparse" were  
completely wrong, it's now "verbose", so we have 20 times as much data  
flowing as really needed (huge mistake number 3).   To complete the  
travesty, make sure management doesn't let you fix any of the real  
problems with the code - just make minor changes so it doesn't crash.
Run until the VM crashes.  Repeat


On Jan 1, 2008, at 13:37, Bill Kayser wrote:

> That's a neat trick.  I'd love to hear the details on that.  Do you  
> mean that you ran out of memory before the GC could clean everything  
> up?  I'm pretty sure I could write a program that did nothing but  
> allocate memory (non rooted) and I can't imagine the JVM would fall  
> over.
> You can swamp the garbage collector by creating too many objects,  
> generating them faster than it can collect them - we've run into  
> that with Hibernate at work.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://javac.com/pipermail/javamail/attachments/20080101/b45d3ed8/attachment-0002.html>