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

[Christian Thalinger]

Looks good.

On Oct 2, 2013, at 3:47 AM, Albert Noll <albert.noll at oracle.com> wrote:

> Hi Valdimir,
> 
> thanks for your feedback. See comments inline.
> Here is the new webrev: http://cr.openjdk.java.net/~anoll/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/20131003/e581dde1/attachment.html