Shared deletion list is not naturally freed and triggers too many resets in V8 with JIT optimization

_From [byron.c....@gmail.com](https://code.google.com/u/101184679827294438523/) on September 17, 2014 20:32:07_

In a run of Octane on V8 with inference-based JIT optimization (not yet committed), all shared deletion list entries remain pending until the application exits. There are ~6,000 shared deletion list entries accumulated at that point. This is not a problem in Ion. It looks like this is caused by idle worker threads in V8, which never enter DR and therefore never clear their reference count on pending deletions.

This is probably also an issue in base DR (without JIT optimization), but it is much less of a problem because only a few shared fragments are individually deleted (most deletions occur via flush, which performs a synch).

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1543_

Start by reproducing the Octane run described in the issue with V8's inference-based JIT optimization, then trace the shared deletion list and idle worker-thread handling. Done means pending deletion entries are cleared naturally without accumulating thousands of entries or requiring excessive resets; the payload names no files or tests.

Written by the indexing model from the issue text.