-
Bug
-
Resolution: Fixed
-
P1
-
8, 9
-
b170
-
generic
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8180681 | 10 | Thomas Schatzl | P1 | Resolved | Fixed | b09 |
JDK-8180535 | 9.0.4 | Thomas Schatzl | P1 | Resolved | Fixed | b01 |
JDK-8197276 | 8u192 | Thomas Schatzl | P1 | Resolved | Fixed | b01 |
JDK-8195281 | 8u172 | Thomas Schatzl | P1 | Resolved | Fixed | b03 |
JDK-8188687 | 8u171 | Thomas Schatzl | P1 | Resolved | Fixed | master |
JDK-8190045 | 8u162 | Thomas Schatzl | P1 | Resolved | Fixed | b04 |
JDK-8183671 | 8u161 | Thomas Schatzl | P1 | Resolved | Fixed | b01 |
JDK-8180748 | 8u152 | Thomas Schatzl | P1 | Closed | Fixed | b05 |
JDK-8186322 | 8u144 | Thomas Schatzl | P1 | Closed | Fixed | b32 |
JDK-8192233 | emb-8u161 | Thomas Schatzl | P1 | Resolved | Fixed | b01 |
JDK-8191271 | 7u181 | Poonam Bajaj Parhar | P1 | Closed | Fixed | b01 |
JDK-8194078 | 7u171 | Poonam Bajaj Parhar | P1 | Resolved | Fixed | b31 |
JDK-8191910 | 7u161 | Poonam Bajaj Parhar | P1 | Closed | Fixed | b32 |
JDK-8199961 | openjdk7u | Thomas Schatzl | P1 | Resolved | Fixed | master |
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+168)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+168, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux 2.6.32-642.11.1.el6.x86_64 #1 SMP Wed Oct 26 10:25:23 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux, Red Hat Enterprise Linux Server release 6.8 (Santiago)
Windows 7 Enterprise 64-bit, Service pack 1
A DESCRIPTION OF THE PROBLEM :
Other bugs, for example
With the classic concurrent mark sweep the memory is reclaimed correctly, but not with G1.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Use the Java code below to generate and intern strings and to trigger full garbage collections. Run the program like this:
-------------------
java -XX:NativeMemoryTracking=detail -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics -XX:MetaspaceSize=100m -XX:MaxMetaspaceSize=100m -XX:+UseStringDeduplication -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xloggc:gc-jdk8-marksweep.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xms256m -Xmx256m -cp classes StringInterner
java -XX:NativeMemoryTracking=detail -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics -XX:+UseG1GC -XX:MetaspaceSize=100m -XX:MaxMetaspaceSize=100m -Xloggc:gc-jdk8-g1.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xms256m -Xmx256m -cp classes StringInterner
-------------------
Check the output and search for Symbol. We got:
Symbol (reserved=27549KB, committed=27549KB)
Symbol (reserved=424789KB, committed=424789KB)
Note that the memory for symbols (interned strings etc) is 27M for concurrent mark sweep and 424M for G1 when the maximum metaspace size was configured to be 100M.
Just in case, double-check the gc logs to make sure that there were full gc:s performed. We got four lines similar to:
2017-05-09T10:29:24.738+0000: 24.028: [Full GC (System.gc()) 124M->386K(256M), 0.0570296 secs]
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
1) The interned strings should be garbage collected when G1 performs a full gc, so we should get a similar size for Symbol with G1 as we got with concurrent mark sweep.
2) The maximum amount of native memory allocated should never be larger than the configured maximum metaspace size, 100M.
ACTUAL -
The native memory occupied by interned strings continued to grow with G1 passed the maximum metaspace size even though full garbage collections were performed.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public class StringInterner {
public static volatile String lastString;
public static void main(String[] args) {
for (int iterations = 0; iterations < 40;) {
String baseName = UUID.randomUUID().toString();
for (int i = 0; i < 1_000_000; i++) {
lastString = (baseName + i).intern();
}
if (++iterations % 10 == 0) {
System.gc();
}
LockSupport.parkNanos(500_000_000);
}
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Use another garbage collector, in our case concurrent mark sweep.
- backported by
-
JDK-8180535 Interned string and symbol table leak memory during parallel unlinking
-
- Resolved
-
-
JDK-8180681 Interned string and symbol table leak memory during parallel unlinking
-
- Resolved
-
-
JDK-8183671 Interned string and symbol table leak memory during parallel unlinking
-
- Resolved
-
-
JDK-8188687 Interned string and symbol table leak memory during parallel unlinking
-
- Resolved
-
-
JDK-8190045 Interned string and symbol table leak memory during parallel unlinking
-
- Resolved
-
-
JDK-8192233 Interned string and symbol table leak memory during parallel unlinking
-
- Resolved
-
-
JDK-8194078 Interned string and symbol table leak memory during parallel unlinking
-
- Resolved
-
-
JDK-8195281 Interned string and symbol table leak memory during parallel unlinking
-
- Resolved
-
-
JDK-8197276 Interned string and symbol table leak memory during parallel unlinking
-
- Resolved
-
-
JDK-8199961 Interned string and symbol table leak memory during parallel unlinking
-
- Resolved
-
-
JDK-8180748 Interned string and symbol table leak memory during parallel unlinking
-
- Closed
-
-
JDK-8186322 Interned string and symbol table leak memory during parallel unlinking
-
- Closed
-
-
JDK-8191271 Interned string and symbol table leak memory during parallel unlinking
-
- Closed
-
-
JDK-8191910 Interned string and symbol table leak memory during parallel unlinking
-
- Closed
-
- blocks
-
JDK-8180280 [TESTBUG] Test for JDK-8180048
-
- Resolved
-
- relates to
-
JDK-8197510 fastdebug builds fail due to lack of p2i
-
- Resolved
-