BEA Systems has reported the following problem seen with their
WebLogic WorkShop Tool product.

They are couple of related RFE's already fixed in 1.4.1 :


4506433 - Tools vendors: debugging is too slow 
4656977 - Tools vendors: debugging is too slow (in C2) 
							
But BEA is more concerned about the startup performance still seen
in 1.4.1. They observe a difference of 50% or more in application 
startup when -Xdebug is specified to enable debugging.

Customer Problem Description:
----------------------------
We are seeing big startup overheads from enabling
basic debugging support in the Sun VM.  Being able
to run with reasonable performance with debugging
enabled is increasingly important to us with the
focus on  Workshop and iterative development.

We'd like to understand whether the overhead we're
seeing is typical, whether there are any workarounds,
and whether Sun has any plans to improve this in the
future.  My understanding was that 1.4.1 was
supposed to have improvements in this area, but
we're still seeing a lot of overhead.

====================================

SUMMARY:

We are seeing a performance hit in startup times of 50% or more
when we specify -Xdebug to enable debugging.

DETAILS:

We're running with the HotSpot Client VM (1.4.1_02).

We observe a difference of 50% or more in application startup when
we specify -Xdebug to enable debugging.  For example an application
that starts in 1:05 without -Xdebug requires 1:39 with -Xdebug.
My initial suspicion was that -Xdebug was causing us to run
in pure interpreted mode, except that we're running with 1.4.1 which
is supposed to support "Full Speed Debugging".  We see this overhead
without any debugger attached and without even loading the JDWP
library (no -Xrunjdwp option).

QUESTIONS:

- Is this typical?  If so, what are the reasons for this level
   of startup degradation and is this likely to improve in the future?

- A common scenario is for a user to start the application,
   and once it has gotten through its basic startup to start a
   debugging session.  In this case the startup performance is
   affected by the presence of -Xdebug even though the user
   isn't actively debugging during startup.  Is there anything
   that can be done to reduce the -Xdebug overhead prior to
   the start of actual debugging?  The JPDA documentation
   talks about using "onthrow" and "oncaught" options
   to delay the initialization of the JDWP library,
   but the JDWP library doesn't seem to be the problem in this
   case - the problem is the basic overhead of -Xdebug.  Is
   there any way to delay this overhead until we actually
   start debugging - or to programatically turn on or off
   -Xdebug support after the VM has started?

- Any other magic options, tricks, or workarounds you can suggest?