RFR(M) : 8064669 : compiler/whitebox/AllocationCodeBlobTest.java crashes / asserts

[Vladimir Kozlov]

Could you add comments to create_sweeper_thread()? It is not clear from 
first glance.

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.

Thanks,
Vladimir

On 11/14/14 7:03 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8064669/webrev.00/
> 261 lines changed: 231 ins; 22 del; 8 mod;
>
> Hi all,
>
> Please review patch:
>
> Problems:
> 0. NMethodSweeper::possibly_sweep is executed outside
> CodeCacheSweeperThread
> 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.
>
> Fix:
> 0. WB_ForceNMethodSweep use CodeCacheSweeperThread to execute
> possibly_sweep
> 1. move ctor invocation to locked section
> 2. handle safepoint after processing nmethod in
> NMethodSweeper::sweep_code_cache
>
> 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
>
> jbs:https://bugs.openjdk.java.net/browse/JDK-8064669
> testing: jprt + compiler/whitebox tests