Do you mean?

1. you can inadvertently generate illegal code, code that if allowed
to run would get things like stack underflow?

2. The programs you can generate are too complicated.  The byte code
verifier can't decide if they are safe or not?

3. That you can generate legal code that would run safely, but that
looks bad to the byte code verifier?

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Hi Chris,

Thankyou for your long reply. It is certainly true that I can be mistaken
for assuming that the number of lines of bytecode in some way correlates to
the speed at which it executes. However, in a few (and it is a few) cases,
it can be true. While these optimisations do little on their own, the
combined effect of calling such an algorithm using these (and other such)
optimisations over 10,000,000 times can be quite substantial. These
optimisations, to be fair, that I have written do not do miracles with the
speed, but will however reduce the overall time by up to half a minute -
bearing in mind it can take up to 10 to complete a series of computations!
Any optimisation at all is welcome, at this level!

The optimisations/customisations have a couple of characteristics:

1. In some places, it is merely to choose the correct function that runs...
for example

   switch (test)
       {
       case 1:    a = method1(b,c,d); break;
       case 2:    a = method2(b,c,d); break;
       case 3:    a = method3(b,c,d); break;
       }

As you can see, the end result and the calling parameters are the same, just
the function called is based on test... therefore, the optimisation
basically places all the parameters on the stack, then calls the correct
function based on test, and then at the end stores the result. Effectively,
the switch functionality is on the method name alone.

You may say, "sure I understand how that may optimise the classfile in terms
of size, but not speed?" but for some reason (perhaps some different JIT
optimisation is used) it does run that little bit faster.

2. The next one is a little contentious! It involves calling two functions
sequentially where the parameters are the same. Now Java sometimes does an
optimisation that duplicates the parameter on the stack so that it isn't
loaded onto the stack again for the second function. Sometimes it does not
(and I haven't particularily had the time to pin down why and when!). But
suffice to say, this is the second of the main characteristics.

3. The above one can be extended to include cases where the after the first
function, the parameter is modified, but the second function wants to use
the original parameter (ie unmodified). Now Java will allow something like:

   int a = param;
   function1(a);
   param += function3();
   function2(a,param);

but this uses extra local variables (which is slower than duplicating the
value on the stack and using it again).

4. Finally, and most dubious of all!, using different invoke instructions to
bypass the inheritance rules of the Java language. I posted this in another
message to java.lang.programmer on 27/08/2003 under the title "Re: quick
inheritance question".

Not all these necessarily are great optimisations, but they do help keep the
code size down (memory limitations!) and improve the performance slightly.

Its all a bit convoluted! I'd love to show you all the code, and take you
through it, but I don't have the priviledge of being able to do that :o)

Thanks for your comments tho'... I'll let you know if I do end up creating
my own java-esque compiler!

Will


Some of us don't use the JIT.  It is great for certain applications, but
the startup and memory costs swamp the benefits for our applications.
When most of your code is executed very few times, and there are few
tight loops, the JIT just gets in the way.  Business logic is like that.