Resource size hints appear to be used incorrectly when using compression

[Alan Bateman]

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