Re: [rvm-research] Call-Site Information

Thanks Michael and Jipeng. When porting the patch to my version of
JikesRVM, I (consistently) made sure that nodes are well-formed objects.
So, I do create ReturnAddressNode(s) when constructing the tree, and store
a reference to the leaf node in object's header (which I have trouble
reconstructing towards the end of run). Anyway, somewhere I must have
missed something. For the moment though, I turned to a slightly different
approach. You see, for my purposes, I actually don't need to keep all the
active nodes around. All I need is to assign a unique hash to the context
tree (could be as simple as concatenating the ids of all methods in the
current context), and storing the hash in the object's header. So, I am
good for now. Thanks for your replies.

On Wed, Jul 27, 2016 at 6:26 AM, Jipeng Huang <[email protected]> wrote:

> Yes, Mike is right about it. If you're simply patching with our approach,
> the CCU nodes are not really regular objects but instead raw memory (as
> Mike said, the nodes do not have regular java headers). The extra word we
> added in regular java object and stack framed just simply stores the
> address-like ObjectReference. So when trying to access parent nodes or
> other fields (if you have extended to have), you can use similar approach
> inside NodeOps.
>
> On Tue, Jul 26, 2016 at 11:42 AM, Michael Bond <
> [email protected]> wrote:
>
>> 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]> 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 [email protected]://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]
>>> 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 [email protected]://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>
>


-- 
*Shoaib Akram*
*ELIS - Gent University*
*Belgium*

------------------------------------------------------------------------------

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