Re: On the speed of jarred BootCP

On Fri, 2004-10-08 at 17:18, Rene Wagner wrote:
> On Fri, 2004-10-08 at 07:58, Grzegorz B. Prokopski wrote:
> > > a) zip on my system creates v2.0 zip archives which don't work with
> > >    the zip loader (took me some time and a lot of fprintf's to figure
> > >    that out).
> > 
> > Yes, I've noticed that, forgot to mention.  I didn't get as far as
> > gdb-ing the problem though so could you please tell me at what 
> > statment/line it fails actually? 
> 
> I'm not sure about the line number. Should be somewhere around l. 438.
> 
>             default:            /* An error during inflation occured. */
>               inflateEnd (&zip_stream);
>               goto error;

Oh, that's bad.  Apparently zlib does not support the kind of
compression zip uses, or maybe I am missing something as how to
initialize zlib differently in some cases?  I wonder whether other
free VMs have similar problems?

> > Forget about that option.  It's commented out and we won't be using it.
> > We want something like:
> > 	--enable-compressed-classes
> > 
> > By default it should try to find fastjar, and if it's not available
> > find zip (and bomb out if none of them is found).
> 
> Well. zip currently doesn't produce anything the zip loader will be
> able to uncompress...

We could still procude an uncompressed .jar with zip by passing '-0'.

> > There's one thing that would be nice to support though, sth. like:
> > 
> > 	--enable-compressed-classes=storeonly
> > 
> > which would tell fastjar or zip not to compress the files in .jar.
> 
> The "or" doesn't work here. There's no way you can select from the two.

It would be _possible_ to support =storeonly,zip but I don't think it
would actually make much sense.

> My suggestion would be something like this:
> 
> --enable-compressed-classes             Default to storeonly for now
> --enable-compressed-classes=fastjar     fastjar with default compression
> --enable-compressed-classes=storeonly	fastjar without compression (I
>                                         don't think zip supports that at
>                                         all.)

(I thin 'zip -0' does exaclty this - store.)

Yes, your suggestion is very good.

I still think =storeonly should first try fastjar and then zip. They
should be equivalent when using -0 option (and they both have it).

> Future options (once the zip loader supports it...)
> --enable-compressed-classes=zip         Use zip

Exactly.

> > This IMO should actually be the default :-)  

On non-embedded systems we do want to have .jarred classes because
some programs expect it, but OTOH we don't want to make it too slow.
This is a reasonable tradeoff IMO.  And on an embedded platform you
simply configure with =fastjar and you're done.

> "default" as in "enabled even if --enable-compressed-classes isn't given
> as a parameter at all"?

Yes.  When this switch is not specified it should be equivalent to
	--enable-compressed-classes=storeonly

> I.e. you would have to explicitly disable it
> with
> 
> --enable-compressed-classes=no
> 
> (or --disable-compressed-classes if that works)

--disable-compressed-classes would be the option to get uncompressed
classpath, yes.  IIRC the effect inside configure script is the same
as if you passed --enable-compressed-classes=no, that is, in both cases
the value of "$compressed_classes" is set to "no".

> > * After all that is done - check startup time of a HelloWorld that does
> >   String.split() 1) when  the compressed classpath IS split into
> >   libclasspath and resources, 2) when everything is in
> >   libclasspath.jar, 3) when the classpath IS split into libclasspath
> >   and resources but in =storeonly mode 4) bootclasspath consists of
> >   uncompressed .class files tree (like we have it right now).
> 
> "check startup time" as in 'time sablevm Hello' ?

Yes.  The important bit here is that this Hello should not only display
something meaningless, but attempt to use regular expressions for
example to split a string.  This will triger resource loading from boot
class path, so we'll be able to say how much faster is the solution with
separated libclasspath.jar and resources.jar than with single
libclasspath.jar.

> > Do you think you can make it work, like, by the end
> > of the weekend?
> 
> Possibly. I can't tell for sure yet.

I feel inclined to wait a bit.  This is definitely worth having in
1.1.7.

In the meantime maybe Etienne could import latest GNU CP CVS again? :)
We don't want to make a new release with an "old" classpath ;-p

Cheers,

				Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski      <[email protected]>
Debian GNU/Linux           http://www.debian.org
SableVM - LGPL'ed Java VM  http://www.sablevm.org
Why SableVM ?!?            http://sablevm.org/wiki/Features