Re: On the speed of jarred BootCP

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;

> > The solution to a) is using fastjar, but I haven't got to adjusting
> > the configury to use that instead of zip yet.
> 
> Yes, we should be using fastjar IMO, unless we fix the zip problem.
> Or maybe there's some switch to zip that tells it to use less
> sophisticated storage methods? 

Not that I'm aware of.

> Yes, data are installed in pkgdatadir = $(datadir)/$PACKAGE
> PACKAGE could be "sablevm-classpath" for now, so it'd end up in
> /usr/share/sablevm-classpath which also sounds natural.  I can't
> remember why we wanted to have everything in /usr/share/sablevm?
> I don't think there's any really good reason.  All that would need
> to be changed is just some paths in src/libsablevm/Makefile IIRC.

OK.

> 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...

> Note that we
> *may* provide =something suffix to --enable-* parameters, so this
> would be possible:
> 
> 	--enable-compressed-classes=zip
> 
> And we *might* support that *if* we wanted to allow somebody to force
> usage of zip instead of fastjar.  BUT I do NOT think it's necessary.
> Autodetection with preference of fastjar over zip should do just fine.
> 
> 
> 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.

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.)

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

> This IMO should actually be the default :-)  

"default" as in "enabled even if --enable-compressed-classes isn't given
as a parameter at all"? I.e. you would have to explicitly disable it
with

--enable-compressed-classes=no

(or --disable-compressed-classes if that works)

> This way we could save
> on a) disk space b) startup time.  And some software (ANT comes to mind)
> really expects classpath to consist of zip/jar files so it's much
> better to have bootclasspath in jarred form even if we care for
> startup time.

Would be fine with me.

> * 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' ?

> Do you think you can make it work, like, by the end
> of the weekend?

Possibly. I can't tell for sure yet.

Rene