On Jul 12, 2013, at 11:33 AM, Patrick Walton wrote:
>> * Could we "freeze" background pages (on a language level?) and unload
>> them in order to conserve memory and avoid extra processing work, with
>> the expectation of resurrecting them later as needed?
>
> Rust does have good support for ser
On 7/12/13 7:09 PM, Boris Zbarsky wrote:
On 7/12/13 7:45 PM, Patrick Walton wrote:
2. Use the JS GC for wrapped objects and reference counting for
non-wrapped objects. This assumes there are no cycles between them,
which I believe to be the case (though could be wrong)
If we can have both wrap
On 7/12/13 7:11 PM, Boris Zbarsky wrote:
Hmm. 18 64-bit words is enough for a basic element, I'd think, though
with the copy/on-write setup we would need to measure carefully.
Subclasses might need to heap-allocate some of their members, though,
which is a bit of a pain.
Right; unique pointers
On 7/12/13 10:09 PM, Boris Zbarsky wrote:
Option 4 is to go with a GC and CC setup and refcounting on the Rust
side, I guess.
Though the developer experience of CC is not that great, to be honest.
What would implenentation of a DOM object that ends up not fitting in 18
64-bit words look like?
On 7/12/13 8:25 PM, Patrick Walton wrote:
On 7/12/13 4:45 PM, Patrick Walton wrote:
1. Use the JS GC for everything; eat the cost of eagerly creating all
wrappers. As Boris mentioned, maybe this isn't so bad. I would assume
this is what Oilpan is doing in Blink.
After talking to Terrence from
On 7/12/13 7:45 PM, Patrick Walton wrote:
2. Use the JS GC for wrapped objects and reference counting for
non-wrapped objects. This assumes there are no cycles between them,
which I believe to be the case (though could be wrong)
If we can have both wrapped and unwrapped DOM nodes, I don't see h
On Fri, Jul 12, 2013 at 5:55 PM, Robert O'Callahan wrote:
> A quick scan suggests that all 34 sec-critical bugs filed against Web
> Audio so far are either buffer overflows (array-access-out-of-bounds,
> basically) or use-after-free. In many cases the underlying bug is something
> quite different,
On Fri, Jul 12, 2013 at 6:00 PM, Patrick Walton wrote:
> In general the overhead for writes and borrows will probably be only a
> couple of instructions over a dereference operation. Reads should be
> unbarriered, although I think we need a little more design to make that
> happen in the current
On 7/12/13 5:48 PM, Robert O'Callahan wrote:
Does Option> compile down to a single machine word with no
overhead for dereferencing?
The Rust compiler now implements optimizations to compile Option of a
pointer down to a nullable pointer (although I would have to verify that
it indeed works in
On Fri, Jul 12, 2013 at 11:33 AM, Patrick Walton wrote:
>
> * Do we have data showing how many security bugs we could be avoiding in
>> Servo in comparison to Gecko? Is the security benefit truly as valuable
>> if expected performance benefits don't pan out?
>>
>
> We've been talking to some membe
On Fri, Jul 12, 2013 at 5:43 PM, Patrick Walton wrote:
> I suspect it would be something like:
>
> #[deriving(JsManagable)]
> struct MyObject {
> field_a: int,
> field_b: float,
> field_c: Option>**,
> ...
> }
>
Great, that looks OK.
Does Option> comp
On 7/12/13 5:38 PM, Robert O'Callahan wrote:
What would the developer experience be like with this approach? I mean,
what kind of code would developers have to write to declare classes
managed by JS and to declare references to such objects?
I suspect it would be something like:
#[deriving
On Fri, Jul 12, 2013 at 5:25 PM, Patrick Walton wrote:
> On 7/12/13 4:45 PM, Patrick Walton wrote:
>
>> 1. Use the JS GC for everything; eat the cost of eagerly creating all
>> wrappers. As Boris mentioned, maybe this isn't so bad. I would assume
>> this is what Oilpan is doing in Blink.
>>
>
> A
On 7/12/13 4:45 PM, Patrick Walton wrote:
1. Use the JS GC for everything; eat the cost of eagerly creating all
wrappers. As Boris mentioned, maybe this isn't so bad. I would assume
this is what Oilpan is doing in Blink.
After talking to Terrence from the JS team, apparently with a month or
tw
On 7/12/13 1:40 PM, Jack Moffitt wrote:
I can write an example of a script that would produce such a situation, if
desired.
Yes, please. I would love to have a concrete example.
So I think there are basically three options:
1. Use the JS GC for everything; eat the cost of eagerly creating al
On 2013-07-12 2:33 PM, Patrick Walton wrote:
Servo is *also* designed to be amenable to OS sandboxing, so that
processes compromised via unsafe code or the JIT can be stopped from
taking over the system. In general, although we don't have fine-grained
sandboxing today, we try to specify the inter
On 7/12/13 4:40 PM, Jack Moffitt wrote:
I can write an example of a script that would produce such a situation, if
desired.
Yes, please. I would love to have a concrete example.
// Create wrapper for "1" and store it in a global var
var global = document.getElementById
> The pwn2own and Pwnium results demonstrate, at least to me, that memory
> safety is still valuable even in the presence of intricate sandboxing. We
> need defense in depth, and Rust's type system provides a strong layer of
> defense for new code.
Yeah. IMO, memory safety is a BFD.
Nick
___
On 07/12/2013 04:12 PM, Patrick Walton wrote:
On 7/12/13 12:43 PM, Josh Matthews wrote:
Yes, this is the bed we have made for ourselves in Servo at this point.
Can we just have the JS trace hook for a DOM node recursively search
through children for wrappers, even those that don't have wrapper
On 07/12/2013 04:06 PM, Patrick Walton wrote:
On 7/12/13 12:18 PM, Josh Matthews wrote:
When you say "very much", I get worried. All codegen'ed DOM code uses @
pointers
Does it need to use @ pointers? That seems unfortunate.
At one point I was trying to write bindings code that could deal wi
> I can write an example of a script that would produce such a situation, if
> desired.
Yes, please. I would love to have a concrete example.
jack.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
On 7/12/13 4:31 PM, Patrick Walton wrote:
On 7/12/13 1:27 PM, Boris Zbarsky wrote:
What keeps the "X" that is a child of "2" alive?
Interesting question. I had assumed that X's were kept alive by their
parents.
Consider this DOM fragment, disconnected from the document:
X
/ \
1 2
On 7/12/13 1:27 PM, Boris Zbarsky wrote:
What keeps the "X" that is a child of "2" alive?
Interesting question. I had assumed that X's were kept alive by their
parents. After all, JS will not try to free things that it doesn't know
about (and presumably JS doesn't know about wrapperless nodes
On 7/12/13 4:12 PM, Patrick Walton wrote:
On 7/12/13 12:43 PM, Josh Matthews wrote:
Yes, this is the bed we have made for ourselves in Servo at this point.
Can we just have the JS trace hook for a DOM node recursively search
through children for wrappers, even those that don't have wrappers?
On 7/12/13 3:34 PM, Kyle Huey wrote:
That means you have to eagerly create JS wrappers for every node in the DOM
tree.
True.
So you can't do lazy prototype setup
You still can as long as you don't have any nodes for a given prototype...
lazy wrapper creation
Indeed.
Those are big spee
On 7/12/13 12:43 PM, Josh Matthews wrote:
Yes, this is the bed we have made for ourselves in Servo at this point.
Can we just have the JS trace hook for a DOM node recursively search
through children for wrappers, even those that don't have wrappers?
To illustrate, suppose we have this DOM:
On Fri, Jul 12, 2013 at 12:43 PM, Josh Matthews wrote:
> On 07/12/2013 03:34 PM, Kyle Huey wrote:
>
>> On Fri, Jul 12, 2013 at 12:29 PM, Josh Matthews > >wrote:
>>
>> On 07/12/2013 03:22 PM, Kyle Huey wrote:
>>>
>>> On Fri, Jul 12, 2013 at 12:18 PM, Josh Matthews >>>
> wrote:
>
On 7/12/13 12:18 PM, Josh Matthews wrote:
When you say "very much", I get worried. All codegen'ed DOM code uses @
pointers
Does it need to use @ pointers? That seems unfortunate.
and I don't understand what you mean by "can't have strong
references to DOM nodes"; consider events we eventually
On 07/12/2013 03:34 PM, Kyle Huey wrote:
On Fri, Jul 12, 2013 at 12:29 PM, Josh Matthews wrote:
On 07/12/2013 03:22 PM, Kyle Huey wrote:
On Fri, Jul 12, 2013 at 12:18 PM, Josh Matthews
wrote:
On 07/12/2013 02:33 PM, Patrick Walton wrote:
* What is the plan to handle cycles between th
On Fri, Jul 12, 2013 at 12:29 PM, Josh Matthews wrote:
> On 07/12/2013 03:22 PM, Kyle Huey wrote:
>
>> On Fri, Jul 12, 2013 at 12:18 PM, Josh Matthews > >wrote:
>>
>> On 07/12/2013 02:33 PM, Patrick Walton wrote:
>>>
>>> * What is the plan to handle cycles between the DOM and JS?
>
On 07/12/2013 03:22 PM, Kyle Huey wrote:
On Fri, Jul 12, 2013 at 12:18 PM, Josh Matthews wrote:
On 07/12/2013 02:33 PM, Patrick Walton wrote:
* What is the plan to handle cycles between the DOM and JS?
The JavaScript garbage collector handles all DOM objects, so the JS
garbage collector w
On Fri, Jul 12, 2013 at 12:18 PM, Josh Matthews wrote:
> On 07/12/2013 02:33 PM, Patrick Walton wrote:
>
>> * What is the plan to handle cycles between the DOM and JS?
>>>
>>
>> The JavaScript garbage collector handles all DOM objects, so the JS
>> garbage collector will trace all DOM-JS cycles an
On 07/12/2013 02:33 PM, Patrick Walton wrote:
* What is the plan to handle cycles between the DOM and JS?
The JavaScript garbage collector handles all DOM objects, so the JS
garbage collector will trace all DOM-JS cycles and clean them up.
What does this mean precisely? Are we going to need t
On 7/12/13 11:04 AM, Benjamin Smedberg wrote:
I'd like to understand what the parallelism targets are... if DOM and
layout are not parallelized with a single DOM tree but we can run
multiple of these tasks at once (so that tabs are isolated from
eachother) is that good enough for a v1 product? Is
Here are my attempts at answers.
On 7/12/13 10:51 AM, Josh Matthews wrote:
* Are there viability criteria? How much better (performance-wise) than
other engines does Servo have to be considered worth continued investment?
No idea. There are both security and performance wins, so both must be
On 7/12/2013 1:51 PM, Josh Matthews wrote:
* Are there viability criteria? How much better (performance-wise)
than other engines does Servo have to be considered worth continued
investment?
I suspect that the answer to this depends also on the security question
asked below. If we get "on-par"
I talked to a room of Gecko platform engineers about Servo today. I drew
a diagram of the most recent architecture plans (constellation; multiple
pipelines of script (with copy-on-write DOM planned), layout, renderer,
and compositer; script tasks with multiple pages per origin;
cross-origin fra
37 matches
Mail list logo
