> Any opinions on exposing this functionality in the C API? Is it too
> low-level / implementation-dependent?
Hi Kent,
My feeling would be that this is a little implementation dependent.
These functions really only exist because our GC only supports fixed
sized objects – but we are interested in looking at some point at
changing our GC implementation to be able to able to allocate
arbitrary sized objects on the GC heap. This would implicitly allow
us to better track the additional cost. We could add API to report
extra emory cost anyway, and if the heap implementation changed so
that we no longer supported this then it would become a no-op, and be
deprecated over time.
> If exposing reportExtraMemoryCost() as-is is acceptable, I'll go
> ahead and create the patch. Otherwise, suggestions for alternative
> approaches are welcome. :)
Depending on the lifecycle of the additional data, one solution might
be to add a version of "JSObjectMake", which rather than taking a
void* argument could take a size parameter, allocate the storage, and
have an output argument to return the additional storage allocated.
We could implicitly report the extra cost of this storage, and in the
future if we do have the ability in the future to store arbitrary
sized objects in the GC heap, then this method could allocate the
extra data and the JSObject in a single allocation out of the GC heap,
saving the extra malloc.
What are your thoughts Geoff?
cheers,
G.