JDK-8141207 : Unused symbols are not removed from CDS archive
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2015-11-02
  • Updated: 2018-07-31
  • Resolved: 2018-07-31
Related Reports
Blocks :  
Relates :  
Description
$ java -Xshare:dump
Preload Warning: Cannot find sun/text/normalizer/UnicodeMatcher
...
total   :  13063134 [100.0% of total] out of  27385856 bytes [47.7% used]

$ strings images/jdk/lib/i386/hotspot/classes.jsa | grep sun/text/normalizer/UnicodeMatcher
sun/text/normalizer/UnicodeMatcher

Comments
This is not on our current list of priorities. We will considered this feature if we receive additional customer requirements.
31-07-2018

Not critical and saving is going to be small. Defer to JDK 11.
05-04-2017

The problem with dump time symbol allocation is: Klass* ClassLoaderExt::load_one_class(ClassListParser* parser, TRAPS) { TempNewSymbol class_name_symbol = SymbolTable::new_symbol(parser->current_class_name(), THREAD); guarantee(!HAS_PENDING_EXCEPTION, "Exception creating a symbol."); return SystemDictionary::resolve_or_null(class_name_symbol, THREAD); } Symbol* SymbolTable::allocate_symbol(const u1* name, int len, bool c_heap, TRAPS) { assert (len <= Symbol::max_length(), "should be checked by caller"); Symbol* sym; if (DumpSharedSpaces) { // Allocate all symbols to CLD shared metaspace sym = new (len, ClassLoaderData::the_null_class_loader_data(), THREAD) Symbol(name, len, PERM_REFCOUNT); } So even when we are using a TempNewSymbol, the symbol becomes permanent (refcount == -1) anyway. This bug should be fixed after JDK-8072061 is pushed.
16-02-2017

Fixing of this bug depends on JDK-8072061 Eliminate the need to manually specify CDS region sizes. With JDK-8072061, the archive should contain only Symbols that are stored in the SymbolTable. For classes that are not found during loading, their names should be removed from the SymbolTable (due to the use of TempNewSymbol), and therefore will not be included in the archive. Test case: $ cat > MyClassList foo.foo.foo $ java -Xshare:dump -XX:+UnlockDiagnosticVMOptions -XX:SharedClassListFile=MyClassList Allocated shared space: 1073741824 bytes at 0x0000000800000000 Loading classes to share ... Preload Warning: Cannot find foo.foo.foo Loading classes to share: done. Rewriting and linking classes ... Rewriting and linking classes: done Number of classes 131 instance classes = 117 obj array classes = 6 type array classes = 8 Updating ConstMethods ... done. Removing unshareable information ... done. Scanning all metaspace objects ... Allocating RO objects ... Allocating RW objects ... Updating embedded pointers ... Updating external pointers ... mc space: 34053 [ 1.2% of total] out of 131072 bytes [ 26.0% used] at 0x0000000800000000 md space: 3328 [ 0.1% of total] out of 4096 bytes [ 81.2% used] at 0x0000000800020000 ro space: 788584 [ 28.9% of total] out of 790528 bytes [ 99.8% used] at 0x0000000800021000 rw space: 923320 [ 33.8% of total] out of 925696 bytes [ 99.7% used] at 0x00000008000e2000 st space: 4096 [ 0.2% of total] out of 4096 bytes [100.0% used] at 0x00000007bfc00000 od space: 868384 [ 31.8% of total] out of 872448 bytes [ 99.5% used] at 0x00000008001c4000 total : 2621765 [100.0% of total] out of 2727936 bytes [ 96.1% used] $ strings $JAVA_HOME/lib/server/classes.jsa | grep 'foo' >foo.foo.foo
16-02-2017