| 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: V4 EpicsString |
| From: | Andrew Johnson <[email protected]> |
| To: | [email protected] |
| Cc: | [email protected] |
| Date: | Fri, 08 Jul 2005 12:14:02 -0500 |
Hi Ben,I think it's true to say that the "simple" cords approach to strings is only possible if you have a Garbage Collecting memory manager. For proof of that statement, consider what happens if I extract a short string from the middle of another huge string; with a cord implementation this extraction does no copying, it just records a pointer and the length. If the huge string then gets unreferenced by its original owner, the memory holding the huge string must not be freed since another cord is still pointing into the middle of it. A GC memory manager may be able to work out that most of the string is unused and hence release it, but using the regular malloc/free model can't do that. A reference-counted implementation would be possible, but now you're complicating the string implementation and the major advantages of cords start slipping away.
One of the tenets of Garbage Collection is that it is pretty much an all-or-nothing kind of thing; either you use GC for everything, or you can't use it at all, since references to GC memory may only exist in non-GC memory such as in OS structures (think of the string that holds the name of one of my tasks for instance). Somewhere in the documentation you pointed to on the Boehm GC memory manager it was stated that it has only been implemented on systems that have virtual memory.
I don't know whether anyone has ever tried to use GC under RTEMS, but I'm pretty confident that it would not be easy to implement in vxWorks. Writing and tuning a GC is not an easy thing to do, and certainly not something the EPICS community has any experience with. We do however understand the issues associated with the use of malloc/free in the real-time systems that have to be implemented at many EPICS sites.
I think we have to be conservative in our design choices for EPICS 4.0, and I would certainly not favour the idea of including a full-blown GC memory manager in EPICS. I agree that we should discuss the topic of memory management next week, and I've added it to my list of topics, but I don't think you're going to win us around to adopting GC.
- Andrew -- Podiabombastic: The tendency to shoot oneself in the foot.