[gclist] Garbage collection and XML

Bryan O'Sullivan bos@serpentine.com
Tue, 6 Mar 2001 21:19:37 -0800 (PST)


[Claims that this thread is relevant to garbage collection are
starting to feel a little weak.  Oh well.]

d> However, you could also play the game of indexing your entities,
d> and indexing instances of entities.  That is, map objects to
d> integers. [...]  This is probably too horrible to contemplate for
d> most people, given that you've got untyped integers instead of
d> typed objects, and no garbage collection at all under the covers.

I actually went off and did this for an indexing and searching app
fairly recently.  Provided your API doesn't reveal the integer-ness of
the underlying representation to its users, and can overcome the cost
of converting back and forth at method entry and exit points, it is
possible to surprise people with the kind of performance and memory
overhead you can sustain with this kind of Java application.

The usual fearsome memory requirements lose some teeth as integers
aren't as heavily-boxed as objects in Java.  Granted, you now have
huge tables of interned strings sitting around that won't shrink or go
away until you drop all references to the entire tables, but for this
kind of application, it's easy to sidle around the problem with
references to "necessary time/space tradeoffs".

What is less fun is writing and maintaining the code behind the
pristine-looking API.  Unless you want to rebox all the integers you
had carefully unboxed earlier so you can use the java.util.Map
interface, you're condemned to CS201 rebuild-silly-data-structures
hell.

Makes one yearn for parametric classes and interfaces, =E0 la GJ.

	<b