- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 13 Feb 2010 15:07:04 -0500
- To: Ian Hickson <ian@hixie.ch>
- CC: public-webapps@w3.org
On 2/13/10 6:18 AM, Ian Hickson wrote: > I'm concerned about the GC-sensitivity of such behaviour (we might end > up snookering ourselves in a situation where specific GC behaviour > actually matters for compatibility). We haven't gotten there yet, in 8 years of two different implementations having this behavior.... > How about the following compromise: these methods return a new object > each time, except if they are called with the same argument as the > previous invocation of the method? i.e. cache the last returned object > only. Would that be acceptable? As far as I can tell, no. That formulation makes it impossible to drop the cache as needed, effectively leading to a memory leak if no one calls these methods for a while. > Alternatively, if we need to cache more than that, how about blowing > away the cache with each spin of the event loop, so that anything in a > tight loop is cached (and _not_ subject to GC — this could be a > problem if the script calls one of these methods with 10000 different > arguments and sets properties on each one) Indeed. Especially because these objects can end up taking up a fair amount of memory... > but not beyond one task? > (i.e. don't share objects in calls across setTimeout) Those two are not quite the same condition. Implementing the latter in Gecko would not be too bad. Implementing the former, assuming I understand what you mean correctly, would require totally rewriting the Gecko event loop. -Boris
Received on Saturday, 13 February 2010 20:07:41 UTC