Memory Management for nsIScriptContext: Difference between revisions

(Update to current thinking and decisions by Brendan.)
 
(5 intermediate revisions by 5 users not shown)
Line 12: Line 12:


* We can not have the memory management functions exclusively on nsIScriptContext.  There is code that currently stores a |void *| script object, but has no nsIScriptContext available.  One example is nsJSEventListener, which stores the |void *|, but has the |nsIScriptContext| provided as part of invoking the event.  nsJSEventListener would not want to store an nsIScriptContext just to free the script object.  Another example is the XUL cache which will be extended to cache all languages, but will not want to store an nsIScriptContext just to handle cache shutdown.
* We can not have the memory management functions exclusively on nsIScriptContext.  There is code that currently stores a |void *| script object, but has no nsIScriptContext available.  One example is nsJSEventListener, which stores the |void *|, but has the |nsIScriptContext| provided as part of invoking the event.  nsJSEventListener would not want to store an nsIScriptContext just to free the script object.  Another example is the XUL cache which will be extended to cache all languages, but will not want to store an nsIScriptContext just to handle cache shutdown.
[http://hostgator1centcoupon.net/ Hostgator VPS Coupon]
[http://hostgator-reseller-coupon.com/ Hostgator Reseller Coupon]
[http://hostgator-vps-coupon.net/ Hostgator 1 cent coupon]


* Linkage issues mean that "helper functions" are unsuitable for use here.  As the DOM implementation and each language implementation are individual components, public static functions are not globally reachable.  Either xpcom interfaces or fully inline C++ classes can be used to assist with these tasks.
* Linkage issues mean that "helper functions" are unsuitable for use here.  As the DOM implementation and each language implementation are individual components, public static functions are not globally reachable.  Either xpcom interfaces or fully inline C++ classes can be used to assist with these tasks.
Line 28: Line 32:
* Having performance critical code keep a reference to the nsILanguageRuntime.
* Having performance critical code keep a reference to the nsILanguageRuntime.


Even still, a key problem to this approach remains its fragility.  By explicitly requiring manual Drop/Hold calls, there is alot of scope for programmer error in the face of error conditions (ie, early returns) to cause difficult to track leaks.  The inevitability of such errors is evidenced by nsCOMPtr and various other tricks already in the code base.
Even still, a key problem to this approach remains its fragility.  By explicitly requiring manual Drop/Hold calls, there is a lot of scope for programmer error in the face of error conditions (ie, early returns) to cause difficult to track leaks.  The inevitability of such errors is evidenced by nsCOMPtr and various other tricks already in the code base.


== Implementation idea #2 ==
== Implementation idea #2 ==
Line 98: Line 102:
== Notes ==
== Notes ==


Implementation idea #2 has been implemented and works well.  However, concerns exist regarding the performace overhead in terms of speed and bloat.
Implementation idea #2 has been implemented and works well.  However, concerns exist regarding the performance overhead in terms of speed and bloat.
4

edits