[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:08:09 PST 2014

Hi Vitaly,

you are right, hashing would provide a faster lookup. I have to evaluate 
if using a hash container
provides a speedup over the current version or most of the time is spent 
checking dependencies.

Thanks for looking at this.


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/1256b1fa/attachment.html 

More information about the hotspot-compiler-dev mailing list