Thread

Re: [HACKERS] Its not my fault. Its SEG's FAULT!

Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-04-03T09:35:26Z

David Gould wrote:
> 
> Vadim:
> > I agreed with Maurice.
> > Using GC instead of MemoryDuration everywhere isn't good idea for
> > database server.
> 
> Why? Please state your reasons for this claim.
> 
> > But we could implement additional GC-like allocation mode and use it
> > where is appropriate!
> 
> This assumes that there is a "where it is not appropriate". My contention
> is that it is generally appropriate. So my question must be, where is it
> not appropriate and why?

Where would you put call to collector in Executor ?

> The examples you give are certainly places where a GC would be very very
> useful.  But, I think restricting the GC to cover only some allocations
> would lose most of the benifit of using a GC altogether.
> 
> First, the entire heap and stack have to be scanned as part of the root
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> set in either case. However your proposal only lets the collector free
  ^^^^^^^^^^^^^^^^^^
> some of the garbage identified in that scan. This has the effect of making
> the cost of each bit of reclaimed storage higher than it would be in the
> general case. That is, the cost of a collection remains the same, but less
> storage would be freed by each collection.

No! In GC-like allocation mode I meant to use malloc to allocate
memory in big chunks (> 8K) and use Last_Allocated_Byte counter for
each chunk in palloc() to "allocate" memory. pfree will do nothing. 
GC-destroyer will just free a few chunks - without any scans. 
Many GC-storages will be available simultaneously (GC_Storage_Identifier 
will be returned by StartGCAllocation() call and used by EndGCAllocation() 
to free memory in given storage). GC-allocations will be made in current memory
context (in term of postgres) ==> code using special memory contexts
(relation cache etc) will not be affected at all (switching to another
context will stop GC-allocation untill first context restored)
as well elog(ERROR) clean up feature.

> Second, one of the reasons a GC can be faster that explicit allocation /
> deallocation is that it frees the rest of the system from doing bookeeping
> work. A half-and-half system does not get this benifit.
> 
> PostgreSQL is I think an especially good candidate to use a GC as the overall
> complexity of the system makes it very hard to determine the real lifetime of
> any particular allocation. This is why we have the complex MemoryDuration
> system that we currently have. This is also why we have the leaks and vast
> storage requirements that we have.

Sure - it's not so hard to determine lifetime of any allocation.
Please, don't forget that postgres was _academic_ research project
for very long time and so there were no big efforts against leaks etc.

> Did you have a chance to review the links I sent in the earlier posting?
> Some of the papers referenced there are quite interesting, particularly
> the Zorn papers on the real cost of explicit storage allocation.

Sorry - I just started and will continue...

Vadim