JDK-8176454 : Performance: jweak references not suitable for robust cache architecture
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Rejected
  • Submitted: 2017-03-09
  • Updated: 2018-06-06
  • Resolved: 2018-06-06
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
tbd_majorResolved
Related Reports
Blocks :  
JDK-8072498 - Multi-thread JNI weak reference processing
Cloners :  
JDK-8204505 - Performance: jweak references not suitable for robust cache architecture
Relates :  
JDK-8194312 - Support parallel and concurrent JNI global handle processing
Relates :  
JDK-8072498 - Multi-thread JNI weak reference processing
Description
Performance: jweak references not suitable for robust cache architecture

#1 Contrary to the expectations, jweak objects that are destroyed with DeleteWeakGlobalRef() take more GC time than alive one, but with dead objects (see attached test case)

#2 DeleteWeakGlobalRef() does not actually free the memory

#3 jweaks are processed single threaded by the GC
Comments
[~pliden] It was still open because, although I'm pretty sure it's fixed, I hadn't gotten around to running the test to verify that. A resolution of Rejected doesn't seem right though.
06-06-2018
Why is this bug still open? Closing/Rejecting it since issue #1 and #2 are runtime issues (and with OopStorage, issue #1 is no longer relevant). And there's already another bug for issue #3.
06-06-2018
We already have an RFE for parallelizing jweak processing - see the linked JDK-8072498.
13-03-2017
What about the fact that the jweak references are processed by GC on a single thread? Can GC process jweak in parallel?
13-03-2017
As Kim says, this is a symptom of how the life-cycle of JNI handles is managed. The increase in GC times is just a side effect of them never going away, even when they're not used. So, reassigning this to runtime.
10-03-2017
It appears that JNIHandleBlocks in the global lists are never removed. So an application that allocates a large number of JNI handles and then deletes them will continue to pay the cost of having a large number of handles forever.
09-03-2017
The results show step #3 taking longer than #2 no matter what kind of build it is, i.e. the disparity exists in both debug and product build.
09-03-2017
Running the attached test will output: #0 nothing happened yet ... zero gc time: 7 zero gc time: 4 zero gc time: 4 zero gc time: 4 zero gc time: 4 zero gc time: 4 zero gc time: 4 zero gc time: 4 zero gc time: 4 zero gc time: 5 total time: 44 #1 allocating memory, creating objects, jweaks ... live objects gc time: 104 live objects gc time: 90 live objects gc time: 89 live objects gc time: 93 live objects gc time: 93 live objects gc time: 88 live objects gc time: 92 live objects gc time: 90 live objects gc time: 93 live objects gc time: 100 total time: 932 #2 freeing java objects ... dead objects gc time: 26 dead objects gc time: 8 dead objects gc time: 8 dead objects gc time: 8 dead objects gc time: 8 dead objects gc time: 8 dead objects gc time: 8 dead objects gc time: 8 dead objects gc time: 14 dead objects gc time: 9 total time: 105 #3 freeing jweak references ... destroyed jweaks gc time: 25 destroyed jweaks gc time: 20 destroyed jweaks gc time: 24 destroyed jweaks gc time: 23 destroyed jweaks gc time: 27 destroyed jweaks gc time: 26 destroyed jweaks gc time: 25 destroyed jweaks gc time: 19 destroyed jweaks gc time: 22 destroyed jweaks gc time: 27 total time: 239 I would expect at step #3 GC times close to those from step #0.
09-03-2017