Attila Szegedi schrieb: > [...] > With that in mind I'll walk you through the code for fixarg resolution. > > line 100 of OverloadedFixArgMethod says: > objMember = argTypes.getMostSpecific(members); > "argTypes" is is an instanceof my ClassString class representing the > actual arguments of the parameters at the call site. It is passed a > list of all overloads (members) to select the most specific. > > getMostSpecific() will do the following: > 1. find all methods applicable to the argument types (as per JLS > 15.12.2) in its getApplicables() method. We do both applicability by > subtyping (JLS 15.12.2.2) and by method invocation conversion (JLS > 15.12.2.3) in a single pass, which is greatly helped by the fact that > we can not pass primitive values to our dynamically invoked methods > anyway, they're already wrapped into their object counterparts :-)
ah, ok, I missed that part. > 2. then we try to find all maximally specific methods among the > applicables (methods have a partial "is more specific" ordering based > on their argument types, see JLS 15.12.2.5). In case there's exactly > one maximal element, it is by definition of partial ordering the most > specific element, and it'll be selected to be invoked. If there's more > than one maximal element, we have an ambiguity and an exception needs > to be thrown. yepp, that part I found ;) > The "most specific method among all applicable methods for given > types" is a formal expression of "method most fitting the call". > > There's one additional hurdle though. With dynamic languages, there's > the question of what's the assumed Java type of the arguments used for > the call, right? I maintain a map of target types, one per number of > arguments for the overloaded method. I.e. if you have two 2-arg > overloads: > > foo(java.lang.String, java.util.List) > foo(java.lang.String, java.util.Set) > > then the target types for argument conversion for all 2-arg overloads > of foo will be computed to be [java.lang.String, > java.util.Collection]. When the method is dynamically invoked, the > passed callProtocol will be asked to provide a representation of the > first method as if it were a String, and to provide a representation > of the second method as if it were a Collection. Hopefully in the real > invocation, the second argument will already be either a list or a > set, so it will be returned unchanged. If it is however a collection > that is neither a list nor a set, then no method will be invoked and > an error will be thrown. that is different from what we do in Groovy, because in Groovy we "convert" just before the call and there will be no error, because invalid choices are already removed.No I guess what you mean is getting the argument types... ehm.. no again... why should the arguments depend on the unified method parameter types? Why not add a method that checks if a parameter is assignable to an argument and let the language decide how it should behave here. Then you might still need a coercion step before the call, but here again I would let the language plug in. [...] >> ah yes, one more thing.. isn't your marshalTypes and selectorCache in >> OverloadedFixArgMethod a good place for memory wholes? > > A memory leak? ehm, yes, sorry ;) > marshalTypes certainly isn't. It might retain Class objects used in > argument types of the overloaded method, but those can't be unloaded > anyway until the class that the method itself belongs could be unloaded. I call these usually parameter types to make a difference to argument types which are the types of the arguments of my call. > OTOH, selectorCache is, as it might retain a Class object that is a > subclass of argument types of the method, loaded through a different > class loader. I'd need a "WeakClassString" class that weakly > references its Class objects. > > That said, the "mops" map in BeansMetaobjectProtocol is the one that > should really be rewritten using weak references for keys and soft > references for MOP objects (and then when the class gets GCed, all > associated Overloaded*ArgMethod objects will get GCed as well, > resulting in marsalTypes going away). that would be ok then > There are other places in the > code that accumulate class references, i.e. > ClassBasedMetaobjectProtocolImpl. I'm aware of these issues, and > intend to address them. Caching information pertaining to Class > objects is tricky business as it's hard to get right - I've > implemented few systems already in the past. Most notably, you usually > can't use a map with both weak key and weak value refs, as that way > the value gets GCed too often and the cache miss ratio is too high, > mostly defeating the purpose. Using a weak key ref and soft value ref > is better in cache hit terms, but if your soft-cached value holds a > direct or indirect strong ref to the key object (and it does if the > value is a method or holds a method, and key is the class declaring > said method), then you've essentially promoted the weakly-referenced > key object to soft reachability instead of weak reachability once its > strong references are gone. Groovy uses a map with SoftReferences for the keys and values to store the MetaClasses > This'll postpone its GC and subsequent > unloading of its class loader, but is fortunately usually okay with > regard to memory management semantics otherwise, even if it can cause > higher temporary memory pressure (until soft references are cleared). > As usual, the lunch is not free, but if implemented properly it won't > lead to an OOME and all class garbage will get GCed even if with a bit > of an additional delay. a bad effect we noticed is that a MetaClass might get collected leading to a cache miss in the next call, causing the recreation of the class just to be collected again a later. This is bad, it slows down the program very much. I thought about counting the recreations or something or to keep a fixed number of classes... something like this, but I didn't come to a satisfying solution. > Anyway, these are issues I'm aware of, and intend to take care of. In > the first pass, I'd like to see the API and the implementation > stabilize without additional complexity of memory management issues. > Then when we're happy with it, I'll apply the required dosage of weak > and soft referencing where necessary :-) sure ;) bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.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 -~----------~----~----~----~------~----~------~--~---
