RFR(M) : 8064669 : compiler/whitebox/AllocationCodeBlobTest.java crashes / asserts
igor.ignatyev at oracle.com
Wed Nov 26 17:45:05 UTC 2014
can I get a review for this fix?
On 11/23/2014 11:23 AM, Igor Ignatyev wrote:
> 346 lines changed: 271 ins; 42 del; 33 mod;
> On 11/21/2014 06:33 PM, Igor Ignatyev wrote:
>> 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.
> - replaced instantiation of j.l.Thread by Thread::allocate_threadObj method
> - added comments
>>> 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/
> - introduced NMethodSweeper::_stat_lock -- the mutex which is used
> during sweeper's statistics updates
> - moved statistics updates from NMethodSweeper::process_nmethod
>>> 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.
> during testing, I found that sweeper_thread can complete its work and be
> deleted, so sweeper_thread->threadObj() can be collected before
> JNIHandles::make_local creates a handler. to prevent such situations, I
> moved Thread::start after JNIHandles::make_local
>>> 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
>>>> 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
>>>> 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