[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

memory management

From: Neal H. Walfield
Subject: memory management
Date: Thu, 26 Jun 2008 15:57:03 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shij┼Ź) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Thu, 26 Jun 2008 13:32:53 +0200,
Bas Wijnen wrote:
> > As long as there is memory available, memory allocations are granted.
> I understand from your explanation that any activity can reserve some
> memory, and it can claim as much memory as it likes, as long as it is
> available.  Then when memory is exhausted, some activity's memory will
> be shrunk, but never further than the reserved amount.  Is that correct?
> Does an activity for which the allocation is shrunk get a notification
> and can it somehow save the contents?  Or should every page which is not
> reserved be considered cache which can disappear without notice?

Memory is transparently multiplexed in the usual Unix fashion.  One
key advantage that Viengoos offers is that it is possible to guide the
eviction decision.

A policy can be associated with a frame of memory.  This is done at
access time by copying the policy stored in the capability into the
frame.  The policy that is stored in the capability is saved alongside
the frame.  By not storing the policy in the object but in the
capability, any user of an object can control the management policy of
the associated memory--even read-only users (although they cannot set
the discardable bit).  The policy consists of a priority and a
discardability predicate.

When Viengoos selects a page to evict from an activity, it chooses the
page with the lowest priority.  If there are multiple pages with the
lowest priority, it selects the one that was least recently used.

The discardability predicate allows a program to indicate that the
page can simply be discarded.  When such a frame is choosen for
eviction, it is immediately enqueued on the available list.  When it
is reused, the fact that it was discarded is noted.  The next time the
object is accessed, the accessing thread receives a discarded
activation allowing it to take appropriate action, e.g., regenerating
the content.

When calculating the availability, Viengoos also considers allocation
trends.  If a lot of memory is being allocated and an activity has
more than its fair share, the amount of available memory will be
decreased.  This enables proactive (as opposed to reactive

reply via email to

[Prev in Thread] Current Thread [Next in Thread]