Heap changes (Was Re: [fpc-devel]How to subscribe to list)

[Peter Vreman]

> > 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)

Can you send me a copy privately.

> >
> >  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.

But these constants can be changed by the program. For example to allocate 
smaller memory blocks from the OS. And the returnnil const is necessary for 
tp compatibility in objects iirc.

> >   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].

These updates can be added easily.

> >   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.

Must see code first

> >   6. BESTMATCH removed (it is time consuming procedure)

It's a leftover from earilier implementation without merges.

> >   7. SysGetMem now merges blocks.

This is good

> >   8. `heaporg', `heapptr' and `beforeheapendmask' are
> >      not used now and removed (new memory from system go directly
> >      to free list)

Are you really sure the beforeheapendmask can be removed? Becuase the error 
it triggered was rather tricky:

When there are less bytes left then the size of tfreerecord (=12 bytes). 
Then you can't allocate a new block after it. And also not check if the 
block after it is used.

Example:

OS Block allocated of 1024 bytes.

You allocate 1016 bytes. Then you can't use the last 8 bytes and you need 
to set some flag that the  block of 1016 bytes is the last block after 
which you can't checked.


>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.

Does it really speed up? Becuase it also adds some extra overhead to pass 
the size. And the extraneous moves are at max only 3 extra movsl assembler 
instructions.


> >  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.

Ever looked at heaptrc, then you know why they are exported.



> >
> > 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.

brk() is slower. And more importantly it can't be used with dynamicly 
linked libraries.




Peter