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

Re: garbage collection?

On Thu, 12 Apr 2001, Jerry Seeger wrote:
> 
> 
> 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. 
Why? Who is the right person if not you?

> If you can show me a quick 
> and easy way to traverse references maybe I'll take a shot at it.
seach for members of type OzoneProxy via reflection

> 
> 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.

And, very important:
4) must be able to run incremental

The following link should be a good starting point. It gives an overview over
Conservative GC Algorithmic (mark and sweep)

http://reality.sgi.com/boehm_mti/gcdescr.html

> 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.

The simplest approach would be to let the GC run as an ordinary client thread
and let the pessimistic locking of ozone do the rest. 


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