What does AggressiveOpts do with my timings?

Steve Bohne Stephen.Bohne at Sun.COM
Thu Mar 27 12:20:01 PDT 2008


Hi Regina,

This is likely a bug in the time caching feature introduced in b12 under 
AggressiveOpts.  You can confirm this by running with 
"-XX:+AggressiveOpts -XX:-CacheTimeMillis" and see if the problem goes 
away.  There is an interaction between time caching, counted loops with 
the server compiler, and biased locking, that can make time offsets go 
squirrelly around 4 seconds (or BiasedLockingStartupDelay) into the 
run.  It should go away around b26, when time caching will be removed.

Steve

Regina Anger wrote:
> Hi,
>
> When I run the code attached belog with -XX:+AggressiveOpts I get weird timings.
>
>
>   1       BugTest::fillRect (27 bytes)
>   2       java.lang.Math::abs (11 bytes)
>   1%      BugTest::main @ 9 (50 bytes)
>   1%  made not entrant  (2)  BugTest::main @ 9 (50 bytes)
> Run: 677
>   2%      BugTest::main @ 9 (50 bytes)
> Run: 780
> Run: 623
> Run: 676
> Run: 676
> Run: 624
> Run: 104  <----- Why so low?
> Run: 1193<------ Why so high?
> Run: 624
>
> Without -XX:+AggressiveOpts the timings are stable at ~630ms after initial warm-up.
> I am using JDK7b20 on Linux.
> Although its really unimporntant, I am quite curious, whats going on here?
>
> Regi
>
> public class SpeedTest {
> 	static int[] opcodes = new int[30];
> 	static int cnt = 0;
> 	static int dummy=0;
> 	
> 	public static void main(String[] args) {
> 		while (true)
> 		{			
> 			long start = System.currentTimeMillis();
> 			
> 			for (int i = 0; i < 100000000; i++)
> 			{
> 				test();
> 			}
> 			System.out.println("Run: " + (System.currentTimeMillis() - start));
> 		}
> 	}
> 	
> 	public static final void test() {
> 			dummy += opcodes[Math.abs(++cnt % 30)];
> 	}
> }
> _________________________________________________________________
> Explore the seven wonders of the world
> http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE
>   




More information about the hotspot-compiler-dev mailing list