RFR: 8256020: Don't resurrect objects on argument-dependency access

[Erik Österlund]

On Tue, 10 Nov 2020 19:05:41 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>  
> 
> > > The original assert seems to imply that a new MutableCallSite refers to an old but unmarked DirectMethodHandle.
> 
> > 
> 
> > Sounds like the old MutableCallSite escaped the snapshot at the beginning somehow. Maybe it is related to your new reference processor?
> 
> 
> 
> Hmm I think it is more subtle than that.
> 
> I changed all occurances of argument_oop() one-by-one with the 'phantom' variant to narrow it down. It really is the flush_dependencies() method that breaks it. However, as you noted, it cannot accept NULL there, otherwise it would crash. However, we *do* have a special code-path there that returns the original object instead of NULL *when the calling thread is not a Java thread* (See https://bugs.openjdk.java.net/browse/JDK-8237874). I believe this is why the fix helps. OTOH, if I don't do this, the remainder of the barrier would evacuate the object, and thus make the unreachable object alive again. :-S I suspect that we must skip evacuating objects when we get AS_NO_KEEPALIVE, but that seems to result in a "memory stomping" error. Grrrr.

Any non-raw access load should expose only the to-space object. But that is completely orthogonal to whether it should be marked or not. And obviously, having completely different semantics for accesses depending on whether the access is performed on a Java thread or not, is not a good idea. Sounds like the barrier code needs fixing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1113