Hi,
On 26/10/2008, at 7:39 AM, weiming zhao wrote:
> Hi,
>
> I have two questions about MMTK:
>
> 1) Both the user manual and some posts in this maillist archive say
> that a
> fixed size or a percentage of available virtual memory can be
> specified
> during the construction of a space.
>
> However, when I read the code, I find that the only relevant
> parameter is
> "page budget", which is referenced in Space.acquire ->
> PageResource.reservePages to check if GC is required. So, it's not
> directly
> related with the Space size. Maybe I missed something...
Yes, you can specify the amount of virtual memory for a space. We try
to avoid this as much as possible so as not to tie down virtual
memory. By default, most spaces will be constructed to use
discontiguous space (ie they share virtual memory). However, you can
specify some virtual memory range if you wish using a VMRequest. This
is done by passing an argument to VMRequest.create(). If no argument
is passed, a default discontiguous request handle is created. In
most cases this is what we do.
For an example of where we do pin down virtual memory, at the
constructor for the default space in the NoGC plan. You will see it
is constructed to use 0.6 of all available virtual memory:
VMRequest.create(0.6f);
Note that the above comments will be correct for the 3.0.X releases,
but not necessarily for older releases.
> 2) Besides, when I first tried to implement my own Plan (just for
> study
> purpose), I forgot to override the "getPagesRequired()",
> "getPagesUsed()".
> The result is that it can run successfully even with very small heap
> size
> (specified by Xmx). So it seems that there is no hard limit of the
> heap
> size. it depends on the correct accounting of the plan. Is my
> understanding
> right?
This is a completely different matter.
Here you are talking about how many pages are *consumed* by a space at
any point in time. This is entirely different (strictly less than or
equal) to the amount of virtual memory reserved for a given space.
Virtual memory is reserved ahead of time (it is a static property of a
plan), while the page count is a dynamic property depending on how the
heap is utilized at any point in time.
You need to override getPagesUsed() for your particular plan. This
should add the usage of any space defined in the plan to that in the
super class. Here is the definition for SemiSpace:
public int getPagesUsed() {
return super.getPagesUsed() + toSpace().reservedPages();
}
You also *may* need to override getPagesAvail() for your particular
plan. In the case of SemiSpace, we must account for a copy reserve
(ie a 2 X space overhead), so getPagesAvail() for SemiSpace is defined
thus:
public final int getPagesAvail() {
return(super.getPagesAvail()) >> 1;
}
If you don't have a copy reserve or any other such special requirement
for your plan, then you don't need to override getPagesAvail().
--Steve
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers