On Tue, 13 Feb 2024 08:39:38 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> Sorry really struggling to understand this now. We have gone from a simple >> miscalculation to apparently doing everything wrong. >> >> IIUC this API does not currently handle virtual threads correctly -i s that >> the case? If so I would like to see that fix factored out and done >> separately before this fix is done. Thanks. > >> Sorry really struggling to understand this now. We have gone from a simple >> miscalculation to apparently doing everything wrong. IIUC this API does not >> currently handle virtual threads correctly - is that the case? If so I would >> like to see that fix factored out and done separately before this fix is >> done. Thanks. > > Thank you for the concern, David. But it is not clear what it is. Could you, > please, explain a little bit? > Why do you think the virtual threads are handled incorrectly? @sspitsyn - When you get the chance, can you checkout these possible changes for the objmonusage001 test? https://github.com/openjdk/jdk/pull/17839 Summary of my test changes: - extend the check() function to verify more of the jvmtiMonitorUsage fields - add detailed comments at each of the verification points so it's clear what is being verified and why - add a better summary for the overall test - make it clear which output lines document failures I've also made some temporary debugging changes that are only useful while updating this test: - temporarily use the "printdump" parameter to enable test output - add a flag to verify the current JVMs bad jvmtiMonitorUsage fields so that the test can pass with an unmodified JVM - add a flag to add a delay that helps check for a lack of races in the verification points These proposed test changes help document how I think the GetObjectMonitorUsage API is supposed to work on a simple test case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1942747157
