Improving AppCDS for Custom Loaders
ioi.lam at oracle.com
Tue May 1 18:32:36 UTC 2018
As discussed with Volker and Yumin in previous e-mails, AppCDS has some
experimental support for custom class loaders. However, it's not very
easy to use.
For example, you can write a classlist like this:
java/lang/Object id: 1
CustomLoadee id: 2 super: 1 source: /tmp/foo.jar
The CustomLoadee class will be stored in the shared archive with a CRC
code. During runtime, if a customed loader wants to load a class of the
same name, and its classfile has the same size and CRC as the archived
class, the archived version will be loaded. This speeds up class loading
by avoiding parsing the class file, and saves space by sharing the
mmap'ed class metadata across processes.
You can see an example test at:
However, the current scheme requires you to specify all the super
classes and interfaces. There's no support provided by the
-XX:DumpLoadedClassList option.It can be helped somewhat with Volker's
1. "Dump-as-you-go". As suggested by Yumin, we can provide a jcmd to ask
a running JVM process to dump all of its loaded classes, including those
loaded by custom loaders, into an archive. An alternative is to dump the
archive at JVM exit time (or when you press Ctrl-C, etc.
2. Add information about the custom classes for -XX:DumpLoadedClassList.
The trouble is some class loaders don't specify a code source that can
be understood by the built-in class loaders. For example, the "Fat Jars"
would have a code source like
also, many custom loaders would pre-process the classfile data before
defining the class, so we can't simply archive the version of the class
One possible solution for #2 is to include the class file data in the
java/lang/Object id: 1
CustomLoadee id: 2 super: 1 source: base64
Of the 2 solutions:
#1 seems easier to use, but may require more invasive modifications in
the VM, especially if you want to be able to continue execution after
#2 would be easier to implement, but the classlist might be huge.
Also, #2 would allow post-processing tools to remove unneeded classes,
or merge two runs into a single list. The output of #1 is essentially a
binary blob that's impossible for off-line analysis/optimizations.
Any comments, or suggestions for alternatives?
More information about the hotspot-runtime-dev