RFR (S): 8025656: compiler/8013496/Test8013496.sh fails on assert
Vladimir Kozlov
vladimir.kozlov at oracle.com
Wed Oct 2 10:21:23 PDT 2013
Good. Can you aligh the comment a bit nicely before the push :) (no need to review).
Thanks,
Vladimir
On 10/2/13 3:47 AM, Albert Noll wrote:
> Hi Valdimir,
>
> thanks for your feedback. See comments inline.
> Here is the new webrev: http://cr.openjdk.java.net/~anoll/8025656/webrev.01/
> <http://cr.openjdk.java.net/%7Eanoll/8025656/webrev.01/>
>
> On 01.10.2013 19:33, Vladimir Kozlov wrote:
>> Albert,
>>
>> I think the only problem is call to handle_full_code_cache() in C1 Compiler::get_buffer_blob(). Please verify that.
>> There are calls during adapters generation and I don't see which state at that time.
> Yes, I think that this is the only call that causes the assertion to fail. I checked the state of the thread in
> AdapterHandlerLibrary::create_native_wrapper() and AdapterHandlerLibrary::get_adapter and in both
> functions the thread is in state '_thread_in_vm'.
>
>> If the problem only in get_buffer_blob() it will be solved when you remove the call in 8023014.
> Yes, it will be removed.
>> On other hand it will not hurt to have transition here.
> I agree that's why I would keep it. It could help to fix JDK-8022968 more easily.
>> You need to fix comment:
>>
>> "This ensures that handle_full_code_cache()" should be "This ensures that possibly_sweep()"
>> Fixing the test is fine.
>>
> Done.
>
> Thanks again,
> Albert
>
> Thanks,
>> Vladimir
>>
>> On 10/1/13 5:04 AM, Albert Noll wrote:
>>> Hi,
>>>
>>> could I have a review for this small patch?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8025656
>>> webrev: http://cr.openjdk.java.net/~anoll/8025656/webrev.00/ <http://cr.openjdk.java.net/%7Eanoll/8025656/webrev.00/>
>>>
>>> Problem: handle_full_code_cache is called when the calling thread is in a wrong state.
>>>
>>> Solution: Switch to the right thread state before calling sweeper.
>>>
>>> I also re-wrote the corresponding test. In the new version, the arguments take a larger InitialCodeCacheSize
>>> and ReservedCodeCacheSize. Too small code cache sizes can fail the compiler runtime initialization and hence
>>> the test. Checking proper compiler runtime initialization is checked by 8023014.
>>>
>>> Many thanks in advance,
>>> Albert
>>>
>>>
>
More information about the hotspot-compiler-dev
mailing list