Rémi Forax wrote: [...]
call site is not immutable. You can change the target method handle and by design the target method handle is not stored in a volatile field.
Well I am speaking about Groovy on pre java7 here. I think for the backport it might not be a good idea too. Of course I know this conflicts with the nature of being a backport. But if you have to go throug a memory barrier for each time you access the target of a call site, then this surely is no pro for the performance. For me the conclusion is that the code for pre java7 and java7 will differ in more ways than what a backport offers. This means maybe the invalidation, but surely means the MethodHandle target.
[...]
Another solution is to not do the polling at each call but just increment a counter and do the polling let say every 1000 calls. If I finally decide to implement invalidation, I think I will implement it like that.
Even though the counter would be accessed concurrently a simple non volatile int field without any memory barriers when you access it would be enough. It does not matter if it is not exactly every 1000 calls I guess. If 10 threads are running, it can very well happen, that much more than 10000 calls are made before new polling occurs. And it can also happen, that all threads in a short period reach the 1000 count and you get a lot of polling.
I am a bit worried about hotspot here. And if you do it using memory barriers it is not better than polling.
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.
