Bug 114893 – fast/workers/dedicated-worker-lifecycle.html needs a re-write

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Mark Lam]

Currently, fast/workers/dedicated-worker-lifecycle.html is relying on the GC collecting an orphaned Worker object in a timely manner.  Since it is not realistic to assume when GC will collect a single object, this is an unreasonable expectation.  As a result, the test can time out waiting for the GC to act.

Instead, what is reasonable is to expect that the GC will collect Worker objects on a timely basis such that it keeps memory usage at an acceptable level.  In this case, that means the test should create a lot more than 1 Worker (we'll go with 100) and expect the GC to leave no more than a small amount around (we'll go with 20 here) in the duration of the test.  This shows that the GC is making adequate progress towards reclaiming dead Workers on a timely basis.

[Mark Lam]

Created attachment 198956 [details]
the patch.

For the max remaining orphaned workers after GC’ing, I opted to go with 10 instead of 20 workers (which was previously proposed in the bug description).  The choice is a bit arbitrary but is based on the following "back of a napkin" estimate:

1. 10 workers means 10 threads.
2. Assume each thread will take up ~128k of stack memory.
3. Assume memory used in JS heap for Worker objects, and WorkerGlobalScopes are insignificant (adequately covered by the the 128k per worker estimate above). 

Hence, total memory used by 10 workers = ~1.25M.  On a typical desktop system with 4G of RAM these days of which 2G is available, this represents ~.06% of available memory.  On an embedded device with just 256M of RAM of which 128M is available, the 1.25M represents .9% of available memory.  This seems to be still tolerable.

If we tolerate 20 workers instead, then the estimate wastage on the embedded device case will go up to 1.8% which I feel less comfortable with.  So, I’m opting to go with only tolerating a max of 10 unreclaimed orphaned workers out of 100 in the amount of time the test gets to run.

[Geoffrey Garen]

Comment on attachment 198956 [details]
the patch.

r=me

[Mark Lam]

Thanks for the review.  Landed in r148846: <http://trac.webkit.org/changeset/148846>.