Summary: | Typed Arrays should be part of JSC | ||
---|---|---|---|
Product: | WebKit | Reporter: | Dominic Szablewski <dominic.szablewski> |
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | ap, barraclough, fpizlo, isaacburns, oliver, tonikitoo |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All |
Description
Dominic Szablewski
2012-11-27 14:09:38 PST
My understanding (Oliver may comment further) is that this is difficult, since Typed Arrays are defined by web specs rather than ECMA262, and are dependent on other types implemented in WebCore making them hard to move. That said, we've had a number of clients call for this – it would be really great to do so if we can. I noticed that for the jsc command line tool, the Typed Arrays are actually exposed and can be used. This does not expose the prototype and some API methods, but I guess it's a testament that Typed Arrays really are fully defined internally in JSC itself. See jsc.cpp around line 224: addConstructableFunction(globalData, "Uint8Array", constructJSUint8Array, 1); ... I understand that Typed Arrays are not part of the ECMA spec, so maybe a compile switch for JSC could control if the API is exposed or not!? (In reply to comment #2) > I noticed that for the jsc command line tool, the Typed Arrays are actually exposed and can be used. This does not expose the prototype and some API methods, but I guess it's a testament that Typed Arrays really are fully defined internally in JSC itself. See jsc.cpp around line 224: > > addConstructableFunction(globalData, "Uint8Array", constructJSUint8Array, 1); > ... > > I understand that Typed Arrays are not part of the ECMA spec, so maybe a compile switch for JSC could control if the API is exposed or not!? No, jsc has internally defined a bunch of types that are sufficiently abi compatible for the engine to use them in place of the clusterfuck that is the w3c typed array spec. They don't have any of the necessary concepts to be used as the basis for the w3c typed arrays, and jsc can only support one or the other of these models. Thanks for clarifying, Oliver! I had a hard time understanding how all the sources for typed arrays fit together. This is probably not the place to announce this, but I guess someone may find it useful: I've now made a version of JSC that directly includes Typed Arrays. It can be found here: https://github.com/phoboslab/JavaScriptCore-iOS/tree/typed-arrays This uses the compiled .idl files of the WebCore project as a basis; which is probably pretty stupid to begin with, but it seems to work just fine. I've also added some API methods to work with Typed Arrays directly in native code: https://github.com/phoboslab/JavaScriptCore-iOS/blob/typed-arrays/JavaScriptCore/API/JSTypedArray.h (In reply to comment #4) > Thanks for clarifying, Oliver! I had a hard time understanding how all the sources for typed arrays fit together. > > > This is probably not the place to announce this, but I guess someone may find it useful: I've now made a version of JSC that directly includes Typed Arrays. It can be found here: > > https://github.com/phoboslab/JavaScriptCore-iOS/tree/typed-arrays > > This uses the compiled .idl files of the WebCore project as a basis; which is probably pretty stupid to begin with, but it seems to work just fine. Yeah, I tried this originally but found it upsetting (esp. given the idl would have to stay in webcore for changes, etc yet still be correct in JSC) > > I've also added some API methods to work with Typed Arrays directly in native code: > > https://github.com/phoboslab/JavaScriptCore-iOS/blob/typed-arrays/JavaScriptCore/API/JSTypedArray.h I saw your announcement on twitter. I'm somewhat surprised at the performance gains you got without the JIT. --Oliver (In reply to comment #5) > I saw your announcement on twitter. I'm somewhat surprised at the performance gains you got without the JIT. I don't know how big the performance difference in JavaScript itself is, but the bottleneck was always converting from and to JS through an API that wasn't made for this. We came up with a hack for Ejecta: Building a JSON string and using JSValueMakeFromJSONString was actually faster than creating an Array "by hand". See the ByteArrayToJSObject and JSObjectToByteArray functions here: https://github.com/phoboslab/Ejecta/blob/master/Source/Ejecta/EJConvert.m#L290 We implemented this recently. *** This bug has been marked as a duplicate of bug 119064 *** Phil, is it now possible to use typed arrays in projects that link to JavaScriptCore only, and don't create an HTML document? This is what this bug requested. (In reply to comment #8) > Phil, is it now possible to use typed arrays in projects that link to JavaScriptCore only, and don't create an HTML document? This is what this bug requested. Yes. They're now present on the global object by default. (In reply to comment #9) > (In reply to comment #8) > > Phil, is it now possible to use typed arrays in projects that link to JavaScriptCore only, and don't create an HTML document? This is what this bug requested. > > Yes. They're now present on the global object by default. What Alexey P. is asking is if there is a way to access the data within a TypedArray object through the JSC API. For example, create and populate a Uint8Array in script, then pass the object to a native callback. There still is no way to access the buffer, as Dominic S. suggests. (In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > Phil, is it now possible to use typed arrays in projects that link to JavaScriptCore only, and don't create an HTML document? This is what this bug requested. > > > > Yes. They're now present on the global object by default. > > What Alexey P. is asking is if there is a way to access the data within a TypedArray object through the JSC API. For example, create and populate a Uint8Array in script, then pass the object to a native callback. There still is no way to access the buffer, as Dominic S. suggests. That's correct. I agree that such a feature would be cool! Bug 120112 tracks adding more of an API, and buffer access in particular. I agree that it's appropriate to consider this bug resolved. Thanks for the note, Alexey. I will follow the new bug. |