[PJUG Javamail] Java Memory Management

[Richard Johnson]

Douglas neglected to mention that the DB was designed by a committee
external to the applications team, and that said committee placed (might
still place, for all I know) much greater emphasis on the importance of
fifth normal form than in whether data sets could sensibly be
represented as data objects.  
 
In other words, all of the many objects he had to work with were already
relations in the DB.  If I were a GC, I'd care primarily about relations
(references) and trying to figure out whether any object was free, when
it was a tangled mess of interdependent external references would drive
me buggy too.
-- 
Richard Johnson
who one tried to help Douglas with this and went home with a migraine
 

________________________________

From: javamail-bounces at pjug.org [mailto:javamail-bounces at pjug.org] On
Behalf Of Douglas Bullard
Sent: Tuesday, January 01, 2008 6:39 PM
To: Bill Kayser
Cc: 'Javamail'; 'Carlus Henry'
Subject: Re: [PJUG Javamail] Java Memory Management


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/20080102/72c451a3/attachment-0002.html>