[webkit-dev] Qtish API for JavaScriptCore

[Oliver Hunt]

On Aug 28, 2009, at 3:25 AM, Kent Hansen wrote:

> ext Simon Hausmann wrote:
>> Hi Oliver,
>>
>> On Wednesday 26 August 2009 11:04:29 pm ext Oliver Hunt wrote:
>>
>>> A further
>>> issue is that any API that binds directly to JSC internals
>>> realistically needs to be developed by the engineers working on the
>>> core engine as a developing such an API needs enormous care to not
>>> cause harmful long term problems.
>>>
>>
>> I understand that. We've been bitten by that, too, as we've ported  
>> our
>> existing API to JSC internals, to see how it can be done. The vast  
>> majority
>> was straight forward as we've been careful in the original design  
>> to only
>> expose what you can do in JavaScript itself. In a few places we've  
>> made
>> mistakes but we've found solutions for them, too, that don't affect  
>> the
>> internals in flexibility or performance. (*pokes some of the guys  
>> to elaborate
>> a bit here*)
>>
>
>
> Hi,
> Here's a rough overview of JSC hacking we've been doing:
>
> - Fixing purely ECMA-compliance-related things. These are mostly small
> discrepancies we've found when running our tests; the associated JSC
> patches should be straightforward to either accept or reject (we'll be
> creating separate Bugzilla tasks for these). If they're not fixed,  
> it's
> not critical for us, as I doubt much real-world JS depends on the
> behavior anyway (otherwise you'd think the issues would have been  
> fixed
> already).

Fixing ES compliance is unrelated to the QT JS API, but such patches  
also need to be fairly carefully examined, as there are places where  
our behaviour differs from some other engines but is in compliance  
with the spec.  Other changes may result in site breakages, etc.  They  
should really just be placed on bugs.webkit.org for review.

>
> - Adding ability to introspect non-enumerable properties of objects  
> from
> C++. JSObject::getPropertyNames() seems to be made only to support the
> JS for..in statement; we added an extra parameter so you could ask for
> non-enumerable properties as well. We need this for debugging and
> autocompletion. The patch is large because there are a lot of classes
> that reimplement getPropertyNames(), so all the signatures must be
> updated... I'm interested in hearing if there are alternatives, e.g.
> adding a separate virtual function getNonEnumerablePropertyNames() and
> only implement it in JSObject for a start (and we would then  
> reimplement
> it in our own Qt "bridge" classes).
> See also https://bugs.webkit.org/show_bug.cgi?id=19119; looks like the
> Inspector would also gain from providing this functionality.

I am concerned about the performance impact of changing  
getPropertyNames, as well as correctness -- getPropertyNames does  
specifically exist for the support of for..in enumeration.

>
> - Being able to delete a property from C++ even if the property has
> DontDelete=true. We implemented this by adding a checkDelete  
> argument to
> JSObject::deleteProperty(). I think it's similar in spirit to the put 
> ()
> methods that have a checkReadOnly argument. The patch is not that  
> large
> compared to the getPropertyNames() change, because there aren't as  
> many
> classes reimplementing deleteProperty().

I'm not sure what you're saying here.

>
> - Storing CallFrame::callee() as a generic JSObject instead of a
> JSFunction. Any JSObject can be invoked as long as its getCallData()
> returns something, so we didn't see a good reason for only being  
> able to
> store JS callees (in the QtScript API we need to offer the callee for
> native functions as well).
I'd be very careful with a change like this.  Especially given the  
inspector debugger is already able to do what you're claiming you  
needed to change JSC to support.

> - Some more flexibility in dealing with timeouts: Make TimeoutChecker
> subclassable so we can get a callback at timeout, make it possible to
> adjust the timeout interval.
Once again, i'd need to see the patch and perf impact.

> - Adding column number information to the parser + debugger callback.
> Not life-critical, but reasonably easy to add to the parser anyway.
The parser already includes sufficient information for this.  Tracking  
such extra information again is highly likely to regress parsing  
performance so i'd need confirmation of performance -- but as i said,  
it's unnecessary to modify the parser for this.

> - Hacking error.sourceURL and error.line to be called error.fileName  
> and
> error.lineNumber instead. We don't know how many existing QtScript  
> users
> out there rely on the fileName and lineNumber properties being present
> on error objects, though; maybe we can make the source-incompatible
> change JS-wise of using the JSC names. A safer solution would be to  
> just
> copy sourceURL and line over to fileName and lineNumber in the parts  
> of
> our code where we have the chance to do that (i.e. not inside JSC  
> itself).
You can't change these names, and we don't really want additional  
properties added to exception objects.  Fixing the way such  
information is propagated is a long term goal.

> - Trying to make our debugger callbacks (which we relay from the JSC
> debugger callbacks) have precisely the same semantics as in our old
> engine. We have a similar debugging interface as JSC::Debugger, but
> obviously "similar" doesn't cut it for this low-level stuff. Geoffrey
> Garen said in another mail in this thread that the debugger exposed  
> too
> much internal engine knowledge, and that's also true for the API we
> provide for QtScript.
The debugger is not API, and should not be depended upon.  If you are  
interacting with the debugger you are not using the JSC API, and so  
you will not be able to rely on JSC not changing and breaking your API.

> We'll be creating Bugzilla tasks with patches for the things we hope
> make sense to get upstream (regardless of whether the QtScript API
> itself makes it upstream at some point, which I agree is not very
> reasonable so long as it depends on JSC internals), so we can discuss
> any implications in more detail.

These really should already be in bugs.webkit.org, as i've said i'm  
kind of concerned about some of the changes you've described so it  
would have helped you to talk to us earlier.

>
> Regards,
> Kent
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev