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 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
