harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Popov (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-2889) [jdktools][jdwp] group identical Breakpoint, Step, MethodEntry, MethodExit events
Date Sat, 07 Jul 2007 10:38:04 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ivan Popov updated HARMONY-2889:
--------------------------------

    Attachment: H2889_jdwp_agent.patch

JDWP spec sys that the following different kind of events for the same location in the same
thread can be combined into single event set packet (ordered in a way they are generated by
JVMTI):

  Method Entry Event 
  Step Event 
  Breakpoint Event 
  Method Exit Event 

Implementation of combined JDWP events for different kind of collocated events is not easy,
because of asynchronous nature of JVMTI event callbacks. Agent should cache events generated
in different callbacks and send them once in a single event set packet. There are two different
approaches for such algorithm:

1. cache all events for the same location according to existing event requests and send them
in a single packet after last event callback is invoked

2. upon invocation of the first event callback check existing requests applicable to this
location, predict  other combined events, send all events in a sngle packet and ignore later
event callbacks for predicted events

Each of these approaches rely on correct order of invocation of JVMTI  event callbacks, but
second one looks less sensitive to such order and may use simple heuristics to recover from
errors. This approach is implemented in JDWP agent.

Implemented algorithm follow second approach and works as follow:

On the first invocation of a potentially combined event callback RequestManager:
  - figures out other combined events to be generated later for this location
  - combines all events into a single packet and sends event packet
  - stores info about sent events and number of ignored event callbacks

On the later invocation of a potentially combined event callback RequestManager:
  - checks if there is already stored info about predicted events for this location
  - ignores this event callback and decreases number of ignored callbacks
  - if no more ignored callbacks left or event is generated for a new location then the stored
info is deleted
  
This algorithm is simple enough and works quite stably, it's safe to apply it in JDWP agent.

Several experiments with RI revealed that it does not follow JDWP spec and never combines
METHOD_EXIT events with any other events. I added special flag in RequestManager implementation
(ENABLE_COMBINED_METHOD_EXIT_EVENT=false) to preserve compatibility with RI behavior. However,
it may be easily changes to follow JDWP spec.

I'm attaching patch 'H2889_jdwp_agent.patch' for JDWP agent, which provides this functionality.
This patch should be applied after all patches for HARMONY-2892. I tested it with JDWP unit,
functional, and stress tests, and it works fine on both Windows and Linux.


> [jdktools][jdwp] group identical Breakpoint, Step, MethodEntry, MethodExit events
> ---------------------------------------------------------------------------------
>
>                 Key: HARMONY-2889
>                 URL: https://issues.apache.org/jira/browse/HARMONY-2889
>             Project: Harmony
>          Issue Type: Improvement
>          Components: JDK
>            Reporter: Ivan Popov
>            Priority: Minor
>         Attachments: H2889_jdwp_agent.patch
>
>
> According to JDWP spec Breakpoint, Step, MethodEntry, MethodExit events for the same
location can be grouped into one event set. Without this feature user have to resume thread
twice when, for example, stepping over a line with breakpoint.
> Current implementation of JDWP agent groups only identical events, it does not group
different events into one event set. Implementing grouping for different JDWP events based
on JVMTI callbacks requires rather sophisticated algorithm.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message