Callsite invalidation requirements?
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
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
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
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
Any comments on this last statement? Or suggestions in general?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mlvm-dev