Re: [Jxcl-devel] RE: So what's the status of JXCL

[Dale K. <Dal...@In...>]

----- Original Message -----
From: "Jim Dixon" <jd...@di...>
To: "King Dale" <dal...@th...>
Cc: <jxc...@li...>
Sent: Tuesday, March 02, 2004 3:29 PM
Subject: RE: [Jxcl-devel] RE: So what's the status of JXCL


> On Tue, 2 Mar 2004, King Dale wrote:
>
> > I've been studying the code and think I have a grasp. I think we can fix
the
> > try-finally problems. It appears one problem is that the Eclipse
compiler
> > generates something entirely different than the Sun compiler. I think
what
> > javac generates has also changed from one version to another. Looking at
> > this old article from 1997 it describes the code that Eclipse generates:
> >
> > http://www.javaworld.com/javaworld/jw-02-1997/jw-02-hood.html
>
> More to read over coffee.  However, at a glance it's an inaccurate
> description of how the compiler generates code.

I think it is more of an outdated description of how things were done long
ago. Note that the article is from 1997.

> > So something has changed in javac land. What I see from javac duplicates
the
> > code from the finally clause in multiple places if it is small and uses
a
> > subroutine if it is longer.
>
> Got an example?  I test this using samples where the finally clause is one
> statement.  It always uses the subroutine.

Examples below.

> >                        Eclipse seems to always use the subroutine. When
> > javac uses the jsr, it duplicates the jsr in all paths that exit the try
> > block gracefully then does a goto to the code after the try. Eclipse
moves
> > the jsr to the end and has all those paths do a goto to the jsr which
then
> > falls through to the code after the try.
>
> That's different from what I see.

Which version are you using. The impression I got from the bug reports is
that they changed this for 1.4 or later.

> > I'll try to do a bug search in the bug database to see if I can learn
more.
> > I'm guessing that they did this to make life easier for HotSpot to
figure
> > things out, which makes like more complicated for those trying to figure
out
> > control flow with the output of other compilers.

Looking at the bug database there are complaints about the changes to the
generated code for finally and talk about the inlining of finally code,
which is what I see.

I've attached 3 files

Test.java is a version of your Finally class that adds another version of
runTest that makes the finally bock larger.
javap_javac_1.4.2_03.txt is the output of javap -verbose for the class
compiled with JDK1.4.2_03-b02.
javap_eclipse_3.0M7.txt is the javap -vebose output when compiled with
version 3.0M7 of Eclipse.

Note that javap screws up some line endings.

Notice the fun part that javac actually has duplicated the finally code in
multiple places so has multiple instances in the line number table.

I'm beginning to think annotation at the source level is the way to go. It
looks like there are too many ambiguities in the bytecode and it will
probably only get worse in 1.5.
--
  Dale King