On Sep 28, 2010, at 11:31 PM, Adam Barth wrote:
On Tue, Sep 28, 2010 at 11:02 PM, Maciej Stachowiak <mjs@apple.com> wrote:
On Sep 28, 2010, at 10:48 PM, Kinuko Yasuda wrote:
Hi Webkit folks,
I'm writing a JSC binding code (custom binding code for now) for a method that can take JSON-format parameters, and I want to know what would be the right/recommended way. I mean, I want to write a binding code that can executes javascript code like:
directoryEntry.getFile("lockfile.txt", {create: true, exclusive: true});
Where the getFile() method is defined as:
interface DirectoryEntry : Entry { void getFile(in DOMString path, in Flags flags, /* ... */); }; interface Flags { attribute boolean create; attribute boolean exclusive; };
(They are from the File API: Directories and System's draft [1])
And what I have written for this is like following:
if (!exec->argument(1).isNull() && !exec->argument(1).isUndefined() && exec->argument(1).isObject() && !exec->argument(1).inherits(&JSFlags::s_info)) { JSObject* object = exec->argument(1).getObject(); flags = Flags::create(); JSValue jsCreate = object->get(exec, Identifier(exec, "create")); flags->setCreate(jsCreate.toBoolean(exec)); JSValue jsExclusive = object->get(exec, Identifier(exec, "exclusive")); flags->setExclusive(jsExclusive.toBoolean(exec)); }
Basically the code calls JSObject::get() to get values for the given property names. This looked straightforward, but I was told that the get(exec) re-enters Javascript and could do any arbitrary thing.
This much is true. In principle, any property can be a getter, so get() could re-enter into arbitrary JS code.
In general, this is a dangerous pattern that we use in our bindings. Figuring out which objects can be garbage collected when running arbitrary JavaScript is very tricky.
I don't see anything unsafe in the code snippet cited.
In the V8 bindings, it's cheap to grab a "local" handle to a JS object, which prevents its GC. Is there / should there be a similar concept in JSC?
JSC as it currently exists does not need a similar concept. Currently it has a partially-conserviative collector which scans the machine stack for potential references to values. So simply having the value in a local variable will do. Likewise, you can assume that a JS function's arguments are protected so long as it is executing, even if the function is implemented in C++. At some point we may need to change the GC in a way that requires indirection via handles, but we'll cross that bridge when/if we come to it. Regards, Maciej