Excelsior JET

[Jared MacDonald]

I would like to purchase Excelsior Jet, because the performance
improvement for my Swing application does look extremely promising.
But I'm having some issues with the trial version. When I ran a small
sample Swing app that I wrote, I got a NullPointerException. After
about three iterations of adding System.err.println's, I narrowed it
down to one line:

panel.add(button, "0 3 f c");

The layout manager for this panel is an instance of TableLayout ("f c"
means "fill along the x-axis, center along the y-axis"). When I
changed the line to

panel.add(button, "0 3");

it worked fine, and then bombed on the next occurrence of "... f c").
This caused me to look into the code TableLayout, and how it handles
such constraints, and I did find the rather suspect design choice to
parse everything as integers, catch the NumberFormatException, and
then parse them as the expected set of letters -- but regardless, the
point is that this code works fine running as a standard Java program,
but throws NullPointerException as a Jet-compiled EXE.

Has anyone else encountered this issue or similar ones? I'd appreciate
any feedback whatsoever. Thanks,

Jared

 

[Roedy Green]

Has anyone else encountered this issue or similar ones? I'd appreciate
any feedback whatsoever. Thanks,

I have found the Jet people very responsive to bug reports and
suggestions, even if you don't have a support contract.

The only things I have noticed, more in earlier versions, were some
strange visual artifacts as apps came up. They just looked strange
for a second then kicked into the proper appearance.

The Jet optimisers do some pretty aggressive stuff, so I would not be
in the least surprised if they get confused if you play unusual games
in your code.

I remember spending years sending in bug report after bug report on
IBM's optimising Fortran H compiler. It must be so frustrating
writing such a program, coming up with a clever optimisation, then a
customer comes up with a pathological case that means you can't use
it.

If you finally do decide to buy Jet, please click through the buy on
my site on the way to the Jet site. I will get a small cut if you do.
It will cost you the same. They deliver directly to you.
http://mindprod.com/jgloss/jet.html

 

[Roedy Green]

The program below produces this out when run via Java:

Are you using the same class libraries in both cases? We could be
chasing a bug in the class library.

 

[Roedy Green]

java.exe StringTokenizerTest a
1. Got 'a'
Token is 'a'

When run via the compiled EXE, it produces:

strtok.exe a
1. Got 'a'
Token is 'null'

I get the same result using JDK 1.4.2 Win 2K, same class files for
both.

Presumably something in nextToken confused it. What really puzzles me
is I can't se how nextToken could EVER return null no matter how
confused it got.


public String nextToken() {
/*
* If next position already computed in hasMoreElements() and
* delimiters have changed between the computation and this
invocation,
* then use the computed value.
*/

currentPosition = (newPosition >= 0 && !delimsChanged) ?
newPosition : skipDelimiters(currentPosition);

/* Reset these anyway */
delimsChanged = false;
newPosition = -1;

if (currentPosition >= maxPosition)
throw new NoSuchElementException();
int start = currentPosition;
currentPosition = scanToken(currentPosition);
return str.substring(start, currentPosition);
}

 

[Jared MacDonald]

This is one of those sad cases when 99% of the time the optimisation

works, but you can't use it because of that pathological 1%

Gotcha. Thanks so much for reproducing it.

Well, the good news is that I was that able to crack open the source
of the offending code (TableLayout.jar) and rewrite the section that
parses the constraints string to avoid the problem.

Once I fixed that, recompiled and retested, the entire program seems
to work beautifully -- and a good deal faster. So I do think I'll be
purchasing Jet anyway despite this initially troubling edge case that
happened to bite me.

Thanks again.

Jaerd

 

[Roedy Green]

Well, the good news is that I was that able to crack open the source
of the offending code (TableLayout.jar) and rewrite the section that
parses the constraints string to avoid the problem.

what did you do, create a second local variable mirror the value for
the exception?

This brings back memories, writing strange Fortran IV code to dodge
the bugs in IBM's Fortran H optimising compiler.

Any word from Jet on a fix? I lay in bed last night with the horrible
thought that this bug would bring the Jet programmers to the
realisation that nearly all optimisation in futile, since you can get
exceptions at almost any time that throw a monkey wrench.

This also reminds me of an announcement from IBM a long time ago that
their 370 processors would no longer tell you precisely where an
exception occurred. This made them faster. In a sense, that Jet bug
is of that form. The exception is not capturing the PRECISE state of
the universe at the time of the exception. It was capturing it a tad
early.

 

[Jared MacDonald]

Well, the good news is that I was that able to crack open the source

what did you do, create a second local variable mirror the value for
the exception?

I don't know enough about compilers to know how what I did fixed it.
But it was the first thing I tried. I changed the code from one large
try/catch block into four independent ones:

String token = null;

try
{
token = strtok.nextToken();
row1 = new Integer(token).intValue();
}
catch (NumberFormatException ex)
{
handle(token, strtok);
}

try
{
token = strtok.nextToken();
col1 = new Integer(token).intValue();
}
catch (NumberFormatException ex)
{
handle(token, strtok);
}

// ... Same pattern for row2, col2 ...

private void handle(String token, StringTokenizer strtok)
{
// Parse as letters ...
}

That, for each of the four values the class was interested in, where
the handle method basically did what had previously been contained
within the single catch block. Like I said, I don't know why this made
the difference, but the value of "token" was preserved this way.

Any word from Jet on a fix?

None yet.

Jared