RFR (S): 8025656: compiler/8013496/Test8013496.sh fails on assert

[Albert Noll]

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
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131002/4aff17ba/attachment.html