As we discussed, the MultiJava project needs a
developer's tips file that lays out in more detail what
should be done as a developer working from source code.
The developer tips file should also include a description of
using JSwat for debugging. Here is the basic gist of it,
lifted from an email I wrote last August:
My general technique is to add a call to the static method
> Debug.breakMe() from the location in the code that I wish to
> investigate. I then set a breakpoint in JSwat on
invocations of this
> method and use the "step out of method" control to get at
the code I'm
> interested in. Using a method call like this allows me to
insert a
> conditional break; something that is especially useful
when debugging
> the compiler running against a large code corpus as was
the case with
> this bug.
>
> So in this particular case I attacked the bug where the
external
> generic function wasn't found. I did this by adding a
conditional
> break in JMethodCallExpression::typecheck for the case
where the
> method identifier was prependChild. Then I traced through
the method
> lookup code to make sure the correct file was being found
on the
> implicit search. It was.
>
> So the next question I had was why the file was not processed
> correctly. Again I used a conditional break, this time in
> Main::catchUpGF when the file of interest was passed as an
argument.
> I traced this processing into the processTaskQueue
re-entrant method,
> where I noticed that the task was aborting immediately
after parsing,
> instead of proceeding through to the typecheck phase. I also
> discovered that the task was aborting because the field
that tracks
> what phase processing should stop at was mis-set.
>
> Looking at the code I didn't see how this was happening,
so I added a
> breakpoint on modifications to this variable (use the
Breakpoints
> menu, it offers more sorts of breakpoints than the GUI
widgets do). I
> traced through some code looking for a misplaced set, but
didn't find
> one. But I did notice a case where the processTaskQueue
method
> terminated without resetting the variable. I looked
through the code
> (having narrowed the problem to a 10-12 line block of code
between
> setting and resetting the variable) and realized that a caught
> exception was just being rethrown and the variable wasn't
reset in
> this case.
>
> A couple of other things to keep in mind. JSwat seems to
memorize the
> CLASSPATH you were using the first time you ran it. You
need to go to
> the Options menu and Set Classpath to add additional
directories.
> Also the working directory for the compiler when run from
within JSwat
> is whatever directory JSwat was started from. Thus you
need to 'cd'
> to the directory containing the test case before starting
JSWat.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=635640
The developer tips file should also include a description of
using JSwat for debugging. Here is the basic gist of it,
lifted from an email I wrote last August:
My general technique is to add a call to the static method
> Debug.breakMe() from the location in the code that I wish to
> investigate. I then set a breakpoint in JSwat on
invocations of this
> method and use the "step out of method" control to get at
the code I'm
> interested in. Using a method call like this allows me to
insert a
> conditional break; something that is especially useful
when debugging
> the compiler running against a large code corpus as was
the case with
> this bug.
>
> So in this particular case I attacked the bug where the
external
> generic function wasn't found. I did this by adding a
conditional
> break in JMethodCallExpression::typecheck for the case
where the
> method identifier was prependChild. Then I traced through
the method
> lookup code to make sure the correct file was being found
on the
> implicit search. It was.
>
> So the next question I had was why the file was not processed
> correctly. Again I used a conditional break, this time in
> Main::catchUpGF when the file of interest was passed as an
argument.
> I traced this processing into the processTaskQueue
re-entrant method,
> where I noticed that the task was aborting immediately
after parsing,
> instead of proceeding through to the typecheck phase. I also
> discovered that the task was aborting because the field
that tracks
> what phase processing should stop at was mis-set.
>
> Looking at the code I didn't see how this was happening,
so I added a
> breakpoint on modifications to this variable (use the
Breakpoints
> menu, it offers more sorts of breakpoints than the GUI
widgets do). I
> traced through some code looking for a misplaced set, but
didn't find
> one. But I did notice a case where the processTaskQueue
method
> terminated without resetting the variable. I looked
through the code
> (having narrowed the problem to a 10-12 line block of code
between
> setting and resetting the variable) and realized that a caught
> exception was just being rethrown and the variable wasn't
reset in
> this case.
>
> A couple of other things to keep in mind. JSwat seems to
memorize the
> CLASSPATH you were using the first time you ran it. You
need to go to
> the Options menu and Set Classpath to add additional
directories.
> Also the working directory for the compiler when run from
within JSwat
> is whatever directory JSwat was started from. Thus you
need to 'cd'
> to the directory containing the test case before starting
JSWat.