JDK-8164694 : possible problem with clean_weak_method_links
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-08-23
  • Updated: 2019-09-13
  • Resolved: 2019-08-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Duplicate :  
Relates :  
When we redefine classes, we make one attempt to call clean_weak_method_links().  But if the metadata is on the stack, we don't clear it.  It seems we could leave stale metadata behind this way.  I think we need to have the GC cleanup, clean_weak_klass_links call clean_weak_method_links.  Or maybe combine them together into clean_weak_metadata_links.
In JDK-8202447, VirtualCallData::clean_weak_method_links() was changed to check is_old() instead of on_stack(), so this may already be fixed.

Removed JVMCI tag. We were already storing Method*'s in the MethodData before jvmci, but with jvmci there are more cases to handle.

For "extra data", liveness for cleaning is based on !is_old(), but for VirtualCallData it's based on !on_stack(). It seems like we should use the same liveness for both kinds of data. If we use is_old, then we need to make sure new is_old data cannot be added (can this happen because of old methods that are "on stack"?). If we use on_stack, then the whole MethodData should go away when it's no longer "on stack".

Hi Dean, I'll assign this issue to you for now so that you keep track of it. Somebody else on our team might eventually pick it up (unless you have some time to look into it yourself). Thanks, Zoltan

ILW=possible crash not yet seen in practice,problem not yet seen in practice,no workaround=MLH=P4