Garbage Collection in Open Office

[Zainul Franciscus-2]

Hi,

I just started exploring the Open Office API.  At the moment I am trying to load a document using com.sun.star.frame.XComponentLoader. The API is very simple and straight forward.

One thing that I am really interested to know at this point is regarding the memory management of Open Office. So for this discussion I would like to use the XComponent Loader as an example.

Scenario: I load a document using XComponent Loader. After XComponent Loader finish loading the document, how does open office garbage collect the resources that XComponentLoader create or use. Does it garbage collect on a certain condition, e.g.: run garbage collection when heap size is more than 'X' amount ? Or does it garbage collect immediately after we finish loading a document ?

Thank you.





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stephan Bergmann]

On 11/03/09 05:36, Zainul Franciscus wrote:

> One thing that I am really interested to know at this point is regarding
> the memory management of Open Office. So for this discussion I would
> like to use the XComponent Loader as an example.
>
> Scenario: I load a document using XComponent Loader. After XComponent
> Loader finish loading the document, how does open office garbage collect
> the resources that XComponentLoader create or use. Does it garbage
> collect on a certain condition, e.g.: run garbage collection when heap
> size is more than 'X' amount ? Or does it garbage collect immediately
> after we finish loading a document ?

The life-cycle of UNO objects is managed via reference counting (that's
why com.sun.star.lang.XComponent.dispose is needed to explicitly disband
ring references).  If only C++ is involved, the clients'
com::sun::star::uno::Reference smart-pointers to a given UNO object will
cause destruction of the UNO object as soon as the last uno::Reference
to it goes out of scope.  If access from other, garbage-collected
languages like Java is added into the picture, things become less
deterministic, as a reference held from Java on a UNO object is only
decreased when the Java runtime decides to garbage-collect the
corresponding Java proxy object.
<http://udk.openoffice.org/common/man/lifecycle.html> has some more on this.

Underneath the UNO object layer (i.e., within the C++ implementation)
memory management is traditional C/C++ style (i.e., more or less manual
and ad hoc), maybe even using (bounded) caches here and there.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...