How to interpret Chrome memory profiling result, memory allocation timeline - GSAP Tween memory leak

I'm maintaining a Vue.js SPA application which uses GSAP for making animations in the webapp. It seemed that memory leaks happened while using animations, so I did memory profiling and I got the result as below:

Please understand that I cannot upload whole specific codes, and instead I would like to ask a question about the way how to interpret the Chrome memory allocation timeline.

1. What does bound_this in native_bind() mean in that retainer stack?
2. I understood as that the Retainers means the objects that could not been deallocated by GC because of the references left somewhere, is this correct?
3. If the statement in question 2 is correct, then is it available to identify the cause of memory leak in the retainer stack above? Or, if that is impossible or hard, then at least can we speculate? If we can speculate it, then what is rationale or reason for that?
4. (Optional) In the code, window.toast Vue component is animated by GSAP Tween, and after the animation terminates GSAP will wrap up the animation(kill()) and the toast will remain in the DOM. GSAP Tween object is stored in Vue component's data, it is handled for controlling animation purpose, and after the animation terminates that animation object will be assigned null so that it can be garbage-collected. But, it seems that even after sufficient amount of time that animation object is not removed according to the result above. It seems this also causes many Detached HTMLDivElements, which leads to memory leaks. I think I thoroughly prevented the memory leak by removing references(assigning null), does this mean I'm missing something? Or, is there a performance issue with GSAP and is there a bug that animation objects in global timeline do not get cleaned?

Please give me any guess or advice even if it's not accurate answer. I'm so frustrated with this issue lately.

from How to interpret Chrome memory profiling result, memory allocation timeline - GSAP Tween memory leak