Re: [drlvm]A subject to profiling instrumenting
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
Re: [classlib] ICU4C 3.6 and ICU4J 3.4.5 have been released]
Great news! Hope many bugs in charset/io/util will disappear with latest icu release. On 9/3/06, Richard Liang <[EMAIL PROTECTED]> wrote: Hello, I will have a look at if there are any problems to move to the new release of ICU. ;-) Best regards, Richard Original Message Subject:[icu-support] ICU4C 3.6 and ICU4J 3.4.5 have been released Date: Fri, 1 Sep 2006 11:45:08 -0700 From: George Rhoten <[EMAIL PROTECTED]> Reply-To: ICU support mailing list < [EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] We are pleased to announce that ICU4C 3.6 was released today. More information about this release can be found on the following ICU download page. http://icu.sourceforge.net/download/3.6.html ICU4J 3.4.5 was also released today. More information about this release can be found on the following ICU download page. http://icu.sourceforge.net/download/3.4.html The ICU4J 3.6 d01 draft release will be available next week. Please stay tuned for more information on that release. George Rhoten IBM Globalization Center of Competency/ICU San José, CA, USA http://www.icu-project.org/ http://icu.sourceforge.net/ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ icu-support mailing list - [EMAIL PROTECTED] To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-support -- Richard Liang China Software Development Lab, IBM -- Andrew Zhang China Software Development Lab, IBM
Re: [classlib] ICU4C 3.6 and ICU4J 3.4.5 have been released]
2006/9/2, Alexey Petrenko <[EMAIL PROTECTED]>: It's interesting how many files from our list are fixed :) ^ bugs SY, Alexey 2006/9/2, Richard Liang <[EMAIL PROTECTED]>: > Hello, > > I will have a look at if there are any problems to move to the new > release of ICU. ;-) > > Best regards, > Richard > > Original Message > Subject:[icu-support] ICU4C 3.6 and ICU4J 3.4.5 have been released > Date: Fri, 1 Sep 2006 11:45:08 -0700 > From: George Rhoten <[EMAIL PROTECTED]> > Reply-To: ICU support mailing list <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], > [EMAIL PROTECTED], [EMAIL PROTECTED] > > > > We are pleased to announce that ICU4C 3.6 was released today. More > information about this release can be found on the following ICU download > page. > > http://icu.sourceforge.net/download/3.6.html > > ICU4J 3.4.5 was also released today. More information about this release > can be found on the following ICU download page. > > http://icu.sourceforge.net/download/3.4.html > > The ICU4J 3.6 d01 draft release will be available next week. Please stay > tuned for more information on that release. > > George Rhoten > IBM Globalization Center of Competency/ICU San José, CA, USA > http://www.icu-project.org/ > http://icu.sourceforge.net/ > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > icu-support mailing list - [EMAIL PROTECTED] > To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-support > > > > -- > Richard Liang > China Software Development Lab, IBM > > > -- Alexey A. Petrenko Intel Middleware Products Division -- Alexey A. Petrenko Intel Middleware Products Division
Re: [classlib] ICU4C 3.6 and ICU4J 3.4.5 have been released]
It's interesting how many files from our list are fixed :) SY, Alexey 2006/9/2, Richard Liang <[EMAIL PROTECTED]>: Hello, I will have a look at if there are any problems to move to the new release of ICU. ;-) Best regards, Richard Original Message Subject:[icu-support] ICU4C 3.6 and ICU4J 3.4.5 have been released Date: Fri, 1 Sep 2006 11:45:08 -0700 From: George Rhoten <[EMAIL PROTECTED]> Reply-To: ICU support mailing list <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] We are pleased to announce that ICU4C 3.6 was released today. More information about this release can be found on the following ICU download page. http://icu.sourceforge.net/download/3.6.html ICU4J 3.4.5 was also released today. More information about this release can be found on the following ICU download page. http://icu.sourceforge.net/download/3.4.html The ICU4J 3.6 d01 draft release will be available next week. Please stay tuned for more information on that release. George Rhoten IBM Globalization Center of Competency/ICU San José, CA, USA http://www.icu-project.org/ http://icu.sourceforge.net/ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ icu-support mailing list - [EMAIL PROTECTED] To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-support -- Richard Liang China Software Development Lab, IBM -- Alexey A. Petrenko Intel Middleware Products Division
[classlib] ICU4C 3.6 and ICU4J 3.4.5 have been released]
Hello, I will have a look at if there are any problems to move to the new release of ICU. ;-) Best regards, Richard Original Message Subject:[icu-support] ICU4C 3.6 and ICU4J 3.4.5 have been released Date: Fri, 1 Sep 2006 11:45:08 -0700 From: George Rhoten <[EMAIL PROTECTED]> Reply-To: ICU support mailing list <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] We are pleased to announce that ICU4C 3.6 was released today. More information about this release can be found on the following ICU download page. http://icu.sourceforge.net/download/3.6.html ICU4J 3.4.5 was also released today. More information about this release can be found on the following ICU download page. http://icu.sourceforge.net/download/3.4.html The ICU4J 3.6 d01 draft release will be available next week. Please stay tuned for more information on that release. George Rhoten IBM Globalization Center of Competency/ICU San José, CA, USA http://www.icu-project.org/ http://icu.sourceforge.net/ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ icu-support mailing list - [EMAIL PROTECTED] To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-support -- Richard Liang China Software Development Lab, IBM
Re: [classlib][TestNG] groups of Harmony test
Stepan Mishura wrote:
On 8/25/06, Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related threads
which posted by George, Vladimir Ivanov and Alexei Zakharov. All of them
are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.
*os.any* - group of tests which pass on any platform. IMHO, most of our
tests should be in this group.
*os.* - group of tests which are designed for one specific
platform. A test may be in more than one of the groups. e.g.,
@Test(groups={"os.win.IA32", "os.linux.IA32"})
** os.any and os. are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests or
implementation to make them pass.
*state.broken.* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={"state.broken.linux.IA32", "os.broken.linux.IA64"})
**state.broken. group may be used as a convenient way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for MacOS,
instead of list 9 os., we can just use state.broken.MacOS
If a test is marked as *state.broken.MacOS* then it sounds like the
test/implementation should be fixed. IMO we should use tag
os.
to define explicitly valid platforms for the test so in this
particular case
we should use 9 os.s
Thank you, Stepan. This sounds reasonable, we should explicitly list
the valid platforms.
Best regards,
Richard
3) [Test type] type.api, type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification of
the entire system. Maybe we'll put them into a separate project. e.g.,
harmony/enhanced/SVT (System Verification Test).
Mixing different types of testing into one test-file doesn't look good
for
me. I'd separate such tests by placing into different
directories/packages.
Thanks,
Stepan.
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
Well, I think our most of existing tests are in the groups of {"os.any",
"type.api", "level.unit"}, and I have asked TestNG to add a new option
"-groups" for its JUnitConverter which allow us to specify the test
groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments or
suggestion. ;-)
--
Richard Liang
China Software Development Lab, IBM
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][TestNG] groups of Harmony test
Geir Magnusson Jr. wrote:
I'm just catching up after a few days of travel. Have you begun
sketching this out on the wiki?
Sorry for my late reply. Just spent a few days looking after my
three-month-old daughter ;-) I have just recorded what we have
discussed on our wiki[1].
[1]. http://wiki.apache.org/harmony/Testing_Convention
Best regards,
Richard
geir
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.* - group of tests which are designed for one
specific platform. A test may be in more than one of the groups.
e.g., @Test(groups={"os.win.IA32", "os.linux.IA32"})
** os.any and os. are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests
or implementation to make them pass.
*state.broken.* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups.
e.g., @Test(groups={"state.broken.linux.IA32", "os.broken.linux.IA64"})
**state.broken. group may be used as a convenient
way to indicate that a test is platform-specific. e.g., If we support
10 platforms, and one test are designed for 9 platforms except for
MacOS, instead of list 9 os., we can just use
state.broken.MacOS
3) [Test type] type.api, type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
complexity as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification
of the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
Well, I think our most of existing tests are in the groups of
{"os.any", "type.api", "level.unit"}, and I have asked TestNG to add
a new option "-groups" for its JUnitConverter which allow us to
specify the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments
or suggestion. ;-)
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
