JDK-8261848 : LOOM: SA needs to add support for scanning StackChunks
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 19,repo-loom
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2021-02-16
  • Updated: 2023-10-24
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 :  
Sub Tasks
JDK-8293669 :  
Description
SA needs to add support for scanning StackChunks in order for the "reverse pointer" support to work properly and find references to objects that come via a StackChunk (directly or indirectly).

The heap scanning starts with the roots, and then does recursive scans of each root object. I've been tracking down how it does this recursive scan. It looks like when visiting a non-array type, you end up in the following Oop method:

  public void iterateFields(OopVisitor visitor, boolean doVMFields) {
    super.iterateFields(visitor, doVMFields);
    ((InstanceKlass) getKlass()).iterateNonStaticFields(visitor, this);
  }

I think if we add InstanceStackChunkKlass::iterateNonStaticFields(), we can have it make the visitor.doOop() call for each oop in the StackChunk, so this might be pretty easy to do. Writing a test will probably be the hardest part.
Comments
A test for this issue would need to create a vthread that has a frame that has the only reference to an object that is the only instance of a given type. The test needs to force the vthread into an unmounted state, and then use something like SA's jhisto to see if that type shows up in the output. Once the test can reliable do that (and show that currently the type does not show up), then I can work on a fix and have the test help prove that it is working. As for how to get the vthread to unmount, I think the following overall approach for the test will work: 1. Limit the number of carrier threads to 1 2. Create and start a vthread that creates a stack reference to an object of the specified type. 3. Have the vthread do a long Thread.sleep() 4. Create and start a second vthread. This should unmount the 1st vthread. 5. Have the second vthread be responsible for triggering the jhisto on the test process. Check the jhisto output for the specified type. Note we need to be careful that the java code executed to run jhisto does not cause the vthread to unmount. It might be necessary to spawn a separate (regular) thread to do that, and have the 2nd vthread simply wait in a tight loop until the jhisto thread is done. The 2nd vthread cannot do anything that might cause it to yield during this loop, so it probably will just loop until a static variable is set true.
25-02-2021