John Rose schrieb:
Here's something to think about as an alternative to the
instanceof/cast/invoke dance for getting metaclasses.
At the Summit we were talking about managing metaobjects via a
class-specific analogue of ThreadLocal. Here's a sketch of what the JSR
292 EG is thinking about in that vein:
http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm-0908/java/dyn/ClassValue.html
The implementation of such a thing should be tuned (as ThreadLocal is
tuned) to execute in a small number of memory references, without locks
or volatiles. Ideally the code would use a one-element cache, like this:
RubyClass metaClass = RUBY_META_OBJECT.get(object.getClass());
=>
mov (object+4), classtemp
mov (classtemp+56), cachetemp
cmp (cachetemp,8), RUBY_META_OBJECT
jne slowpath
mov (cachetemp,4), metaClass
This provides an alternative path to interface injection for storing
per-runtime data on *all* classes (RubyArray and java.lang.String
alike). How useful would this be?
Your feedback might help us decide on where ClassValue sits in a Plan
A vs. Plan B feature cut, if such a cut comes about. See Mark Reinhold's
blog for the A/B conversation.
Plan A and Plan B is speaking of the release plans for jdk7 I guess
I think this feature would absolutely be useful to us. When I think
about mutation, then I see some small problems in the typical usage and
how this might be done. A custom MetaClass might be created outside by
the user and then set. How could that be done with this get logic? If I
first somehow have to ensure that this from outside coming MetaClass
object is fully realized in the sense of concurrency, then this will
probably spoil all the fun about not having locks or volatiles.
where it would absolutely help is with no longer having to Weak or
SoftReference the MetaClasses and leave it to the VM to clean them up
once the Class can be collected.
Since I had some trouble with the IBM JDK in the past it would also be
good to clarify that if that MetaClass references the class it is
assigned to, that this class can still be collected. The Sun JDK has no
problem with that if the metaclass is not hard referenced, but the IBM
JDK versions we had needed special action, luckily on the command line only.
bye Jochen
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
--
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.