harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zouqiong <ust...@gmail.com>
Subject Re: [drlvm]A subject to profiling instrumenting
Date Sun, 03 Sep 2006 05:22:33 GMT
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 <mike.fursov@gmail.com>:
>
> 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 <ustczz@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Best Regards,
> > Qiong,Zou
> >
> >
>
>
> --
> Mikhail Fursov
>
>


-- 
Best Regards,
Qiong,Zou
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message