Now from the right account.
yours,
anton.
On Mon, Nov 23, 2009 at 3:00 PM, Anton Muhin wrote:
> On Sun, Nov 22, 2009 at 1:45 AM, Drew Wilson wrote:
>> I guess I don't really understand why gcPrologue has that
>> ASSERT(wrapper.IsWeak()) then, unless there's something in the DOMMap code
>> that
I guess I don't really understand why gcPrologue has that
ASSERT(wrapper.IsWeak()) then, unless there's something in the DOMMap code
that is removing objects from the map when they transition to PENDING.
Anyhow, it sounds like it's safe to do something like the following in the
epilogue:
if (type
On Sat, Nov 21, 2009 at 12:08 PM, Jens Alfke wrote:
> Disclaimer: This code is fairly nasty and even though I've messed with it for
> a month or two I don't feel that I fully understand it, especially the map.
> (I think the map code needs a redesign at some point: for example, it really
> frig
On Nov 21, 2009, at 10:40 AM, Drew Wilson wrote:
> Can anyone explain (or point me at some docs) for how the
> gcPrologue/gcEpilogue stuff should work, wrt the state of the underlying
> handles (what assumptions does that code make)? I guess I don't really
> understand when objects are taken o
On Sat, Nov 21, 2009 at 9:40 PM, Drew Wilson wrote:
> Can anyone explain (or point me at some docs) for how the
> gcPrologue/gcEpilogue stuff should work, wrt the state of the underlying
> handles (what assumptions does that code make)? I guess I don't really
> understand when objects are taken ou
Can anyone explain (or point me at some docs) for how the
gcPrologue/gcEpilogue stuff should work, wrt the state of the underlying
handles (what assumptions does that code make)? I guess I don't really
understand when objects are taken out of the DOMMap. Let's say I have an
unentangled MessagePort
I "wrote" most of this code in the sense that I took the old garbage
collector design and refactored it to make isolated worlds possible.
I don't understand the MessagePorts lifetime issues in detail,
however.
Adam
On Fri, Nov 20, 2009 at 7:02 PM, Drew Wilson wrote:
> So I looked into the probl
So I looked into the problem further - the issue was that calling close()
would still leave MessagePorts in a seemingly entangled state, which meant
that they would never be freed (turns out this caused some related issues on
the WebKit side related to delaying worker exit).
I updated the code so
There's no bug on this yet - I ran across this when I ran out of memory in
my SharedWorkers soak test I was running (turns out that this bug may be
unrelated to the SharedWorkers bug).
It's quite possible that this is related to the V8GCController code - I'd
forgotten about that. In fact, it's qui
On Fri, Nov 20, 2009 at 1:20 AM, Drew Wilson wrote:
> I'm investigating a leak in the MessagePort/MessageChannel code. Basically,
> if I have a page that looks like this:
>
> new MessageChannel();
>
> We leak two MessagePorts every time we reload the page.
> The WebCore::MessageChannel impl obje
I'm investigating a leak in the MessagePort/MessageChannel code. Basically,
if I have a page that looks like this:
new MessageChannel();
We leak two MessagePorts every time we reload the page.
The WebCore::MessageChannel impl object has two RefPtrs to two MessagePort
objects. When I reload the
11 matches
Mail list logo
