On Thu, 11 Jun 2026 17:04:30 GMT, Chris Plummer <[email protected]> wrote:
>> The PR resolves the issue JDI has with allowing collection of objects that >> are returned by the JDI invoke API before the caller of the API has a chance >> to call ObjectReference.disableCollection(). Details in the first comment. >> >> Consider this to be a prototype. I'm open to discussion on other possible >> solutions. I also still need to update the JDI specs to reflect these >> changes. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Chris Plummer has updated the pull request incrementally with one additional > commit since the last revision: > > support WhiteBoxAPI for debuggee I think the ObejctReferenceImpl cache could use some improvement. There are two main issues. The first is that it uses SoftReferences. That means a full GC (on the debugger side) is not enough to get them collected. The GC needs to determine that the heap is under enough memory pressure to warrant collecting them, which greatly delays, possibly indefinitely, how long it takes to collect them. The other issue is that VirtualMachine.DisposeObjects is not called until 50 ObejctReferenceImpls have been collected. That also can significantly delay disposal. I've prototyped the "always pin" solution, and ran into an issue with a test that allocates large chunks of memory on the debuggee side using the invoke APIs. It expects these chunks to be collected and not to get an OOME, but since they are pinned, and the ObjectReferenceImpl is sticking around, and the test does not do the enablecollection/disposecollection, the test fails with OOME. There are way to address this in the test, but it did get me looking into the ObejctReferenceImpl cache more and how good (or not so good) it is and disposing references. I'd recommend two improvements. The first is to use WeakReferences instead of SoftReferences so the ObejctReferenceImpls are more readily collected. The other is to do VirtualMachine.DisposeObjects every time we've detected that any ObejctReferenceImpls have been collected rather than waiting for 50. This basically means every fullGC the unreferenced ObejctReferenceImpls will be collected, and their ObjectIDs will be disposed (and the RefNode on the debuggee side disposed). ------------- PR Comment: https://git.openjdk.org/jdk/pull/31421#issuecomment-4685679843
