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