RFC(S) 8234146: [TESTBUG] compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC

[Reingruber, Richard]

Hi,

I'd like to get comments on two alternative fixes for 

Bug:    https://bugs.openjdk.java.net/browse/JDK-8234146

The timeouts occur when the system is under load. Then the list of dependent nmethods of the dynamic
call site of the PingPongTest gets as long as 1500 nmethods. The list is iterated in
DependencyContext::mark_dependent_nmethods() every time the call site target is changed. And this
takes longer and longer as the list grows. Note that dependents are removed only when they are made
zombie, but this doesn't happen here.

The list of dependent nmethods is virtually empty if the system is idle, because then the target is
changed faster than the method holding the call site gets compiled. When the jit finishes a
compilation it discards the new nmethod, because the call site target was changed already.

To reproduce long runs I'd suggest to run ContinuousCallSiteTargetChange$PingPongTest manually
taking the command from ContinuousCallSiteTargetChange.jtr of a previous run. Under load [1] the
test will take about 10x as long as without load. 30s vs 3s on my linux x86_64 box for the server
config. With the fixes below the test will take under load approximately as long as without load.

There are 2 possible fixes I'd like to get comments for:

Option A: Force the NMethodSweeper using the whitebox api.
Webrev A: http://cr.openjdk.java.net/~rrich/webrevs/8234146/A/webrev.0/

Option B: Specialize DependencyContext::mark_dependent_nmethods() for call site target changes,
i.e. flag list elements that are marked for deoptimization. Upon the next target change only new
dependents are marked for deoptimization. The list iteration is ended as soon as an element is
encountered that is already flagged.
Webrev B: http://cr.openjdk.java.net/~rrich/webrevs/8234146/B/webrev.0/

Personally I like B better, because I think it is simple and straight forward: if the target
changes, then all dependents need to be invalidated. By construction of the list we can stop the
invalidation if we find an element that was invalidated before. This specialization is of course
less generic, and there might be new types of call site dependencies for which it is illegal, but
currently I can't think of any.

Curious about your comments...

Thanks,
Richard.

[1] To simulate load you can pin the jvm process to one cpu (e.g. on Linux with "taskset 1 java ...")
    or
    wget http://cr.openjdk.java.net/~rrich/webrevs/8234146/CPULoadGenerator.java && java CPULoadGenerator.java N
    where N is the number of CPUs of your box