This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 243200 - Debugging JavaME: excessive requests from NetBeans
Summary: Debugging JavaME: excessive requests from NetBeans
Status: REOPENED
Alias: None
Product: debugger
Classification: Unclassified
Component: Java (show other bugs)
Version: 8.0
Hardware: PC Windows 7
: P3 normal (vote)
Assignee: Martin Entlicher
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-24 08:11 UTC by BorisUlasevich
Modified: 2014-03-31 09:24 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description BorisUlasevich 2014-03-24 08:11:35 UTC
We should have a way to disable functionality not related with JavaME when debugging JavaME applications. Excessive requests reduces performance, loads the channel, and makes VM to do a lot of unnecessary work.

1. Each StepInto comes with Nashorn-related breakpoints requests:

<== ffd2: EventRequest.Set eventKind:CLASS_PREPARE suspendPolicy:EVENT_THREAD modifiers:1 
          modKind:CLASSMATCH classPattern:"jdk.nashorn.internal.runtime.ScriptFunctionData" 
<== ffd6: VirtualMachine.ClassBySignature signature:"Ljdk/nashorn/internal/runtime/ScriptFunctionData;" 

2. There are some fx-related requests at least on session start:

<== 34: EventRequest.Set eventKind:CLASS_PREPARE suspendPolicy:EVENT_THREAD modifiers:1 modKind:CLASSMATCH classPattern:"com.sun.javafx.tk.quantum.QuantumToolkit" 
<== 36: VirtualMachine.ClassBySignature signature:"Lcom/sun/javafx/tk/quantum/QuantumToolkit;" 
<== 38: EventRequest.Set eventKind:CLASS_PREPARE suspendPolicy:EVENT_THREAD modifiers:1 modKind:CLASSMATCH classPattern:"javafx.scene.Node" 

3. There are a number of not reasonable class-exclude modifiers:

<== 1d0: EventRequest.Set eventKind:SINGLE_STEP suspendPolicy:EVENT_THREAD modifiers:9 modKind:STEP thread:1 stepSize:LINE stepDepth:INTO 
         modKind:CLASSEXCLUDE classPattern:"java.lang.StringBuffer" 
         modKind:CLASSEXCLUDE classPattern:"java.lang.invoke.ConstantCallSite" 
         modKind:CLASSEXCLUDE classPattern:"java.lang.invoke.LambdaForm*" 
         modKind:CLASSEXCLUDE classPattern:"java.lang.StringBuilder" 
         modKind:CLASSEXCLUDE classPattern:"java.lang.String" 
         modKind:CLASSEXCLUDE classPattern:"java.lang.invoke.Invokers" 
         modKind:CLASSEXCLUDE classPattern:"java.lang.ClassLoader" 
         modKind:CLASSEXCLUDE classPattern:"java.lang.AbstractStringBuilder"
Comment 1 Martin Entlicher 2014-03-24 13:57:06 UTC
This is already submitted as https://bugs.openjdk.java.net/browse/JDK-6457137
I've attached a patch to that issue, but nobody has applied it yet.
Please vote for that or add comments there, we can not do anything about it in NetBeans.
Comment 2 BorisUlasevich 2014-03-31 09:24:59 UTC
The first thing JDI do after VM connection is AllClasses request, and in our case (CLDC+MEEP) it gets 116 Kb of data. It is rather painful. 

As for ClassPrepare, I do not see a problem. As I can see, JDI asks the event only on those classes where it is about to set breakpoints to.

But look to my description please. I complain there about fx- and Nashort- related requests which have nothing to do with JavaME. Plus long ClassExclude list for breakpoints - I do not think we need it for ME world as well.

I have just checked with jdb.exe debugger. It does not ask VM about fx, nashorn, lambda, etc. So it should be NetBeans specific.