Steve Byrne wrote:
>
> Vincent Trussart writes:
> > One way to handle this problem would be to create an Object pool.
> > There was an article on javaworld (www.javaworld.com) a few months
> > back. Basically, instead of creating new objects you request them from the
> > pool. When they are not needed anymore, you put them back in the pool. This
> >
> > way the GC won't collect them.
> > The pool must be able to "clean up" objects and so on...
>
> Right. I've known projects that have done this and won big. Creating objects
> is somewhat expensive because it's a synchronous operation, and synchronized
> operations are slow in the 1.1 VM (1.2 uses a completely different and clever
> trick to get the overhead of synchronization down into the noise).
Another design pattern is the Flyweight (from the GOF "Design Patterns"
book on just about everyone's bookshelf these days) for large numbers of
objects; the example given is modeling individual character glyphs in a
word processor implementation.
Both of these ideas really are avoiding the whole instantiation thing
entirely, which may not be what you were looking for - but in any OO
system, especially one with garbage collection, you have to consider the
overhead that each object has above and beyond the memory size of its
state. If you were to build a ton of objects, use them and drop them,
you'd be stressing the GC for sure.
Hotspot and 1.2 promise to help with the both ends of the problem -
we'll how that turns out.
--
Paul Reavis [EMAIL PROTECTED]
Design Lead
Partner Software, Inc. http://www.partnersoft.com
