JvmtiExport::post_compiled_method_unload_at_safepoint() is failing in
the following way:

    Internal Error (src/share/vm/prims/jvmtiExport.cpp:1868), pid=22577, tid=14
    assert(SafepointSynchronize::is_at_safepoint()) failed: must be executed at a safepoint

Here is the code for the failure point:

   1866 // used at a safepoint to post a CompiledMethodUnload event
   1867 void JvmtiExport::post_compiled_method_unload_at_safepoint(jmethodID mid,
 const void *code_begin) {
   1868 assert(SafepointSynchronize::is_at_safepoint(), "must be executed at a safepoint");
   1869
   1870 // create list lazily
   1871 if (_pending_compiled_method_unload_method_ids == NULL) {

This assertion failure has been seen in the following VM/NSK tests:

    nsk/jvmti/CompiledMethodUnload/compmethunload001
    nsk/jvmti/RedefineClasses/redefclass028
    nsk/jvmti/RedefineClasses/redefclass029
    nsk/jvmti/RedefineClasses/redefclass030
    nsk/jvmti/scenarios/capability/CM02/cm02t001
    nsk/jvmti/scenarios/events/EM02/em02t003
    nsk/jvmti/scenarios/events/EM05/em05t001
    nsk/jvmti/scenarios/events/EM05/em05t002
    nsk/jvmti/scenarios/events/EM07/em07t002
    nsk/jvmti/scenarios/multienv/MA10/ma10t006

These failures have been see on Solaris SPARC, Solaris SPARC-V9 and
Solaris AMD64 configs. Not all of the tests fail in every config in
evey run.

Here is a link to the Solaris SPARC Client VM -Xcomp failures:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-05-27/RT_Baseline/vm/solaris-sparc/client/comp/solaris-sparc_client_comp_nsk.jvmti.testlist/analysis.html


Here is a link Solaris SPARC-V9 Server VM -Xcomp failures:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-05-27/RT_Baseline/vm/solaris-sparcv9/server/comp/solaris-sparcv9_server_comp_nsk.jvmti.testlist/analysis.html


Here is a link to the Solaris AMD64 Server VM -Xcomp failures:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-05-27/RT_Baseline/vm/solaris-amd64/server/comp/solaris-amd64_server_comp_nsk.jvmti.testlist/analysis.html
Here is a stack trace snippet from the hs_err file from one of the failures:

--------------- T H R E A D ---------------

Current thread (0x00000001007b7000): JavaThread "CompilerThread1" daemon [_thread_in_vm, id=14, stack(0xffffffff60600000,0xffffffff60700000)]

Stack: [0xffffffff60600000,0xffffffff60700000], sp=0xffffffff606ff0f0, free space=3fcffffffff7e4cfa40k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xeb10dc];; __1cHVMErrorOreport_and_die6M_v_+0x6bc
V [libjvm.so+0x504280];; __1cPreport_vm_error6Fpkci11_v_+0x78
V [libjvm.so+0x983194];; __1cLJvmtiExportbOpost_compiled_method_unload_at_safepoint6FpnK_jmethodID_pkv_v_+0x64
V [libjvm.so+0xb6c450];; __1cHnmethodbAmake_not_entrant_or_zombie6MI_b_+0x690
V [libjvm.so+0xd8ab54];; __1cONMethodSweeperQsweep_code_cache6F_v_+0x5b4
V [libjvm.so+0xd8a578];; __1cONMethodSweeperOpossibly_sweep6F_v_+0x90
V [libjvm.so+0x467b28];; __1cMCompileQdDueueDget6M_pnLCompileTask__+0x20
V [libjvm.so+0x46bb38];; __1cNCompileBrokerUcompiler_thread_loop6F_v_+0x270
V [libjvm.so+0xe033fc];; __1cKJavaThreadRthread_main_inner6M_v_+0x174
V [libjvm.so+0xe03268];; __1cKJavaThreadDrun6M_v_+0x310
V [libjvm.so+0xbc8f2c];; java_start+0x184

The other stacks appear to be similar.
These failures have also been observed on Linux-AMD64, Win32 and
Win-AMD64. Changed the call record OS to be "generic". Also changed
the build to HSX-19-B01 show that failures will show up as "known".
The sub-baselines have the code the introduced the failures, but
the hotspot_version bump to HSX-19-B02 hasn't trickled down yet.