Prev: Why a file system required in an embedded Device
Next: PHY initialization
From: D Yuniskis on 24 Feb 2010 01:48
Hi,

Quasi-deterministic malloc/free implementations tend to
be inefficient (i.e., wasteful of resources).

But, I wonder if dynamic changes to the algorithms used
by malloc/free can be exploited to provide *application
specific* deterministic behavior in certain contexts.

E.g., implement malloc(3) more like:

malloc(size_t size, int (* selector)(fragment_t *))

with similar changes to free(3).

Has any work been done in this regard?

Or, any work evaluating different algorithms to satisfy
requests and releases? I suspect any experiments into
this have probably been applied in desktop environments
instead...

Thx,
--don
From: Boudewijn Dijkstra on 24 Feb 2010 03:49
Op Wed, 24 Feb 2010 07:48:35 +0100 schreef D Yuniskis
<not.going.to.be(a)seen.com>:
> Quasi-deterministic malloc/free implementations tend to
> be inefficient (i.e., wasteful of resources).

Non-deterministic malloc/free implementations tend to
be inefficient (i.e., unpredictable timing).

> But, I wonder if dynamic changes to the algorithms used
> by malloc/free can be exploited to provide *application
> specific* deterministic behavior in certain contexts.
>
> E.g., implement malloc(3) more like:
>
> malloc(size_t size, int (* selector)(fragment_t *))

What are you implying here? The user seems to be required to supply a
pointer to a "fragment selector function". What is that supposed to do?

> with similar changes to free(3).
>
> Has any work been done in this regard?
>
> Or, any work evaluating different algorithms to satisfy
> requests and releases? I suspect any experiments into
> this have probably been applied in desktop environments
> instead...



--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)
From: Vladimir Vassilevsky on 24 Feb 2010 10:52

Have different heaps with different algorithms.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com



D Yuniskis wrote:

> Hi,
>
> Quasi-deterministic malloc/free implementations tend to
> be inefficient (i.e., wasteful of resources).
>
> But, I wonder if dynamic changes to the algorithms used
> by malloc/free can be exploited to provide *application
> specific* deterministic behavior in certain contexts.
>
> E.g., implement malloc(3) more like:
>
> malloc(size_t size, int (* selector)(fragment_t *))
>
> with similar changes to free(3).
>
> Has any work been done in this regard?
>
> Or, any work evaluating different algorithms to satisfy
> requests and releases? I suspect any experiments into
> this have probably been applied in desktop environments
> instead...
>
> Thx,
> --don
From: D Yuniskis on 24 Feb 2010 11:31
Boudewijn Dijkstra wrote:
> Op Wed, 24 Feb 2010 07:48:35 +0100 schreef D Yuniskis
> <not.going.to.be(a)seen.com>:
>> Quasi-deterministic malloc/free implementations tend to
>> be inefficient (i.e., wasteful of resources).
>
> Non-deterministic malloc/free implementations tend to
> be inefficient (i.e., unpredictable timing).

That is well-known. My point is, those attempts at producing
(quasi)deterministic algorithms usually work at the expense
of wasting memory (c.a.e)

>> But, I wonder if dynamic changes to the algorithms used
>> by malloc/free can be exploited to provide *application
>> specific* deterministic behavior in certain contexts.
>>
>> E.g., implement malloc(3) more like:
>>
>> malloc(size_t size, int (* selector)(fragment_t *))
>
> What are you implying here? The user seems to be required to supply a
> pointer to a "fragment selector function". What is that supposed to do?

Obviously: select the "best" fragment to fit the request!

>> with similar changes to free(3).
>>
>> Has any work been done in this regard?
>>
>> Or, any work evaluating different algorithms to satisfy
>> requests and releases? I suspect any experiments into
>> this have probably been applied in desktop environments
>> instead...
From: D Yuniskis on 24 Feb 2010 11:33
Hi Vladimir,

Vladimir Vassilevsky wrote:
>
> Have different heaps with different algorithms.

I currently support multiple heaps. The post was intended
to show how *any* heap could support a choice of algorithms
(hence the selector function) -- which could be applied to
a single heap as well as multiple heaps.

>> E.g., implement malloc(3) more like:
>>
>> malloc(size_t size, int (* selector)(fragment_t *))
>>
>> with similar changes to free(3).
>>
>> Has any work been done in this regard?
>>
>> Or, any work evaluating different algorithms to satisfy
>> requests and releases? I suspect any experiments into
>> this have probably been applied in desktop environments
>> instead...
 |  Next  |  Last
Pages: 1 2 3
Prev: Why a file system required in an embedded Device
Next: PHY initialization