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 Wed, 20 Sep 2006 01:39:55 GMT
2006/9/19, Mikhail Fursov <mike.fursov@gmail.com>:
> Hi Qiong,
> I tried to apply and to build your patch on Windows.
> I checked out the revision required by the patch, built the code but had
> some problems to run it: the VM crashed at startup. I'll try to build the
> patched version on Linux (as you did) and will report soon.
> -Xem jet option is default configuration for JET-only mode. No profiling
> is
> done in this mode.
> When both JET and OPT compilers work JET does profiling for OPT compiler.
> Here is the place you added your code. I think that failure in this mode
> is
> result of the patch.

But I am curious that  the OPT recompile the bytecode of the method, not
on my instrumented code. How can it affect the OPT and cause errors.

As far as I understand from the diffs your patch does the following:
> 1) Calls the new VM helper for every memory access. This helper saves the
> trace for every thread separately.

I call the new VM helper only for getfield, getstatic and aaload bytecode.

2) Collects some kind of edge profile for blocks in JET. This is OK, but the
> way you did it looks unsafe.

I don`t understand why it`s unsafe.

My proposal is to increase the code and feature base step by step. I mean
> that it's hard to find out the reason of the problem when there are
> several
> features added simultaneously and none of them is stable.
> Can we remove the code changes from VM side and leave test JET changes
> only
> first? If you need to track all memory access addresses in JIT we can add
> an
> internal JET helper that dumps addresses to a file. Most of the spec98
> benchmarks are single threaded so no TLS support is needed on the early
> stage. Once we are sure that tracing feature is implemented in JET
> properly
> we can move the helper body to VM, add TLS support and test the code
> again.
> And only after it's done we can add and test edge profiling support to
> JET.
> What do you think about this plan?

Ok, i will remove the code changes from VM side and test JET changes only.
will report it later. And I don`t want to track all memory access addresses,

it`s too large and not necessary.

BTW the JIRA 1363 that is already merged to the SVN trunk adds edge profiler
> support to the EM. The Edge Profiler is used in OPT only but has a lot of
> JIT independent code we can reuse.

It sounds good. I will have a look at the patch. And discuss later. :-)

> Mikhail Fursov

Best Regards,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message