[9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times
Albert Noll
albert.noll at oracle.com
Thu Jan 9 07:54:12 PST 2014
Hi Vitaly,
I have just measured where the version that includes the patch spends
most time:
It turns out that ~90% of the time is used for checking dependencies.
The remaining 10%
are spent constructing the dependency signature, performing the lookup,
and adding
dependency signatures.
Best,
Albert
On 01/09/2014 03:49 PM, Vitaly Davidovich wrote:
>
> Hi Albert,
>
> Just a thought - since you don't care about order of dependencies
> (just uniqueness) wouldn't a hashing container be more optimal than
> binary search tree?
>
> Thanks
>
> Sent from my phone
>
> On Jan 9, 2014 9:30 AM, "Albert Noll" <albert.noll at oracle.com
> <mailto:albert.noll at oracle.com>> wrote:
>
> Hi all,
>
> could I get reviews for this patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-7194669
> webrev: http://cr.openjdk.java.net/~anoll/7194669/webrev.00/
> <http://cr.openjdk.java.net/%7Eanoll/7194669/webrev.00/>
>
> Problem:
> The dependency verification code in
> CodeCache::mark_for_deoptimization walks over all live nmethods in
> the code cache and checks all dependencies for each nmethod. This
> leads to checking the same dependency multiple times which can
> take a huge amount of time.
>
> Solution:
> To avoid checking dependencies more than once, dependencies are
> abstracted by dependency signatures, which consider (i) the type
> of a dependency and (ii) the identity hashes of the arguments
> of a dependency. For each dependency that will be checked, a
> dependency signature is generated
> and that dependency signature is compared against a set of already
> checked dependency signatures.
> If a dependency has already been checked, the check is skipped.
> Dependency signatures of a specific type are stored in a binary
> tree to provide a fast lookup. I.e., each
> dependency type has its own binary tree. The key to the tree is
> the identity hash of one argument. More
> details about the data structure are described as comments in the
> code.
>
> Results:
> An evaluation of the performance gain shows a 4.3x speedup of
> dependency checking. More concretely,
> I used nashorn + octane on a 64-bit Linux Hotspot version. The
> dependency checking time of the
> original version is 3888 seconds. The dependency checking time of
> the optimized version is 902 seconds.
>
> Passed jprt.
>
>
> Many thanks in advance,
> Albert
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140109/72b55ff1/attachment-0001.html
More information about the hotspot-compiler-dev
mailing list