On 07/25/2013 01:36 PM, Boris Zbarsky wrote:
On 7/25/13 9:25 AM, Josh Matthews wrote:
type_id is an enum to distinguish between node types, with an inner enum
in the element case to distinguish the kind of element. All enums are
automatically 8 bytes, and if any variant contains another enum tha
On 7/25/13 9:25 AM, Josh Matthews wrote:
type_id is an enum to distinguish between node types, with an inner enum
in the element case to distinguish the kind of element. All enums are
automatically 8 bytes, and if any variant contains another enum that
automatically bumps it up to 16.
OK. So I
On 07/25/2013 12:13 PM, Boris Zbarsky wrote:
On 7/25/13 8:51 AM, Josh Matthews wrote:
wrapper: 8 bytes
type_id: 16 bytes
abstract: 16 bytes
out_of_line: 8 bytes
layout_data: 8 bytes
Hmm. That's a lot smaller than 128 bytes, right? I guess the point is
that you could't put _all_ of parent/fir
On 07/25/2013 12:13 PM, Boris Zbarsky wrote:
On 7/25/13 8:51 AM, Josh Matthews wrote:
wrapper: 8 bytes
type_id: 16 bytes
abstract: 16 bytes
out_of_line: 8 bytes
layout_data: 8 bytes
Hmm. That's a lot smaller than 128 bytes, right? I guess the point is
that you could't put _all_ of parent/fir
On 7/25/13 8:51 AM, Josh Matthews wrote:
wrapper: 8 bytes
type_id: 16 bytes
abstract: 16 bytes
out_of_line: 8 bytes
layout_data: 8 bytes
Hmm. That's a lot smaller than 128 bytes, right? I guess the point is
that you could't put _all_ of parent/first/last/next/prev/ownerdoc
inline, which is
>> That's what I thought. 16 words is 128 bytes, right? If each "pointer"
>> member is effectively two words because of the COW stuff, that still
>> means we should be able to fit in 6 or so of them plus a few other
>> bits... What does the memory layout of a Node look like in our setup
>> right
On 07/25/2013 11:30 AM, Boris Zbarsky wrote:
On 7/24/13 12:16 PM, Josh Matthews wrote:
All DOM objects are represented with |JSManaged whatever|.
When you want to access a property owner_document of Whatever, you use
|do whatever.with_imm |whatever| { whatever.owner_document }|, and |do
whatever
On 7/25/13 8:30 AM, Boris Zbarsky wrote:
On 7/24/13 12:16 PM, Josh Matthews wrote:
All DOM objects are represented with |JSManaged whatever|.
When you want to access a property owner_document of Whatever, you use
|do whatever.with_imm |whatever| { whatever.owner_document }|, and |do
whatever.wit
On 7/24/13 12:16 PM, Josh Matthews wrote:
All DOM objects are represented with |JSManaged whatever|.
When you want to access a property owner_document of Whatever, you use
|do whatever.with_imm |whatever| { whatever.owner_document }|, and |do
whatever.with_mut |whatever| { whatever.owner_document
On 07/23/2013 10:08 PM, Boris Zbarsky wrote:
On 7/23/13 6:34 PM, Josh Matthews wrote:
Accordingly, there are now branches of servo, rust-mozjs,
and mozjs (all named 'inline') that contain my work to date on storing
DOM objects inline in their JS wrappers' fixed slots. There are some
rooting prob
On 7/23/13 7:08 PM, Boris Zbarsky wrote:
On 7/23/13 6:34 PM, Josh Matthews wrote:
Accordingly, there are now branches of servo, rust-mozjs,
and mozjs (all named 'inline') that contain my work to date on storing
DOM objects inline in their JS wrappers' fixed slots. There are some
rooting problems
On 7/23/13 6:34 PM, Josh Matthews wrote:
Accordingly, there are now branches of servo, rust-mozjs,
and mozjs (all named 'inline') that contain my work to date on storing
DOM objects inline in their JS wrappers' fixed slots. There are some
rooting problems that make it crash once in a while, but o
I took the shortest route for prototyping right now and added really
basic APIs that did what I needed for our local embedding of
Spidermonkey. Accordingly, there are now branches of servo, rust-mozjs,
and mozjs (all named 'inline') that contain my work to date on storing
DOM objects inline in
13 matches
Mail list logo
