hlovatt schrieb:
> If you treat the problem as a multiple-dispatch problem, can't you?
>
> 1. Issue all code without using the type information, as though
> everything was Object in Java lingo. Doesn't stop the compiler from
> issuing type errors, but not worth optimizing compiler output.
that depends on your language. In Groovy we have cases were you would
need static type information
> 2. Use whatever method resolution algorithm you need to find the
> desired method and put the found method in a method handle.
>
> 3. If a new method is loaded, invalidate all the handles. The new
> methods are loaded by the class loader and therefore this is a thread-
> safe operation and you don't need any additional locking.
this sounds like the wrong order... method lookup in the sense of
invokedynamic+bootstrap is done if the callsite has not yet a method or
the method was invalidated. Usually you want to do just a simple check
if that method is still valid. If you now do a complete method
selection, then this is certainly no simple check and will most probably
cost you big times, unless your method selection process is really
really fast.
> 4. Surround the call to the method with a try catch block that looks
> for a class cast exception; if the exception occurs, then under a lock
> invalidate the method handles and retry. To reduce code bloat, isolate
> pure code and group this into one try block. EG if p1 and p2 are pure
> functions then:
>
> try { p1( ... ); p2( ... ); }
> catch (ClassCatchException notUsed) { lock(); invalidateMethodHandles
> (); p1( ... ); p2( ... ); release(); }
>
> (Better still, the sequences p1( ... ); p2( ... ); could be replaced
> by a function call.)
This assumes p1 and p2 cannot normally cause such an exception. If that
assumption is right for your language I don't know. In case of Groovy it
certainly is not.
bye blackdrag
--
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
-~----------~----~----~----~------~----~------~--~---
