JDK-8072498 : Multi-thread JNI weak reference processing
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-02-04
  • Updated: 2019-12-03
  • Resolved: 2018-08-28
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 12
12 b09Fixed
Related Reports
Blocks :  
JDK-8204505 - Performance: jweak references not suitable for robust cache architecture
Blocks :  
JDK-8176454 - Performance: jweak references not suitable for robust cache architecture
Blocks :  
JDK-8200557 - OopStorage parallel iteration scales poorly
Relates :  
JDK-8210100 - ParallelGC should use parallel WeakProcessor
Relates :  
JDK-8235247 - WorkerDataArray leaks C heap memory for associated work items
Relates :  
JDK-8210164 - building Minimal VM fails with error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
Relates :  
JDK-8202813 - Move vm_weak processing from SystemDictionary to WeakProcessor
Relates :  
JDK-8210148 - Minimal VM build has new warnings after JDK-8072498 (Multi-thread JNI weak reference processing)
Relates :  
JDK-8210131 - vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code
Relates :  
JDK-8176454 - Performance: jweak references not suitable for robust cache architecture
Relates :  
JDK-8043575 - Dynamically parallelize reference processing work
Relates :  
JDK-8194312 - Support parallel and concurrent JNI global handle processing
Relates :  
JDK-8204505 - Performance: jweak references not suitable for robust cache architecture
Description
Recent posting to hotspot-gc-dev@openjdk.java.net shows very high JNI weak reference processing times, i.e. over 6 seconds during a parallel CMS remark.

Here is a GC log entry for a CMS Remark:
2015-02-03T03:24:27.419-0800: 17917.047: [Rescan (parallel) , 0.0625400 secs]2015-02-03T03:24:27.482-0800: 17917.110: [weak refs processing2015-02-03T03:24:27.482-0800: 17917.110: [SoftReference, 1 refs, 0.0010820 secs]2015-02-03T03:24:27.483-0800: 17917.111: [WeakReference, 0 refs, 0.0015340 secs]2015-02-03T03:24:27.484-0800: 17917.112: [FinalReference, 0 refs, 0.0007930 secs]2015-02-03T03:24:27.485-0800: 17917.113: [PhantomReference, 0 refs, 0.0008860 secs]2015-02-03T03:24:27.486-0800: 17917.114: [JNI Weak Reference, 6.1104040 secs], 6.1148360 secs]2015-02-03T03:24:33.596-0800: 17923.225: [scrub string table, 0.0006670 secs] [1 CMS-remark: 531682K(5242880K)] 1827698K(7759488K), 6.1785190 secs] [Times: user=7.22 sys=0.00, real=6.18 secs]

AFAIK, all HotSpot collectors (G1 GC, Parallel GC, CMS GC and Serial GC) are single threaded when it comes to processing JNI weak references even with -XX:+ParallelRefProcEnabled.
This enhancement request is for multi-threading the processing of JNI weak references.