Details
-
Sub-task
-
Resolution: Fixed
-
P4
-
16
-
b09
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, we 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.
http://hg.openjdk.java.net/jdk/jdk/file/4d36e29a5410/src/hotspot/share/memory/metaspaceShared.cpp#l286
When a dynamic CDS archive is dumped, we 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.
Attachments
Issue Links
- is blocked by
-
JDK-8256172 Clean up CDS handling of i2i_entry
- Resolved
- relates to
-
JDK-8250990 Consolidate object copying code for CDS static/dynamic archive dumping
- Resolved
-
JDK-8261552 s390: MacroAssembler::encode_klass_not_null() may produce wrong results for non-zero values of narrow klass base
- Resolved
-
JDK-8261608 Move common CDS archive building code to archiveBuilder.cpp
- Resolved
(1 links to)