Re: [rvm-research] How to record objects' read/write times

On 24/05/15 20:16, 王晨曦 wrote:
> Thanks for Robin and Eliot 's heap!
>
> This problem is complex and I don't make it clear. When I make
> progress  ,I will post it here.
>
> Now I'm working on some basic problems. And one of these problems is
> how to confirm the nurser's size.( in GenImmix config )

By default MMTk's generational plans use a bounded Appel-style nursery 
[1].  At the end of each collection, the nursery size is set to 1/2 the 
available heap size, rounded down to the configured maximum.  As the 
mature space grows, the heap size shrinks until a major collection is 
triggered and the nursery grows again.  We find this gives the best 
throughput, while the maximum nursery size bounds the time for a nursery GC.

This calculation is actually done implicitly in Space#acquire, Plan#poll 
and Gen#collectionRequired.

> I want to know the nursery(CopySpace)'s  exact size when the jikesrvm
> is running.  So I insert some Log.writeln into the source code.

This is actually a difficult question to answer, because we don't 
explicitly calculate the size of a space.  What we have is several 
spaces, all competing for the available virtual memory, both by 
allocating it to the VM, and by reserving it for a copy reserve, or for 
fragmentation overheads etc.

The calculation that is performed each time Space#acquire is called is: 
if we satisfy this allocation request, then can we *guarantee* that 
there will there be enough memory to collect the heap next time we make 
a global allocation request, without violating the heap size constraints.

For example, at the end of a collection there may be 64MB of free heap, 
so you could say that at this point in time the nursery is 32MB in size, 
and if all objects are allocated in the nursery then by the next 
collection there would be 32MB of nursery space consumed.  On the other 
hand, if (say) a 10MB object was allocated in the Large Object Space, 
then at next collection there would be less than 27MB of objects in the 
nursery space.

As a second example, each thread allocates a local buffer (32K I think) 
of nursery space when it allocates using a BumpPointer, so if 128 
threads allocate a single 12 byte object and one thread allocates the 
remainder, by the time of the next collection, nearly 4MB of memory will 
be committed but unallocated by the (almost) idle threads, plus 4MB of 
copy reserve that can never be used.

As a third example, in the GenCopy collector, pretenuring objects into 
the mature space will reserve the allocated size plus a 100% copy 
reserve, again subtracting space from the nursery.

And so on.

>
> The  x86_64-linux.properties content is:
>
>   13 target.arch=ia32
>   14 target.os=Linux
>   15 target.bootimage.code.address=0x64000000
>   16 target.bootimage.data.address=0x60000000
>   17 target.bootimage.rmap.address=0x67000000
>   18 #target.max-mappable.address=0xb0000000
>   19 target.max-mappable.address=0xa0000000
>   20 target.address.size=32
>   21 target.dll-ext=.so
>   22 target.dll-prefix=lib
>   23 target.jni-suffix=${target.dll-ext}
>   24 target.arch.sse2=full
>   25 target.arch.hw_fsqrt=true
>
>
> I insert some Log.writeln in the CopyLocal.java
>
>    public CopyLocal(CopySpace space) {
>      super(space, true);
>
>      //debug
>      Log.writeln("In CopyLocal");
>      Log.writeln("heap start:"+space.HEAP_START.toLong());
>      Log.writeln("heap end:"+space.HEAP_END.toLong());
>      Log.writeln("heap name:"+space.getName());
>      Log.writeln("nursery space start:"+space.getStart().toLong());
>      Log.writeln("nursery space extent:"+space.getExtent().toLong());
>    }

While you can get away with this in the constructor, you wouldn't be 
able to put this code in any normal method.

