> From: Charles Oliver Nutter > As above, volatility is not important if threads are actively > guarding. It only becomes a problem if you expect threads to reflect > call site changes automatically without doing any of their own guard > logic
My question is if I do not do a sync operation when do the callsites get the new values. Its always referenced to threads so are the targets cached relative to a thread? If this is true then new threads will always get new targets. Of course if I use a pool or a timer I would guess that the targets may never update. So far each I get a new thread for each request and am not doing any sync and it works. But.... > Specifically, I was looking up the > method before I got the class's SwitchPoint...which is exactly the > wrong order. There were cases where I could end up associating the > looked-up method with a newer SwitchPoint, effectively caching forever > the wrong method. I can see this as an interesting problem. One could presume that there is possibly a thread between the switchPoint and the fallback when the switch fires. So when it goes a get the target it could be the new target which it then pollutes. So the switchPoint needs to relace itself and the callsite when it fires so the old fallback updates the one being dropped and not the new. I have callsite-switch-callsite as it is but I need to make sure that the second call site is what is passed to the fallback and not the first or root. thanks mark
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
