Re: [HACKERS] Its not my fault. Its SEG's FAULT!
От | Vadim B. Mikheev |
---|---|
Тема | Re: [HACKERS] Its not my fault. Its SEG's FAULT! |
Дата | |
Msg-id | 3524AD5E.5F18640C@sable.krasnoyarsk.su обсуждение исходный текст |
Ответ на | Re: [HACKERS] Its not my fault. Its SEG's FAULT! (dg@illustra.com (David Gould)) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: dg@illustra.com (David Gould)Дата:
Сообщение: Re: [HACKERS] Its not my fault. Its SEG's FAULT!