[Webkit-unassigned] [Bug 123058] JSC should have an API for typed arrays

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=123058





--- Comment #9 from Filip Pizlo <fpizlo at apple.com>  2013-10-19 14:43:40 PST ---
(In reply to comment #8)
> > > JSObjectGetTypedArrayBase(JSContextRef, JSValueRef)
> > > JSObjectGetTypedArrayByteLength(JSContextRef, JSValueRef)
> 
> > OK, but out of curiosity, does it have to be?  You can get a JSGenericTypedArrayView's base and length without an ExecState*.
> 
> Whenever we’ve made the decision to leave out JSContextRef before, we’ve come to regret it. For example, we made that decision for strings, and now we regret it.
> 
> In this case, I could imagine some implementations that might require an ExecState* in order to get a backing pointer. For example, if we did pin the pointer, and pinning required a GC allocation, then we would need an ExecState*. Or, if some typed arrays had a super-slow mode, in which their backing buffer pointers were maintained in an external hash table, that would require an ExecState*. Or if some typed arrays had an "I'm currently in GPU memory" mode, that would require an ExecState*.

Interestingly, slowDownAndWasteMemory() does require VM& but it doesn't take either VM& or ExecState*.  It just uses heapFor().  That's because there were too many places that expected to be able to get a native buffer from a JS buffer and they didn't have an ExecState* lying around.

But, sure, we don't have to expose such madness to the C API customers.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.