Now from the right account.
yours,
anton.
On Mon, Nov 23, 2009 at 3:00 PM, Anton Muhin <ant...@google.com> wrote:
> On Sun, Nov 22, 2009 at 1:45 AM, Drew Wilson <atwil...@chromium.org> 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 is removing objects from the map when they transition to PENDING.
>
> DOMMaps are just caches and thus shouldn't retain objects
> (GCPrologue/GCEpilogue is just a somewhat hacky way to account for
> special marking)---if we keep a persistent handle in not weak state,
> that would keep the object behind it alive forever.
>
>> Anyhow, it sounds like it's safe to do something like the following in the
>> epilogue:
>> if (type == V8Index::MESSAGE_PORT && !(wrapper.IsWeak() ||
>> wrapper.IsNearDeath()) {
>> // Make the port weak again (undo the ClearWeak() in GcPrologue)
>> wrapper.MakeWeak();
>> }
>
> Looks safe for me as well. I'd only suggest to drop
> !wrapper.IsWeak()---it's not explicit, but all the wrappers should
> have the same datum and callback.
>
> yours,
> anton.
>
>> On Sat, Nov 21, 2009 at 12:08 PM, Jens Alfke <s...@google.com> wrote:
>>>
>>> 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 out of the DOMMap.
>>>
>>> If you're talking about what happens in V8GCController: the prolog/epilog
>>> stuff that it does is, in my understanding, mostly related to temporarily
>>> grouping together the handles for objects in the same DOM tree, so that none
>>> of them will be collected before the whole tree goes away. I don't think the
>>> code there moves stuff in or out of the DOMMap.
>>>
>>> The DOM map is twiddled at other times. Objects are added to the DOM map
>>> when they need to be returned in JS form to V8, and removed when V8 calls
>>> back to tell Chrome that a weak handle's been GC'd.
>>>
>>> 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 frightens me that the line of code that ref()s a DOM object being
>>> added to the map is in an entirely different source file from the line that
>>> eventually deref()s it when it's removed. This makes me nervous about
>>> potential ref leak bugs.)
>>>
>>> —Jens
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
