JDK-6272174 : -Djava.compiler=NONE and -Xdebug anachronisms unanachronistically disable full-speed debugging
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 5.0,6,6u2
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2005-05-18
  • Updated: 2019-07-03
  • Resolved: 2011-04-24
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.
JDK 6 JDK 7 Other
6u2Fixed 7Fixed hs11Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
The following test case fails pretty much on all the platforms during 
> our nightly runs
> Test Case : nsk/regression/b4516835
> Since the tlog file indicates the dependency on "JVMDI", I was wondering 
> if this is a supported test case
> #==> nsk/regression/b4516835 test LOG:
> #--> This test for #4516835 bug; Category: hotspot; Subcategory: jvmdi
> #    Synopsis: JVMDI: -Djava.compiler=NONE anachronism disables 
> full-speed debugging


I've looked in the ancient bug report which regressed, and have learned that the 1.3 JPDA front-ends the back-end was launched with this pair of options.  This mean if someone used a debugger built on a 1.3 JDK to debug a program running on a Mustang VM then they wouldn't get full-speed debugging.  Clearly that was a bigger deal during the dvelopment of 1.4 which is when the original bug 4516835 was created.

From what I can see we never spec'ed the interaction between these flags (at least not externally), so we have not broken any contracts.  This twistedly arcane behavior can be restored, if anyone cares, by adding a global flag.  In either case, the code/comments at arguments.cpp:1998 that implements this needs to be dealt with:

      // This must be done after all arguments have been processed.
      // java_compiler() true means set to "NONE" or empty.
      // The -Xdebug mini-agent sets the breakpoint capability (amongst many).
      if (java_compiler() && !JvmtiExport::can_post_breakpoint()) {
        // For backwards compatibility, we switch to interpreted mode if
        // -Djava.compiler="NONE" or "" is specified AND "-Xdebug" was
        // not specified.

###@###.### 2005-05-18 02:23:57 GMT
###@###.### 2005-05-18 02:36:19 GMT

This bug affects the following NSK test:


###@###.### 2005-05-25 19:28:37 GMT
Please, see the description of the main CR.
Please, note that the 6u2 should match the JDK 5 behavior to fix the interoperability issue.

SUGGESTED FIX See attached webrev.

EVALUATION The 6u2 implementation should match jdk 5 behavior. Please, see my comment in the main CR. It includes processing of the java.compiler proprety, the -Xdebug option and the environment variables: JAVA_COMPILER, JAVA_TOOL_OPTIONS and _JAVA_OPTIONS .

SUGGESTED FIX Set a global flag on -Xdebug instead of using the breakpoint hack ###@###.### 2005-05-18 02:41:42 GMT

EVALUATION NetBeans 4.1 beta still uses it to launch debuggees: 6925 pts/27 S 0:00 /net/mmm.sfbay/export/home/jjh/jdk1.5.0/jre/bin/java -Xdebug -Xnoagent -Djava.compiler=none -Xrunjdwp:transport=dt_socket,address=localhost:62343 -classpath /home/jjh/AnagramGame/build/classes com.toy.anagrams.ui.Anagrams I suspect other IDEs do to. I think we better fix it. - jjh ###@###.### 2005-05-18 02:40:38 GMT