Re: [rvm-research] Call-Site Information

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