Callsite invalidation requirements?

Mark Roos mroos at roos.com
Thu Feb 9 10:53:15 PST 2012


Since Smalltalk is usually single threaded I have not been focused on 
concurrency issues.  Now that I have
that working I have been looking at extending Smaltalk to a concurrent 
approach.

One issue that immediately came to the forefront is the invalidation of 
call sites when a setTarget is invoked.
I have two scenarios,  bulk invalidation of a large quantity of sites and 
the continuous updating of sites as
different methods are added to a site's  inline cache.  I have some good 
inputs from Rémi on the bulk issue 
so I would like discuss the continuous case.

My implementation was adapted from code shared by Rémi and Charles which 
generates a chain of GWTs as
new implementations are added.  For each new  method lookup a setTarget is 
done to the callsite adding
this new GWT to the head of the existing target.  Currently I am using a 
MutableCallSite with no calls to
syncAll() or any explicit means to sync the changes across threads.

This is working now for what I believe are these reasons.
        Smalltalk tends to be async thread handling with new thread for 
reach incoming message
        The lookups are due to adding a missing implementation not due to 
code replacement

Moving forward I see some issues.
        I would like to use thread pools and am concerned that they may 
have threads which are holding
        old targets.  This includes the use of Timer

        I will need multiple threads as workers to take advantage of cores

        If code does change there is the possibility that a thread may be 
executing some code which
        is old ( sync does not go back in time ) but that calls a new 
method which is dependent on the old.
        So it seems like I would like to hold off the sync of new code 
until all threads are finished
        executing ST code.

So I think there are two distinct scenarios,  code changes and 
implementation lookups.

For code changes I don't know.  Waiting for all threads to finish seems 
problematic.  When developing
this is probably OK but I use code changes in production to hot update 
systems and to add features
on the fly. 

For lookups I am not sure there is any need to sync.  If a GWT chain is 
missing an implementation
its just gets added.  As long as each thread gets the correct method the 
fact that some of the GWTs
in a chain are lost or duplicated by other threads is just an efficiency 
issue.  So just being thread safe
is enough.

Any comments on this last statement? Or suggestions in general?

regards
mark







-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120209/d6f5b3d0/attachment-0001.html 


More information about the mlvm-dev mailing list