From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ca9eef4d5e2078ea X-Google-Attributes: gid103376,public From: Corey Minyard Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/06 Message-ID: #1/1 X-Deja-AN: 295904103 Sender: minyard@wf-rch.cirr.com References: Organization: Wonderforce Research Newsgroups: comp.lang.ada Date: 1997-12-06T00:00:00+00:00 List-Id: gwinn@res.ray.com (Joe Gwinn) writes: > > Memory Management. The Ada Runtime System makes extensive calls to the C > functions malloc() and free(), a cause for worry. Variable-block > allocators such as malloc and free are generally unsuited for nonstop > heavy use, and will generally either leak memory or fragment their memory > pool, causing the application to run slower and slower until it eventually > jams. The use of free() in a realtime system is generally forbidden; > it's OK to allocate a bunch of memory during startup, and explicitly > manage it yourself during operation, but it is not OK to use malloc and > free for realtime memory management. The claim is that Wind River's > version of malloc/free is stable in realtime use. It's hard to see how > this could be true. This will need further research. > Although this is not Ada related, I ran into this, too, when using C. The VxWorks implementations of malloc() and free() are very bad, they are slow and their speed decreases over use (we saw >100ms malloc times on every call after a while!). I ported GNU malloc, used the standard VxWorks calls to allocate a block, and used that instead. The times remained sub-millisecond even after a long time. Some people in VxWorks have the port, I suggest you contact you VxWorks rep for it, since they have probably improved it. -- Corey Minyard Internet: minyard@acm.org Work: minyard@nortel.ca UUCP: minyard@wf-rch.cirr.com