Macro / Inlineable

[swpalmer]

@princec

Sometimes if you inline too much you end up with, say, a loop that’s just a bit too bloated to fit nicely in the L1 CPU cache, which is a big performance hit as the cache will just thrash back and forth to the L2 cache as the loop executes each iteration. And other crazy cases.

Cas

I can see how this applies to loop un-rolling, but not inlining. If you have a method called in a loop you have the method call plus the method body (not yet inlined) to fit in the cache. If it is inlined you only have the method body to fit in the cache, without the additional instructions of the method call.

What am I missing?

[mthornton]

@swpalmer

I can see how this applies to loop un-rolling, but not inlining. If you have a method called in a loop you have the method call plus the method body (not yet inlined) to fit in the cache. If it is inlined you only have the method body to fit in the cache, without the additional instructions of the method call.

What am I missing?

If the method is called from more than one place, inlining will produce multiple copies of the body.

[princec]

Not only that but an inlined method may call other inlineable methods. The compiler will effectively flatten all the calls it can down to a specific depth (tuneable, I believe, by the -XX:MaxInlineSize and -XX:FreqInlineSize flags) as I understand it. I’m not sure how you tune the depth it’ll flatten code to though.

BTW I just found an interesting switch:

-XX:CompileOnly=test.Test

which would appear to tell the compiler to only compile one specific class.

Cas

[oNyx]

@erikd

Personally, I’ve never seen the slightest performance improvement after declaring stuff “final”.

As for proguard, I just gave it one more shot with JEmu2 (I’ve tried it before with the JEmu2’s predecessors).
At first I got a got a StackOverflowException. After some twiddling, I got rid of the error by disabling optimizations, and the result was a .jar of significantly reduced size (enough to make it worthwhile). Unfortunately, I got a security exception: something to do with the byte code verifier.
After doing more playing with the various options, I finally got something that worked, but it was only <2kb smaller than the original (which weighs in at 987kb) and I had to disable basically everything. So for me it was not at all worth the effort, but of course YMMV…
Maybe I was just not meant to use obfuscators ;D

With pack/gz compression…
JEmu2.jar 1,014,155 Bytes
JEmu2.jar.pack.gz 224,055 Bytes

:o

[princec]

pack.gz is incredible stuff and I can’t figure out why they don’t retrofit it into 1.4 ASAP.

Cas

[swpalmer]

Is the pack.gz stuff documented at all??? I tried once to figure out how it is supposed to work and it wasn’t clear what exactly pack did or how it was to be used. Do the classloaders know how to read directly from the .jar.pack.gz file? Do you have to use a certain file extension for it to work properly? Or is it not directly usable in packed .gz form, and it must be manually expanded after downloading?

[princec]

A packed jar needs to be unpacked properly before it can be used like a normal jar using new classes in the JRE. More than that I don’t really know.

Cas

[oNyx]

@swpalmer

Yes, its documented. Kind of. Well, the bad thing is that the docu only comes with an servlet example. Right now I’ve written 2 and a half php versions and the article is like 80% done (needs some re-structuring).

Well, the classloader doesnt do it. The JWS client does the work. Its basically on-the-fly decompression (before saving the files to disk)… the rest is as usual.

All you need for using it is some server sided logic. Oh and its backward compatible… all you need to do is sending the right stuff accordingly to the jws-client’s accepted encoding (basically).

[swpalmer]

I have an application that I distribute on Windows only has a single downloadable installer. The installer included the JRE, which we install for private use of our application - we don’t want a public JRE used so we have control for QA purposes. We’ve found several issues with minor upgrades e.g.1.5.0_01 to 1.5.0_03 … the _03 release will hard crash in the JVM after a day or so of running our app.

Since the JRE is a large percentage of the download I was thinking it would be cool to use the pack200 tech. to improve the situation. Unfortunately we are using InstallAnywhere, which needs the JRE itself in order to run… and includes it as a ZIP archive. So it seems custom code to unpack the JARs in the JRE will never get a chance to run :(.

I guess I should file an enhancement request with ZeroG…

[princec]

I guess you should use NSIS with LZMA compression instead and forget ZeroG.

Cas

[oNyx]

You can unpack without java. The jdk comes with a native unpack program, which can be used by installers. The jre installer uses this technique (afaict).

http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/unpack200.html

You could use these cmd line parameters:

pack200 --no-gzip --modification-time=latest --effort=9 --deflate-hint=“false” --strip-debug --unknown-attribute=strip foo.jar.pack foo.jar

http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/pack200.html

And instead of gzip you could use a superior compression scheme like lzma. Over at 7.zip.org you can get the lzma sdk, which comes with a cmd line compressor/decompressor.

However, the best option would be using an installer, which already does that like NSIS.

With lzma the JEmu2 jar gets down to 201,947 Bytes (-fb255) and the rt.jar gets even down to 3,543,040 Bytes gasp

Warning - while you were typing a new reply has been posted. You may wish to review your post.

Uhm yea… basically what Cas said. LZMA ftw! ;D

[princec]

Readers may like to note the difference in download size between the Mac OS version of Ultratron (which is more or less just the pure java 1.4 jars needed to play the game in a zip) and the Win32 version of Ultratron (which also contains an entire, er, Puppygames Java Runtime. Possibly)

Cas

[swpalmer]

Though we also have the ability to package a linux installer (without VM) for a “remote mode” version of our application. It’s essentially the UI to the real app that talks to a server via TCP instead of to a local process via JNI.

And everyone here HATEs doing installers (because all Installers seem to be painful to deal with), so it’s not like we want to do it all over again just to save some bytes in the download… well I want to, so long as it isn’t me doing it

Can I pack/unpack the JARs from a JRE install without hosing anything? (e.g. they are signed, right?)

That also means if Sun adds a new JAR to the mix in Java 6, then I have to tweak everything all over again or have some obscure bug because a class is missing and it isn’t found until some weird user tries something dumb.

I think this is really a job for the Install Anywhere folks.