RFR 8174954: Parameter target type is allowed access after a module read edge or a package export has occurred after failed resolution

[John Rose]

On Oct 20, 2017, at 7:17 AM, harold seigel <harold.seigel at oracle.com> wrote:
> 
> I used a lock because, if resolution fails, the thread checks if another thread's resolution either simultaneously succeeded or failed.  I didn't see how to safely check both success and failure by another thread without using a lock.

Right; we would need a two-word cas to update both states atomically, using cas.

> The possibility of successful resolution by one thread while another thread's resolution failed with a LinkageError exception is unlikely (probably requiring a perfectly timed change to the module graph).

This is a real possibility with indy/condy, since BSMs can misbehave.

> Could the check for success be done outside of the lock, after the cas?  The resolution_error array element could then be cleared, if need be.

Something clever like that might be possible, but I don't see it yet.  (I was
hopeful!)  I think this suggestion can cause the erring thread to throw while
the winning thread sets a result.  The resolution_error element might be
acted on by the losing thread, if no message gets to it by the time it decides
what to do.  (Another thread might be doing a slow-motion cas at the same
moment.)

Basically, the resolved_refs array is null if either of two states holds:  Not yet
resolved, or resolved in error.  (The interpreter scurries into the runtime if it
finds a null, and DTRT.)  This invariant makes it true that, as long as nobody
ever sets the RR element to non-null, everybody can agree on a final state
if they use a lock.

I think if a non-null value is cas-ed in, and another thread is getting a failure,

There is one other way to make things work lock-free:  Represent the resolution
states (none, done, error) more fully in the RR word that gets cas-ed.  This would
require an interpreter change to DTRT if the RR word indicates the error state.

The indication could be simple sentinel value, an error_sentinel like the null_sentinel.
If the interpreter sees error_sentinel, it would call into the runtime, which would
then extract the error from a table and throw it.

Thanks for the helpful discussion.

— John