RFR(XS) 8046289: compiler/6340864/TestLongVect.java timeout with

Igor Veresov igor.veresov at oracle.com
Mon Jul 7 16:56:47 UTC 2014


This looks alright.

igor

On Jul 3, 2014, at 5:37 AM, Rickard Bäckman <rickard.backman at oracle.com> wrote:

> Vladimir, Tobias
> 
> I've looked into something that tries to find out when we have "good
> enough" profiling information. Since the bug I've been working on only
> happens with the -Xcomp flag, I've tried to special case that instead so
> that we don't put uncommon traps when running with -Xcomp since the
> profiling information usually is pretty bad.
> 
> Updated webrev: http://cr.openjdk.java.net/~rbackman/8046289.3/
> 
> Thanks
> /R
> 
> On 07/01, Tobias Hartmann wrote:
>> Hi,
>> 
>>> Some background: Tobias and me have been looking at JDK-8014830
>>> [1] and JDK-8030976 fixed the problem. I suspect that this change
>>> will return 8014830.
>> 
>> I just tested the changes and the bug (JDK-8014830) appears again.
>> The problem is that no uncommon trap is added after the first loop
>> and therefore the second loop, especially the call to inc(), is not
>> profiled. The compiler assumes that the call site is never executed
>> and does not inline inc().
>> 
>> I agree with Vladimir that we should not special case loop exits but
>> find a solution for the case were we only have limited or no profile
>> information.
>> 
>> Best,
>> Tobias
>> 
>>> 
>>> Best regards,
>>> Vladimir Ivanov
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8014830
>>> 
>>> On 6/30/14 11:26 AM, Rickard Bäckman wrote:
>>>> Reviews please?
>>>> 
>>>> Thanks
>>>> /R
>>>> 
>>>> On 06/23, Rickard Bäckman wrote:
>>>>> Hi,
>>>>> 
>>>>> a test started to timeout after JDK-8030976 was pushed. The
>>>>> test was run
>>>>> with -Xcomp flag, so the profiling data available is non-existing or
>>>>> small. For some cases that meant that if a loop had at least 1
>>>>> iteration
>>>>> executed it would look like the loop would always take the backedge and
>>>>> never end and we would generate an uncommon trap on the loop exit.
>>>>> 
>>>>> The small change checks if the block we are considering turning into an
>>>>> uncommon trap is a loop exit.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046289
>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8046289/
>>>>> 
>>>>> Thanks
>>>>> /R
>>>> 
>>>> 
>> 



More information about the hotspot-compiler-dev mailing list