>
> I got the output as below:
>
>     2 In CopyLocal
>     3 heap start:1610612736  //0x6000 0000
>     4 heap end:2684354560  // 0xA000 0000
>     5 heap name:nursery
>     6 nursery space start:2537553920  //0x9740 0000
>     7 nursery space extent:146800640   //0x8c00 0000
>
>
> The heap size is matching to the config in the x86_64-linux.properties
> (1G) ; and the nursery size is 15% of the heap (140M),  just as the
> NURSERY_VM_FRACTION = 0.15f;
>
> And I know this is just  the limit of the heap size and nursery size
> ,not the exact size when the jikesRVM is running. So I insert some
> other Log.writeln into the function " public void
> collectionPhase(short phaseId)" in Gen.java , see below:
>
>
>    public void collectionPhase(short phaseId) {  //Initialize?  every
> phase need to be  initialized ??
>
>      if (phaseId == SET_COLLECTION_KIND) {
>        super.collectionPhase(phaseId);
>        gcFullHeap = requiresFullHeapCollection(); // gcFullHeap is a
> boolean, what's the flag use for ?
>        return;
>      }
>
>      if (phaseId == PREPARE) {
>
>      Log.writeln("In Gen.java/PREPARE");
>      Log.writeln("nursery lowerbound:"+Options.nurserySize.getMinNursery());
>      Log.writeln("nursery uppperbound"+Options.nurserySize.getMaxNursery());

I'm not sure how this code is working, because you can't do string 
concatenation in MMTk code, nor can you do the implicit conversion from 
long to String that this expression performs. You need to write this as:

 >      Log.writeln("In Gen.java/PREPARE");
 >      Log.write("nursery lowerbound: ");
 >      Log.writeln(Options.nurserySize.getMinNursery());
 >      Log.write("nursery uppperbound: ");
 >      Log.writeln(Options.nurserySize.getMaxNursery());


>
>
> When I run :  rvm
>
> the output is  matching  to the default config :
>
> 2685 In Gen.java/PREPARE
> 2686 nursery lowerbound:512      // 2MB
> 2687 nursery uppperbound8192   // 32MB
>
> 2085 In Gen.java/CLOSURE
> 2086 nursery lowerbound:512
> 2087 nursery uppperbound8192
>
> 2694 In Gen.java/RELEASE
> 2695 nursery lowerbound:512
> 2696 nursery uppperbound8192
>
>
> And I know this is only the config of the option ,not the exact
> nursery size. It's just the upper bound and lower bound.
>
> When I run : rvm -X:gc:fixedNursery=10m  -jar dacapo-9.12-bach.jar h2
>
> The output is :
>
> 1143 In Gen.java/CLOSURE
> 1144 nursery lowerbound:2560   // 10MB
> 1145 nursery uppperbound2560
>
> 1110 In Gen.java/RELEASE
> 1111 nursery lowerbound:2560
> 1112 nursery uppperbound2560
>
> Yeah, Now the option of the nursery size is fixed 10MB.
>
> My questions are :
>
> 1) I want to know how do the default  parameters pass to the PagesOption.value ?

-X:gc:printOptions on the command line.  Note that options are processed 
left-to-right, and printOptions will show you the value at the given 
point in time.  This means that

rvm -X:gc:printOptions -X:gc:boundedNursery=128M -X:gc:printOptions

will show you the values before and after setting the boundedOptions value.

> I insert Log.writln into the NurserySize and  FixedNursery 's
> constructor ,but print nothing ! And just as above, The
> Options.nurserySize.getMinNursery() output is the default parameters.
> So I think the object  fixedNursery must be built.

The Option objects are created at Build time.  You will see the output 
of these in the BootImageWriterOutput.txt file.

>    public NurserySize() {
>
>      //debug
>      Log.writeln("In NurserySize.java:Init NurserySize");
>
>      boundedNursery = new BoundedNursery();
>      fixedNursery = new FixedNursery(boundedNursery);
>    }
>
>
>    public FixedNursery(BoundedNursery boundedNursery) {
>      super(Options.set, "Fixed Nursery",
>          "Fix the minimum and maximum size of the nursery to this value",
>          Plan.DEFAULT_MIN_NURSERY);
>      this.boundedNursery = boundedNursery;
>
>      //debug
>      Log.writeln("In fixedNursery");
>      Log.writeln("Plan.DEFAULT_MIN_NURSERY"+Plan.DEFAULT_MIN_NURSERY);
>      Log.writeln("Plan.DEFAULT_MIN_NURSERY"+Plan.DEFAULT_MIN_NURSERY);
>    }
>

Parsing of options is done in 
org.jikesrvm.mm.mminterface.MemoryManager#processCommandLineArg.  You 
can print the values at runtime using -X:gc:printOptions.

You can also set loggingChanges=true in OptionSet 
(org.mmtk.utility.options) to track all changes to option values.

>
> 2) If I want to know the exact size of the nursery (GenImmix), Where
> can I insert the Log.writeln ?

See the discussion above - this isn't such a well-defined concept.  The 
best you can do is probably to print out the size of nurserySpace during 
the PREPARE phase of collection.

hope this helps,

Robin

[1] Simple Generational Garbage Collection and Fast Allocation. Andrew 
W. Appel. Software--Practice and Experience 19(2):171-183, February 1989.

>
> Thank you very much.
>
>
>
> On Tue, May 12, 2015 at 12:35 PM, Robin Garner <[email protected]> wrote:
>> On 11/05/15 17:53, 王晨曦 wrote:
>>> Hi,every one
>>>
>>>     I want to record objects' read and write times. As far as I know,
>>> the Write Barrier is inserted before every Pointer update( object
>>> assignment ), so I can modify the Write Barrier to record the
>>> reference  times of the source object. But I know the reference times
>>> is not equal to the write times of the   source object. Such as:
>>>
>>> class a{
>>>     ........
>>> }
>>>
>>> class b{
>>>
>>> a test =new a();
>>>
>>> double array_double[ ];
>>> int   array_int[];
>>>
>>> ....
>>> }
>>>
>>>
>>> and the write barrier will only be inserted before the: (Is this right ?)
>>>
>>> b.test=a ; //pointer update
>>>
>>> but these assignment below will be ignored. But I think these
>>> assignments will contribute the main read/write times.
>>>
>>> for(i=0;i<Const;i++)
>>>      array[i]=...
>>>      array_int[i]===
>>>
>>
>> If you look at the MutatorContext class you will see that there is not
>> just one write barrier, but one per type plus a couple of special cases,
>> so there should be opportunities to instrument every field access.
>>
>> I can't emphasize Eliot's point (3) enough: be very careful of the code
>> you invoke in a barrier.  You need to be certain you don't trigger
>> another barrier, and if you are instrumenting all types you must use the
>> methods in org.mmtk.vm.Barriers to do *all* heap writes.
>>
>> Regards,
>> Robin
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Jikesrvm-researchers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>
>
>


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers