[PJUG Javamail] Java Memory Management
dbullard at nurflugel.com
Wed Jan 2 02:39:19 UTC 2008
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
> 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...
More information about the Javamail