[webkit-reviews] review requested: [Bug 114893] fast/workers/dedicated-worker-lifecycle.html needs a re-write : [Attachment 198956] the patch.

[bugzilla-daemon at webkit.org]

Mark Lam <mark.lam at apple.com> has asked  for review:
Bug 114893: fast/workers/dedicated-worker-lifecycle.html needs a re-write
https://bugs.webkit.org/show_bug.cgi?id=114893

Attachment 198956: the patch.
https://bugs.webkit.org/attachment.cgi?id=198956&action=review

------- Additional Comments from Mark Lam <mark.lam at apple.com>
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.