-
Sub-task
-
Resolution: Fixed
-
P4
-
16
-
b09
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.
- 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)