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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to