JDK-8250989 : Consolidate buffer allocation code for CDS static/dynamic dumping
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-08-03
  • Updated: 2021-02-11
  • Resolved: 2021-02-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 17
17 b09Fixed
Related Reports
Blocks :  
JDK-8256172 - Clean up CDS handling of i2i_entry
Relates :  
JDK-8261608 - Move common CDS archive building code to archiveBuilder.cpp
Relates :  
JDK-8261552 - s390: MacroAssembler::encode_klass_not_null() may produce wrong results for non-zero values of narrow klass base
Relates :  
JDK-8250990 - Consolidate object copying code for CDS static/dynamic archive dumping
Description
When a static CDS archive is dumped, we unconditionally allocate a 4GB ReservedSpace and use that as the buffer for writing the archive content. We usually don't need such a big ReservedSpace. It also unnecessarily complicates Metaspace::global_initialize().

http://hg.openjdk.java.net/jdk/jdk/file/4d36e29a5410/src/hotspot/share/memory/metaspaceShared.cpp#l286

When a dynamic CDS archive is dumped, allocate a buffer that's just big enough. That way we are less likely to run out of memory:

http://hg.openjdk.java.net/jdk/jdk/file/4d36e29a5410/src/hotspot/share/memory/dynamicArchive.cpp#l730

It makes no sense to have two different buffer allocation code. We should always use the second variant since it's more frugal and less intrusive.
Comments
Changeset: c5ff4544 Author: Ioi Lam <iklam@openjdk.org> Date: 2021-02-07 07:10:38 +0000 URL: https://git.openjdk.java.net/jdk/commit/c5ff4544
07-02-2021
Doing this is more complicated than I thought. I will need to do it in smaller steps.
17-09-2020
This should be done after JDK-8250990
03-08-2020