JDK-8075805 changed the implementation CodeCache::gc_epilogue() to also clean ICs of unloaded nmethods. Since this code is executed at a safepoint if may increase safepoint duration. A better solution is to do the cleaning in the sweeper:

diff -r c0ea5537dc8b src/share/vm/runtime/sweeper.cpp
--- a/src/share/vm/runtime/sweeper.cpp	Tue Aug 25 07:49:55 2015 +0200
+++ b/src/share/vm/runtime/sweeper.cpp	Wed Aug 26 12:56:55 2015 +0200
@@ -645,6 +645,12 @@
       assert(result == None, "sanity");
       result = Flushed;
     } else {
+      {
+        // Clean ICs of unloaded nmethods as well because they may reference other
+        // unloaded nmethods that may be flushed earlier in the sweeper cycle.
+        MutexLocker cl(CompiledIC_lock);
+        nm->cleanup_inline_caches();
+      }
       // Code cache state change is tracked in make_zombie()
       nm->make_zombie();
       SWEEP(nm);

Martin Doerr also mentioned some other potential problems with method unloading [1]:

"Additionally, it may be required to adapt a couple of assertions.
We modified the following ASSERT code (based on hotspot 25)
1. in CompiledIC::is_call_to_compiled():
Accessing cached_metadata() may be unsafe if !caller->is_alive().
2. in CompiledIC::is_call_to_interpreted():
CodeBlob* db may be gone if cb is unloaded.
3. in CompiledIC::verify():
is_call_to_compiled() has crashed. Seems to be unsafe in megamorphic case so we changed the order of the checks.
4. in nmethod::verify_clean_inline_caches():
In case of relocInfo::virtual_call_type CompiledIC may still point to a zombie method."

[1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-August/018744.html