407894 - MAc timer returns values that are a power of 2

Status: VERIFIED FIXED

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Brent Baker]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: 

Calling getTimer() on mac will only return values that are a power of 2.

Reproducible: Always

Steps to Reproduce:
1. ./shell test.abc


Actual Results:  
The timer values that will be printed will start at zero and then after a couple of zeros it will be 2048, and depending on the speed of the machine may make it to 4096.

Expected Results:  
Printed timer values should be real.

Comment 1

[Brent Baker]

Attachment: Testcase source

Comment 2

[Brent Baker]

Attachment: Testcase compiled

Comment 3

[Tommy Reilly]

Attachment: Patch

Comment 4

[Brent Baker]

A testcase should be added that will basically check that the result from the getTimer() is not always a value that is a power of 2.

Comment 5

[Brent Baker]

Attachment: Acceptance testcase

Comment 6

[Edwin Smith]

Comment on attachment 367020 [details] [diff] [review]
Acceptance testcase

this test could easily return false 10 times on a fast system with a sufficiently coarse timer.

Comment 7

[Brent Baker]

Attachment: testcase v2

Changed code to keep checking the timer until there is a new value and make sure that the 2 values are not a power of 2. If the values are equal a load loop is run (to take up time). The load loop is tuned to the machine by increasing its load until the timers are different. Then this load factor is what is used for subsequent loops. This should make sure that enough work is happening on fast machines and not too much on slow machines.

Comment 8

[Edwin Smith]

Comment on attachment 367075 [details] [diff] [review]
testcase v2

btw, Math.pow(sleeper,2) is overkill, sleeper *= sleeper would be the same.  but check this out: you're squaring sleeper, which will grow super fast (2, 4, 16, 256, 64k, 4B) -- the last two steps are so far apart, in the off chance you get to 64k, the next one will hang or wraparound (wrap around, i guess, with signed int math). the timer will be stable with a "just" exponential curve: 

(sleeper <<= 2).

Comment 9

[Brent Baker]

Pushed testcase as 1620:7a6b74ed85a0

Comment 10

[Brent Baker]

removing QRB request, bug resolved/verified