[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: garbage collection?



On Wednesday, April 11, 2001, at 03:50 AM, Falko Braeutigam wrote:

On Tue, 10 Apr 2001, Reason wrote:
You can make very complex interrelationships between objects, you just have
to make the low-level code that manages the objects a little different.
Persistent Ozone objects hang around until you database().destroy() them.
So, to take a trivial example, if you have multiple objects of class X that
contain references to a single object of class Y, you need to change the
behavior of X.removeReferenceToY() (or vice versa) such that the Y object is
destroy()ed if it doesn't have any references left.

Removing references on deletion is pretty easy -- just use the onDelete()
method liberally.

[I can't see any reason as to why you couldn't start up an object removal
thread in a persistant object in the database server as well, but that may
be costly compared to just deleting where appropriate in you low-level
code].

Have a look at www.twilightminds.com/datafull.html for an example of complex
interrelationships (based on simple rules and three classes) handled in an
Ozone environment.

I agree. Explicitly handling deletion of object in a application specific
manner is not that hard to achieve in the majority of cases _and_ is much
faster than a generic GC. Anyway, Jerry, a generic GC for sure would be a
great enhancement of ozone. If you need it then it would be great if you would
help to come up with a solution.


Falko


An unscientific analysis of my application makes me think that it would probably double the complexity of my code to track references - perhaps even more if I want to eliminate the chance of circular references causing a leak. My app is really very simple but the data can be very intertwined.

I my not be the right person to build GC into ozone, but here are some thoughts on what the requirements would be. If you can show me a quick and easy way to traverse references maybe I'll take a shot at it.

1) should be scheduleable. It could be a significant performance hit, so you want to be able to control when it happens. App developers could inform users when GC is taking place so they will understand why things are slower.
2) Should be transactional. Obviously, if database state changes during GC no data should be lost.
3) Objects stored by name should never be garbage collected. These would be considered root objects.

Off the top of my head, I can think of a couple of different methods for GC - one would be a two-pass system where you traverse all objects that can be reached from a root and mark them. A second pass looks at every object in the database and deletes unmarked objects. Any objects that are locked during the first pass would be considered reachable. You have to make sure that objects created between the two passes are marked appropriately. Another method could be to start from the roots and copy any object found to a new database. After all objects are copied, the first database is deleted. This can also help to group related objects together in the database. Once the copy process starts, all new objects created in other transactions would be created in the new database.

Of those two methods, I like the first one better, but the second one does reduce fragmentation. There are probably other ways to do it also. The hardest part seems to me to make the process robust enough that objects can be created and destroyed in other threads without breaking the GC.

Jerry

Reason
http://www.exratio.com/

----- Original Message -----
From: "Jerry Seeger" <vikingjs@mac.com>
To: <ozone-users@ozone-db.org>
Sent: Monday, April 09, 2001 7:01 PM
Subject: garbage collection?


Does ozone do garbage collection? I have objects that may be parts of
several different collections and I sure don't want to have to keep
track of the number of references to each one to know when to remove it
from the database. This could be a deal breaker for me - the whole
reason I want to use an OODBMS is so I can have very complex
interrelationships and treat them just like regular Java code.

Jerry Seeger
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com