EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: again: memory management
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Wed, 6 Jul 2005 13:24:29 +0200
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  <20052006  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  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·