JDK-6457137 : Traffic of ClassPrepareRequests
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2006-08-04
  • Updated: 2023-12-14
  • Resolved: 2016-11-04
Related Reports
Relates :  
JDK-8146986 - JDI: Signature lookups for unprepared classes can take a long time
Description
Developers of J2ME support for NetBeans did measuring of the JDWP traffic, because excessive traffic makes mobility debugging problematic.
They have found that right after the attach, there is a lot of traffic related to class prepare events. It was found that there are two related requests created in the VirtualMachineImpl constructor - ClassPrepareRequest and ClassUnloadRequest. As a response to them a huge traffic is being sent from the debuggee.

Is it possible to transfer just those ClassPrepareEvents for which explicit ClassPrepareRequest was submitted?
This traffic is not only a problem for J2ME debugging, but also for remote debugging on a slow connection. See e.g. https://netbeans.org/bugzilla/show_bug.cgi?id=188732
Comments
This is not on our list of current priorities. If this changes, please reopen this issue.
04-11-2016
SUGGESTED FIX I've added a detailed description of the fix as an attachment. Hopefully this makes the patch clear and easy to understand.
04-11-2010
SUGGESTED FIX I've made an attempt to fix this by removing InternalEventHandler that is responsible for the huge traffic of ClassPrepareEvents. Instead of caching of all classes loaded in the target VM (which can also pollute too much memory in the client VM by the way), the proposed change keeps only the reference types that we were asked for. As a result, VirtualMachine.allClasses() gets slower, since we have to retrieve all the classes from the target VM. But this can be expected and this method is not so often used anyway, comparing to the other debugging functionality. With this change I've got significant improvement in performance during remote debugging. Can someone please review and integrate this patch?
12-08-2010
EVALUATION The JDI front-end keeps a cache of all classes in the debuggee. During startup, the front-end retrieves all classes to init this cache, and turns on class prepare and class unload events to maintain the cache as classes come and go. This means that a class prepare event will be sent over JDWP for every class that was prepared after the debugger attaches to the debuggee. *** (#1 of 1): [ UNSAVED ] ###@###.###
04-08-2006