[9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times (original) (raw)

Albert Noll albert.noll at oracle.com
Tue Jan 14 02:21:32 PST 2014


Hi, thanks for looking at the patch.

@Roland: Thanks for your suggestion. The current version follows your suggestion and uses pointers to the dependency arguments as identifiers. As a result, the argument identifiers are guaranteed to be unique if no safepoint occurs. A No_SafepointVerifier checks this assumption. For testing, used -XX:+SafepointALot; so far, no problem.

@Dean: I hope the above explanation answers your question.

@Christian: The current version uses an overloaded '==' operator in the class DependencySignature.

Here is the new webrev: http://cr.openjdk.java.net/~anoll/7194669/webrev.02/

Best, Albert

On 01/10/2014 09:59 PM, Christian Thalinger wrote:

This looks good. Just a suggestion (you can ignore that if you want): GrowableArray has find() and contains() methods. If you would override operator== in DependencySignature you could use GrowableArray::find().

On Jan 10, 2014, at 5:28 AM, Albert Noll <albert.noll at oracle.com> wrote:

Hi,

I've evaluated the performance difference (nashorn + octane) between binary search and a linear search. The linear-search version uses one GrowableArray<DependencySignature*> for each dependency type. The difference in dependency checking time is 15-20%, i.e., binary search is 15-20% faster than linear search. However, using linear search to cache checked dependencies is still ~4X faster compared to checking all dependencies. I guess 15-20% is not enough to justify using the new data structure. Here is the new webrev that uses linear search: http://cr.openjdk.java.net/~anoll/7194669/webrev.01/ Best, Albert On 01/09/2014 06:57 PM, Roland Westrelin wrote: As I recall running some nashorn benchmarks takes about 10X more time when using fastdebug VM if VerifyDependencies is not switched off. Thanks Vladimir. What about simply pushing the dependency signatures to an unsorted growableArray() and doing a linear search? Maybe that’s good enough?

Roland.



More information about the hotspot-compiler-dev mailing list