Rémi Forax wrote: > As far as I understand your code, you're creating one delegate by > OpenJDK method handle.
Yes, that's right. > I think it's better to create one only when you actually calls the > MethodHandle, i.e. when or invokeExact, invoke or CallSite.setTarget are > called so you will be able to use one ILGenerator for the whole method > handle tree. Yes, this is on my TODO list. > A nice way to do that is to record a stub delegate that will trigger the > generation of the IL and replace itself. This is possible, but it's complicated a bit by the need to have a different stub for each different signatures (using covariance and/or generics the number can be reduced substantially, but both add some complexity (e.g. covariance is not supported by C# 2.0 so it would complicate my build process)). > Maybe you can do better, it seems you can debug the CLR on the fly, this > should trigger a deoptimisation of the debugging codes so you may be > able to use it to deopt all codes that use a specific CallSite/static > final method handle to force the code to reload its variable from the > fields that should be marked volatile otherwise. The CLR doesn't support deoptimization :-( Only in .NET 4.5 they are adding something a little bit like it, but it is very limited and not intended for scenarios like this [1]. Regards, Jeroen [1] http://blogs.msdn.com/b/davbr/archive/2011/10/10/rejit-limitations-in-net-4-5.aspx -- 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.
