I've been working on the GStreamer version of in-band text tracks, but I haven't looked at the details of how RefPtr works. My guess is that JavaScript is holding those extra refs, and the "clear memory cache" forces a JS garbage collect.
On 10/01/2013 03:48 AM, Benjamin Dupont (bedupont) wrote: > > Hi all, > > > > I am currently working on the InbandTextTracks in webkit and I am > trying to understand how the memory is released. > > > > When we launch the track-in-band.html layout test, two in-band text > tracks have been created and added, the corresponding RefPtr has a > refCount equals to three. > > 1. Why are there 3 owners for each in-band text track? Is there an > hidden cache mechanism? > > > > After this test, if we load another page, the player is destroyed and > the clearTextTracks method is called. > > In my understanding, the player should be the only owner of in-band > text tracks and thus after the clearTextTracks method is called, the > ref count should be decreased to 0 and the in-band text track object > should be deleted. > > In fact, after the clearTextTracks method the ref count isn't equals > to 0 thus the in-band text track object isn't deleted. > > This text track object is deleted when the clear memory cache is called. > > > > 2. Is it a normal behavior? If yes, what is the interest to use smart > pointer? > > > > 3. How does the clear memory cache know that this ref pointer (with a > ref count != 0) can be released? > > > > Thanks in advance for your explanations, > > > > Regards, > > Benjamin Dupont. > > > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
signature.asc
Description: OpenPGP digital signature
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
