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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
