On Wed, Nov 14, 2012 at 10:29 PM, Ryosuke Niwa wrote:
> On Wed, Nov 14, 2012 at 10:14 PM, Cris Neckar wrote:
>
>> On Wed, Nov 14, 2012 at 10:05 PM, Ryosuke Niwa wrote:
>>
>>> On Wed, Nov 14, 2012 at 9:59 PM, Adam Barth wrote:
>>>
On Nov 14, 2012 8:59 PM, "Ryosuke Niwa" wrote:
>
On Nov 14, 2012, at 11:09 PM, Chris Evans wrote:
> On Wed, Nov 14, 2012 at 8:59 PM, Ryosuke Niwa wrote:
> On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn wrote:
> I was present for one of the discussions about the exploit and how an arena
> like allocator could have helped at Google. One prop
On Nov 14, 2012, at 10:36 PM, Elliott Sprehn wrote:
>
> On Thu, Nov 15, 2012 at 1:29 AM, Ryosuke Niwa wrote:
> ...
> In other words, why are you interested in using the proposed allocation
> mechanism for only DOM nodes/objects instead of everything in WebCore/WebKit?
>
>
> This was my con
On Wed, Nov 14, 2012 at 8:59 PM, Ryosuke Niwa wrote:
> On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn wrote:
>
>> I was present for one of the discussions about the exploit and how an
>> arena like allocator could have helped at Google. One proposed solution was
>> to allocate all the JS typed b
On Thu, Nov 15, 2012 at 1:29 AM, Ryosuke Niwa wrote:
> ...
> In other words, why are you interested in using the proposed allocation
> mechanism for only DOM nodes/objects instead of everything in
> WebCore/WebKit?
>
>
This was my concern as well. It would seem you'd need many different
arenas, a
On Wed, Nov 14, 2012 at 10:14 PM, Cris Neckar wrote:
> On Wed, Nov 14, 2012 at 10:05 PM, Ryosuke Niwa wrote:
>
>> On Wed, Nov 14, 2012 at 9:59 PM, Adam Barth wrote:
>>
>>> On Nov 14, 2012 8:59 PM, "Ryosuke Niwa" wrote:
>>> >
>>> > On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn
>>> wrote:
>>>
On Nov 14, 2012, at 10:05 PM, Ryosuke Niwa wrote:
> On Wed, Nov 14, 2012 at 9:59 PM, Adam Barth wrote:
>
> On Nov 14, 2012 8:59 PM, "Ryosuke Niwa" wrote:
> >
> > On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn
> > wrote:
> >>
> >> I was present for one of the discussions about the exploit a
On Wed, Nov 14, 2012 at 10:05 PM, Ryosuke Niwa wrote:
> On Wed, Nov 14, 2012 at 9:59 PM, Adam Barth wrote:
>
>>
>> On Nov 14, 2012 8:59 PM, "Ryosuke Niwa" wrote:
>> >
>> > On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn
>> wrote:
>> >>
>> >> I was present for one of the discussions about the e
On Nov 14, 2012, at 9:59 PM, Adam Barth wrote:
>
> On Nov 14, 2012 8:59 PM, "Ryosuke Niwa" wrote:
> >
> > On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn
> > wrote:
> >>
> >> I was present for one of the discussions about the exploit and how an
> >> arena like allocator could have helped at
On Wed, Nov 14, 2012 at 9:59 PM, Adam Barth wrote:
>
> On Nov 14, 2012 8:59 PM, "Ryosuke Niwa" wrote:
> >
> > On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn
> wrote:
> >>
> >> I was present for one of the discussions about the exploit and how an
> arena like allocator could have helped at Goog
On Nov 14, 2012 8:59 PM, "Ryosuke Niwa" wrote:
>
> On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn
wrote:
>>
>> I was present for one of the discussions about the exploit and how an
arena like allocator could have helped at Google. One proposed solution was
to allocate all the JS typed buffers in
On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn wrote:
> I was present for one of the discussions about the exploit and how an
> arena like allocator could have helped at Google. One proposed solution was
> to allocate all the JS typed buffers in an arena.
>
> Is there a reason we can't just do th
I was present for one of the discussions about the exploit and how an arena
like allocator could have helped at Google. One proposed solution was to
allocate all the JS typed buffers in an arena.
Is there a reason we can't just do that? It's much less intrusive to
allocate ArrayBuffer in an arena
Following up on a bugzilla discussion:
> It is indeed significant that only a small number of classes are allocated
> within RenderArena. For example, when there's a RenderObject which has been
> freed but is still in use, it's not possible for the attacker to allocate
> (e.g.) a raw ArrayBuff
On Wed, Nov 14, 2012 at 5:55 PM, Maciej Stachowiak wrote:
>
> On Nov 14, 2012, at 5:19 PM, Rik Cabanier wrote:
>
>
>
> I send the question to the fx list.
> Tab Atkins brought up that we could extend the 'globalCompositeOperator'
> so it also takes a comma separate list of a blend and a composit
On Nov 14, 2012, at 3:46 PM, Chris Evans wrote:
> On Wed, Nov 14, 2012 at 2:48 PM, Geoffrey Garen wrote:
>
> This is magical thinking. RenderArena is no different from FastMalloc.
>
> It's actually different enough to be interesting:
Thanks for sharing these. I think understanding what is di
On Nov 14, 2012, at 3:19 PM, Chris Evans wrote:
> On Tue, Nov 13, 2012 at 11:14 PM, Ryosuke Niwa wrote:
> On Tue, Nov 13, 2012 at 10:23 PM, Eric Seidel wrote:
> RenderArena was a perf optimization for the rendering tree, which
> hyatt imported from Mozilla 10 years ago:
> http://trac.webkit.or
On Nov 14, 2012, at 5:19 PM, Rik Cabanier wrote:
>
>
> I send the question to the fx list.
> Tab Atkins brought up that we could extend the 'globalCompositeOperator' so
> it also takes a comma separate list of a blend and a compositing operation.
>
> Calling:
> mycontext.globalCompositeOpera
On Wed, Nov 14, 2012 at 1:37 PM, Maciej Stachowiak wrote:
>
> On Nov 14, 2012, at 8:33 AM, Rik Cabanier wrote:
>
>
>
> On Tue, Nov 13, 2012 at 11:19 PM, Maciej Stachowiak wrote:
>
>>
>> On Nov 13, 2012, at 4:43 PM, Rik Cabanier wrote:
>>
>> Maciej,
>>
>> did this sound reasonable to you?
>>
>>
On Wed, Nov 14, 2012 at 3:46 PM, Chris Evans wrote:
> On Wed, Nov 14, 2012 at 2:48 PM, Geoffrey Garen wrote:
>
>> Hi Eric.
>>
>> Here are some problems in RenderArena that I know of:
>>
>> - Grows memory without bound
>> - Duplicates the functionality of FastMalloc
>> - Makes allocation error-pr
On Wed, Nov 14, 2012 at 3:27 PM, Ojan Vafai wrote:
> On Wed, Nov 14, 2012 at 2:48 PM, Geoffrey Garen wrote:
>
>> Having dealt with the specific technical question of RenderArena, I'd
>> like to briefly discuss the meta-level of how the WebKit project works.
>>
>> Sam Weinig and I both provided r
On Wed, Nov 14, 2012 at 2:48 PM, Geoffrey Garen wrote:
> Hi Eric.
>
> Here are some problems in RenderArena that I know of:
>
> - Grows memory without bound
> - Duplicates the functionality of FastMalloc
> - Makes allocation error-prone (allocation in the wrong arena is sometimes
> a leak, someti
On Wed, Nov 14, 2012 at 3:19 PM, Chris Evans wrote:
> On Tue, Nov 13, 2012 at 11:14 PM, Ryosuke Niwa wrote:
>
>> On Tue, Nov 13, 2012 at 10:23 PM, Eric Seidel wrote:
>>
>>> RenderArena was a perf optimization for the rendering tree, which
>>> hyatt imported from Mozilla 10 years ago:
>>> http:/
On Wed, Nov 14, 2012 at 3:27 PM, Ojan Vafai wrote:
> On Wed, Nov 14, 2012 at 2:48 PM, Geoffrey Garen wrote:
>
>> Hi Eric.
>>
>> Here are some problems in RenderArena that I know of:
>>
>> - Grows memory without bound
>> - Duplicates the functionality of FastMalloc
>> - Makes allocation error-pro
On Wed, Nov 14, 2012 at 2:48 PM, Geoffrey Garen wrote:
> Hi Eric.
>
> Here are some problems in RenderArena that I know of:
>
> - Grows memory without bound
> - Duplicates the functionality of FastMalloc
> - Makes allocation error-prone (allocation in the wrong arena is sometimes
> a leak, someti
On Tue, Nov 13, 2012 at 11:14 PM, Ryosuke Niwa wrote:
> On Tue, Nov 13, 2012 at 10:23 PM, Eric Seidel wrote:
>
>> RenderArena was a perf optimization for the rendering tree, which
>> hyatt imported from Mozilla 10 years ago:
>> http://trac.webkit.org/changeset/2635
>>
>> The prevailing lore has
On Wed, Nov 14, 2012 at 2:48 PM, Geoffrey Garen wrote:
> Hi Eric.
>
> Here are some problems in RenderArena that I know of:
>
> - Grows memory without bound
> - Duplicates the functionality of FastMalloc
> - Makes allocation error-prone (allocation in the wrong arena is sometimes a
> leak, someti
Hi Eric.
Here are some problems in RenderArena that I know of:
- Grows memory without bound
- Duplicates the functionality of FastMalloc
- Makes allocation error-prone (allocation in the wrong arena is sometimes a
leak, sometimes a use-after-free, and sometimes a heizenbug of the two)
- Makes al
On Nov 14, 2012, at 8:33 AM, Rik Cabanier wrote:
>
>
> On Tue, Nov 13, 2012 at 11:19 PM, Maciej Stachowiak wrote:
>
> On Nov 13, 2012, at 4:43 PM, Rik Cabanier wrote:
>
>> Maciej,
>>
>> did this sound reasonable to you?
>
> Still doesn't make sense to me. Even if we don't implement CSS
On Wed, Nov 14, 2012 at 10:58 AM, Ryosuke Niwa wrote:
> On Tue, Nov 13, 2012 at 12:35 PM, Dirk Pranke wrote:
>
>> On Tue, Nov 13, 2012 at 12:29 PM, Dirk Pranke
>> wrote:
>> > On Tue, Nov 13, 2012 at 12:13 PM, Darin Adler wrote:
>> >> I’d prefer an directory-based overlay/inheritance approach to
On Tue, Nov 13, 2012 at 12:35 PM, Dirk Pranke wrote:
> On Tue, Nov 13, 2012 at 12:29 PM, Dirk Pranke
> wrote:
> > On Tue, Nov 13, 2012 at 12:13 PM, Darin Adler wrote:
> >> I’d prefer an directory-based overlay/inheritance approach to sharing
> WebKit1- vs. WebKit2-specific expectations over in-
On Wed, Nov 14, 2012 at 12:01 AM, Dirk Pranke wrote:
>
> The way ref tests are currently implemented, there is no direct way to
> say "use test X as a reference for test Y" (although this is in the
> W3C specs for ref tests, which suggests using tags in the test
> html). Previous conversations o
On Tue, Nov 13, 2012 at 11:19 PM, Maciej Stachowiak wrote:
>
> On Nov 13, 2012, at 4:43 PM, Rik Cabanier wrote:
>
> Maciej,
>
> did this sound reasonable to you?
>
>
> Still doesn't make sense to me. Even if we don't implement CSS
> 'alpha-compositing' and 'blend-mode' today, I assume we will wa
The LLInt doesn't compile anything to native code, since its an interpreter. It
interprets the code instead.
-Filip
On Nov 14, 2012, at 3:19 AM, wingoog moon wrote:
>
>
> -- Forwarded message --
> From: wingoog moon
> Date: Wed, Nov 14, 2012 at 1:51 AM
> Subject: Understend
On Tue, Nov 13, 2012 at 8:59 PM, Raphael Kubo da Costa wrote:
> Dirk Pranke writes:
>
> > So, it seems like WK1 and WK2 keywords might be useful. However, I
> > don't really want to add more divergence between ports, so it would be
> > nice to have everyone agree to use it if we were to add it.
>
-- Forwarded message --
From: wingoog moon
Date: Wed, Nov 14, 2012 at 1:51 AM
Subject: Understending LLInt
To: squirrelfish-...@lists.webkit.org
Hi All.
At which point LLInt starts to compile bytecode to the native code?
If I'm not mistaken it should be in prepareForExecution fu
36 matches
Mail list logo
