[9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test

[Vitaly Davidovich]

Hi Albert,

A couple of easy suggestions/ideas:

1) since you don't resize the backing array, you can make the size be a
template parameter - compiler can then constant propagate it and save a few
instructions.

2) if #1 above is not needed, can also consider making size be a power of 2
so you can replace mod instruction with an & when computing idx.

You did mention that this is the bare minimum implementation to support
just what you need, so perhaps above is overkill anyway.

Thanks

Sent from my phone
On Feb 21, 2014 3:06 AM, "Albert" <albert.noll at oracle.com> wrote:

>  Hi,
>
> could I get reviews for this small patch?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839
>
> Problem: The problem is that the patch (7194669) - which was supposed to
> speed-up dependency checking
>                causes a performance regression. The reason for the
> performance regression is that most dependencies
>                are unique, so we have the overhead of determining if the
> dependency is already checked plus the
>                overhead of dependency checking. The overhead of searching
> is significant, since we perform
>                a linear search on 6000+ items each time.
>
> Solution: Use a hashtable instead of linear search to lookup already
> checked dependencies. The new hashtable
>                is very rudimentary. It provides only the required
> functionality to solve this bug. However, the functionality
>                can be easily extended as needed.
>
> Testing: jprt, failing test case, nashorn. The failing test case completes
> in approx. the same time as before 7194669.
>              For nashorn + Octane, this patch yields the following times
> spent for dependency checking:
>
>               with this patch:  844s
>                        7194669: 1080s
>            before 7194669: 5223s
>
> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/
>
> Thanks,
> Albert
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140221/91eaff63/attachment.html