I am curious about a bug in my implementation. I instrumented the
profile code using jet. And I referred that it can`t works with
compress and javac of jvm98.
Today I found out that if I only use jet (-Xem jet), both of the
benchmark can run successfully. While I use jet and opt, it will
error.
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
2006/9/19, Mikhail Fursov [EMAIL PROTECTED]:
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)
This is the JIRA number for my profile.
https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12350137
If still have problem, please tell me.
If you are free, we can discuss about what to do next.
2006/9/13, Mikhail Fursov [EMAIL PROTECTED]:
Qiong,
I tried to build your
2006/9/18, zouqiong [EMAIL PROTECTED]:
This is the JIRA number for my profile.
https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12350137
If still have problem, please tell me.
If you are free, we can discuss about what to do next.
I have fix the aaload problem, and it can
Qiong,
I tried to build your vm.tar.bz2 file and have the following problems:
1) RUNTIME_OBJ_PATTERN_FILE_NAME is not defined but used
2) open/write_thread.h file is absent
3) mutex_write_thread is used in jit_runtime_support.cpp but is not
declared.
Can you post only diffs file to JIRA with
ok, I think your proposal is good.
the bug about profile the aaload is still exist :-(
I decide to solve it later.And now i want to implement the profile by
sampling.
Assign a counter to each BB, if the counter is larger than the threshold,
then
the original native code of the BB will be
Hi Qiong,
I got your files from JIRA and started to learn your changes. I will be
ready to test it on Monday.
Also I have a proposal: let's choose SVN revision number as the base and
post only diffs to this revision to JIRA. How do you think, will it work?
Doing this we will minimize the size of
On 9/6/06, zouqiong [EMAIL PROTECTED] wrote:
Ok, I will put my diffs to the JIRA later. And I have solved the issue I
asked two days ago.
Ok, I will wait the JIRA number from you.
It needs liblwdis.so supporting.
Check JIRA 1402 for it. http://issues.apache.org/jira/browse/HARMONY-1402
This is the JIRA number.
https://issues.apache.org/jira/browse/HARMONY-1406
I upload the vm code, it`s not so large, 3.8 Megabytes.
And the code still have bugs when profile the AALOAD.
But I am not sure the GETFIELD and GETSTATIC are totally right. :(
If you want to profile the AALOAD, please
Hi Qiong,
What do you think about putting your diffs to the JIRA? Doing this way we
can write and test the code together?
Apache gurus,
is JIRA the standard tool to simulate SVN branching for developers that are
not commiters?
Should we gain some success in a feature implementation before we get
Hi, Mikhail:
Ok, I will put my diffs to the JIRA later. And I have solved the issue I
asked two days ago.
I want to know how to use the option -Xdumpfile, It needs liblwdis.sosupporting.
If it need to be written by ourselves, I will finish it. If not, could you
please tell me where can I
get
在06-9-4，Salikh Zakirov [EMAIL PROTECTED] 写道：
zouqiong wrote:
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:
在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
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
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
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
On the 0x1D6 day of Apache Harmony [EMAIL PROTECTED] wrote:
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
Hi,
I am reading JET in DRLVM now. And try to add some profile instrument via
JET, mainly recording the memory accessing patterns. Anyone who are
interested with it can discuss with me. Thanks!
--
Best Regards,
Qiong,Zou
On the 0x1D6 day of Apache Harmony [EMAIL PROTECTED] wrote:
Hi,
I am reading JET in DRLVM now. And try to add some profile instrument via
JET, mainly recording the memory accessing patterns.
Sounds interesting again :)
Anyone who are interested with it can discuss with me. Thanks!
20 matches
Mail list logo
