(Re: minor off-list clarification on non-transparent objects) I see, it looks like this is the relevant bit of the strawman:
There are three built-in types that are considered *opaque*: Object, string, and Any. For security, they are not allowed to expose their internal storage since they may contain pointers (see below). A struct or array type is opaque if it contains opaque fields or elements, respectively. A type that is not opaque is *transparent*. Overlooked it on my first read-through since it isn't directly referenced elsewhere. That seems like it addresses the problem. Looking at the strawman and the polyfill and the spidermonkey implementation, each one seems to have a different API for arrays. Is this something that will get standardized later? I've seen get, getItem and [] as 3 different ways to read values out of a typed object array; [] seems like an obvious poor choice in terms of being able to polyfill, but I can see how end users would also want typed object arrays to act like actual arrays. The spidermonkey implementation seems to expose 'fieldNames' in addition to fieldOffsets/fieldTypes for reflection, which seems like a good idea. If DataView were to also get optimized in SpiderMonkey, that would release a lot of the pressure (use-case wise) for Typed Objects to expose fine-grained control over alignment/padding and it would make it less immediately necessary for them to exist. That's probably a good thing. What is the intended use scenario when trying to pass a typed object array to WebGL? Pass the array's .buffer where a typed array would normally be passed? Or is it basically required that WebGL be updated to accept typed object arrays? It's not totally clear to me whether this will work or if it's already been figured out. The elementType property on typed object arrays is a great addition; I'd suggest that normal typed arrays also be updated to expose an elementType. i.e. (new Uint8Array()).elementType === TypedObject.uint8 On Mon, Nov 18, 2013 at 2:35 AM, Dmitry Lomov <[email protected]> wrote: > We definitely are looking for feedback on the proposal! Please keep it > coming. > Here are some answers reflecting our current thinking. > > > On Sun, Nov 17, 2013 at 4:07 PM, K. Gadd <[email protected]> wrote: > >> Since the strawman is close to the final spec, questions/nitpicks: >> >> I noticed the current spec explicitly provides no control over element >> alignment/padding. Are there specific reasons behind that? It dramatically >> reduces the value of typed objects for doing file I/O (aside from the >> endianness problem, which actually doesn't matter in many of those cases), >> and it means they can't be used to provide direct compatibility with C >> struct layouts in specific cases - for example, filling vertex buffers. I >> understand that there is no desire to provide the *full* feature set >> available in C (fixed-size arrays, variable-size structs, etc.) but >> alignment/padding control is used quite a bit. >> >> DataView has significant performance issues (some due to immature >> v8/spidermonkey implementations, some due to the design) that make it >> unsuitable for most of these use cases, even if it's the 'right' way to >> handle endianness (disputable). >> >> The handwaving that WebGL implementations can 'just introspect' in these >> cases seems shortsighted considering the reality of WebGL: hundreds of >> shipped libraries and apps using current WebGL cannot be guaranteed to keep >> doing the right thing when interacting with typed arrays. If a typed array >> full of Typed Objects can still be treated like an array full of bytes or >> float32s, that allows existing WebGL code to keep working, as long as you >> ensure the layout of the objects is correct. That means people can start >> incrementally adding uses of Typed Objects to their code right away - and >> it means they can introduce them based on a polyfill of Typed Objects >> instead of waiting for the browser to implement *both* Typed Objects and >> new WebGL support for Typed Objects. >> > > The idea for alignment/padding is to _specify_ it for typed objects. There > is a rule that tell the user how the typed object will be aligned and that > rule is set in stone. If the programmer declares a typed object, she/he > knows what the memory layout is. However, we do not (at least in the first > version) provide any explicit API for changing the alignment. > > The rule is "Each field is padded to reside at a byte offset that is a > multiple of the field type’s byte alignment (specified below via the > [[ByteAlignment]] internal property). The struct type’s byte length is > padded to be a multiple of the largest byte alignment of any of its > fields." So every field is at its natural boundary, and the natural > boundary of the struct is the largest of the natural boundaries of its > field types. This rule is pretty much what C compilers do anyway. > > This appears to us a good compromise between API and implementation > complexity and expressiveness. > > BTW, DataView are indeed implemented poorly performance-wise, at least in > V8. It is on my short term list to fix this in V8. > > > >> >> My primitives have control over alignment/padding and it doesn't seem to >> be that hard to implement (in JS, that is) - are there things that make >> this hard to provide from inside a VM? Being able to add extra padding, at >> least, would be pretty useful even if alignment has to remain locked to >> whatever the requirements are. >> >> I see reference types are exposed (string, object, any) - the way this >> actually works needs to be clearly stated. Is it storing a GC pointer into >> the buffer? Are there safety concerns if it's overwritten, or loaded from a >> json blob or something else like that? How big are string/object/any in the >> internal representation? Does their size depend on whether the running >> browser is 32-bit or 64-bit? >> > > Typed objects that have 'string', 'object' or 'any' fields are > "non-transparent". It means that there is no way for the programmer to get > at their underlying storage. This is enforced by the spec. > > Thanks and hope this helps, > Dmitry > > >> >> I'd be open to collaborating on a polyfill of Typed Objects once it's >> clear how they actually work. We can repurpose JSIL's existing >> implementation and modify it to get the semantics in the spec. >> >> >> On Sun, Nov 17, 2013 at 5:04 AM, Till Schneidereit < >> [email protected]> wrote: >> >>> On Sun, Nov 17, 2013 at 10:23 AM, K. Gadd <[email protected]> wrote: >>> >>>> Are there any known-good polyfills for the current draft Typed Objects >>>> / Binary Data spec? >>>> >>> >>> I want this, too, and will start working on it soon-ish if nobody else >>> does or already did. >>> >>> >>>> Presently, JSIL has a set of primitives that roughly correspond with a >>>> big chunk of the draft specification. I'm interested in seeing whether they >>>> can work atop ES6 typed objects, which means either adapting it to sit on >>>> top of an existing polyfill, or turning my primitives into a polyfill for >>>> the draft spec. If it's useful I might be able to find time for the latter >>>> - would having a polyfill like that be useful (assuming a good one doesn't >>>> already exist)? >>>> >>>> Having an efficient equivalent to the spec in JS VMs is pretty >>>> important for JSIL to ever be able to deliver emscripten-level performance >>>> (a single emscripten-style fake heap is not an option because .NET relies >>>> on garbage collection). If a polyfill (even a partial one) could help move >>>> the process along for the spec, that'd be great. If what the process >>>> actually needs is some sort of feedback, maybe I could offer that instead. >>>> The status of the spec is unclear to me :) >>>> >>> >>> The strawman at [1] is fairly close to what's going to end up in the >>> spec, content-wise. Additionally, the implementation in SpiderMonkey is >>> pretty complete by now, and there are lots of tests[2]. I don't know what >>> the timing for integrating Typed Objects into the spec proper is, cc'ing >>> Niko for that. >>> >>> >>> cheers, >>> till >>> >>> >>> [1]: http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects >>> [2]: >>> http://mxr.mozilla.org/mozilla-central/source/js/src/tests/ecma_6/TypedObject/ >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
