[concurrency-interest] NavigableMap implementation bugs
Osvaldo Pinali Doederlein
osvaldo at visionnaire.com.br
Mon Jun 9 21:09:52 UTC 2008
Doug Lea wrote:
> I don't think so. Relaying the subset methods to the *Set classes
> was just an implementation expediency under the mis-thought that they
> would take care of recursive subsets etc rather than needing
> special implementations for KeySets. But the byproduct for remove()
> is clearly wrong so they do need separate implementations.
>
This remembers me from an old pet peeve, the fact that java.util.HashSet
is implemented as a wrapper over java.util.HashMap. This sucks
performance-wise, due to the additional indirections everywhere, and
even more important, because every entry single object is larger than
necessary - it contains a key and a value fields, but a single field
would be necessary for HashSet. If you have a Set with millions of
entries, the overhead of one useless pointer per entry is significant.
Plus, the wrapping implementation uses a dummy, fixed Object instance as
the value for all entries - and this may create another subtle
performance problem: large numbers of "cross-space" references in the
heap. I know that in most GCs only old-to-young refs are evil, but it
seems that in some GCs any cross-space reference is bad (requires remset
tracking), like Detlef et al's new "Garbage-First" collector (if I
understood it).
Back in J2SE1.2 time, the runtime savings from the wrapping
implementation could be significant... but, today? The HashMap* classes
inside the latest rt.jar are 18,5Kb total (uncompressed), versus 3Kb
from HashSet. That's a 12Kb of space saving, plus some small saving in
JIT time too. I'd say that this is an irrelevant advantage, even in
JavaME. The performance bonus of a tuned HashSet, however modest, would
certainly be much more significant. I know it's ugly from a maintenance
POV to have two large classes that will be 90% identical, but to
paraphrase the movie Some Like It Hot, nothing is perfect...
A+
Osvaldo
--
-----------------------------------------------------------------------
Osvaldo Pinali Doederlein Visionnaire Informática S/A
osvaldo at visionnaire.com.br http://www.visionnaire.com.br
Arquiteto de Tecnologia +55 (41) 337-1000 #223
More information about the core-libs-dev
mailing list