Object Finalization and GC 
Author Message
 Object Finalization and GC

How do I encourage HD to perform a GC cycle and run my finalization
routines. It appears to hold off as long as possible, and on a machine with
a virtual address space of more than 500 MBytes that can take quite a
while...

I have some references to COM interfaces that I would like to have released
when no longer used, and I was trying to avoid the incessant reference
counting promoted by MS. My feeling is that as long as an interface pointer
is reachable then it should be valid, regardless of how many internal copies
of it have been made. Of course, if I pass a COM interface pointer to the
outside world then I will perform an AddRef on it first.

I have searched hi and lo through the documentation and also in the
namebanks of the HD provided private routines and I can find nothing that
hints at tuning the GC mechanism...

Anyone have a suggestion?

David McClain
Sr. Scientist
Raytheon Systems Co.
Tucson, AZ



Tue, 27 Nov 2001 03:00:00 GMT  
 Object Finalization and GC

Quote:

> How do I encourage HD to perform a GC cycle and run my finalization
> routines. It appears to hold off as long as possible, and on a machine with
> a virtual address space of more than 500 MBytes that can take quite a
> while...

I don't know how to force a GC but to drain the finalization queue you
can call 'drain-finalization-queue'. This should go through all
current queued objects (those that have become unreachable) and call
finalize on them.

Chris.



Wed, 28 Nov 2001 03:00:00 GMT  
 Object Finalization and GC
Yeah, but the problem is that nothing gets enqueued...

Quote:


>> How do I encourage HD to perform a GC cycle and run my finalization
>> routines. It appears to hold off as long as possible, and on a machine
with
>> a virtual address space of more than 500 MBytes that can take quite a
>> while...

>I don't know how to force a GC but to drain the finalization queue you
>can call 'drain-finalization-queue'. This should go through all
>current queued objects (those that have become unreachable) and call
>finalize on them.

>Chris.



Wed, 28 Nov 2001 03:00:00 GMT  
 Object Finalization and GC

Quote:

> Yeah, but the problem is that nothing gets enqueued...

    Ever?  Or just "soon"  enough?   If it is never is there a chance there
    some strong reference to this "garbage" which makes it uncollectable?

Quote:



> >> How do I encourage HD to perform a GC cycle and run my finalization
> >> routines. It appears to hold off as long as possible, and on a machine
> with
> >> a virtual address space of more than 500 MBytes that can take quite a
> >> while...

   How long to you hold the Dylan "wrapper" for this COM object?  If you hold
   it a long time then this Dylan heap object will probably make it into the
   "oldest" generation.  In a generational collector, the length of an object's
   lifetime does influence the length of an object's "death process".  Namely,
   it takes longer to "die off".  A generational collector will scavange the "new"
   stuff first since it is much more likely to be ephemeral.  If that is enough
   to continue computation then the gc process stops there.   Only when the
   "new" generation's promotions fill up the "old" generational space that a GC
   is done on the "old stuff".  The objective is not to look at the "old"
   stuff for as long as  possible, since most if it is very likely not garbage.

   Therefore, holding something a long time has the effect of "burying" it
   pile of stuff that isn't garbage.  It may not get "marked" as garbage for
   a long time.   That seems more of a problem of finding a better place to
   "bury" the object than "tuning the collector" (at least the kind collector
   the "object" is currently subject to).

   You could force your heap to be smaller so that the oldest generation would
   be GC'ed more often.  If most of that old stuff really isn't garbage then the
   repeated collection attempts just spend alot of time not particularly
   accomplishing much. You'll raise the total time that the program spends garbage
   collecting.  That's annoying when you have enough memory you don't really
   have to do this.

   If timeliness is very important then I'd recommend doing it manually.
   [ There is a diconnect when trying to couple two different garbage
     collectors.  One may not "feel" the GC pressures of the other. ]

---

Lyman



Thu, 29 Nov 2001 03:00:00 GMT  
 Object Finalization and GC

Quote:
> How do I encourage HD to perform a GC cycle and run my finalization
> routines. It appears to hold off as long as possible, and on a
> machine with a virtual address space of more than 500 MBytes that
> can take quite a while...

I posted this question to our memory manager gurus at Harlequin, and
here's what they said:

  HD doesn't offer any promptness guarantees for finalization, any
  more than it guarantees promptness of reclaiming memory.

  Memory is a limited resource, and the HD GC has been designed to
  ensure that Dylan programs make efficient use of it by collecting
  objects often enough but not too often. The timing of finalization
  is directly related to the timing of memory reclamation, and the
  usage of finalization is considered to be appropriate for cleaning
  up resources which are no more scarce than memory (such as memory
  allocated outside of Dylan).  In general, if it's necessary to
  perform a clean-up action more promptly than this, then we would
  recommend using some other approach.

