Le 22/09/2010 22:24, Tom Rodriguez a écrit :
I wonder if the fix can improve performance of benchmarks that use java.util
collection,
because this API uses a similar class hierarchy scheme.
There are normally more than 1 or 2 implementors of the collection interfaces
so static information isn't as useful. Much of the time the existing type
profiling works great because we're only seeing a single type but of course
there are cases where it falls down.
Yes but most of collections inherits from an abstract class, AbstractList,
AbstractCollection etc,
so even if there are more than 2 implementors, they can inherits from the same
abstract class.
Collections.java by itself contains 3 unique implementors of the each of the
core collection interface to support checked, unmodifiable and synchronized
variants. These are unrelated to the abstract classes you mention above.
java.util.concurrent includes yet more unrelated variants. So looking at the
hierarchy is of little use for most of those interface types. Anyway we can
obviously do better than we are currently doing.
tom
You're right about checked, unmodifiable and synchronized, but checked
and synchronized variants
are rarely used and unmodifiable should inherit from their abstract
counterparts.
Also note that single and empty variants inherit from abstract versions.
For java.util.concurrent classes, queues (exactly blocking queues) are
used in a polymorphic way,
the other classes like ConcurrentHashMap, CopyOnWriteArraySet, etc are
rarely involved in
a polymorphic callsite.
Rémi
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
