#14 Proposal: Use of Method{Entry|Exit}Events

[Johannes Rieken]

This proposal supports the use of the MethodEntryEvent
and MethodExitEvent instead of the BreakpointEvent.
The goal is to simplify the way Jassda works by
increasing it's speed.

Method{Entry|Exit}Events: These event types can be used
to trigger an event by entering or leaving a method. By
the use of filters they can be limited to certain classes.

Currently Jassda uses breakpoints to mark the begining
and end of a method. By hitting these breakpoints
appropriate events are triggered. Contrary to
MethodXXXEvents breakpoints work for a single code
location s.t. every breakpoint refers to a method-begin
or a method-end. But what does it take to install a
breakpoint?

*Jassda needs to be informed of all classes currently
loaded and all classes being loaded during program
execution. This causes a lot of traffic between jassda
and it's backend, and forces a suspend-resume action of
the vm for every class. (One can see that by tracing
JDWP output during a Jassda run.)

*If a class is mentioned by the modules all methods
have to be determined.

*By triggering dummy events for methods Jassda learns
which methods are important for the modules. This is
time consuming and the dummy events are a bit awkward.

*Jassda needs to inspect the Bytecodes and
LineNumberTable for every method of interest. After
that it can set breakpoints

*Jassda stores every installed breakpoint in a
BreakpointPool in order to assign it to a method begin
or end.

The proposal suggests to ommit all these steps and to
install MethodEntry/ExitEvents for all classes the
modules listen on. This can be done during start-up by
changing the method
'Broker.registerControlEvents(Debuggee)'. This is very
simular to the way the ClassPrepareEvent is set up.
Once installed these events will notify Jassda of
*every* method entered and exited. This will cause some
overhead but my assumption is that it is less than the
steps mentioned above. There would be no need for a
ClassPrepareEvent, code inspection, and breakpoint storage.

With the release of Java 1.6 the MethodExitEvent will
have a new method which allows retrieval of the return
value - if it exists. This would spare the bytecode
manipulation prior to the usage of Jassda and add some
more comfort for users.

Although this proposal will be laborious to implement
it should simplify the way Jassda works and lead to
faster execution.
*less steps to mark a method begin/exit are required
*JDWP traffic is reduced
*no need to simulate events and to store breakpoints
*(after 1.6) no need for prior code manipulation

Well, it is still to be discussed and to be assigned...