Callsite invalidation requirements?

[Mark Roos]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120214/d4495da2/attachment.html