Startup Performance

Patches

Startup Performance Measurement

1. Measure the first startup.
2. Measure a subsequent startup of the same application.
3. Measure a subsequent startup of a different application which reuses some classes.
   

Applications

• Eclipse startup is known for bothering users. A subsequent Eclipse startups should be improved.
• Some specs include startup measurements into final score. It seems that subsequent runs would help improving the peak score.
  

Ideas

• Use pools mapped to files to speed up loading of classes from the boot class path. Alexei Shipilev knows well dll memory layout to make mapping at the same virtual address work. Generally we should allocate the mappable chunk as early as possible, before most dynamic libraries are loaded. Even if this fails, this is no more than optimization and VM can proceed without it.
• String pool may be serialized as well.
• Precompile / save jitted code for later use.
• Store compiled code in DLL/SO formats. Do not reinvent formats for code. If VM has a compiler, why should not it have a linker?
• Use single boot class path cache.
• Think of unpacking jar files, make the size of unpacked jars reasonable, HARMONY-5280.
  • Remove debugging information from class files.
  • Obfuscate private and undocumented class fields.
• Reorder boot class path putting important jars first.
• Save VM state dumping heap memory, thread stacks, states of files, sockets and other open resources. While the task look heavy, for a particular application use case this might be doable.
• Remove duplicated jar reads, HARMONY-5285.
• Delay a method recompilation, HARMONY-5356.
• <Integrate Sergey's thoughts>
  

Thanks Pavel Pervov, Alexei Shipilev, Eugenia Maenkova, Andrey Yakushev, Sergey Kuksenko, Natalya Naumova, Gregory Shimansky.

Class Data Sharing Plan

• Refactor VM startup to use pools for the component manager.
• Add pool serialization to the component manager.
  • Serialize a string pool.
  • Serialize prepared classes.
• Fix bugs.