harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm]A subject to profiling instrumenting
Date Tue, 19 Sep 2006 15:18:54 GMT
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.

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.
2) Collects some kind of edge profile for blocks in JET. This is OK, but the
way you did it looks 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?

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.

Mikhail Fursov

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