JDK-8256302 : releasing oopStorage when deflating allows for faster deleting
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2020-11-12
  • Updated: 2023-11-22
  • Resolved: 2023-06-07
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.
JDK 21 Other
21 b26Fixed naResolved
Related Reports
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8291418 :  
Description
The loop for deleting ObjectMonitor is slow because of the transition to blocked for each iteration.
If we release oopStorage when deflating we can do this entire loop while blocked instead, which will be much faster.
Since we only need to free some c-heap.
From similar situations the differences can be up to 10x, mainly due to compiler may use much more aggressive optimizations and much better predictions (the list is random access).
In rare situations when we have a list with 10 k OMs, using 10 usec per item instead of 100 usec can mean we will not "get behind".

E.g. we then could do:
>    size_t deleted_count = 0;
>    ThreadBlockInVM tbivm(self);
>     for (ObjectMonitor* monitor: delete_list) {
>       delete monitor;
>       deleted_count++;
>     }
>   }


Comments
This change has been effectively backed out by JDK-8319137.
22-11-2023

This changed has introduced a race condition - see JDK-8319137
01-11-2023

Fix was pushed while main bug was targeted to '22'. Reset the main bug to fixed in '21' and copied the Robo Duke entry here.
07-06-2023

Dukebot added a comment - 5 minutes ago Changeset: 64020048 Author: Daniel D. Daugherty <dcubed@openjdk.org> Date: 2023-06-07 19:59:13 +0000 URL: https://git.openjdk.org/jdk/commit/6402004852ccc993bb6e879c49fb71e2afdcdfbe
07-06-2023

The v03 version of the patch has been rebased to jdk-21+25 and another round of Mach5 testing is being done: Mach5 Tier1: - no failures Mach5 Tier2: - no failures Mach5 Tier3: - no failures Mach5 Tier4: - no failures Mach5 Tier5: - 1 unknown, unrelated test failure: - javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java failed with: Unexpected exception caught = java.io.IOException: Cannot bind to URL [rmi://:5801/server5801]: javax.naming.CommunicationException [Root exception is java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.lang.ClassNotFoundException: RMIClientFactory (no security manager: RMI class loader disabled)] - I've spotted this exact failure in another adhoc Mach5 job set so I don't think this failure is related. Mach5 Tier6: - 1 known, unrelated test failure: - jdk/jfr/tool/TestView.java failed due to a variant of JDK-8309238 Mach5 Tier7: - no failures Mach5 Tier8: - 2 known, unrelated test failures, 1 unknown, unrelated test failure - vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java failed due to JDK-8205957. - applications/javafuzzer/BigTest.java failed due to JDK-8309268. - applications/microbenchmarks/indy/Test_2.java#id18 failed due to a test harness issue.
05-06-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/11296 Date: 2022-11-22 17:52:45 +0000
22-11-2022

I won't have time to investigate this issue for JDK19.
04-05-2022

[~rehn] - Feel free to edit the bug to make things more clear since all I did was copy stuff from the PR.
12-11-2020