RFR(M) : 8064669 : compiler/whitebox/AllocationCodeBlobTest.java crashes / asserts
vladimir.kozlov at oracle.com
Thu Nov 20 19:37:40 UTC 2014
Could you add comments to create_sweeper_thread()? It is not clear from
You create a second CodeCacheSweeperThread (first is created during VM
startup) to just run sweeper_thread_entry(). Right? How these 2 threads
interacts (I mean do we need locks?). Or CodeCache_lock in
sweeper_thread_entry() is enough?
How you stop InfiniteLoop daemon thread? It will run after VM exits?
The rest change seems fine.
On 11/14/14 7:03 AM, Igor Ignatyev wrote:
> 261 lines changed: 231 ins; 22 del; 8 mod;
> Hi all,
> Please review patch:
> 0. NMethodSweeper::possibly_sweep is executed outside
> 1. DummyBlob is initialized after the lock is released, so other threads
> are able to see uninitialized blob
> 2. NMethodSweeper::sweep_code_cache can pass null to process_nmethod,
> this also can lead to a crash. this situation can happen if safepoint
> happens during sweeping and after safepoint another thread iterates over
> all nmethods.
> 0. WB_ForceNMethodSweep use CodeCacheSweeperThread to execute
> 1. move ctor invocation to locked section
> 2. handle safepoint after processing nmethod in
> 3. added new test to verify that forceNMethodSweep actually work
> 4. AllocationCodeBlobTest is modified
> - to checks that deoptimization works fine w/ dummy blobs
> - to execute forceNMethodSweep more often to increase a chance to
> catch such kind problems
> testing: jprt + compiler/whitebox tests
More information about the hotspot-compiler-dev