Call site caches may not be thread safe
---------------------------------------
Key: JRUBY-2048
URL: http://jira.codehaus.org/browse/JRUBY-2048
Project: JRuby
Issue Type: Bug
Components: Compiler
Reporter: Charles Oliver Nutter
Assignee: Charles Oliver Nutter
Fix For: JRuby 1.1RC2
The call site cache we have currently, InlineCachedCallSite, may not be
thread-safe. In general, it will not break in any catastrophic way. However it
is the case that if two threads attempt to call against the same site at the
same time, and they're both calling against the same type, and while they're
calling against that type the type is changed by a third thread, and the last
thread to win when updating the call site updates it with old information.
Or a simpler case that springs to mind: while a thread is in the call site, the
type in question changes; because the call site has not yet registered itself
with the type it does not get flushed out by the change, and so we end up with
a call site caching the old method forever (or until the next rebinding of that
name).
This may indicate a key flaw in the push logic for changes, requiring either
synchronization as part of cache updating or requiring more guards in the call
sites themselves (for example, guards to flush the call site if a class serial
number has changed since the last cache).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
