Arguments objects use malloc for their ArgumentsData. It'd be nice if we could either allocate both ArgumentsObject + ArgumentsData in the nursery, or if we could store ArgumentsData inline in the object if the number of arguments is small (probably requires making ArgumentsObject a non-native object...) Arguments objects are typically short-lived, so nursery allocation would be nice. This should also make it easier to inline arguments object allocation in Ion.

Terrence, could we use the nursery's new finalizer list for this?

(In reply to Jan de Mooij [:jandem] from comment #1) > Terrence, could we use the nursery's new finalizer list for this? (We'd still need the malloc for the ArgumentsData in this case, but this would allow us to allocate the object itself in the nursery.)

I think for this sort of thing we should be able to have objects in the nursery which have class finalizers but are not in that finalizers_ list, as long as the only thing the class finalizer does is release memory which for the object is known to be in the nursery. This is analogous to what we do for the |slots| and |elements| members of native objects --- the object is only explicitly tracked by the nursery if for whatever reason it is holding onto memory in the malloc heap. Making this change would let arguments objects *and* their data be allocated in the nursery, with no bookkeeping to drag down performance when we end up doing a minor GC. This would also help lots of other kinds of objects, like array buffers, and would open up new laziness opportunities like letting outline typed objects and typed arrays own their data rather than requiring an array buffer. We currently can't do this because doing so would mean adding a finalizer to these classes, which would trash performance for all outline typed objects/arrays (even with JSCLASS_FINALIZE_FROM_NURSERY).

What Brian said +1. Right now you can request an object with "nDynamicSlots" worth of slots data; it should just be a matter of generalizing the malloc. I'll take a look at the arguments side of the allocation today and see what would be required, plumbing wise. It shouldn't be too bad.

See http://kpdecker.github.io/six-speed/. Babel uses the arguments object when transpiling default parameter values for spec compliance and it's very slow in Firefox, 1.5 thousand slower than native. Fx has a built-in fast implementation but 99% of people will just transpile without serving a pure ES6 version to Firefox.

(In reply to Michał Gołębiowski [:m_gol] from comment #5) > See http://kpdecker.github.io/six-speed/. Babel uses the arguments object > when transpiling default parameter values for spec compliance and it's very > slow in Firefox, 1.5 thousand slower than native. Bug 1175466 improved this a lot, that's probably why FF 41 is faster than 38/39/40 on the "defaults" test. I'll try to land bug 1175511 today, it should also help. Will look into this more after that lands, we shouldn't be 1000x slower.

I think Babel uses OOB accesses on the arguments object, making that fast is bug 1131996. I'll see how hard that is.