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

[Rickard Bäckman]

Thank you for the review.

On 07/07, Igor Veresov wrote:
> 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
> >>>> 
> >>>> 
> >> 
> 
/R
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140708/7e58db6b/signature.asc>