Comments from Jon:

Yep, I'm still seeing a severe JVM process performance issue with the
profiled JVM upon instrumenting the classes on the new JVM's... it
works perfectly with the JFluid instrumented JDK 1.4 JVM, but
something is definately amiss with the newer JVM's when classes are
instrumented.

I think the changes you made so that the connection wont timeout and
the popup comes up in the IDE helps, but only masks the root problem
we have here.

Below are my observations when just taking the stock JBoss 4.0.2
download and running it on JDK 1.4.2, JDK 1.5.0_04, and 1.6.0-ea-b46. 
What I do is connect to them on their startup, and only do a "Monitor
Application".  Once the Jboss server has completed its startup
sequence, I then "Modify Profiling" to the "Analyze Memory Usage" and
let it go and instrument all classes in the JVM, the dialog box is up
for 10 seconds or so, and then goes away.

Then with the JFluid 1.4.2 JVM, less than 10 seconds later, I'm all
done and the profiled JVM is responding back to the profiler.

With the other two, I have to wait more than 5 minutes until the
profiled JVM begins sending data back to the profiler.  Something is
definately amiss.

Observe the process stats of the profiled java process before the
instrumentation occurs:

JFLUID JDK 1.4.2 JVM:
Kernel Time: 02.281 User Time: 31.312
Private bytes: 176M  Peak: 176M
Working Set: 85M     Peak:  85M
Page Faults: 25K

JDK 1.5.0:
Kernel Time: 03.248 User Time: 35
Private bytes: 178M  Peak: 178M
Working Set: 86M     Peak:  86M
Page Faults: 28K

JDK 1.6.0 -- Java VM: Java HotSpot(TM) Client VM 1.6.0-ea-b46
Kernel Time: 04.031 User Time: 37.703
Private bytes: 179M  Peak: 180M
Working Set: 86M     Peak:  86M
Page Faults: 30K

Observed the process stats of the profiled java process after instrumentation:

JFLUID JDK 1.4.2 JVM:
Kernel Time: 02.953 User Time: 39.750
Private bytes: 183M  Peak: 187M
Working Set: 104M     Peak:  108M
Page Faults: 30K

JDK 1.5.0:
Kernel Time: 11.250 User Time: 2:28.031
Private bytes: 195M  Peak: 1191M
Working Set: 82M     Peak:  455M
Page Faults: 346K

JDK 1.6.0 -- Java VM: Java HotSpot(TM) Client VM 1.6.0-ea-b46
Kernel Time: 11.343 User Time: 2:04.937
Private bytes: 209M  Peak: 1186M
Working Set: 35M     Peak:  585M
Page Faults: 343K

Will partially affress in M10 by doing redefine in batches ratehr than all at 
once.

See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6340201

This particular issue is fixed in M10 to the degree that is possible on the NB 
profiler side. There are issues filed against the JDK that cover the remaining 
parts:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6340201
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6173565

Verification of old issues.

Closing old issues

Reverting to original Target Milestone value changed by mistake. Sorry for
inconvenience.