JDK-4675577 : RFE: need more efficient logic for BREAKPOINT/SINGLE_STEP in one set
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2002-04-26
  • Updated: 2003-04-12
  • Resolved: 2002-09-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
JDK-4195505 - JVMDI: Breakpoints not reported when stepping
Relates :  
JDK-4478469 - single stepping with lots of Java threads is very slow
Relates :  
JDK-4416804 - jdb in 1.3 is 6.5 times slower than 1.2
Description
###@###.### 2002-04-26

The JPDA backend currenty uses temporary BREAKPOINT events to cause
BREAKPOINT and SINGLE_STEP events at the same location to be in the
same event set. In HotSpot, setting and clearing a BREAKPOINT is
done via a VM operation which is done during a safepoint. This isn't
a problem with just a few threads, but doesn't scale well when you
have a lot of threads.

This logic was originally added with the following bug fix:

4195505 4/3 JVMDI: Breakpoints not reported when stepping

This change should be done with the HotSpot work being done via:

4478469 4/2 single stepping with lots of Java threads is very slow
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic mantis mantis-b02 FIXED IN: mantis mantis-b02 INTEGRATED IN: mantis mantis-b02
14-06-2004
EVALUATION ###@###.### 2002-05-10 Add a routine that returns true if a BREAKPOINT is set at the current location and false otherwise. Update the deferred event logic to only defer the event if a BREAKPOINT is set at the same location as the current event.
11-06-2004
SUGGESTED FIX ###@###.### 2002-05-24 See 4416804_4675577-webrev.tar for the proposed changes. ###@###.### 2002-06-18 See 4416804_4675577-webrev-cr1.tar for the relative changes made during code review round 1. ###@###.### 2002-06-25 One additional change was found during the testing phase for the Hopper port: ------- src/share/back/threadControl.c ------- *** /tmp/sccs.JTaiCI Tue Jun 25 15:42:45 2002 --- threadControl.c Tue Jun 25 15:37:40 2002 *************** *** 1719,1724 **** --- 1719,1728 ---- node = findThread(env, &runningThreads, thread); if (node != NULL) { node->cleInfo.eventKind = 0; + if (node->cleInfo.clazz != 0) { + (*env)->DeleteGlobalRef(env, node->cleInfo.clazz); + node->cleInfo.clazz = 0; + } } debugMonitorExit(threadLock); *************** *** 1757,1762 **** --- 1761,1770 ---- node = findThread(env, &runningThreads, thread); if (node != NULL) { node->cleInfo.eventKind = kind; + /* Create a class ref that will live beyond */ + /* the end of this call */ + clazz = (*env)->NewGlobalRef(env, clazz); + /* if returned clazz is NULL, we just won't match */ node->cleInfo.clazz = clazz; node->cleInfo.method = method; node->cleInfo.location = location; Hopper is better about catching uses of non-global references after they have been released which is why this bug made it through the Merlin-Update2 testing cycle.
11-06-2004
PUBLIC COMMENTS .
10-06-2004