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
