Possible bug in nmethod::flush_dependencies()

[Roman Kennke]

We're encountering a bug with Shenandoah:

https://bugs.openjdk.java.net/browse/JDK-8231999

That looks to me like an upstream bug in nmethod::flush_dependencies().

The assert that happens there is caused by call_site being NULL in
flush_dependencies().

If you look at nmethod::flush_dependencies() (nmethod.cpp around lines
1533-1542) you'll see that it makes a DepStream from the nmethod. It
then fetches argument_oop(0) from it. If you look at dependencies.cpp
lines 978 DepStream::argument_oop() it will call recorded_oop_at() which
(when using _code, which is the case here) will call nmethod::oop_at().
Which has if (index == 0) return NULL.

In other words, the way the code is written, call_site is basically
guaranteed to be NULL. Yet,
java_lang_invoke_CallSite::context_no_keepalive() expects a non-NULL
call_site argument.

Maybe I am missing something? Can anybody make out how this is supposed
to work?

Thanks,
Roman