JDK-8195120 : Finish SA OopStorage support
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 11
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2018-01-16
  • Updated: 2024-04-29
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.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Description
JDK-8194312 added the class OopStorage.  It provided enough of an implementation for SA to be able to pass existing tests.  However, that SA implementation is just a stub, and needs to be finished.

Comments
What is needed is the implementation of the following OopStorage methods: public boolean findOop(Address handle) { // TODO: walk OopStorage to find the Oop return false; } public void oopsDo(AddressVisitor visitor) { // TODO: Visit handles in OopStorage } This requires adding the ability to access OopStorage instance fields, and knowing how to access the data in those fields, which are themselves of types that SA does not currently know about (Block, ActiveArray, and AllocationListEntry). There may be more. As for how this lack of support currently impacts SA, I can find 3 areas: - PointerFinder (as exposed by the clhsdb findpc/whatis commands) will not be able to properly detect if an address is a JNI global. It does have the proper logic in place, but relies on OopStorage.findOop(addr), which currently is not functional. - ReversePtrsAnalysis (as exposed by the clhsdb revptrs command) will not be able to include JNI globals in its analysis. - Heap dumps are not writing JNI globals (HPROF_GC_ROOT_JNI_GLOBAL). Once again the code is in place, but relies on OopStorage.oopsDo(addr) Note there are other types of OopStorage other than for JNI globals, but it seems these are primarily to cover roots embedded in hotspot objects (like a java.langThread oop in a hotspot Thread object), which is something SA was never taught how to access, so I don't think this part of the OopStorage support impacts SA.
29-04-2024

Changing this from an enhancement to a bug.
20-05-2021

My understanding is that without updating SA to know about OopStorage, many GC roots are potentially missed, resulting in an incomplete full heap dump or scan.
20-05-2021

webrev for JDK-8194312: http://cr.openjdk.java.net/~kbarrett/8194312/open.01/index.html
26-01-2021

[~kbarrett], can you clarify how/why this is important to SA? Is there some functionality that is missing or inaccurate as a result the lack OopStorage support?
26-01-2021