在06-9-3，zouqiong <[EMAIL PROTECTED]> 写道：
I am now doing two things: 1. track accesses to the three things you refer. And just the same implementation as some rt_helper_***, but the following error happens: java.exec: /root/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg_ia32.cpp：1621： void Jitrino::Jet::Compiler::gen_patch(const char*, const Jitrino::Jet::CodePatchItem&): 断言"cpi.target_offset != 0"失败。 abort_handler()
I try to dump the native code generated by the JET use the DBG_DUMP_CODE flag opened, but it seems that it should have liblwdis.so supported? Where can I get the lib? or Is there other ways to see the native code? I want to know some way to find out the reason for it. GDB seems not
helpful. 2. implementing the SEQUITIR algorithm. I will tell the performance about it after I have finished it. 2006/9/1, Mikhail Fursov <[EMAIL PROTECTED]>: > Hi Zou, > At last I read the papers you sent and I hope now I can answer to your > questions more precisely. > I think it's a good idea to start with JET just to test the base > algorithms > implementation: SEQUITIR, GC support and so on. > Once we have framework working we can easily port everything to OPT and > measure the performance gain. > IMO what you need in JET is primitive and not optimized a read-barrier > implementation: track all accesses to > 1) static variables (getstatic opcode) > 2) object fields (getfield) > 3) array elements (aaload) Once you are able to dump memory accesses of these opcodes you can build > SEQUITIR gramma and detect hot traces. > To trace this operations you can write a simple intrinsic function to > Jitrino sources and call it from JET with 'gen_call_novm' method. > I can help you to implement these barriers if you need. > > BTW, I do not sure if SEQUITIR performance is enough to be used in > runtime. > Have you already done any estimation what does it cost? I.e. how many > instruction must me executed during a tracing to add new symbol (or > address) > to SEQUITIR gramma? > > > On 8/31/06, zouqiong <[EMAIL PROTECTED]> wrote: > > > > > > > > Recording mem-access patterns is a performance-oriented task, am I > > > right? > > > > > > yes, perfect right. > > > > How do you think, should patterns depend on certain JIT and GC > > > tightly? I suspect they depend heavily on GC, and not-so-much on > > > JIT. Though, I should say that JET uses a very cheap register > > > allocation mechanism, so it should negatively influence on the > number > > > of memory accesses, and heavily. If you are more oriented on > > > performance you should be rather using OPT for that. But, yet, I do > > > not mind if you start with a more easy-to-use JET :) > > > > > > I think memory access pattern depends heavily on GC. I want to use > > JET to instrument some profile to get the access sequence of OBJECTS. > > Making use of GC to analyze the sequence is what to do next. I think > you > > are an expert on GC. Am I right? :-) > > I don`t choose the OPT, because I think JET is much more easier and > faster > > than OPT. We shouldn`t waste too much time in instrumenting. Is it? > > > > > > Are you trying to implement some known techniques or is your work a > > > subject of ongoing research? What papers can I read on this to be > more > > > acquainted with what you are doing? > > > > > > Yes, I want to first implement Chilimbi`s work in DRLVM. The following > > list > > mainly line out the techniques: > > 1.Efficient Representations and Abstractions for Quantifying and > > Exploiting > > Data Reference Locality. > > 2.Bursty Tracing: A Framework for Low-Overhead Temporal Profiling > > 3.Dynamic Hot Data Stream Prefetching for General-Purpose Programs > > 4.Profile-guided Proactive Garbage Collection for Locality > Optimization > > > > If you want to know it more quickly, just reading the first three > paper. > > > > > > -- > > > Egor Pasko, Intel Managed Runtime Division > > > > > > > > > > --------------------------------------------------------------------- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Best Regards, > > Qiong,Zou > > > > > > > -- > Mikhail Fursov > > -- Best Regards, Qiong,Zou
-- Best Regards, Qiong,Zou
