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

Albert Noll albert.noll at oracle.com
Wed Oct 2 03:47:13 PDT 2013

Hi Valdimir,

thanks for your feedback. See comments inline.
Here is the new webrev: 

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.

Thanks again,

> 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 

More information about the hotspot-compiler-dev mailing list