A simple PIC api

[Mark Roos]

Hi Rémi,

I assume you want me to be more specific about my concerns on:
        taking into account invalidation, multi core memory model and 
volatile state. 

My model is that I have a GWT chain, a cache, and  a fallback which is 
updating the chain, and more
than one core using the same callsite.

So I have shared mutable state in the callsite holding things like depth, 
a list of receivers and the
current target.  It is likely that the two threads could be setting 
different targets etc.  So I worry
about syncing access.  But that seems like it could be expensive even 
though the possibility of
a collision would be rare.  Seems like a place for STM :).  I currently 
lock the callsites mutable parts
but I am not sure if I can lock the entire site or if I even should. 
Obviously most to the time the
site can be shared with no issues.  Perhaps its enough to lock the 
fallback?

The volatile state question is about the sharing of the call sites across 
threads.  It really ok if the
two threads create different caches as the code executed is always 
correct.  But when I change code
on the fly the caches all need to update so I need to make the cache 
volatile.  I can do this now with
a switch point so its not a big deal.

My invalidation concern is that as I update my chain that the jvm decides 
that I no longer deserve to
be inlined.  Especially when I drop the entire chain to rebuild it many 
times.

As I use object references for my test comparison I wonder if as they need 
to be tracked by the
GC does this add overhead.

I hope these are invalid concerns but if they were not I would think that 
letting the jvm know this was a pic
would allow it to handle them with a minimum loss in performance.

regards
mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20150311/45cb368b/attachment.html>