JDK-8019845 : NPG: Memory leak during class redefinition
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs25
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • Submitted: 2013-07-03
  • Updated: 2014-06-26
  • Resolved: 2013-07-26
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 8 Other
8Fixed hs25Fixed
Related Reports
Relates :  
java/lang/instrument/RedefineBigClass.sh test shows memory leak with latest jdk8.

The leak might not have been detected before because the test only prints available memory size in its log and is treated as passed anyway.

After the test is improved how it was suggested in JDK-8016838 it will be able to fail upon a memory leak.
I found that the memory leak was first introduced in jdk8-b69 (hs25-b13). So it may not be related to JDK-8003419. It can just turn out that the improved RedefineBigClass.sh test detects (at least) three different memleaks: the original one it was designed for, the one fixed in JDK-8003419 and the leak which is currently observed in the latest jdk.

We need to check if this is still a problem after this fix went in: JDK-8003419: NPG: Clean up metadata created during class loading if failure

Moving to hotspot/runtime.

Yes, you're right. Thanks for the pointer! The leak is observed with b58, but not with b57. Can you please tell me the bug number, so I could close this issue as a duplicate?

This could be a HotSpot permgen removal bug. Try with JDK8-b57 (the last build before the permgen removal) and see if it reproduces there.