On 09/08/2018 10:42, Luke Hutchison wrote:
Good info, I was wondering about the claims (in the ModuleReader
javadoc) about how ByteBuffer was being used for high-speed
classloading, given that in the past rt.jar has been compressed. This
makes a lot more sense if the system modules are not compressed.
So yes, the issues I raised are about the use of decompressed sizes in
the loading of resources from runtime images that were created with
compression.
I don't think rt.jar was compressed in JDK 8 or older, at least not
unless you are looking at embedded builds where it helped with the
static footprint (and depending on processor/environment, it may help
with class loading performance too).
The API note (and it's just a note, not normative text) about class
loading in the ModuleReader javadoc was to document the rational for the
read/release methods. The built-in class loaders make heavy use of it
when loading classes/resources from modules in the run-time image and
significant work was done to ensure that the buffers are views on the
underlying memory mapped file.
The support for compressing resources in the jimage is something that
does need attention so I created JDK-8209176 to track that. As I said,
we haven't done as much performance testing with compression enabled.
I'll also add that your comments about malicious values need to be
viewed in the context of the tool that creates the run-time image -
there is no support whatsoever for using jimage files that have not been
created by the jlink tool.
-Alan
