Details
-
Enhancement
-
Resolution: Won't Fix
-
P3
-
None
-
9
Description
When analyzing startup behavior byte[] allocation showed up in the profiles coming from reading JAR entries to byte[] and sending them to defineClass. The JarFile/ZipFile APIs only allows the user to get an inputstream which handles the inflation of the entry being read. The inflation as part of a stream causes extra copying to happen while in internal buffers before the final copy to the external byte[].
By introducing a private API that allows the entry to be directly copied to a new or provided ByteBuffer it is possible to speed up the inflation of an entry significantly. The reason for this API being private is that it would not support all entries as buffers can only be 2GB in size, and JAR/ZIP allows for much larger entries. For classloading this is not an issue as the entries read are required to fit in a byte[] already.
A couple of common places use the faster extraction and then read the data using ByteArrayInputStream. Pontentially this could be used in the ZipFile.getInputStream as well for entries with known and small size.
See attached graphs below for microbenchmark results. Startup time on a large server application with ~10000 classes loaded from 600 jar files improved by ~4% and showed a reduction in allocation during startup.
By introducing a private API that allows the entry to be directly copied to a new or provided ByteBuffer it is possible to speed up the inflation of an entry significantly. The reason for this API being private is that it would not support all entries as buffers can only be 2GB in size, and JAR/ZIP allows for much larger entries. For classloading this is not an issue as the entries read are required to fit in a byte[] already.
A couple of common places use the faster extraction and then read the data using ByteArrayInputStream. Pontentially this could be used in the ZipFile.getInputStream as well for entries with known and small size.
See attached graphs below for microbenchmark results. Startup time on a large server application with ~10000 classes loaded from 600 jar files improved by ~4% and showed a reduction in allocation during startup.
