John Rose schrieb: > See Jesse Glick's bug along these lines: > http://bugs.sun.com/view_bug.do?bug_id=6389107 > > It's the closest thing I know of to a systematic overview of these > sorts of RFEs. (Caveat: I'm not a GC expert.)
Yes, that goes in the direction... this link method could even be void as far as I am concerned. > On Mar 10, 2009, at 5:21 AM, Jochen Theodorou wrote: > >> If we keep that structure, then we would really need a different >> kind of >> reference... One that allows us to make a hard reference from the >> class >> object to our meta class. Something like: >> >> reference = new LinkingReference(x,y) > > Making this work in a GC is probably hard. GCs are designed to work > locally on compact representations of the heap graph. Adding a link > "on the side" like this seems to require non-local operations in inner > loops that have been carefully designed to exploit locality (e.g., in > L1/L2 caches). I'm not saying it's impossible, but it needs to be a > big enough win to pay for a considerable engineering effort. > > As I see it, the difference between this and weaker proposals is that > it (in effect) injects a field into an object, without the object's > cooperation. it could work as if we had a field without a name on x and the field value would be y, yes... > If we're going to ask the GC to inject reference values > into objects, let's go the whole way and inject module-specific > annotations (internally, fields) into uncooperative objects. It's > very hard to do this, especially in a non-relocating GC, without > bloating the header of every object, whether the feature is used or not. I see... unless there is already a slot for this and some kind of array or list structure to keep the references? Wouldn't that be possible? I am not really talking about injecting the field then. I am thinking of letting every objects have that slot from the beginning.. maybe it would be part of the header? The bloating should be limited then I think. > The weaker link injection scenarios can be done with cooperative > objects that have APIs to acept: Thread, Class, ClassLoader, etc. > > A variation on this design is to use interface injection. One of its > use cases is putting class-local values on uncooperative classes. > E.g., putting a GroovyMetaClass on java.lang.String. (We talked about > this last JavaOne.) Again, this is more feasible because it only > applies to classes, not arbitrary objects. well, if it works for classes then it would solve 100% of the problems of this kind in Groovy 1.5.x, but in not for per instance MetaClasses, as we have them since 1.6. You know, when I first heard of instrumenting java classes I thought what a great opportunity this could be. But the actual restrictions they have made them nearly unusable for many cases. In Groovy it is a common thing to have an arbitrary object from a parent loader we don't control. Anything that would help us would have to work with such an object or at last on its class Now in case of my reference idea the actual realization of the hard link would be fully up to the VM, since we wouldn't need any access to the link itself. Only maybe to cut that link, but that is out of scope for Groovy and could be simulated if not provided. This also means the link is fully hidden from the programmer. As for interface injection... I am worried about for example: """ If a type check ever finds that a given class does not implement an interface, that interface cannot later be injected into the class. """ What if an object comes from Java land into Groovy land and such a check has happened already? What ever we use to inject the interface cannot happen before the object enters Groovy land... how ever the injection is done itself. I didn't look at the prototype, but if interface injection again requires special action at the class loader level, then it might not be usefull to us at all... Also I wonder what happens if the class provides a method that also exists in the interface. I assume we cannot inject that method then... which means we would have to resort to clunky method names that hopefully are never used by the user.. or am I wrong here? or worse... what if for example the return types conflict? But considering all these problems are actually no problems, then there is still the fact that if I cast the object to this interface then it will show all that internal information. You wrote in your blog for example about GroovyObject and considering Attila's work with a generalized MOP this effect is in fact what we want. But it feels like making a field public that should be private instead. 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 -~----------~----~----~----~------~----~------~--~---
