At the moment, the embedding registers a callback function with SpiderMonkey to provide allocation metadata to attach to new objects. Since we'll soon have string allocation metadata as well, we should replace this callback function with a builder object, and provide an appropriate base class.

The code that handles metadata now talks exclusively of "object metadata callbacks", but we want "allocation metadata builders". This is a purely mechanical patch that changes the names. This does mean that we'll momentarily have a function pointer typedef named ...Builder, but I don't think that's entirely wrong. We'll replace it in the next patch anyway.

Neither of these changes should have any visible effect on behavior, so there are no tests.

Comment on attachment 8723948 [details] [diff] [review] Replace allocation metadata callback with a builder class. Review of attachment 8723948 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/builtin/TestingFunctions.cpp @@ +1664,5 @@ > AutoEnterOOMUnsafeRegion oomUnsafe; > > RootedObject obj(cx, NewBuiltinClassInstance<PlainObject>(cx)); > if (!obj) > + oomUnsafe.crash("ShellAllocationMetadataBuilder::build"); If all the metadata callbacks are oom-unsafe in practice, maybe we should pass that in to ::build()?

(In reply to Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8] from comment #4) > If all the metadata callbacks are oom-unsafe in practice, maybe we should > pass that in to ::build()? Yeah, good suggestion. I didn't realize it, but JSCompartment::setNewObjectMetadata returns void.

Make metadata builder methods take an AutoEnterOOMUnsafeRegion, since they're not designed to report OOM conditions.

https://hg.mozilla.org/integration/mozilla-inbound/rev/ad5ff46b72e7 https://hg.mozilla.org/integration/mozilla-inbound/rev/fc76f66bf11f https://hg.mozilla.org/integration/mozilla-inbound/rev/12f6c52e4b4d

This was required for the Clang builds. The general reason seems to be explained here: http://stackoverflow.com/questions/7411515/why-does-c-require-a-user-provided-default-constructor-to-default-construct-a But since the class has a virtual method, it shouldn't be POD, so I don't really understand.

https://hg.mozilla.org/mozilla-central/rev/ad5ff46b72e7 https://hg.mozilla.org/mozilla-central/rev/fc76f66bf11f https://hg.mozilla.org/mozilla-central/rev/12f6c52e4b4d https://hg.mozilla.org/mozilla-central/rev/0d06527892bc https://hg.mozilla.org/mozilla-central/rev/4ebc3275aa3d