about specifying GC space size and heap size
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
 |
about specifying GC space size and heap size
by weiming zhao
::
Rate this Message:
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... 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? Thanks a lot! |
|
|
Re: [rvm-research] about specifying GC space size and heap size
by Steve Blackburn
::
Rate this Message:
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 > > > Thanks a lot! > -- > View this message in context: http://www.nabble.com/about-specifying-GC-space-size-and-heap-size-tp20167730p20167730.html > Sent from the jikesrvm-researchers mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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 |
|
|
Re: [rvm-research] about specifying GC space size and heap size
by weiming zhao
::
Rate this Message:
Hi Steve,
Very appreciate for your detailed explanation. So, for 1), does it mean that, by default, without explicitly specifying the space size via VMRequest(), the space size is dynamic. It can grow as required until reaches the limit of the whole heap? for 2), "Xmx" specifies the virtual address space of the heap. When the virtual machine starts, it reserves the virtual address space via ways like "mmap". When a space requests for pages, it asks for physical memory from OS and maps them to the virtual address space (is it done by Mmapper.ensureMapped()? ). If we don't maintain the accounting correctly, virtual address conflicts may occur. Above is my understanding. Please correct me if I'm wrong. BTW, I also tried the MMTK harness mentioned in the WIKI. It's convenient and powerful. But I'm not sure if it can be used to debug the MMTK step by step in Eclipse. I set some breakpoints in my own GC plan, then run the harness in Eclipse, but the program doesn't stop. Is it normal or I missed some setting? Thanks a lot! On Sat, Oct 25, 2008 at 5:23 PM, Steve Blackburn <Steve.Blackburn@...> wrote: Hi, ------------------------------------------------------------------------- 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 |
|
|
Re: [rvm-research] about specifying GC space size and heap size
by Steve Blackburn
::
Rate this Message:
On 26/10/2008, at 9:40 AM, weiming zhao wrote: for 1), does it mean that, by default, without explicitly specifying the space size via VMRequest(), the space size is dynamic. It can grow as required until reaches the limit of the whole heap? Yes.
No. It specifies how much memory may be used, it has nothing to do with address spaces. When the virtual machine starts, it reserves the virtual address space via ways like "mmap". When a space requests for pages, it asks for physical memory from OS and maps them to the virtual address space (is it done by Mmapper.ensureMapped()? ). MMTk accounts for page usage abstractly. It keeps track of how many pages are in use. It may have more pages mmapped than "in use". The amount that matters for GC triggering etc is the amount "in use". If we don't maintain the accounting correctly, virtual address conflicts may occur. No. This is orthogonal. Virtual address conflicts are entirely unrelated to accounting for pages. If you are having virtual address conficts between Jikes RVM and the libraries, you may need to modify the config file for your build target (build/target/xxx.properties). In particular, the *.address= lines. If you are having virtual address conflicts *within* Jikes RVM, this is a bug, either in your plan, or possibly in MMTk. Above is my understanding. Please correct me if I'm wrong. BTW, I also tried the MMTK harness mentioned in the WIKI. It's convenient and powerful. But I'm not sure if it can be used to debug the MMTK step by step in Eclipse. I set some breakpoints in my own GC plan, then run the harness in Eclipse, but the program doesn't stop. Is it normal or I missed some setting? I understand that you can do this, but I don't know for sure. I will let Robin or Daniel reply. --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 |
|
|
Re: [rvm-research] about specifying GC space size and heap size
by Daniel Frampton
::
Rate this Message:
To answer your question about the harness: Provided you are running a test that triggers a collection (and you run it in debug mode) then it should stop at breakpoints for you.
The only argument required is the path to the test-script. The OutOfMemory script should definitely cause a collection.
Other options you can find in the options package. One of the most important is the plan=XXX option which gives the prefix to find all the plan classes. The default is "org.mmtk.plan.marksweep.MS".
Cheers,
Daniel.
On Sun, Oct 26, 2008 at 10:00 AM, Steve Blackburn <Steve.Blackburn@...> wrote:
------------------------------------------------------------------------- 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 |
|
|
Re: [rvm-research] about specifying GC space size and heap size
by weiming zhao
::
Rate this Message:
Hi Daniel,
Thanks for your reply. Yes, it just works now. But last night, it didn't work. (maybe I stayed up too late last night and got some illusions. :D) Thanks, Weiming
On Sun, Oct 26, 2008 at 12:11 AM, Daniel Frampton <zyridium@...> wrote:
------------------------------------------------------------------------- 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 |
| Free embeddable forum powered by Nabble | Forum Help |
