Re: [classlib] ICU4C 3.6 and ICU4J 3.4.5 have been released]

2006-09-03 Thread Richard Liang



Andrew Zhang wrote:

Great news!

Hope many bugs in charset/io/util will disappear with latest icu release.


For nio-charsets, we have to wait for icu4jni 3.6 which has been delayed 
for one month. :-(


Best regards,
Richard


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=lnkkid=120709bid=263057dat=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








--
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: [drlvm]A subject to profiling instrumenting

2006-09-03 Thread zouqiong

在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
Jitrino::Jet::Compiler::gen_patch(const char*, const
Jitrino::Jet::CodePatchItem): 断言cpi.target_offset != 0失败。
abort_handler()


I try to dump the native code generated by the JET use the DBG_DUMP_CODE
flag opened,
but it seems that it should have liblwdis.so supported?
Where can I get the lib? or Is there other ways to see the native code?




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





--
Best Regards,
Qiong,Zou


Re: [DRLVM][GC] proposal: tools to help verify all live references are properly enumerated

2006-09-03 Thread FaeLLe

Hello Ivan,

What would be the criteria for freeing up the garbage collected objects in
new area ?

Wont if lead to performance issues with duplication of memory ?

Just wondering,

- Vikram Mohan

On 8/29/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:


Weldon,

I think there are two different tasks:
   1. We need to make sure that GC doesn't break heap consistency.
   2. We need to detect wrong / unreported roots from JIT/VM.

First task is solved by HARMONY-881.
Second task can be addressed with your proposal. The point is, that
java stack can contain some garbage (slots which will never be used),
this can complicate this task.

I have used different approach to locate second problem:
Most likely unreported roots leads to crash or at least unexpected
behaviour of program.
I have written special GC (customized the HARMONY-1269) which moves
all objects after garbage collection to new area. Old area is marked
as inaccessible (hardware protection: pages has neither read nor write
permission). Failing program can be started with the GC implementation
and the exact place with outdated root can be identified.
--
Ivan

On 8/29/06, Weldon Washburn [EMAIL PROTECTED] wrote:
 One of the harder GC debugging problems is verifying that all live
 references are indeed reported to the GC.  In other words, verify the
 stuff that happens outside the GC that impacts the GC.  This actually
 complements verifying that GC internals are functioning correctly.
 Both are important for building a product quality JVM.  Perhaps it
 makes sense to build the following tool for Harmony:

 Build a stack scanner that scans a given Java thread and compares each
 4-byte slot to see if it can be interpreted as a ref ptr into the java
 heap.  Put the scan results in a list.  The locations that match what
 the JIT reports are removed from this list.  The assumption is that
 two independent approaches to identifying live references is most
 likely correct.  The remaining (hopefully few) items on the list can
 be manually inspected by JIT and VM developers to determine if somehow
 a live reference was actually overlooked.

 The above approach can be refined.  More powerful filters can be
 constructed to reduce the clutter of false positives.  It may even be
 possible to run the JVM in debug mode that will do an assert(0); if
 it sees suspicious bit patterns in the stack.

 Thoughts?

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
www.FaeLLe.com
www.VikramMohan.com


Re: [general] DaCapo Benchmark Suite and Paper

2006-09-03 Thread Geir Magnusson Jr.

Excellent!  lets get this as part of our test rig...

Steve Blackburn wrote:
The DaCapo research group is pleased to announce a new beta release of 
the DaCapo benchmark suite, an accompanying set of performance 
evaluation methodologies for dynamically compiled languages [Blackburn 
et al., OOPSLA 2006], and mailing lists for community participation and 
feedback. All are available at www.dacapobench.org.


The DaCapo benchmark suite is a set of 11 non-trivial, real-world, open 
source Java benchmarks. This release contains numerous substantial 
improvements over earlier beta releases of the suite, including new, 
larger benchmarks and a greatly improved harness.  We encourage 
researchers and developers from industry and academia working with Java 
to use the DaCapo suite and apply the methodologies presented in the 
accompanying paper (www.dacapobench.org/dacapo-oopsla-2006.pdf 
http://www.dacapobench.org/dacapo-oopsla-2006.pdf).  The paper 
recommends performance evaluation and benchmarking methodologies for 
dynamically compiled languages, describes and analyzes the suite, and 
critiques the current state of measurement methodology in the field. The 
web site also contains a link to a companion 30-page technical report 
which includes comparative data for SPEC benchmarks.


The suite and paper represent the culmination of five years of work from 
around twenty individuals across eight institutions.


We anticipate that this will be the final beta release.

Enjoy!

Steve Blackburn, on behalf of the DaCapo research group 
(http://www-ali.cs.umass.edu/DaCapo/)



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [general] DaCapo Benchmark Suite and Paper

2006-09-03 Thread Steve Blackburn

Geir Magnusson Jr. wrote:

Excellent!  lets get this as part of our test rig...

That sounds like a good idea.

I think DRL should be able to run all of the benchmarks.

Eclipse presents a minor hurdle since it expects a Sun-like organization 
of jre libs.  However, I've added a workaround for this for now (new to 
this release).  I'll be interested in working with DRL people on 
developing a better long-term solution.  Ideally we'll include in the 
benchmark a jre lib stub which eclipse will always build against, 
regardless of the JVM being tested.  This avoids the problem DRL was 
seeing and also ensures the test workload is not affected by the 
organization of the host JVM's libs.


For those who are curious: the eclipse benchmark includes performing 
some eclipse source builds.  In the case of our benchmark, this entails 
compiling parts of the eclipse sources.  These compilations need to be 
with respect to some jre libs.  Eclipse has its own expectation of where 
to find such libs and how they will be laid out.  Sun-based JVMs work 
fine, but many others (including DRL) will not.   IBM's j9 has a 
different layout, but works by virtual of special-casing within the 
eclipse codebase.


Cheers,

--Steve



-
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] HARMONY-1225 : all ready to just apply?

2006-09-03 Thread Alexey Petrenko

Right.

SY, Alexey

2006/9/4, Geir Magnusson Jr. [EMAIL PROTECTED]:

Ok, to apply 1225, I assume I can just ignore the failed chunks as we
discussed. But for the parts where patch thinks it's been applied, I
assume you don't want me to -R either?

geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Alexey A. Petrenko
Intel Middleware Products Division

-
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

2006-09-03 Thread Mikhail Loenko

Hi Vladimir

Could you please decribe for what purpose it will be used?

I mean why one might have to either exclude or run only regression tests?

Thanks,
Mikhail

2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:

On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:



 Vladimir Ivanov wrote:
  Also some tag for regression tests should be added.
 Yes. Do you think we could annotate regression test as
 *level.regression*? Thanks a lot.


Yes, I do. While tests can have more than one group it will enough.
 thanks, Vladimir


Richard
  thanks, Vladimir
 
 
  On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
 
 
 
  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.platform id
   *os.any* - group of tests which pass on any platform. IMHO, most of
   our tests should be in this group.
   *os.platform id* - 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.platform id are mutually exclusive, that is,
   tests in os.any group should not be in os.win.IA32.
  
   2) [Test state] state.broken, state.broken.platform id
   *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.platform id* - 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.platform id 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.platform id, 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:
  groups
  run
  include name=os.any /
  include name=type.api /
  include name=os.win.IA32 /
  exclude name= state.broken /
  exclude name=state.broken.win.IA32 /
  /run
  /groups
  
  Hello All,
 
  I'm sorry. It seems that the example does not work. I will try to
 figure
  another example soon. ;-)
 
  Best regards,
  Richard
  
   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]






-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [build-test-infra] Build Test Infrastructure

2006-09-03 Thread Vladimir Ivanov

Seems, that links
 
upload60551http://harmonytest.org/testapp.do;jsessionid=9644A083467EC4F0C4CC806DB107C3F2?method=showrunid=upload60551
Europe/Moscow
11.2.0 x86 Windows XP 5.1
upload60552http://harmonytest.org/testapp.do;jsessionid=9644A083467EC4F0C4CC806DB107C3F2?method=showrunid=upload60552
Europe/Moscow
11.2.0 x86 Windows XP 5.1
upload60553http://harmonytest.org/testapp.do;jsessionid=9644A083467EC4F0C4CC806DB107C3F2?method=showrunid=upload60553
Europe/Moscow
11.2.0 x86 Windows XP 5.1

are broken.
thanks, Vladimir

On 9/1/06, Anton Luht [EMAIL PROTECTED] wrote:


Hello,

I've deployed the test infrastructure app  to http://harmonytest.org .
It is mostly for demo purpose - the disk space is not too large - I
hope it will move somewhere else after evaluation.  Please try to
upload your test results there and send comments/wishes about the app
- I'll try to implement them.

There is no design because I didn't dare to make it Apache-looking :)

The problem I see is that DRL VM version as seen is 'java.exe
-version' is not seen in System.getProperties() as is not recorded in
xmls with test results because of it. It's hard to identify the
configuration the tests were run on - I think version information
should be added to properties.

I don't want to send the account data to the list - please let me know
if you want to have access to the site.

On 8/4/06, Anton Luht [EMAIL PROTECTED] wrote:
 Hello,

 I've uploaded a proto of a proto for test infrastructure to
 http://issues.apache.org/jira/browse/HARMONY-1062 . At least it allows
 to upload test results to a server. Unfortunately I haven't found a
 server to deploy it yet so I can't send URL that contains test
 installation. The screenshots look much like those I've sent before.
 Sorry I haven't implemented Alexei's proposal to make test report
 JUnitReport style looking but I do remember about it.

 I've tried to separate web application logic from data access logic -
 the latter is implemented with data stored in files.
 --
 Regards,
 Anton Luht,
 Intel Middleware Products Division



--
Regards,
Anton Luht,
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]