You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Ivan Popov (JIRA)" <ji...@apache.org> on 2007/07/07 12:38:04 UTC

[jira] Updated: (HARMONY-2889) [jdktools][jdwp] group identical Breakpoint, Step, MethodEntry, MethodExit events

     [ 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.