From: Chin-Yang L. <to...@ma...> - 2005-11-05 14:27:37
|
Hello, How=20does=20RVM=20decide=20to=20trigger=20GC,=20except=20for=20invoking=20S= ystem.gc()?=20=20 What=20is=20the=20difference=20between=20the=20options=20"-Xms20=20-Xmx120"=20= and=20"-Xms120=20-Xmx120"?=20Does=20the=20former=20have=20more=20opportuniti= es=20for=20triggering=20GC? Thanks=20&=20Regards, tomy |
From: Eliot M. <mo...@cs...> - 2005-11-05 14:47:46
|
>>>>> "Chin-Yang" == Chin-Yang Lin <to...@ma...> writes: Chin-Yang> How does RVM decide to trigger GC, except for invoking Chin-Yang> System.gc()? Chin-Yang> What is the difference between the options "-Xms20 -Xmx120" Chin-Yang> and "-Xms120 -Xmx120"? Does the former have more Chin-Yang> opportunities for triggering GC? Basically, it will trigger GC when some allocation area fills up. There is no single GC in Jikes RVM, so to answer your question much more specifically would require knowing which GC you built into your system. However, assuming the command line parameters you gave are obeyed by the given GC, the former says "start with a heap size of 20 Mb and allow it to grow to 120 Mb", while the latter says "start with 120 Mb and the max is 120 Mb". What might happen in the former case is that some number of GCs would be required in order to grow from 20 Mb to 120 Mb -- assuming the GC's policy is to grow. If the percentage of space reclaimed at 20 Mb is very high, then it might not grow, since using a large heap size may not make that much difference in overall running time. If the percentage reclaimed is somewhat lower, then it might grow. In the second case, you've told it a particular size, and it might just use that size. Thus, I would expect that the second set of flags might result in fewer GCs, and would be surprised it they led to MORE GCs, than the first set of flags. If you ask your question in the context of a particular GC / configuration, then someone might be able to give you a more precise answer. Also, it is usually possible to obtain some log information for the GC component, telling you how many GCs it did, and even to get a log entry for each GC performed. Best wishes -- Eliot |
From: Robin G. <rob...@an...> - 2005-11-05 22:59:40
|
>>>>>> "Chin-Yang" == Chin-Yang Lin <to...@ma...> writes: > > Chin-Yang> How does RVM decide to trigger GC, except for invoking > Chin-Yang> System.gc()? > > Chin-Yang> What is the difference between the options "-Xms20 -Xmx120" > Chin-Yang> and "-Xms120 -Xmx120"? Does the former have more > Chin-Yang> opportunities for triggering GC? ... > If you ask your question in the context of a particular GC / > configuration, > then someone might be able to give you a more precise answer. Also, it is > usually possible to obtain some log information for the GC component, > telling you how many GCs it did, and even to get a log entry for each GC > performed. Try -X:gc:verbose=1 for basic information about when GC occurs, or -X:gc:verbose=3 to see what happens in each area of the heap. cheers |
From: Sean C. <m94...@ma...> - 2008-03-26 13:19:49
|
Eliot Moss wrote: > > > Basically, it will trigger GC when some allocation area fills up. There is > no single GC in Jikes RVM, so to answer your question much more > specifically would require knowing which GC you built into your system. > > > If you ask your question in the context of a particular GC / > configuration, > then someone might be able to give you a more precise answer. > I want to know when to trigger GC in "refcount" of JikesRVM-2.9.1. I searched the previous messages, and found this queston about triggering GC. Can anyone help me? sean Eliot Moss wrote: > > so, it is > usually possible to obtain some log information for the GC component, > telling you how many GCs it did, and even to get a log entry for each GC > performed. > > > > > > -- View this message in context: http://www.nabble.com/When-to-trigger-GC-in-RVM--tp1348621p16300891.html Sent from the jikesrvm-researchers mailing list archive at Nabble.com. |
From: Eliot M. <mo...@cs...> - 2008-03-26 15:36:29
|
Sean -- I'm not sure if you're asking "In the built-in refcount collector, when does it trigger GC?" or "If I build my own refcount collector, when *should* it trigger GC?", but the answer is probably not all that different. Disclaimer: I am not up on the details of the latest form of these collectors. A ref counting collector most commonly uses a free list from which to allocate, since it will free objects in place and generally not move objects that are still reachable. Jikes RVM maintains a free list for each of a number of sizes. Object sizes get rounded up a little, to reduce the number of size categories some. Objects larger than a certain size are handled separately. A typical scheme breaks the whole space up into *blocks*. When a particular size is requested, and there are no free objects of that size (i.e.., that size's free list is empty), the allocator tries to get a block from the block allocator. If it succeeds, then it breaks the block up into objects of the given size, putting them onto the free list, allocates one of them, and continues. If it cannot get a block, it triggers GC. Large objects request one or more contiguous blocks. If the request cannot be satisfied, the allocator requests GC. I don't know what other schemes are readily available in Jikes RVM, but it is possible to use bump pointer style allocation (slicing objects off a large chunk, one at a time, without regard to individual size (except really large objects still probably get special treatment)). Collection puts small chunks on the appropriate free list, and larger ones can be reallocated in bump pointer style. But the general principle still applies: when you can't satisfy an allocation request, you trigger GC. Of course one can set things up to allow specific requests from the program to do a GC to be honored, and that also will trigger. But these are basic principles of GC. I'm wondering why you're asking. Are you new to GC or are you getting at something more subtle? What is it that you expected or desired to happen? -- Eliot |
From: Eliot M. <mo...@cs...> - 2008-03-28 10:51:40
|
Since the primary allocation compress does is large buffers, I suspect it is Large Object Space (LOS) that is running out for some reason. Increasing the overall heap size will not help unless LOS is increased. Steve B or someone with more recent familiarity with MMTk details can probably give a more precise answer. -- Eliot |
From: Yan T. <ta...@cs...> - 2008-03-26 16:11:38
|
Sean, GC is triggered when the application tries to request more memory. It usually in the implementation of "new" function. I remember there is a "poll" function in that part of codes. If "poll" finds that memory pressure is high, then, it will pause current "new" request, and first do a GC. Otherwise, direct allocate memory space for the request. There is also two parts of codes. One is slow_alloc, and the other is fast_alloc. You can search the coes. Thanks. Yours, Yan Tang On Wed, Mar 26, 2008 at 9:19 AM, Sean Cheng <m94...@ma...> wrote: > > > Eliot Moss wrote: > > > > > > Basically, it will trigger GC when some allocation area fills up. There > is > > no single GC in Jikes RVM, so to answer your question much more > > specifically would require knowing which GC you built into your system. > > > > > > If you ask your question in the context of a particular GC / > > configuration, > > then someone might be able to give you a more precise answer. > > > > I want to know when to trigger GC in "refcount" of JikesRVM-2.9.1. > I searched the previous messages, and found this queston about triggering > GC. > Can anyone help me? > > sean > > > Eliot Moss wrote: > > > > so, it is > > usually possible to obtain some log information for the GC component, > > telling you how many GCs it did, and even to get a log entry for each GC > > performed. > > > > > > > > > > > > > > -- > View this message in context: > http://www.nabble.com/When-to-trigger-GC-in-RVM--tp1348621p16300891.html > Sent from the jikesrvm-researchers mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |
From: Sean C. <m94...@ma...> - 2008-03-28 08:17:04
|
Eliot Moss wrote: > > Sean -- I'm not sure if you're asking "In the built-in refcount collector, > when > does it trigger GC?" or "If I build my own refcount collector, when > *should* it > trigger GC?", but the answer is probably not all that different. > Yes, I want to ask about the "build-in refcount collector" in MMTK of JikesRVM-2.9.1. When I use FastAdaptiveRefcount configuration to run "_201_compress" of SPECjvm98, there is always a problem about "out-of-memory" error. For example: I am using 100MB, 128MB, and 150MB. [root@sepc08 cdrom]# rvm -Xmx100M -Xms100M -X:gc:verbose=1 SpecApplication _201_compress [Forced GC][GC 1 Start 0.16 s 11076KB -> 10436KB 52.42 ms] Caching Off Speed = 100 ======= _201_compress Starting ======= Run 0 start. Total memory=104857600 free memory=94158848 Loop count = 5 3153920 931067 2856960 1132510 962560 688827 1280000 591635 1157120 368657 3153920 931067 2856960 1132510 962560 688827 1280000 591635 1157120 368657 3153920 931067 2856960 1132510 962560 688827 1280000 591635 1157120 368657 3153920 931067 2856960 1132510 962560 [GC 2 Start 4.97 s 102504KB (CD 120.57 ms)-> 99936KB 242.53 ms] 688827 [GC 3 Start 5.36 s 102652KB (CD 42.41 ms)-> 95156KB 62.14 ms] 1280000 591635 1157120 [GC 4 Start 5.58 s 98312KB 269.09 ms)-> 98264KB 64.16 ms] [GC 5 Start 5.65 s 98264KB (CD 48.23 ms)-> 98260KB 66.42 ms] >>>> spec.benchmarks._201_compress.Main exited with exception: >>>> java.lang.OutOfMemoryError <<<< java.lang.OutOfMemoryError at spec.benchmarks._201_compress.Compressor$Hash_Table.<init>(Compress.java:0) at spec.benchmarks._201_compress.Compressor.<init>(Compress.java:0) at spec.benchmarks._201_compress.Compress.spec_select_action(Compress.java:0) at spec.benchmarks._201_compress.Harness.run_compress(Harness.java:0) at spec.benchmarks._201_compress.Harness.inst_main(Harness.java:0) at spec.benchmarks._201_compress.Main.runBenchmark(Main.java:0) at spec.benchmarks._201_compress.Main.harnessMain(Main.java:0) at spec.harness.ProgramRunner.runOnce(ProgramRunner.java:382) at spec.harness.ProgramRunner.runBenchmark2(ProgramRunner.java:306) at spec.harness.ProgramRunner.runBenchmark(ProgramRunner.java:238) at spec.harness.ProgramRunner.run(ProgramRunner.java:206) at spec.harness.RunProgram.run(RunProgram.java:60) at SpecApplication.runBenchmark(SpecApplication.java:255) at SpecApplication.main(SpecApplication.java:171) Exception in thread "main": java.lang.NullPointerException at SpecApplicationRunner.benchmarkDone(SpecApplication.java:281) at spec.harness.ProgramRunner.runBenchmark(ProgramRunner.java:244) at spec.harness.ProgramRunner.run(ProgramRunner.java:206) at spec.harness.RunProgram.run(RunProgram.java:60) at SpecApplication.runBenchmark(SpecApplication.java:255) at SpecApplication.main(SpecApplication.java:171) [End 5.71 s] ******************************************************* [root@sepc08 cdrom]# rvm -Xmx128M -Xms128M -X:gc:verbose=1 SpecApplication _201_compress [Forced GC][GC 1 Start 0.16 s 11076KB -> 10436KB 52.27 ms] Caching Off Speed = 100 ======= _201_compress Starting ======= Run 0 start. Total memory=134217728 free memory=123518976 Loop count = 5 3153920 931067 2856960 ... 2856960 1280000 591635 1157120 [GC 2 Start 5.33 s 107644KB -> 105984KB 104.45 ms] [GC 3 Start 5.44 s 105984KB -> 104472KB 17.50 ms] >>>> spec.benchmarks._201_compress.Main exited with exception: >>>> java.lang.OutOfMemoryError <<<< java.lang.OutOfMemoryError at spec.benchmarks._201_compress.Compressor$Hash_Table.<init>(Compress.java:0) at spec.benchmarks._201_compress.Compressor.<init>(Compress.java:0) at spec.benchmarks._201_compress.Compress.spec_select_action(Compress.java:0) ... ************************************************** [root@sepc08 cdrom]# rvm -Xmx150M -Xms150M -X:gc:verbose=1 SpecApplication _201_compress [Forced GC][GC 1 Start 0.15 s 11076KB -> 10436KB 52.73 ms] Caching Off Speed = 100 ======= _201_compress Starting ======= Run 0 start. Total memory=157286400 free memory=146587648 Loop count = 5 3153920 931067 2856960 1132510 962560 688827 ... 1280000 591635 1157120 [GC 2 Start 5.27 s 108668KB -> 106860KB 112.74 ms] [GC 3 Start 5.39 s 106860KB -> 105100KB 17.53 ms] >>>> spec.benchmarks._201_compress.Main exited with exception: >>>> java.lang.OutOfMemoryError <<<< java.lang.OutOfMemoryError at spec.benchmarks._201_compress.Compressor$Hash_Table.<init>(Compress.java:0) at spec.benchmarks._201_compress.Compressor.<init>(Compress.java:0) at spec.benchmarks._201_compress.Compress.spec_select_action(Compress.java:0) at spec.benchmarks._201_compress.Harness.run_compress(Harness.java:0) at spec.benchmarks._201_compress.Harness.inst_main(Harness.java:0) ... Exception in thread "main": java.lang.NullPointerException at SpecApplicationRunner.benchmarkDone(SpecApplication.java:281) at spec.harness.ProgramRunner.runBenchmark(ProgramRunner.java:244) at spec.harness.ProgramRunner.run(ProgramRunner.java:206) at spec.harness.RunProgram.run(RunProgram.java:60) at SpecApplication.runBenchmark(SpecApplication.java:255) at SpecApplication.main(SpecApplication.java:171) [End 5.41 s] *************************************************************************** They all stop at 106MB, whatever the specification heap size is. There are enough memory for the system, but the system trigger GC continually instead of increasing memory usage. And finally caused 'out-of-memory'. So I want to know the reasons why will GC be triggered. To my knowledge, if the heap is close to full, then GC will be triggered. Is there any other reason that will trigger GC? Are the fullness of decBuffer or "purple buffer" related to triggering GC? Eliot Moss wrote: > > > > > But these are basic principles of GC. I'm wondering why you're asking. Are > you > new to GC or are you getting at something more subtle? What is it that you > expected or desired to happen? > > -- Eliot > > -- View this message in context: http://www.nabble.com/When-to-trigger-GC-in-RVM--tp1348621p16347601.html Sent from the jikesrvm-researchers mailing list archive at Nabble.com. |
From: Nagy M. <nag...@gm...> - 2008-03-31 07:33:10
|
Hi, I am trying to implement a path profiler under Arnold-Ryder's framework. My profiler works fine outside of the framework, but when I enable it, the update of the path register goes wrong and ends up with strange path IDs. I tried debugging my code by inserting probes right before and after each update (either a move or add instruction) that logs the value of the path register. I found out that for some reason the path register is set to some weird value every now and then that is not cause by any of the moves or adds I inserted. I dumped the LIR for one of the problematic methods and it seems fine. I use ir.regpool.makeTempInt() for allocating the path register and r.copyRO() when using it as an operand. I am not sure if I need to do something else when allocating a register. Also, I instrument in the HIR. Again, the problem only occurs when enabling the instrumentation sampling framework. Anyone ran into something similar ? thanks, Nagy Mostafa CS Dept., UCSB |
From: Michael B. <mik...@cs...> - 2008-03-31 16:43:28
|
Hi Nagy, My guess is that the beginnings and ends of paths do not correspond to the switch points of the Arnold-Ryder framework. The Arnold-Ryder framework switches between uninstrumented instrumented code at yieldpoints, so if a path crosses a yieldpoint, then only some of the instrumentation for that path will execute. For example, suppose we're in uninstrumented code, then initialization of the path register (r=0) wouldn't execute, then the framework could switch to instrumented code, then path register increments (r+=c) and path updates (count[r]++) would execute, leading to invalid path values. Combining Ball-Larus path profiling with the Arnold-Ryder framework is problematic since some Ball-Larus paths will naturally cross yieldpoints (e.g., the path from BEGIN to END). In general, using sampling with path profiling is tricky since paths include a bit of program history rather than being a single point like a basic block. In previous work called PEP (suggested by Dave Grove in a previous response), Kathryn McKinley and I showed that it's cheap (1% overhead) to use all-the-time instrumentation for path register initialization and increments (r=0, r+=c), so sampling only needs to be applied to path updates (count[r]++). I wonder if this approach would work okay for what you're doing? The PEP implementation is available on the Jikes RVM Research Archive. We used the regular yieldpoint-based sampling mechanism to sample path updates (plus Arnold-Grove sampling to adjust the sampling rate and reduce timing bias), but you could instead apply the Arnold-Ryder framework to just path updates to get the same effect. On the other hand, if you're set on applying the Arnold-Ryder framework to all path profiling instrumentation, you might consider using a variant of it called bursty tracing by Martin Hirzel and Trishul Chilimbi. Bursty tracing also switches between uninstrumented and instrumented code, but when it enters uninstrumented code, it stays in it for longer than just until the next yieldpoint. cheers, Mike On Mon, 31 Mar 2008, Nagy Mostafa wrote: > Hi, > I am trying to implement a path profiler under Arnold-Ryder's framework. > My profiler works fine outside of the framework, but when I enable it, > the update of the path register goes wrong and ends up with strange path > IDs. I tried debugging my code by inserting probes right before and > after each update (either a move or add instruction) that logs the value > of the path register. I found out that for some reason the path register > is set to some weird value every now and then that is not cause by any > of the moves or adds I inserted. I dumped the LIR for one of the > problematic methods and it seems fine. I use ir.regpool.makeTempInt() > for allocating the path register and r.copyRO() when using it as an > operand. > > I am not sure if I need to do something else when allocating a register. > Also, I instrument in the HIR. Again, the problem only occurs when > enabling the instrumentation sampling framework. > > Anyone ran into something similar ? > > thanks, > Nagy Mostafa > CS Dept., UCSB > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |