[fpc-devel]How to subscribe to list

[Michael Van Canneyt]

On Mon, 6 Nov 2000, Sergey Korshunoff wrote:

> Hello everybody.
> There is no description in FPC doc's about this list subscription.
> May be it is better to put some doc's about this procedure in FPC
> doc's insteed of following sentense in readme.txt:
>   Information about available lists and subscription can be found
>   on http://lists.freepascal.org/mailman/listinfo
> I do not have direct internet access. Can You send me answer by
> e-mail?
> 
> Regards,
>   Sergey Korshunoff
> 
> PS: I have modified version of heap manager for FPC (v1.00).
> In FPC 1.02 problem of memory fragmentation was solved in "FreeMem"
> procedure. I think this is not so good. In my version a merging
> is performed in "GetMem" procedure (when we looking freelists[0]
> for a free memory block).
> This is faster (about 20% faster for a GetMem/FreeMem test cycle)
> 
>  And my version do not allocate new memory from system if
> we have continius memory block of needed size (in v1.02 we do not
> merge blocks which start from some block in freelists[1..x])
> 
> Well. There is notes about my changes (related to v1.00):
>   Sergey Korshunoff (seyko at p5.f434.n5020.z2.fidonet.org):
>   1. Some constants moved from heaph.inc to this file.
>   2. Value returned by `SysMaxavail' is more correct now.
>   3. In SysGetMem:
>        dec(internal_memavail,size);
>      is moved near to succesful exit (or we need to decrement
>      internal_memavail when we fail to allocate memory).
>   4. Handle case when `HeapError' return value is not in [0,1,2].
>   5. Now we repeat a full memory search path when `HeapError' say
>      to try again. This is like Borland `GetMem' do it. And
>      this allow us to handle a case when `HeapError' lead to
>      a `FreeMem' call without adding any new memory from OS.
>   6. BESTMATCH removed (it is time consuming procedure)
>   7. SysGetMem now merges blocks.
>   8. `heaporg', `heapptr' and `beforeheapendmask' are
>      not used now and removed (new memory from system go directly
>      to free list)

I don't know what the effect is of the above 8 points;
this should be looked at by Peter Vreman or Pierre Muller.

>   9. Procedure ReAllocMem in TMemoryManager record now takes
>      3rd paramater: a size of memory in old block which
>      contain information (some time it is much faster do not
>      to copy not used data from the old block)

AFAIK, this is not Delphi compatible; it should be removed again.

>  10. Functions 'SysGetMem, Sys..' are removed from heaph.inc
>      because you should use MemoryManager for this job.

Not good, since someone may wish to install a memory manager that does
not override all functions, so they may wish to have access to the
old functions.

> 
> syslinux.pp:
>   I replaced a call to syscall_nr_mmap by a call to syscall_nr_brk:
>   1) with syscall_nr_mmap first block of memory, reserved by FPC option
>       "-Cs<n>  set stack size to <n>",
>   and second memory block, asked from Linux, will never be merged.
>   2) Linux do not allow restrict amount of memory (used by
>   program) if this memory is not allocated by syscall_nr_brk.

This is not good; the linux memory system used to use syscall_nr_brk,
this was changed to syscall_nr_mmap() to be compatible with C libraries.
C libraries use mmap(); if we use brk() then this creates conflicts.

> 
> cmem.pp from source/packages:
>   CHeapSize and CMemAvail was added. CMEM do not return memory
>   to system now (this behavior is like behavior of standard heap package).
>  And
> now CMEM really do a work (there was some errors: before changes
>   adding CMEM in Uses statements lead to not working program).

Corrections to cmem may be sent to me; please send a context diff file.

Michael.