Miscellaneous improvements to "jar".

[Ulf Zibis]

Am 26.06.2009 18:45, Xueming Shen schrieb:
> Ulf Zibis wrote:
>>
>> Motivation:
>> Xueming states:
>> *"dat" based uses less disk space, but it has larger startup time, 
>> reading an additional "big" dat file during class 
>> loading/initializing actually takes much longer time than I expected 
>> (I hit the extreme when I worked on the EUC_TW, which I make the size 
>> only 30% of the existing one, but startup is a disaster regression, ...
>> *
>> If loading x bytes from dat file via getResourceAsStream() takes much 
>> longer time than loading x+30% bytes from class file, processing the 
>> UTF-8 conversion, instantiating and initializing additional Class 
>> objects, I imperatively presume, that there must be a big chance for 
>> significantly improving read speed from uncompressed jar file (here 
>> charsets.jar), by using direct channels or how ever. I presume, 
>> enhancing reading from jar files would be a big fish in performance 
>> gain for the whole JDK, as it is very common task in JVM's daily work.
>>
>>
> Ulf, the "jar reading" part of the "class loading/initializing" of 
> charsets.jar (and most of the "core lib" jars) is not via 
> java.util.jar/zip interface,

Oops, sorry for misunderstanding ...

> there is a native level interface for the vm to access those jar 
> files, so adding a nio buffer interface is not going to help startup 
> of jdk/jre itself.

... I was only thinking about the numerous "resources" loaded on startup 
of jdk/jre AND later from user application, and, of course, for more 
motivation to avoid heavy static data in class files.
Additionally, some time ago on a debug session through 
getResourceAsStream(), I noticed, that the construction of the resources 
file's URL seams to be very wasteful (looping StringBuffer#apend() char 
by char (or even strings of length 1), even on 50..100 chars long Strings).

Any chance about outsourcing some code from API's jar code to native 
code, so API customers could profit from the speed of the native level 
interface of the vm to access jar files?

> Martin's estimate of 10%-20% gain indeed is very close, I got less 
> than 5%-8% (for jaring) gain from my prototype implementation. As I
> said it's still something worthing doing, especially it makes the life 
> easier when work together with other nio/channel APIs.

I agree!

-Ulf