On Thu, Jul 10, 2014 at 9:56 AM, Patrick Walton
wrote:
> On 7/9/14 2:48 PM, Robert O'Callahan wrote:
>
>> If you think so, then I think we *should* be considering GC+CC for Servo.
>>
>> Crazy idea: could it even make sense for JS GC to use a traced nursery
>> and a refcounted+CC tenured space?
>>
On Thu, Jul 10, 2014 at 9:53 AM, Patrick Walton
wrote:
> On 7/8/14 1:23 PM, smaug wrote:
>
>> In general issues with GC handling are security bugs, but in CC they
>> lead to leaks.
>>
>
> This is not the case in Servo, though; we should be foolproof for both.
> I'm definitely not willing to compr
On Jul 9, 2014, at 2:48 PM, Robert O'Callahan wrote:
> On Wed, Jul 9, 2014 at 8:23 AM, smaug wrote:
>
>> In general issues with GC handling are security bugs, but in CC they lead
>> to leaks.
>>
>> I could note that max median CC times have been lower than max GC slice
>> times at least since
On 7/9/14 2:48 PM, Robert O'Callahan wrote:
If you think so, then I think we *should* be considering GC+CC for Servo.
Crazy idea: could it even make sense for JS GC to use a traced nursery
and a refcounted+CC tenured space?
This is more or less how RC-immix works, right?
http://users.cecs.anu
On 7/8/14 1:23 PM, smaug wrote:
In general issues with GC handling are security bugs, but in CC they
lead to leaks.
This is not the case in Servo, though; we should be foolproof for both.
I'm definitely not willing to compromise on memory safety. :)
Blink doesn't have a collector for refcou
On Wed, Jul 9, 2014 at 8:23 AM, smaug wrote:
> In general issues with GC handling are security bugs, but in CC they lead
> to leaks.
>
> I could note that max median CC times have been lower than max GC slice
> times at least since early 2012.
> CC needs to deal with possible garbage only, GC ten
On 07/08/2014 05:56 AM, Patrick Walton wrote:
On 7/7/14 7:11 PM, Robert O'Callahan wrote:
Difficult, definitely. Performance problem ... now that we have incremental
CC and bunch of other optimizations, I feel like it isn't. At least
compared to any other viable GC approach, all of which have th
- Original Message -
Not to derail this further with a defense of the CC, but...
> CC is still a performance and memory and safety problem.
At this point, I think the GC is a bigger performance problem. ;) Ok, so it is
doing much more stuff than the CC...
> Yeah, I shouldn't have men
On 7/7/14 8:07 PM, Robert O'Callahan wrote:
The pragmatist in me loves it :-).
There's probably a principled way to implement ForgetSkippable in a way
that's automatically checkable.
Having said all that, I'm not necessarily advocating GC+CC for Servo. It
is a hard and complex approach. I'm sti
On Tue, Jul 8, 2014 at 2:55 PM, Cameron Zwarich wrote:
> There is this blog post:
>
> https://www.webkit.org/blog/3271/webkit-css-selector-jit-compiler/
>
> I’m friends with the author and have anecdotal confirmation that the
> improvements also occur on real web pages.
>
Good. I saw that, but w
On Tue, Jul 8, 2014 at 2:56 PM, Patrick Walton wrote:
> Yeah, I shouldn't have mentioned safety there, since the fundamental
> problem is the same whether or not you use CC or GC. You still have to
> teach the JS engine or the CC about the object graph.
>
> We use compiler support for this in Rus
On 7/7/14 7:11 PM, Robert O'Callahan wrote:
Difficult, definitely. Performance problem ... now that we have incremental
CC and bunch of other optimizations, I feel like it isn't. At least
compared to any other viable GC approach, all of which have their own
performance pitfalls. Safety problem ..
On Jul 7, 2014, at 7:11 PM, Robert O'Callahan wrote:
> zwarich: JITting will give a huge benefit.
>
> Are there experimental results showing this? Because I haven't seen any
> yet, and I'd like to :-).
There is this blog post:
https://www.webkit.org/blog/3271/webkit-css-selector-jit-compiler/
>
>
>- pcwalton: if we can offer things like getComputedStyleAsync, that
>could be a bigger win for authors using them.
>- jack: that doesn't help us now.
>
>
Apart from what jack said, getComputedStyleAsync might be unusable for a
lot of Web authors.
Personally I agree with the conclu
14 matches
Mail list logo
