RFR(M) : 8064669 : compiler/whitebox/AllocationCodeBlobTest.java crashes / asserts
igor.ignatyev at oracle.com
Fri Nov 21 15:33:54 UTC 2014
On 11/20/2014 10:37 PM, Vladimir Kozlov wrote:
> 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?
it is enough for everything except statistics like _flushed_count,
_zombified_count, _total_time_sweeping, etc. I'll think how to deal w/ them.
> How you stop InfiniteLoop daemon thread? It will run after VM exits?
not it won't, deamon threads stop on VM exit.
> 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