review (S) for 6956931: assert(SafepointSynchronize::is_at_safepoint()) failed: must be executed at a safepoint

Daniel D. Daugherty daniel.daugherty at oracle.com
Wed Jun 2 11:21:22 PDT 2010


src/share/vm/code/nmethod.cpp
    Looks like the old code (1344-1358) had the possibility of a
    double event post for both JVM/TI and dtrace. The newly
    refactored code doesn't have that (possible) issue. Nice fix.

    I'm not aware of any open bugs complaining about double
    CompiledMethodUnload events or dtrace probes, but if there are
    I think you've fixed those too.

src/share/vm/prims/jvmtiExport.hpp
    internal_post_compiled_method_unload() should be
    post_compiled_method_unload_internal() if you want to follow
    the existing style in jvmtiExport.

src/share/vm/prims/jvmtiExport.cpp
    Same internal_post_compiled_method_unload() naming issue

Dan


On 6/2/2010 10:51 AM, Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/6956931
>
> 6956931: assert(SafepointSynchronize::is_at_safepoint()) failed: must be executed at a safepoint
> Reviewed-by:
>
> SSince the sweeper no longer runs at a safepoint the compiled method
> unload logic doesn't always run at a safepoint so we need a new
> synchronous notification path that's equivalent to the
> compiled_method_load logic.  I refactored the code a bit to share the
> core notification logic and I refactored the notification in nmethod
> to remove duplication.  Tested with NSK jvmti,jdb,jdi,hprof suites.


More information about the hotspot-compiler-dev mailing list