On Tuesday 05 July 2005 19:32, Kay-Uwe Kasemir wrote:
> Hi Ben:
>
> So H.J. Boehm claims malloc is neither slower
> nor does it cause more fragmentation than
> custom per-class allocators.
The 'malloc' call itself (on most modern system), but please take a look
at
http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_11.html
GC beats the hell out of manual memory management with malloc/free in a
multithreaded setting. Reference counting is hopelessly out-classed.
OTOH, GC uses about twice as much overall memory, see
http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_16.html
This is for 'small' objects. For large ones, malloc/free is better by a
factor of 2 for exec time and by a factor of 9 for maximum pause time.
Maybe it would make sense to use GC for all the small objects and
explicit malloc/free for large ones? Does that even work as expected or
is the GC cost to be paid regardless of /how/ teh large blocks are
allocated? Many interesting questions...
> Quite different from what I was told before,
> and I have no idea who's right.
VxWorks is one of the examples where implementations have been
especially bad. It has probably not been considered by Boehm.
> We had a WindRiver presentation about vxWorks 6.0 here at the SNS.
> They mentioned that vxw 6.0 memory allocation causes
> less fragmentation, using a deterministic 'best fit'.
What I have read, 'best fit' is famous for causing unnecessary
fragmentation. One of the central questions with regard to
fragmentation is: will adjacent freed memory blocks be melted into one?
A simple address ordered first fit can do that efficiently, but maybe
this is hard to implement with hard upper bounds on execution time
(because during free you must search the free list).
> On the downside, it's slower than before, which
> causes most OS routines which 'create' something to be slower.
> So WindRiver seems to see a balance between being fast
> and fragmenting memory.
But they are providing hard real-time bounds on (de-)allocation time!
(or do they? i think they do)
But almost everything in EPICS does /not/ need hard RT garantees.
> My gut feeling is:
> If in doubt, go with the simple approach,
> and leave the memory management to the OS.
Note: EPICS already /has/ its own memory mangement solutions for certain
data types. Channel Access maintains its own memory pools, as do other
parts of the core system.
The question is: do we want to add more custom MM subsystems for array
fields, strings, record instances, etc....? And if yes, what do they
look like? If not, what would a more general solution look like?
For instance: How will we handle re-allocation of array fields? Is the
record support responsible for allocating memory for them and for
freeing it? How do you anticipate how much memory to reserve? Or is
this done by the EPICS core libraries? Must memory explicitly be
de-allocated by user code? How is locking handled?
These are important questions to think about, IMO.
Ben
- References:
- again: memory management Benjamin Franksen
- Re: again: memory management Kay-Uwe Kasemir
- Navigate by Date:
- Prev:
Re: Record support and user-defined fields Kay-Uwe Kasemir
- Next:
Re: Record support and user-defined fields Benjamin Franksen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: again: memory management Matthias Clausen
- Next:
[Fwd: Re: EPICS V4 support for data acquisition] Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|