But more importantly, how would this help with the SharedBuffer problem? It
seems like a separate topic.
>
> We have memory tools on Mac OS X that group allocations by the call stack
> when an object is allocated, and we have come up with scripts that help us
> put allocations into “areas” as you suggest, without adding code to WebKit.
>
> But in cases like the SharedBuffer one, there is no mystery about who
> allocated the memory. The mystery is typically who is holding on to a
> reference to it.
well, you can use same technique to capture call stack in ref inc/dec?
Usually buffers shouldn't be a problem even if widely allocedas you can dump a
few bytes
and get some idea where it came from and who may have been interested in it.
Sometimes I will give objects names and make up the name with some helpful info.
Personally I don't like ref counts. Maybe in a project like this they are the
easiest way
to go but there is no substititue for knowing how long your object is needed.
I haven't looked at this code but is SharedBuffer thread safe etc? I thought
someone was
talking about thread safety of reference counts at some point.
>
> -- Darin
>
_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
