Re: [rvm-research] Call-Site Information

Hi Shoaib,

I believe that, by default, CCU nodes are not actually well-formed 
objects: they don't actually have a header, which allows them to be only 
2 words instead of 4 words. The CCU patch contains a class called 
ReturnAddressNode because there's an option to instead use well-formed 
objects (with a header, i.e., 4 words instead of 2 words), but that 
option is off by default. So I think you should avoid casting CCU nodes 
to ReturnAddressNode (or to any other type), and instead treat them as 
raw memory. There should be existing code paths, enabled by default, 
that show how to access these raw memory "objects."

But that's just my best guess based on incomplete and forgotten 
understanding. Jipeng Huang (CCed), the primary CCU author and 
developer, will likely have more and better ideas. :)

Cheers,
Mike

On 07/26/2016 11:09 AM, Shoaib Akram wrote:
> Hi Michael,
>
> I am porting some features of your calling context profiling patch to 
> my version of JikesRVM (ver. 3.1.2). I am using the generational 
> mark-sweep collector with a 4 MB nursery space, and a very large 
> mature space. I log a reference to every object in mature space in a 
> SanityTable, along with some other statistics. The idea is to relate 
> the statistics to each object's context-sensitive origin, i.e., point 
> in the program where the object was created. There are two major steps 
> to accomplish this following your patch.
>
> First, I reserved space for an extra word in each method's stack frame 
> (to store a reference to an instance of ReturnAddressNode). Second, 
> whenever a new object is created, I (lazily) construct the context 
> tree, and store a reference to the leaf node in the object's header at 
> ALLOC_SITE_OFFSET.
>
> To do the first, I made all the required changes including: (1) 
> instrumenting the prologue and epilogue in BaselineCompiler, (2) 
> Adjusting the offsets (and defining CCU_VALUE_OFFSET) in 
> StackframeLayoutConstants.java, and (3) adding the necessary 
> instrumentation to JNICompiler, MachineSpecificIA, and 
> OutOfLineMachineCode.
>
> For the second part of constructing the tree, I instrument the 
> compilers (both baseline and opt) to call 
> initAllocSiteContextSensitive() in allocSites/AllocSitesInstr.java. At 
> run-time, the idea is to grab the ReturnAddressNode from the 
> constructReturnAddressNode() method in ccu/Instr.java and use the 
> ObjectFieldWrite() utility to store a reference to the returned node 
> in the object's header at ALLOC_SITE_OFFSET.
>
> I am facing two problems when I do all this: (1) Trying to cast the 
> object referenced by the memory located at offset CCU_VALUE_OFFSET in 
> method's stack frame to ReturnAddressNode results in a hardware trap. 
> For instance, the following line is problematic.
>
> ReturnAddressNode node = 
> (ReturnAddressNode)fp.loadObjectReference(Offset.fromIntSignExtend(StackframeLayoutConstants.CCU_VALUE_OFFSET)).toObject();
>
> but the one below is not.
>
> Object node = 
> fp.loadObjectReference(Offset.fromIntSignExtend(StackframeLayoutConstants.CCU_VALUE_OFFSET)).toObject();
>
> Ok, so I can get around it by not touching anything at 
> CCU_VALUE_OFFSET in the method's frame, and creating a context tree 
> from scratch each time an object is created. Basically, grab the frame 
> pointer of current method, and create all the nodes until encountering 
> the method with INVISIBLE_METHOD_ID. Right after storing the leaf node 
> in object's header, I can print the context using various print 
> utilities in NodeOps. So, things are set up propelry.
>
> But, towards the end of the benchmark's run, right before printing the 
> statistics, when I try to access the ReturnAddressNode whose reference 
> I stored in the object's header at ALLOC_SITE_OFFSET, I again have the 
> same problem. I can load the address (or reference) I stored at 
> ALLOC_SITE_OFFSET, but should I try to access the return address 
> stored in the object, or try to access its parent node, or even cast 
> the object referred by that location to ReturnAddressNode, it results 
> in a hardware trap. Reading the fields of objects using offsets 
> (avoiding the cast) results in the same problem.
>
> It appears that I am violating some assumptions regarding what memory 
> is accessible from different part of JikesRVM. Are the 
> ReturnAddressNodes lost by the time I try to access them? Probably not 
> since I am using the ObjectFieldWrite() and not 
> Magic.setObjectAtOffset() to store the reference in object's header. 
> Am I miss something in both cases?
>
> Regards,
> Shoaib.
>
> On Wed, May 25, 2016 at 4:10 AM, Michael Bond 
> <[email protected] <mailto:[email protected]>> wrote:
>
>     Hi Shoaib,
>
>     Yes, this is definitely possible. There are two different ways to
>     do it:
>
>     (1) Insert instrumentation at compile time that "knows" the static
>     allocation site. For example, during compile time, assign a unique
>     integer for every allocation site, and generate instrumentation
>     that writes that integer into the object header.
>
>     (2) Insert instrumentation at compile time that figures out the
>     allocation site at run time. It can do this by looking at the
>     frame pointer and compiled method ID as you say; it gets a little
>     bit complex with optimized code and inlining.
>
>     My group's patch for calling context profiling
>     (https://sourceforge.net/p/jikesrvm/research-archive/44/) has code
>     related to both approaches.
>
>     One gotcha: There's an issue in Jikes RVM (<=3.1.3, at least) such
>     that if the left-most word (by default, this'll be the MiscHeader
>     word) has the least-significant bit as 1 instead of 0, Jikes RVM
>     will crash (at least with certain GCs?). You can avoid this by
>     making sure it's always 0 or by putting the MiscHeader to the
>     right of the TIB pointer; see our Octet patch for an example of
>     the latter (https://sourceforge.net/p/jikesrvm/research-archive/43/).
>
>     Regarding your question about calling into Jikes RVM from MMTk:
>     this is definitely possible, but it's required to go through a
>     specific interface. See classes in org.mmtk.vm such as
>     org.mmtk.vm.Barriers (an abstract method that has a Jikes
>     RVM-specific implementation). You can add your own method to own
>     of the these classes; the method can access Jikes RVM stuff but be
>     called from MMTk.
>
>     Cheers,
>     Mike
>
>
>     On 05/24/2016 02:28 PM, Shoaib Akram wrote:
>>     Hi All,
>>
>>     Hello from PerformanceLab @ Ghent University in Belgium. I want
>>     to ask if there is support in JikesRVM to identify the call-site
>>     of an allocation. Suppose I have the code below:
>>
>>     1  public IntersectionState() {
>>     2       stack = new StackNode[MAX_STACK_SIZE * 2];
>>     3      for (int i = 0; i < stack.length; i++)
>>     4            stack[i] = new StackNode();
>>     5        rstack = new float[53 * 256];
>>     6    }
>>
>>     Each time a new object is allocated (line no. 4 above), I want to
>>     store the call-site information (line 4) in the header of the
>>     object. Is it possible to get the unique identity of the method
>>     and index within the method, where a new object is being
>>     allocated from?
>>
>>     There are some routines in runtime/Magic.java that let you get
>>     the current frame pointer or the id of the compiled method, but I
>>     am not sure if they usable from within MMTk(?) Does anyone know
>>     an an easy way to get the site information at allocation time?
>>
>>     Thanks in advance!
>>
>>     -- 
>>     *Shoaib Akram*
>>     *ELIS - Gent University*
>>     *Belgium*
>>
>>
>>     ------------------------------------------------------------------------------
>>     Mobile security can be enabling, not merely restricting. Employees who
>>     bring their own devices (BYOD) to work are irked by the imposition of MDM
>>     restrictions. Mobile Device Manager Plus allows you to control only the
>>     apps on BYO-devices by containerizing them, leaving personal data untouched!
>>     https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>>
>>
>>     _______________________________________________
>>     Jikesrvm-researchers mailing list
>>     [email protected]
>>     <mailto:[email protected]>
>>     https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>
>
>     ------------------------------------------------------------------------------
>     Mobile security can be enabling, not merely restricting. Employees who
>     bring their own devices (BYOD) to work are irked by the imposition
>     of MDM
>     restrictions. Mobile Device Manager Plus allows you to control
>     only the
>     apps on BYO-devices by containerizing them, leaving personal data
>     untouched!
>     https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>     _______________________________________________
>     Jikesrvm-researchers mailing list
>     [email protected]
>     <mailto:[email protected]>
>     https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>
>
>
>
> -- 
> *Shoaib Akram*
> *ELIS - Gent University*
> *Belgium*
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
>
>
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev

_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers