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.

Reply via email to