We should be more eager about destroying it as re-creating it is cheap.
Created attachment 25337 [details] patch
Comment on attachment 25337 [details] patch r=me
Comment on attachment 25337 [details] patch First patch landed in r38654.
Created attachment 25341 [details] Patch 2 - CachedScriptSourceProvider
Comment on attachment 25341 [details] Patch 2 - CachedScriptSourceProvider > + return JSC::SourceCode(CachedScriptSourceProvider::create(cachedScript), 1); No need for the "1" here -- it's automatic. Isn't there some .bkl action that needs fixing up, too? r=me
Comment on attachment 25341 [details] Patch 2 - CachedScriptSourceProvider Second patch landed in r38664.
Created attachment 25359 [details] Patch 3 - Destroy decoded data on allClientsRemoved
Comment on attachment 25359 [details] Patch 3 - Destroy decoded data on allClientsRemoved Third patch landed in r38676.
Created attachment 25363 [details] patch 4 - Destroy decoded data on a zero-delay timer This approach adds a zero-delay timer after decoding script data to destroy it. This should handle all cases of avoiding re-decoding data shortly after initial re-decode.
Comment on attachment 25363 [details] patch 4 - Destroy decoded data on a zero-delay timer r=geoff garen
<rdar://problem/6393888>
Last patch landed in r38679.