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.