One suggestion that was recommended was using block..cleanup clauses
where the extent of a reference is known, but you are probably doing
that already.

Is this a satisfactory answer? The memory management group are very
strongly of the opinion that explicitly requested garbage collections
are too high a cost to pay, that the whole system is tuned to run only
under its own control. This is why they don't make such a function
available.

Of course, I'd be happy to pass on any opinions to them.

Andy

----------

Harlequin Inc.



Sat, 01 Dec 2001 03:00:00 GMT  
 Object Finalization and GC

Quote:

> Is this a satisfactory answer? The memory management group are very
> strongly of the opinion that explicitly requested garbage collections
> are too high a cost to pay, that the whole system is tuned to run only
> under its own control. This is why they don't make such a function
> available.

> Of course, I'd be happy to pass on any opinions to them.

So you don't think that it's useful for the programmer to be able to say
to the garbage collector "now might be a good time to do a litle
collecting"?  This might be because the program expects to be waiting idle
for a while, e.g. waiting for user input, waiting for a reply to a network
request, waiting for disk I/O etc.  Also it's possible that some unit of
work has been completed that allocated large number of objects that are
now known to be not needed.

In a multi-threading environment, you might well make the idle task check
to see whether a garbage-collect might be a good idea, but I don't think
that you have that sort of thing in HD?

It's certainly good to have the language system preserve the correctness
of programs by making memory management automatic, but it's common for
other automatic mechanisms to provide the user a way to make hints that
may (or may not, if improperly used) possibly improve performance, while
preserving correctness.  Examples abound: cache hint instructions in
recent CPUs, branch prediction hints in recent CPUs, syscalls for
preloading or flushing virtual memory, semantic clues such as "inline" or
"register" in programming languages.  Even automatic transmissions on cars
let you hint that you'd like an upshift or downshift, while leaving the
final decision up to the machine.

-- Bruce



Sat, 01 Dec 2001 03:00:00 GMT  
 Object Finalization and GC

Quote:
> So you don't think that it's useful for the programmer to be able to
> say to the garbage collector "now might be a good time to do a litle
> collecting"?  This might be because the program expects to be
> waiting idle for a while, e.g. waiting for user input, waiting for a
> reply to a network request, waiting for disk I/O etc.  Also it's
> possible that some unit of work has been completed that allocated
> large number of objects that are now known to be not needed.

Just to be clear, I'm just passing on comments from Harlequin's memory
management group, and in my email I think I misrepresented them a
little. Here are some comments from Tony Mann, the head of the group:

  I do think that explicitly requested GCs are too high a price to pay
  - but that's not to say I don't think there should be any user
  control at all.

  All of Bruce's comments and suggestions are excellent ideas. We've
  discussed pretty much all of them in the past, and they're all
  scheduled for future development. Some of them are actually already
  provided by the GC - but they are currently only implemented for use
  in specific circumstances. For example, the compiler makes use of a
  GC-provided mechanism to indicate that it might be worth performing
  a fairly big collection at the end of a compilation. We need to
  generalize this before making it available for other Dylan programs.

  The key point (as Bruce says) is that these are all hints which help
  the underlying machine (the GC) make the final decision for improved
  performance.  Hints might help to make objects become eligible for
  finalization earlier than they would otherwise. But that's a
  different thing from providing a promptness guarantee for
  finalization. If there's a need to clean up resources at a
  particular point in the program, then finalization is almost
  certainly not an appropriate mechanism. I'm not sure if that's the
  case here.

I hope that clears things up.

Andy

----------

Harlequin Inc.



Sat, 01 Dec 2001 03:00:00 GMT  
 Object Finalization and GC


Quote:
> ...

> Is this a satisfactory answer? The memory management group are very
> strongly of the opinion that explicitly requested garbage collections
> are too high a cost to pay, that the whole system is tuned to run only
> under its own control. This is why they don't make such a function
> available.

> Of course, I'd be happy to pass on any opinions to them.

They probably are right that in most situations their system is the best
choice, but, as always, there will be special cases where it performs
suboptimal.  I would think making explicit grabage collection requests
available, together with a strong (and highly visible) warning in the
documentation would give people who face some very special situations
the tool;s they need without compromising the validity of their system.

Hartmann Schaffer



Sat, 01 Dec 2001 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. GC, and objects finalization (was: GC,again)

2. GC and object finalization.

3. Why Files? (Was: Finalization and GC)

4. GC and resource finalization

5. memory management and object finalization in Ruby

6. finalization of classwide type objects

7. Object finalization

8. Zombie Objects Leaks With Automatic GC

9. Finding un-gc-able objects

10. different object aging rates in GC

11. zillion objects and gc

12. Fatal Python error: GC object already in linked list

 

 
Powered by phpBB® Forum Software