The SuperWabaJump Toolkit

Frequently Asked Questions

---

Question

When I run my SuperWabaJump application it reports a NullPointerException at start up, why?

The most common cause of an exception at start up is having code that depends on the order that classes are initialized. Normally Jump will initialize all classes before creating that application main window. Typically the problem is the creation of user interface components in a class (static) initializer. Because the class is initialized before the main window is created, this tends to fail. SuperWaba and other VMs initialize classes when first used, which is often after the main window is created. Relying on this behavior is not a good idea. Jump has a build option (-y) that can help with this situation by initializing classes on first use. However, this mode pays a penalty for the extra flexability of reduced speed and more code. This option is new with Jump 2.1.8.

Go to TOP

---

Question

How do I find out what has happened when my application throws an uncaught exception?

Create you application with debug symbols by specifying -g on the command line and do not remove class names. Also the Jump log memo may contain a stack trace (Jump version ≥2.1.8).

Go to TOP

---

Question

What compiler options should I used to get the fastest code, there are so many?

There are various types of performance optimizations available. In general the split into two groups: safe optimizations and unsafe optimizations.

Safe optimizations are those that are always legal, that do not rely on some special assumption about the application and have been shown to be reliable. The SuperWabaJump Toolkit turns on all such optimizations on by default. There is no reason to turn these optimizations off unless a bug is found in them.

Unsafe optimizations are those that are not always valid. Turning these optimizations on can lead to faster code, sometimes much faster, but doing so is an implicit promise to Jump that the assumptions are valid.

For the toolkit Jump turns on one unsafe optimization NO_AASTORE_CHECK, which tells Jump not to produce code to check that assigning an object to an element of an array is consistent. It is difficult to think of an example of how this can go wrong without javac complaining. SuperWaba does not have this check either, so the toolkit can be considered bug-compatible.

To get the fastest code you will probably compile with Jump command line options -San.

• -S means do not include stack checks. Using this option promises that the application does not cause a stack overflow. This is a pretty safe bet since stack overflow is fatal. Checks for stack overflow are normally performed at the beginning of every method. Removing this check makes the code smaller and faster.
• -a means do not include array bounds checks. Using this option promises that indexing arrays never causes an IndexOutOfBoundsException. Be very sure that this is always true before enabling this option. There is some additional performance benefit from combining this option with -n.
• -n means do not include checks for null pointer use. In normal operation, as part of the safe optimizations, Jump goes to some trouble to identify uses of objects that can't possibly cause a NullPointerException and removes the checks that would otherwise be needed. Typically this removes 75%-80% of all checks for null pointer use. The -n option promises that the application never produces a NullPointerException, which means the compiler can remove all remaining checks. Removing these checks makes the code smaller and faster.

Go to TOP

---

Question

What compiler options should I used to get the most compact code?

For Jump and The SuperWabaJump Toolkit fastest code usually means the smallest too.In addition there are two options that are very useful. One saves spce by not using it, while the other saves space by using it. These are options -g and -c.

• -g Include debug symbols. Using this option increases the size of the code becauses the names of methods are included in the code. Do not use this option if you want the smallest code. However, this option is very useful for identifying problems in the field. So if you want the smallest code then don't use this option.
• -c Remove class names. This option removes the names of classes from the application. Normally the names of classes are included in the class tables so that methods such as Class.getName and Class.forName work. If your code does not rely on such methods then the class names can be removed. Note however that if you remove class names then then debugging is more difficult because an uncaught exception will not be able to identify the name of the exception thrown.

Go to TOP

---

Question

What is this new dynamic class initialization option (-y) all about?

Its about better compatibility with Java and SuperWaba VMs and the performance trade-off.

When a class is first referenced the class must be initialized. This means running the code to initialize static fields and to run the static initializer static {...} method. With Jump all the classes are known up-front, so 'first referenced' means at start up. Jump's standard behaviour is to call all of the class initializations before creating the application instance (main window). There is a big benefit to this that each time a static field is accessed, a static method called or a new instance created Jump can be sure that the class is ready to go - so the code is short and fast.

However virtual machines (VM) work differently; 'first referenced' for a VM usually means the first time it comes across a mention of the class in the executing code - the first time a static field is referenced etc. In java it is easy to write code that depends on the order in which classes are initialized, even though this is extremely bad practice. As a result Jump can behave differently from a classic VM is such cases.

The new -y option performs dynamic class initialization. Instead of calling all the class initialization at start up Jump generates code to check whether a class has been initialize each time it accesses a static field, calls a static method or creates a new instance - if necessary it initializes the class.

In fact Jump isn't quite that dumb. If the static field or method is in the same class or a superclass then you couldn't be where you are in the code without the class and its superclasses being initialized, so there is no need for the check. Suppose you access the same class several times in an unrelated method, then the first time the check is needed, but the second time you know the init is done already - at least as long as there isn't a path to the second that bypasses the first. Well Jump figures that all out and avoids doing work where it can.

So, the Jump -y option makes Jump much more compatible with all that dodgy code out there at the price of lots of extra checks for class initialization. But Jump also makes efforts to avoid the checks where it can, to mitigate the performance cost. In practice the option costs about 1% extra in code size with a slow down that can be 50% in individual snippets of code but is often not noticable overall (in the SpeedTest^? sample application it is not even measurable). The moral is: Write good code, and if you can't then use the -y option.

BTW you can put a line in the project .jump file instead of using the command line option.

  dynamic-class-init= yes

Go to TOP

---

Question

Pila stops without producing an error message or a PRC file. What's wrong?

Pila 1.0 Beta 3 Fluff 7 has a built in limitation for the size of the PRC file. If that limit is exceeded then Pila exits silently. The limitation is 512 Kbytes. There is a quick fix (called 1.0 Beta 4 PMD) that extends the limit to 2 Mbytes, but better fix is needed that does away with the limit altogether.

Go to TOP

---

Question

Jump itself reports a NullPointerException, why?

I found that using JDK1.2.1 caused this. I upgraded to JDK1.2.2 and the problem went away.
- NikkiLocke^?

Go to TOP

---

-- PeterDickerson^? - 30 Jan 2004