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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
