Thread

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

Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-04-03T11:19:39Z

David Gould wrote:
> 
> > What you are describing is similar to the problem of lifetime of objects in
> > a parse tree.
> > If you don't know/understand the grammar being parsed it is very difficult
> > do manage
> > memory correctly. However if you do understand the grammar it's becomes
> > almost trivial.
> 
> Perhaps. Why then does it not work?

There was no proper attention to this issue!

> > I'm sorry I don't agree. If the programmer doesn't know what the lifetimes
> > of the objects creates should be, he probably should first find out. IMO
> > this is
> > one the most import parts of understanding a system.
> 
> To write extention function to make some application domain calculation
> and return a (allocated) double, I now have to understand the whole
> executor? I hope not.
> 
> In any case, there is no mechanism in the current code to allow a function
> author to control this accurately.

And he shouldn't care! He have to make allocation in current context
and let us take care about anything else.

> > >    The statistics I have seen for a derivative of postgres say that 86% of
> > >    all allocations are 64 bytes or less. 75% are 32 bytes or less, and 43%
> > >    are less than 16 bytes. This suggests that allocator overhead about
> > >    doubles the storage needed.
> > Did you also measure the lifetime of the objects. I would expect this to be
> > relatively short (as compared to the lifetime these objects might have with
> > a garbage collector.)
> 
> I did not measure lifetimes. It would take full tracing to really understand
> the behavior in detail and I simply have not done it. However the common
> uncontrolled growth case we see is that the objects may have short lifetimes
> but they are not freed until end of statement so the server just gets bigger
           ^^^^^^^^^^^^^
So we have to fix this!

> > >    is not freed for reuse in a timely way but accumulated until the end
> > >    of the memory duration (ie statement or transaction). This is the
> > >    usual reason for running out of memory in a large query. Additionaly,
> > >    the division of memory into separate pools creates extra fragmentation
> > >    which can only make matters even worse.
> > Don't GC's accumulate memory until "garbage collect" time? At
> 
> No. There is no requirement for this. The Boehm collector has incremental
> collection.

This is interest - I see I have to read more...

Vadim