Re: Behaving differently than RI
2006/11/6, Spark Shen [EMAIL PROTECTED]: Alexey Petrenko 写道: Hi, Mike. You can find compatybility guideline for Harmony here: http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html According to your testcase. I think it is a bug and you should file it to JIRA. AFAIK, ICU has its own mailing list[1]. If that incompatibility is considered a bug, delegate to ICU development team may be more efficient. Right. But even if it is an ICU bug I think that it will be good to have also Harmony JIRA entry with the link to corresponding ICU issue. SY, Alexey [1] ICU support mailing list [EMAIL PROTECTED] 2006/11/4, Mike Ringrose [EMAIL PROTECTED]: Before submitting a bug to JIRA, I was curious to know, how exact should Harmony behave when compared to the RI. For example, the code below produces different results when compared to the RI. DecimalFormat f = new DecimalFormat(.1); System.out.println(f.format(17.16)); Harmony outputs 17.2, while the RI outputs 17.1. The reason for the difference is that Harmony's underlying implementation is taken from ICU which supports options other than what is specified by the RI. Should this difference be considered a bug? Thanks, Mike Ringrose -- Spark Shen China Software Development Lab, IBM
Re: [drlvm][unit] Closing H-1679, H-1722
2006/11/5, Anton Luht [EMAIL PROTECTED]: Hello, Both bugs are verified on svn = r471521, (Nov 5 2006), Windows/ia32/msvc 1310, debug build and can be closed. Done. SY, Alexey On 11/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Fedotov, Alexei A wrote: Anton, Is it ok to close the following issues? * HARMONY-1679 Timer.schedule(TimerTask, delay, period) doesn't cause repetitive invocation of task * HARMONY-1722 notify() in synchronized section makes wait(long) wait forever I don't know about 1679, but I agree about 1722 if it can't be repeated. geir I cannot reproduce them on the latest build. With best regards, Alexei Fedotov, Intel Java XML Engineering -- Regards, Anton Luht, Intel Java XML Engineering
Re: [ant] ant --noconfig helps disabling pre-installed ant rpm on Linux Was: [ant][classlib][em64t]Problems during classlib on em64t (revision 462753)
I remember that we faced the same problem long time ago. So it is probably a good candidate for mentioning on wiki. SY, Alexey 2006/11/5, Fedotov, Alexei A [EMAIL PROTECTED]: Hello, Since my Linux died due to hardware problem I now abide at computers of my friends. Pavel's computer showed the same ANT problem with missing regular expression matcher. After some digging I found out that ANT installed from RPM package has a priority over my ant from $ANT_HOME: http://www.jayasoft.org/node/820 The problem happens because $ANT_HOME/bin/ant reads /etc/ant.conf which sets rpm_mode=true unless --noconfig is set. If you are not a root, you have a little chance to change /etc/ant.conf or add something to pre-installed ANT's lib directory. I started looking for workaround. Supplying --noconfig option for $ANT_HOME/bin/ant worked for me. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Valentin Al. Sitnick (Moscow) [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 7:41 PM To: harmony-dev@incubator.apache.org Subject: Re: [ant][classlib][em64t]Problems during classlib on em64t (revision 462753) Sorry I have not experience to send long logs... svn-info: [exec] Current OS is Linux [exec] Output redirected to property: svn.info.tmp [exec] Executing 'svn' with arguments: [exec] 'info' [exec] [exec] The ' characters around the executable and arguments are [exec] not part of the command. Override ignored for property svn.info build-jar: [subant] Exiting /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/modules/accessibility/build.xml. [antcall] Exiting /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/build-java.xml. [ant] Exiting /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/build-java.xml. BUILD FAILED /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/build.xml:108: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/bu ild- java.xml:183: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/make/properties.xml:249: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/make/properties.xml:259: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/modules/accessibility/build.xml:90: No supported regular expression ma tcher found at org.apache.tools.ant.ProjectHelper.addLocationToBuildException( ProjectHelper.java:539) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:384) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java :275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java :1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets( DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) Caused by: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/build-java.xml:183: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/make/properties.xml:249: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/make/properties.xml:259: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/modules/accessibility/build.xml:90: No supported regular expression ma tcher found at org.apache.tools.ant.ProjectHelper.addLocationToBuildException( ProjectHelper.java:539) at org.apache.tools.ant.taskdefs.MacroInstance.execute( MacroInstance.java:380) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java :275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java :1216) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets( SingleCheckExecutor.java:37) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at
Re: Behaving differently than RI
Alexey Petrenko 写道: 2006/11/6, Spark Shen [EMAIL PROTECTED]: Alexey Petrenko 写道: Hi, Mike. You can find compatybility guideline for Harmony here: http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html According to your testcase. I think it is a bug and you should file it to JIRA. AFAIK, ICU has its own mailing list[1]. If that incompatibility is considered a bug, delegate to ICU development team may be more efficient. Right. But even if it is an ICU bug I think that it will be good to have also Harmony JIRA entry with the link to corresponding ICU issue. Agree with you to report a JIRA to record this issue. SY, Alexey [1] ICU support mailing list [EMAIL PROTECTED] 2006/11/4, Mike Ringrose [EMAIL PROTECTED]: Before submitting a bug to JIRA, I was curious to know, how exact should Harmony behave when compared to the RI. For example, the code below produces different results when compared to the RI. DecimalFormat f = new DecimalFormat(.1); System.out.println(f.format(17.16)); Harmony outputs 17.2, while the RI outputs 17.1. The reason for the difference is that Harmony's underlying implementation is taken from ICU which supports options other than what is specified by the RI. Should this difference be considered a bug? Thanks, Mike Ringrose -- Spark Shen China Software Development Lab, IBM -- Spark Shen China Software Development Lab, IBM
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
Geir Magnusson Jr. wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: did we decide not to go to TestNG? Sigh...I guess there must be too many ones have waited too long for TestNG...(including me) I don't understand - what do you mean? Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it cannot be used for months, so people may think let's just use JUnit instead... Ignore it, I'm all for TestNG...:) geir Paulex - being desperate -- Paulex Yang China Software Development Lab IBM
RE: [doc][drlvm] new docs added - JIT compiler
Geir, all, Could you please find time and look into JIRA 1882 and JIRA 2003. These contain content updates for the website - one for the devguide, removing outdated info, etc; and the other one for JIT - introducing a more-or-less comprehensive description of this component. Adding these to the website does not affect structure/ideology of website, but only adds more info. If somebody volunteers to review, I'd be happy to help and work to improve the docs further. h-2003 http://issues.apache.org/jira/browse/HARMONY-2003 h-1882 http://issues.apache.org/jira/browse/HARMONY-1882 Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 2:18 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] new docs added - JIT compiler oh, thankyou thankyou thankyou Morozova, Nadezhda wrote: Yeah! No problem, I was just thinking a zip would not look as transparent and safe. I'd turn the images from the other doc issue into an archive as well. Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 5:20 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] new docs added - JIT compiler is there any chance you could put a zip of the images into the jira, rather than a dozen or so images? That's actually what turned me off from one of the other doc issues - I said to myself oh, heck, I don't want to download each of those separate thingies... I just want a zip or tgz of them... easier to handle... So please? :) geir Morozova, Nadezhda wrote: All, New documents have been added to HARMONY-2003. These are a description of the Jitrino.OPT and .JET compilers, with a supplementary doc on the pipeline management framework inside the JITs. The docs describe the architecture, processes and usage of the components. It would be great if somebody took a look, expressed an opinion, and, if favorable, committed to the website. Your review or any other feedback are most welcome, Thanks, Nadya Morozova PS: this JIRA is not the only one unresolved doc issue. Find more useful pending patches in our database :-)
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
2006/11/6, Fedotov, Alexei A [EMAIL PROTECTED]: Alexey, I started looking into this thread. Are guidelines on the web site already? I failed to find them. No, this guideline is not published yet. I'll do this in the nearest future. I thought about adding them to get-involved.html. Here are few problems I've noticed: First of all As you know patches are always welcome in Harmony :) 1. The detail level of your instruction is somewhat different from get-involved.html. This text is formal, while the text on the page is quite informal. I do not see problem here. 2. If a guy has a test in a separate file, should he produce a patch from such file and submit the patch? According to guidelines, the answer is yes. Do you mean in a new file? Yes, a new file should be provided as a patch too. Why not? According to my common sense patches are good when you modify existing files. Yes, they are good for modified files. And they also can be used for adding and removing files. 3. Why it is not suggested for an issue reporter to try localizing a buggy module I think that points 2 and 3 are saying this. or even fixing the problem? Nobody said that an issue reporter can not be a resolution provider. 4. Item 4. of issue reporter guidelines doesn't contain enough details for my taste. I believe links should be descriptive: Link the issue to previous posts, JIRAs, RI bugs, etc. Probably your sentence is better. Need to think. 5. The item 2.1 of resolution provider guidelines contains too many details to my mind. Here should be something like a following text (for all roles): a. Update JIRA once per day reporting your progress. b. Always keep the community posted. What for? Why do you want to have DAILY posts on ALL the working issues? I think that we do not need to change anything here since comunity has agreed on the list of notifications it wants to see. And all these cases are described there. 6. The item 2.4 refers to class library build.xml as a main build.xml. Patches are welcome :) 7. You do not specify which unit tests should pass and which VM should be used. Since the changes could affect DRLVM, I would say that all unit tests should pass for DRLVM unless the fall into exclude list. DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 8. I believe a verification stage should happen before committer commits a patch - this would save his time if the issue doesn't resolve the problem. Yes, and nobody argue with this. SY, Alexey -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) :) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue and send a message to dev list. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it.
Re: [drlvm][jit] Moving jet to the top level of drlvm...
Alex Astapchuk wrote: Pavel Pervov wrote: Hello, community, Working through DRLVM sources I (once again) looked at organization of jitrino code. Actually, there are two JITs hidden inside jitrino: JET and OPT. As far as I may observe - these two are code-independent from each other. JIT-guys, could you comment? If I'm right here I would vote for moving them to top level of drlvm/trunk/vm directory to clearly indicate we have two JITs in DRLVM. There are no two JITs, actually. We call them 'compilation paths'. 'jet' here stands for 'Jitrino Express compilation paTh'. As Mikhail already mentioned they share significant parts like logging, PMF, multi-threaded stuff, guard locks, etc. The difference in codebases, came from their targets - the .jet was heavily tuned for very fast compilation, resulting to that many virtual interfaces used in .opt were substituted with direct calls to VM. Personally, I don't see any *practical* reason to separate .jet and .opt. The practical reason is to start convincing ourselves of the modularity. geir
Re: [drlvm] building jitrino in release mode
That's distressing. I usually throw in a build clean every now and then - I'm almost sure I did it early yesterday or sat at the earliest and did a full build, so whatever I committed in the last two days is problematic. Not clear what though... geir Robin Garner wrote: I've been having some problems getting some test cases to exhibit misbehavior for DRLVM, and it turns out that jitrino is built in release mode no matter what BUILD_CFG is set to. Putting this inconsistency aside for a moment, how do I get jitrino to build in debug? I tried changing the setting in build.sh for -Dvm.jitrino.cfg from 'release' to 'debug', but then DRLVM doesn't build on Ubunutu 6 with gcc 3.4.6. There's some linker problem. Can anyone duplicate this (or have it build successfully in debug)? geir That wouldn't be this problem, would it ? build.native.link: [cc] 0 total files to be compiled. [cc] Starting link [cc] `.L217' referenced in section `.rodata' of ../_obj/jit_generic_rt_support_ia32.o: defined in discarded section `.gnu.linkonce.t._ZN8Imm_OpndC1E9Opnd_Sizei' of ../_obj/jit_generic_rt_support_ia32.o [cc] `.L220' referenced in section `.rodata' of ../_obj/jit_generic_rt_support_ia32.o: defined in discarded section `.gnu.linkonce.t._ZN8Imm_OpndC1E9Opnd_Sizei' of ../_obj/jit_generic_rt_support_ia32.o [snip] [cc] `.L46' referenced in section `.rodata' of /home/robing/tmp/harmony/harmony/working_vm/build/lnx_ia32_gcc_debug/semis/vm/jthread/_bin/libjthread.a(thread_helpers.o): defined in discarded section `.gnu.linkonce.t._ZN8Imm_OpndC1E9Opnd_Sizei' of /home/robing/tmp/harmony/harmony/working_vm/build/lnx_ia32_gcc_debug/semis/vm/jthread/_bin/libjthread.a(thread_helpers.o) [cc] collect2: ld returned 1 exit status -- In which case it's happening without the 'debug' setting, and I'd appreciate some help too. :) robin
Re: [drlvm] building jitrino in release mode
Alex Astapchuk wrote: Geir Magnusson Jr. wrote: I've been having some problems getting some test cases to exhibit misbehavior for DRLVM, and it turns out that jitrino is built in release mode no matter what BUILD_CFG is set to. Yes, this is a long-long story. Was done as 'we-will-change-it-back-soon' thing, but remains till this moment. :-) When I get it to build, I'll change it back today :) Putting this inconsistency aside for a moment, how do I get jitrino to build in debug? Here it is: http://tinyurl.com/yxjp4v This are patches for jitrino.xml build.bat, the same change (remove -Dvm.jitrino.cfg=release) need to be done for build.sh as well. k (I made the change in build.sh, as I never work on windows...). I'll look at jitrino.xml (I can't see your URL... I'm in a car at the moment...) thx geir
Re: [drlvm] building jitrino in release mode
Geir Magnusson Jr. wrote:
Alex Astapchuk wrote:
Geir Magnusson Jr. wrote:
I've been having some problems getting some test cases to exhibit
misbehavior for DRLVM, and it turns out that jitrino is built in
release mode no matter what BUILD_CFG is set to.
Yes, this is a long-long story.
Was done as 'we-will-change-it-back-soon' thing, but remains till this
moment. :-)
When I get it to build, I'll change it back today :)
Putting this inconsistency aside for a moment, how do I get jitrino
to build in debug?
Here it is: http://tinyurl.com/yxjp4v
This are patches for jitrino.xml build.bat, the same change (remove
-Dvm.jitrino.cfg=release) need to be done for build.sh as well.
k (I made the change in build.sh, as I never work on windows...). I'll
look at jitrino.xml (I can't see your URL... I'm in a car at the moment...)
If it helps, then here is the copy:
=
project name=vm.jitrino
-target name=init
+target name=init depends=common_vm
property name=build.depends
value=extra.apr,vm.vmcore,vm.encoder /
property name=outtype value=shared /
property name=libname value=jitrino /
@@ -48,7 +48,8 @@
patternset id=java.classes.pattern includes=empty_pattern/
!-- the compiler doesn't extend common compiler --
-compiler name=${build.cxx} id=cpp.compiler
+compiler id=cpp.compiler extends=common.cpp.compiler
=
--
Thanks,
Alex
Re: [drlvm][jit] Moving jet to the top level of drlvm...
Geir Magnusson Jr. wrote: Alex Astapchuk wrote: Pavel Pervov wrote: Hello, community, Working through DRLVM sources I (once again) looked at organization of jitrino code. Actually, there are two JITs hidden inside jitrino: JET and OPT. As far as I may observe - these two are code-independent from each other. JIT-guys, could you comment? If I'm right here I would vote for moving them to top level of drlvm/trunk/vm directory to clearly indicate we have two JITs in DRLVM. There are no two JITs, actually. We call them 'compilation paths'. 'jet' here stands for 'Jitrino Express compilation paTh'. As Mikhail already mentioned they share significant parts like logging, PMF, multi-threaded stuff, guard locks, etc. The difference in codebases, came from their targets - the .jet was heavily tuned for very fast compilation, resulting to that many virtual interfaces used in .opt were substituted with direct calls to VM. Personally, I don't see any *practical* reason to separate .jet and .opt. The practical reason is to start convincing ourselves of the modularity. Ugh. 'Modularity' is good word, I like it. Especially taking into account that no one can measure it. Can you? :-) Moving jet around will give nothing useful. Neither in a short-term nor in a longer perspective. But will take an efforts and add a mess and maybe code duplicate from Jitrino codebase. Jitrino itself is modular enough - again, the JET was not intended as a separate JIT. It's only purpose was (and still is) to be a front-line for Jitrino's main engine - to speed up client apps startup. Absolutely no reason to have it separately. -- Thanks, Alex
Re: [general] Interesting discoveries playing around with japitools
Stefano Mazzocchi wrote: Paulex Yang wrote: Gets more interesting with IBM: -- ibm1.5 vs. sun1.5 Total: 99.77% good, 0% bad, 0.22% missing java.lang: Missing method java.lang.StringBuilder.append(java.lang.StringBuilder): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.capacity(): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.charAt(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointAt(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointBefore(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointCount(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.ensureCapacity(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.getChars(int, int, char[], int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.length(): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.setCharAt(int, char): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.setLength(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.subSequence(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.substring(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.substring(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.trimToSize(): missing in /home/stefano/data/japi/sun1.5 It IS more interesting, because there methods are included in Java 5 API Doc (except the first one)!...there may be some problem happened to JAPI or the Sun JDK' rt.jar...;-) Paulex, good catch! It might well be a japitools bug, then. I did look into the javadoc and stopped after I realized that the first method wasn't there... but I should have continued. Anyway, even a single method should be enough to trigger a TCK reaction (since this is clearly against Sun WORA policies). Indeed. -- Paulex Yang China Software Development Lab IBM
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey, Thank you for your answer. Yesterday I tried to prepare an appropriate patch for get-involved.html but faced several things I couldn't resolve myself. I didn't criticize your text - I was thinking how to fit it into get-involved.html. That is why I raised all these questions. I still have one question which is important, to my mind. You wrote, DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 1. As Geir says, we are small community, and we need to keep ourselves concentrated. Can we give a recommendation to concentrate on one specific VM assuming that VM which is shipped with Harmony 1.0? 2. What is the status of DRLVM smoke tests? As any tests written in java they have a dependency from a class library. Do you think they should be skipped while testing the patch? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 2:03 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) 2006/11/6, Fedotov, Alexei A [EMAIL PROTECTED]: Alexey, I started looking into this thread. Are guidelines on the web site already? I failed to find them. No, this guideline is not published yet. I'll do this in the nearest future. I thought about adding them to get-involved.html. Here are few problems I've noticed: First of all As you know patches are always welcome in Harmony :) 1. The detail level of your instruction is somewhat different from get-involved.html. This text is formal, while the text on the page is quite informal. I do not see problem here. 2. If a guy has a test in a separate file, should he produce a patch from such file and submit the patch? According to guidelines, the answer is yes. Do you mean in a new file? Yes, a new file should be provided as a patch too. Why not? According to my common sense patches are good when you modify existing files. Yes, they are good for modified files. And they also can be used for adding and removing files. 3. Why it is not suggested for an issue reporter to try localizing a buggy module I think that points 2 and 3 are saying this. or even fixing the problem? Nobody said that an issue reporter can not be a resolution provider. 4. Item 4. of issue reporter guidelines doesn't contain enough details for my taste. I believe links should be descriptive: Link the issue to previous posts, JIRAs, RI bugs, etc. Probably your sentence is better. Need to think. 5. The item 2.1 of resolution provider guidelines contains too many details to my mind. Here should be something like a following text (for all roles): a. Update JIRA once per day reporting your progress. b. Always keep the community posted. What for? Why do you want to have DAILY posts on ALL the working issues? I think that we do not need to change anything here since comunity has agreed on the list of notifications it wants to see. And all these cases are described there. 6. The item 2.4 refers to class library build.xml as a main build.xml. Patches are welcome :) 7. You do not specify which unit tests should pass and which VM should be used. Since the changes could affect DRLVM, I would say that all unit tests should pass for DRLVM unless the fall into exclude list. DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 8. I believe a verification stage should happen before committer commits a patch - this would save his time if the issue doesn't resolve the problem. Yes, and nobody argue with this. SY, Alexey -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) :) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Alexei, The1363 submission added functionality for lazy exception support, for exceptions in the VM code. exn_raise_by_name_internal was such a function. This may not be bug free ( as is true of any code ) and we need to check out 2070. I will take a look, as should Pavel. I think that while committing 1363, StackTest failed and there were other asserts, which Geir disabled to not block the large submission. This is not really anything to do with lazy exceptions. This is an issue where parts of the main thread's stack virtual memory are unmapped on Linux. I later added a fix for this. The two issues are orthogonal to each other. Rana On 11/5/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Rana, Pavel (Afremov), All, Geir's comment on r443504 (fix for http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64 bit support, JVMTI improvements) reads: 1) Stack overflow exception stuff is broken. I had to remove the assert in signals_ia32.cpp line 336. Rana knows and will look. I also disabled the StackTest. I have noticed that the patch added a new function exn_raise_by_name_internal which fails on the first invocation checking an assertion about thread state, see http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit] org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest crashes DRLVM. I also have noticed that this function is called to create java.lang.StackOverflowError. Could you help me to understand the current status of the problem? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Rana Dasgupta [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 4:27 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is fixed I fixed the StackOverflow functionality problem by going back and mapping all pages ( guard, alternate stack ) meticulously before trying to protect them. I think we should have done this in the first place. I also cleaned up the previous initialization workarounds and asserts Geir and I had discussed on the JIRA. The Stacktest and all other stack related tests now pass. I'll submit the patch against 1786 in the next few hours after running acceptance tests. Rana On 10/16/06, Rana Dasgupta [EMAIL PROTECTED] wrote: On 10/16/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote: I tried to put some back. StackTest still doesn't work. It's hard to believe... so I gave up and just kept going :) I wonder if the test or the implementation are wrong. Maybe someone who added the test initially could know the answer. There is nothing wrong with the stacktest test itself. The implementation is not quite 100%complete( I think ), but has enough functionality and the test passes on Windows. On Linux, it fails. I am not sure if this is a regression, or if this ever worked. There is a JIRA issue 1786. In summary, memory protection setup for the guard page fails on the main thread(only). So the guard does not work and the overflow is not detected. mprotect fails with an ENOMEM which is either a mapping failure or a kernel failure. mprotect() has some known flakiness it seems, as per literature. The basic implementation on Linux is sound. There are secondary design issues,but we can only get to them later after we have figured out why the guard setup fails on the main thread.
Re: [drlvm][jit] Moving jet to the top level of drlvm...
Jet is a startup fast compilation path, not a seperate pluggable jit. So, while modularity and seperation are important requirements, they may not be needed here. Also, Mikhail and Alex are the best people to decide on this.They are literally the two people who know this code best :-)
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Geir Magnusson Jr. wrote: Yes. I have some docs that need to be put in SVN - I hope to do that today. Once we do that, we need to simply vote to accept the code. If you start working with it ahead of time, that will be good :) geir Are we ready to vote yet? I can't hold my breath much longer gasp :-) Regards, Tim Nathan Beyer wrote: Are there any documents or anything that needs to be resolved before I can start working on the code in HARMONY-1407? http://issues.apache.org/jira/browse/HARMONY-1407 -Nathan -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [general] Interesting discoveries playing around with japitools
Thanks for doing this Stefano. I'll investigate the Sun/IBM findings and let you know. Regards, Tim Stefano Mazzocchi wrote: Being a sucker for statistics and charts, I've decided to look into japitools myself and regenerate the graph of API coverage progress of harmony. In doing so, I started to familiarize myself with the Japitools and I found a few interesting discoveries: the latest version of the three freely available certified java 5 implementations (Sun's, BEA's and IBM's) are *NOT* 100% compatible. So, here's what I did: 1) download the three JVMs 2) download japitools, tar xzf it and cd japitools 3) type: ./bin/japize as $name packages \ /path/to/jvms/$name/jre/lib/*.jar \ +java +javax +org -org.apache -org.ietf and substitute $name with the JVM name 4) you'll obtain three $name.japi.gz files (the binary representation of your API footprint) 5) then type japicompat -s $original.japi.gz $test.japi.gz where original is the JVM that you consider the reference and $test is the one that you want to test. Here are the (a little surprising, I must say) results: -- sun 1.5 vs. bea1.5 --- 99.99% good, 0% missing java.awt.peer: method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in /home/stefano/data/japi/ibm1.5 -- sun 1.5 vs. ibm1.5 --- Total: 99.93% good, 0% bad, 0.06% missing java.awt.peer: Missing method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in /home/stefano/data/japi/ibm1.5 javax.xml.datatype: Bad field javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS: constant [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl] in /home/stefano/data/japi/sun1.5, but constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in /home/stefano/data/japi/ibm1.5 org.omg.stub.javax.management.remote.rmi: Missing class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in /home/stefano/data/japi/ibm1.5 class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie: missing in /home/stefano/data/japi/ibm1.5 org.w3c.dom.html: Missing method org.w3c.dom.html.HTMLFrameElement.getContentDocument(): missing in /home/stefano/data/japi/ibm1.5 method org.w3c.dom.html.HTMLIFrameElement.getContentDocument(): missing in /home/stefano/data/japi/ibm1.5 method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing in /home/stefano/data/japi/ibm1.5 method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing in /home/stefano/data/japi/ibm1.5 - o - There is one method that both Bea and IBM don't implement in awt.peer.WindowPeer and apparently, Sun doesn't implement it either.. it's just a stub! Weird. [see more at http://forums.java.net/jive/thread.jspa?messageID=167137] the differences in datatype factory is plausible and the fact that a stub RMI class is missing is not that big of a deal. It's weird though, that the DOM in IBM's is different than the DOM in Sun's... I guess not that many people use the HTML DOM in java or they would have got that ;-) The really crazy things start to happen if you flip things around and you consider the 'clean room rewrites' as the reference implementations: -- bea1.5 vs. sun1.5 Total: 99.98% good, 0.01% missing javax.xml.namespace: Missing class javax.xml.namespace.QName: missing in /home/stefano/data/japi/sun1.5 Uh? Sun forgot to ship the QName class or this is a japitools bug? googling up shows the class in the java1.5 docs so it's more likely it's a bug in japitools http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/namespace/QName.html Gets more interesting with IBM: -- ibm1.5 vs. sun1.5 Total: 99.77% good, 0% bad, 0.22% missing java.lang: Missing method java.lang.StringBuilder.append(java.lang.StringBuilder): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.capacity(): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.charAt(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointAt(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointBefore(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointCount(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.ensureCapacity(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.getChars(int, int, char[], int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.length(): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in /home/stefano/data/japi/sun1.5 method
Re: Behaving differently than RI
ICU would not see this as a bug, because it is a feature of their implementation of DecimalFormat. The pattern .1 for ICU means to round the value to the nearest tenth, while the RI takes it literally. If you look at the JavaDocs for ICU, you'll see the following message: *This is an enhanced version of DecimalFormat that is based on the standard version in the JDK. New or changed functionality is labeled NEW or CHANGED. [1] This is why I chose my example, the ICU version is an enhanced version of DecimalFormat that extends the RI implementation. I'm not sure if this should be deviation from the RI should be considered a bug. However, if it is, then this issue could be problematic for Harmony using the ICU's implementation. [1] http://icu.sourceforge.net/apiref/icu4j/com/ibm/icu/text/DecimalFormat.html Mike Ringrose *On 11/6/06, Spark Shen [EMAIL PROTECTED] wrote: Alexey Petrenko 写道: Hi, Mike. You can find compatybility guideline for Harmony here: http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html According to your testcase. I think it is a bug and you should file it to JIRA. AFAIK, ICU has its own mailing list[1]. If that incompatibility is considered a bug, delegate to ICU development team may be more efficient. [1] ICU support mailing list [EMAIL PROTECTED] SY, Alexey 2006/11/4, Mike Ringrose [EMAIL PROTECTED]: Before submitting a bug to JIRA, I was curious to know, how exact should Harmony behave when compared to the RI. For example, the code below produces different results when compared to the RI. DecimalFormat f = new DecimalFormat(.1); System.out.println(f.format(17.16)); Harmony outputs 17.2, while the RI outputs 17.1. The reason for the difference is that Harmony's underlying implementation is taken from ICU which supports options other than what is specified by the RI. Should this difference be considered a bug? Thanks, Mike Ringrose -- Spark Shen China Software Development Lab, IBM
Re: [general] Interesting discoveries playing around with japitools
Tim Ellison wrote: Thanks for doing this Stefano. I'll investigate the Sun/IBM findings and let you know. My pleasure, really. Oh, and before anybody thinks there is something malicious about this, let me state that I do *NOT* think there was anything intentional in the various JVM about breaking WORA or things like that. It's obviously just a bug somewhere, in japitools, in the TCK coverage tests, in the IBM JVM class library or (more likely) in a weird combination of all of the above. What I want to emphasize (especially to the Sun officials that watch us) is that not only open source is not about breaking compatibility, but it's able to catch incompatibilities that not even Sun did. ;-) Regards, Tim Stefano Mazzocchi wrote: Being a sucker for statistics and charts, I've decided to look into japitools myself and regenerate the graph of API coverage progress of harmony. In doing so, I started to familiarize myself with the Japitools and I found a few interesting discoveries: the latest version of the three freely available certified java 5 implementations (Sun's, BEA's and IBM's) are *NOT* 100% compatible. So, here's what I did: 1) download the three JVMs 2) download japitools, tar xzf it and cd japitools 3) type: ./bin/japize as $name packages \ /path/to/jvms/$name/jre/lib/*.jar \ +java +javax +org -org.apache -org.ietf and substitute $name with the JVM name 4) you'll obtain three $name.japi.gz files (the binary representation of your API footprint) 5) then type japicompat -s $original.japi.gz $test.japi.gz where original is the JVM that you consider the reference and $test is the one that you want to test. Here are the (a little surprising, I must say) results: -- sun 1.5 vs. bea1.5 --- 99.99% good, 0% missing java.awt.peer: method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in /home/stefano/data/japi/ibm1.5 -- sun 1.5 vs. ibm1.5 --- Total: 99.93% good, 0% bad, 0.06% missing java.awt.peer: Missing method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in /home/stefano/data/japi/ibm1.5 javax.xml.datatype: Bad field javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS: constant [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl] in /home/stefano/data/japi/sun1.5, but constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in /home/stefano/data/japi/ibm1.5 org.omg.stub.javax.management.remote.rmi: Missing class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in /home/stefano/data/japi/ibm1.5 class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie: missing in /home/stefano/data/japi/ibm1.5 org.w3c.dom.html: Missing method org.w3c.dom.html.HTMLFrameElement.getContentDocument(): missing in /home/stefano/data/japi/ibm1.5 method org.w3c.dom.html.HTMLIFrameElement.getContentDocument(): missing in /home/stefano/data/japi/ibm1.5 method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing in /home/stefano/data/japi/ibm1.5 method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing in /home/stefano/data/japi/ibm1.5 - o - There is one method that both Bea and IBM don't implement in awt.peer.WindowPeer and apparently, Sun doesn't implement it either.. it's just a stub! Weird. [see more at http://forums.java.net/jive/thread.jspa?messageID=167137] the differences in datatype factory is plausible and the fact that a stub RMI class is missing is not that big of a deal. It's weird though, that the DOM in IBM's is different than the DOM in Sun's... I guess not that many people use the HTML DOM in java or they would have got that ;-) The really crazy things start to happen if you flip things around and you consider the 'clean room rewrites' as the reference implementations: -- bea1.5 vs. sun1.5 Total: 99.98% good, 0.01% missing javax.xml.namespace: Missing class javax.xml.namespace.QName: missing in /home/stefano/data/japi/sun1.5 Uh? Sun forgot to ship the QName class or this is a japitools bug? googling up shows the class in the java1.5 docs so it's more likely it's a bug in japitools http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/namespace/QName.html Gets more interesting with IBM: -- ibm1.5 vs. sun1.5 Total: 99.77% good, 0% bad, 0.22% missing java.lang: Missing method java.lang.StringBuilder.append(java.lang.StringBuilder): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.capacity(): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.charAt(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointAt(int): missing in /home/stefano/data/japi/sun1.5 method
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
Paulex Yang wrote: Geir Magnusson Jr. wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: did we decide not to go to TestNG? Sigh...I guess there must be too many ones have waited too long for TestNG...(including me) I don't understand - what do you mean? Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it cannot be used for months, so people may think let's just use JUnit instead... What's left for j.u.c? I lost track of that Saga, IIRC. Ignore it, I'm all for TestNG...:) geir Paulex - being desperate
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
All, I have added a patch to http://issues.apache.org/jira/browse/HARMONY-2077 [doc] Good issue resolution guideline, though some things are rephrased though. On 11/6/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Alexey, Thank you for your answer. Yesterday I tried to prepare an appropriate patch for get-involved.html but faced several things I couldn't resolve myself. I didn't criticize your text - I was thinking how to fit it into get-involved.html. That is why I raised all these questions. I still have one question which is important, to my mind. You wrote, DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 1. As Geir says, we are small community, and we need to keep ourselves concentrated. Can we give a recommendation to concentrate on one specific VM assuming that VM which is shipped with Harmony 1.0? 2. What is the status of DRLVM smoke tests? As any tests written in java they have a dependency from a class library. Do you think they should be skipped while testing the patch? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 2:03 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) 2006/11/6, Fedotov, Alexei A [EMAIL PROTECTED]: Alexey, I started looking into this thread. Are guidelines on the web site already? I failed to find them. No, this guideline is not published yet. I'll do this in the nearest future. I thought about adding them to get-involved.html. Here are few problems I've noticed: First of all As you know patches are always welcome in Harmony :) 1. The detail level of your instruction is somewhat different from get-involved.html. This text is formal, while the text on the page is quite informal. I do not see problem here. 2. If a guy has a test in a separate file, should he produce a patch from such file and submit the patch? According to guidelines, the answer is yes. Do you mean in a new file? Yes, a new file should be provided as a patch too. Why not? According to my common sense patches are good when you modify existing files. Yes, they are good for modified files. And they also can be used for adding and removing files. 3. Why it is not suggested for an issue reporter to try localizing a buggy module I think that points 2 and 3 are saying this. or even fixing the problem? Nobody said that an issue reporter can not be a resolution provider. 4. Item 4. of issue reporter guidelines doesn't contain enough details for my taste. I believe links should be descriptive: Link the issue to previous posts, JIRAs, RI bugs, etc. Probably your sentence is better. Need to think. 5. The item 2.1 of resolution provider guidelines contains too many details to my mind. Here should be something like a following text (for all roles): a. Update JIRA once per day reporting your progress. b. Always keep the community posted. What for? Why do you want to have DAILY posts on ALL the working issues? I think that we do not need to change anything here since comunity has agreed on the list of notifications it wants to see. And all these cases are described there. 6. The item 2.4 refers to class library build.xml as a main build.xml. Patches are welcome :) 7. You do not specify which unit tests should pass and which VM should be used. Since the changes could affect DRLVM, I would say that all unit tests should pass for DRLVM unless the fall into exclude list. DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 8. I believe a verification stage should happen before committer commits a patch - this would save his time if the issue doesn't resolve the problem. Yes, and nobody argue with this. SY, Alexey -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) :) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a
Re: [general] Interesting discoveries playing around with japitools
Alexey wrote, As far as I remember TCK does not check for signature compatibility. http://jcp.org/en/resources/tdk reads: Signature Test tool The Signature Test tool verifies that a Java technology implementation undergoing compatibility testing and its reference APIs are mutually compatible as defined in Chapter 13, Binary Compatibility, of The Java Language Specification. The tool automates this verification process with a signature test algorithm that compares the API under test with a reference API. On 11/5/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Really interesting results! :) It seems that japitools are not used for certification :) As far as I remember TCK does not check for signature compatibility. It's just a number (huge number) of tests... SY, Alexey 2006/11/5, Stefano Mazzocchi [EMAIL PROTECTED]: Being a sucker for statistics and charts, I've decided to look into japitools myself and regenerate the graph of API coverage progress of harmony. In doing so, I started to familiarize myself with the Japitools and I found a few interesting discoveries: the latest version of the three freely available certified java 5 implementations (Sun's, BEA's and IBM's) are *NOT* 100% compatible. So, here's what I did: 1) download the three JVMs 2) download japitools, tar xzf it and cd japitools 3) type: ./bin/japize as $name packages \ /path/to/jvms/$name/jre/lib/*.jar \ +java +javax +org -org.apache -org.ietf and substitute $name with the JVM name 4) you'll obtain three $name.japi.gz files (the binary representation of your API footprint) 5) then type japicompat -s $original.japi.gz $test.japi.gz where original is the JVM that you consider the reference and $test is the one that you want to test. Here are the (a little surprising, I must say) results: -- sun 1.5 vs. bea1.5 --- 99.99% good, 0% missing java.awt.peer: method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in /home/stefano/data/japi/ibm1.5 -- sun 1.5 vs. ibm1.5 --- Total: 99.93% good, 0% bad, 0.06% missing java.awt.peer: Missing method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in /home/stefano/data/japi/ibm1.5 javax.xml.datatype: Bad field javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS: constant [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl] in /home/stefano/data/japi/sun1.5, but constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in /home/stefano/data/japi/ibm1.5 org.omg.stub.javax.management.remote.rmi: Missing class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in /home/stefano/data/japi/ibm1.5 class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie: missing in /home/stefano/data/japi/ibm1.5 org.w3c.dom.html: Missing method org.w3c.dom.html.HTMLFrameElement.getContentDocument(): missing in /home/stefano/data/japi/ibm1.5 method org.w3c.dom.html.HTMLIFrameElement.getContentDocument(): missing in /home/stefano/data/japi/ibm1.5 method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing in /home/stefano/data/japi/ibm1.5 method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing in /home/stefano/data/japi/ibm1.5 - o - There is one method that both Bea and IBM don't implement in awt.peer.WindowPeer and apparently, Sun doesn't implement it either.. it's just a stub! Weird. [see more at http://forums.java.net/jive/thread.jspa?messageID=167137] the differences in datatype factory is plausible and the fact that a stub RMI class is missing is not that big of a deal. It's weird though, that the DOM in IBM's is different than the DOM in Sun's... I guess not that many people use the HTML DOM in java or they would have got that ;-) The really crazy things start to happen if you flip things around and you consider the 'clean room rewrites' as the reference implementations: -- bea1.5 vs. sun1.5 Total: 99.98% good, 0.01% missing javax.xml.namespace: Missing class javax.xml.namespace.QName: missing in /home/stefano/data/japi/sun1.5 Uh? Sun forgot to ship the QName class or this is a japitools bug? googling up shows the class in the java1.5 docs so it's more likely it's a bug in japitools http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/namespace/QName.html Gets more interesting with IBM: -- ibm1.5 vs. sun1.5 Total: 99.77% good, 0% bad, 0.22% missing java.lang: Missing method java.lang.StringBuilder.append(java.lang.StringBuilder): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.capacity(): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.charAt(int): missing in /home/stefano/data/japi/sun1.5 method
Re: [drlvm][jit] Moving jet to the top level of drlvm...
Jet is a startup fast compilation path, not a seperate pluggable jit. So, while modularity and seperation are important requirements, they may not be needed here. JET can work standalone (-Xem:jet specified), OPT can work standalone (-Xem:opt), so from outside POV they are independent. Also, correct me if I'm wrong, OPT does not reuse the results of JET compilation when recompiling methods - it has its own completely independent pipeline. We have lots of GCs now but we only have one JIT although modularity concept of DRLVM allows to create different JITs. Also, Mikhail and Alex are the best people to decide on this.They are literally the two people who know this code best :-) Sure they are. That's why I've asked. They both have opposite POVs though. -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
2006/11/6, Alexei Fedotov [EMAIL PROTECTED]: All, I have added a patch to http://issues.apache.org/jira/browse/HARMONY-2077 [doc] Good issue resolution guideline, though some things are rephrased though. I do not think that we need to insert this guideline to get involved page. I personally prefer separate document. And text in your patch looks totally different to the text which was agreed on harmony-dev list. SY, Alexey On 11/6/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Alexey, Thank you for your answer. Yesterday I tried to prepare an appropriate patch for get-involved.html but faced several things I couldn't resolve myself. I didn't criticize your text - I was thinking how to fit it into get-involved.html. That is why I raised all these questions. I still have one question which is important, to my mind. You wrote, DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 1. As Geir says, we are small community, and we need to keep ourselves concentrated. Can we give a recommendation to concentrate on one specific VM assuming that VM which is shipped with Harmony 1.0? 2. What is the status of DRLVM smoke tests? As any tests written in java they have a dependency from a class library. Do you think they should be skipped while testing the patch? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 2:03 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) 2006/11/6, Fedotov, Alexei A [EMAIL PROTECTED]: Alexey, I started looking into this thread. Are guidelines on the web site already? I failed to find them. No, this guideline is not published yet. I'll do this in the nearest future. I thought about adding them to get-involved.html. Here are few problems I've noticed: First of all As you know patches are always welcome in Harmony :) 1. The detail level of your instruction is somewhat different from get-involved.html. This text is formal, while the text on the page is quite informal. I do not see problem here. 2. If a guy has a test in a separate file, should he produce a patch from such file and submit the patch? According to guidelines, the answer is yes. Do you mean in a new file? Yes, a new file should be provided as a patch too. Why not? According to my common sense patches are good when you modify existing files. Yes, they are good for modified files. And they also can be used for adding and removing files. 3. Why it is not suggested for an issue reporter to try localizing a buggy module I think that points 2 and 3 are saying this. or even fixing the problem? Nobody said that an issue reporter can not be a resolution provider. 4. Item 4. of issue reporter guidelines doesn't contain enough details for my taste. I believe links should be descriptive: Link the issue to previous posts, JIRAs, RI bugs, etc. Probably your sentence is better. Need to think. 5. The item 2.1 of resolution provider guidelines contains too many details to my mind. Here should be something like a following text (for all roles): a. Update JIRA once per day reporting your progress. b. Always keep the community posted. What for? Why do you want to have DAILY posts on ALL the working issues? I think that we do not need to change anything here since comunity has agreed on the list of notifications it wants to see. And all these cases are described there. 6. The item 2.4 refers to class library build.xml as a main build.xml. Patches are welcome :) 7. You do not specify which unit tests should pass and which VM should be used. Since the changes could affect DRLVM, I would say that all unit tests should pass for DRLVM unless the fall into exclude list. DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 8. I believe a verification stage should happen before committer commits a patch - this would save his time if the issue doesn't resolve the problem. Yes, and nobody argue with this. SY, Alexey -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) :) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch
Re: [drlvm] HARMONY-1635 heap iteration WAS: [general] version of GCC...
Gregory Shimansky wrote: Salikh Zakirov wrote: Gregory Shimansky wrote: I think you could use 4.1.0 in Fedora Core 5. Since patch level shouldn't really affect the C++ compilation restrictions, the same patch should break on 4.1.0 as well. Gregory, I've looked at harmony-1635.patch you've uploaded to HARMONY-1635, and I see that is based on the outdated patch from HARMONY-1635. (i.e. not the latest version: heap-iteration-optimized.patch). Ok I didn't realize which one to take. So I will upload the updated patch myself. I've checked its compilation on Fedora Core 5 (Bordeaux) with gcc 4.1.0, and it compiles okay. In this case I think it should be committed. If I get any problems with gcc 4.1.1 (which I don't have at hand right now) I'll try to resolve them myself and create an additional fix. I can confirm that gcc 4.1.1 compiled this patch without any problems. As I've written, patchlevel shouldn't matter here, and if gcc 4.1.0 worked, 4.1.1 should work as well (with very rare exceptions). I've just built VM with it without any errors. -- Gregory
Re: [general] Interesting discoveries playing around with japitools
So it looks like I was wrong :) SY, Alexey 2006/11/6, Alexei Fedotov [EMAIL PROTECTED]: Alexey wrote, As far as I remember TCK does not check for signature compatibility. http://jcp.org/en/resources/tdk reads: Signature Test tool The Signature Test tool verifies that a Java technology implementation undergoing compatibility testing and its reference APIs are mutually compatible as defined in Chapter 13, Binary Compatibility, of The Java Language Specification. The tool automates this verification process with a signature test algorithm that compares the API under test with a reference API. On 11/5/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Really interesting results! :) It seems that japitools are not used for certification :) As far as I remember TCK does not check for signature compatibility. It's just a number (huge number) of tests... SY, Alexey 2006/11/5, Stefano Mazzocchi [EMAIL PROTECTED]: Being a sucker for statistics and charts, I've decided to look into japitools myself and regenerate the graph of API coverage progress of harmony. In doing so, I started to familiarize myself with the Japitools and I found a few interesting discoveries: the latest version of the three freely available certified java 5 implementations (Sun's, BEA's and IBM's) are *NOT* 100% compatible. So, here's what I did: 1) download the three JVMs 2) download japitools, tar xzf it and cd japitools 3) type: ./bin/japize as $name packages \ /path/to/jvms/$name/jre/lib/*.jar \ +java +javax +org -org.apache -org.ietf and substitute $name with the JVM name 4) you'll obtain three $name.japi.gz files (the binary representation of your API footprint) 5) then type japicompat -s $original.japi.gz $test.japi.gz where original is the JVM that you consider the reference and $test is the one that you want to test. Here are the (a little surprising, I must say) results: -- sun 1.5 vs. bea1.5 --- 99.99% good, 0% missing java.awt.peer: method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in /home/stefano/data/japi/ibm1.5 -- sun 1.5 vs. ibm1.5 --- Total: 99.93% good, 0% bad, 0.06% missing java.awt.peer: Missing method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in /home/stefano/data/japi/ibm1.5 javax.xml.datatype: Bad field javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS: constant [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl] in /home/stefano/data/japi/sun1.5, but constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in /home/stefano/data/japi/ibm1.5 org.omg.stub.javax.management.remote.rmi: Missing class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in /home/stefano/data/japi/ibm1.5 class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie: missing in /home/stefano/data/japi/ibm1.5 org.w3c.dom.html: Missing method org.w3c.dom.html.HTMLFrameElement.getContentDocument(): missing in /home/stefano/data/japi/ibm1.5 method org.w3c.dom.html.HTMLIFrameElement.getContentDocument(): missing in /home/stefano/data/japi/ibm1.5 method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing in /home/stefano/data/japi/ibm1.5 method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing in /home/stefano/data/japi/ibm1.5 - o - There is one method that both Bea and IBM don't implement in awt.peer.WindowPeer and apparently, Sun doesn't implement it either.. it's just a stub! Weird. [see more at http://forums.java.net/jive/thread.jspa?messageID=167137] the differences in datatype factory is plausible and the fact that a stub RMI class is missing is not that big of a deal. It's weird though, that the DOM in IBM's is different than the DOM in Sun's... I guess not that many people use the HTML DOM in java or they would have got that ;-) The really crazy things start to happen if you flip things around and you consider the 'clean room rewrites' as the reference implementations: -- bea1.5 vs. sun1.5 Total: 99.98% good, 0.01% missing javax.xml.namespace: Missing class javax.xml.namespace.QName: missing in /home/stefano/data/japi/sun1.5 Uh? Sun forgot to ship the QName class or this is a japitools bug? googling up shows the class in the java1.5 docs so it's more likely it's a bug in japitools http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/namespace/QName.html Gets more interesting with IBM: -- ibm1.5 vs. sun1.5 Total: 99.77% good, 0% bad, 0.22% missing java.lang: Missing method java.lang.StringBuilder.append(java.lang.StringBuilder): missing in
Re: [jira] Closed: (HARMONY-1993) A stress test for young generational allocation that measures allocation rate
On 11/5/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 11/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: first, can we also use this test for gcv4.1? Yes. The test is a Java test. The reason I placed it in gc_gen is that it is intended to stress allocation fastpath and corresponding gen 0 collection, and is more useful for tuning these. Rana, Xiao Feng, Please test. I am not building GCv5 right now. I retested on XP and RHEL Linux. BTW, gc_cc and gc_gen directories are both part of the regular builds now.
Re: [drlvm] HARMONY-1635 heap iteration WAS: [general] version of GCC...
Yes, I use a gcc version 4.0.2 on RHEL. I have no problems building + running it now I can confirm that gcc 4.1.1 compiled this patch without any problems. As I've written, patchlevel shouldn't matter here, and if gcc 4.1.0 worked, 4.1.1 should work as well (with very rare exceptions). I've just built VM with it without any errors. -- Gregory
Re: [DRLVM] General stability
Weldon Washburn wrote: Folks, I have spent the last two months committing patches to the VM. While we have added a ton of much needed functionality, the stability of the system has been ignored. By chance, I looked at thread synchronization design problems this week. Its very apparent that we lack the regression testing to really find threading bugs, test the fixes and test against regression. No doubt there are similar problems in other VM subsystems. build test is necessary but not sufficient for where we need to go. In a sense, committing code with only build test to prevent regression is the equivalent to flying in the fog without instrumentation. So that we can get engineers focused on stability, I am thinking of coding the JIRAs that involve new features as later or even won't fix. Please feel free to comment. We also need to restart the old email threads on regression tests. For example, we need some sort of automated test script that runs Eclipse and tomcat, etc. in a deterministic fashion so that we can compare test results. It does not have to be perfect for starts, just repeatable and easy to use. Feel free to beat me to starting these threads :) In my experience on working with drlvm, stability problems are often discovered on the existing VM acceptance tests. Big applications like eclipse or tomcat with long workloads usually reveal problems like lack of class unloading unless they crash on something like threading problems. The acceptance VM tests that we have already are a good start to test stability if they are ran nonstop many times. I don't say that we shouldn't have real application workloads. I just want to say that acceptance tests already usually reveal threading problems quite well if they are ran many times, and race conditions happen in some circumstances. However at the moment we already have failing tests, some of them like gc.LOS on WinXP don't need multiple times to make them fail. There's also java.lang.ThreadTest which fails for me on Windows 2003 server SP1 and now started to fail on Linux as well. -- Gregory
Re: Japi diffs for harmony
I tried sending this previously, but Stefano seems to have not received it (at least I got no response or followup) and (as I suspected) the list definitely didn't because I wasn't subscribed. I subscribed to the digest version now so that I'm not so excluded from japitools-related discussion on harmony-dev. My response to Stefano's questions is below. I've seen further discussion on japitools in the harmony-dev archives and I'll send separate mail addressing the japi-related bits of that. Stuart. -- Forwarded message -- From: Stuart Ballard [EMAIL PROTECTED] Date: Nov 3, 2006 12:29 PM Subject: Re: Japi diffs for harmony To: Stefano Mazzocchi [EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org (this will probably bounce from harmony-dev, I'm not subscribed; feel free to forward it) On 11/3/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Stuart, I'm a *huge* fan of your Japi diffs (I admit that I have a sort of obsessive compulsion about it, getting happy with every small percentage increase and sad when it decreases). *grin* I do the same thing for Classpath. To be honest I find the Harmony results confusing myself; sometimes they seem to bounce up and down with the same errors getting added and removed over and over again. I'm dependent on an unofficial source for Japi files of Harmony, though, because the project doesn't provide official nightly builds as far as I know - and my suspicion is that perhaps different variations are getting built and I'm getting which ever happens to be the last that was built. I haven't gotten around to asking, though, sorry about that. If I could grab an actual tarball of the very latest build at any given time, I'd like that better. See http://builder.classpath.org/dist/ for what they do which is perfect for me. That said, I have a few questions to ask, see below. Great, I'm always happy to clarify this stuff :) It tells me there are 10 packages and 52 classes missing. Great. Then it gives me a percentage. Who is that percentage calculated? Is it by class coverage? method coverage? package coverage? a weighted sum of all the above? The percentages are admittedly difficult to define in a way that's truly meaningful, but the idea of *having* a percentage was too compelling for me not to try to come up with a definition. So here's how Japi calculates it: First of all, anything whatsoever that's neither public nor protected is discarded. Each class or interface (or enum or annotation) counts as one item. Each field, method or constructor within a class counts as one item. *Including* inherited fields and methods, regardless of whether they get overridden in the class itself. Each of these items gets classified as good, bad, minor or missing. If an entire class is missing, *all* its members are classified as missing. Likewise if an entire package is classified as missing, all the classes within it and all their members are counted as missing. If there is more than one error on the same item (eg a class is incorrectly abstract, doesn't implement the right interface *and* has the wrong serialVersionUID) it still only counts as bad once (the serialVersionUID is a minor error but the bad errors take precedence). The percentages are then calculated based on the total count in the left-hand API. In other words if a particular package in the RI had only one single interface with four methods, of which Harmony implemented two correctly and one incorrectly, the percentages for that package would be: 60% good (the interface itself + 2 methods) 20% bad (one method) 20% missing (one method) If Harmony also incorrectly added an extra method to the interface, it would be 60% good, 20% bad, 20% missing, 20% abs. add. (Because while adding members in general is legal, because it's backwards compatible, adding methods to interfaces or abstract classes that have public or protected constructors is not). And yes, that's a total of 120%, because it's a percentage of the left-hand API, and an abs-add error indicates something outside that API. Incidentally the inclusion of inherited members for calculating the percentage causes some strange effects; - because of inherited methods from Object, simply declaring a class has a disproportionate effect, even if none of the declared members of that class itself are present. And because an enum, for example, inherits so many members from Object and Enum, merely declaring an enum has a hugely disproportionate effect compared to the tiny amount of code it takes. But I couldn't come up with another way of defining the percentages that would make sense and be self-consistent. The reasons why are a little complicated and this email is already long so I won't go into them, though. How is it possible that jdk15 vs harmony is 94.66% and harmony vs jdk15 is 90.88% Wow, I'm impressed that harmony is 94.66 against 1.5. That's incredibly good progress - especially if all of that is actual functional implementations
Re: [drlvm][jit] Moving jet to the top level of drlvm...
Agreed. Without the explanation of JET as only a fast path, I also thought JET and OPT are two different JITs. And actually as I can recall, JET and OPT are indeed treated as two different JITs that the EM can select in the JITs chain. Honestly, different paths give me an impression that they are different JITs, unless they share many common compilation steps (passes). If they start from different IR and end in different emitter, it would be hard to convince people they are only different paths of the same JIT. But anyway, this is only my observation. JIT developers decide how to modularize JIT. Thanks, xiaofeng On 11/7/06, Pavel Pervov [EMAIL PROTECTED] wrote: Jet is a startup fast compilation path, not a seperate pluggable jit. So, while modularity and seperation are important requirements, they may not be needed here. JET can work standalone (-Xem:jet specified), OPT can work standalone (-Xem:opt), so from outside POV they are independent. Also, correct me if I'm wrong, OPT does not reuse the results of JET compilation when recompiling methods - it has its own completely independent pipeline. We have lots of GCs now but we only have one JIT although modularity concept of DRLVM allows to create different JITs. Also, Mikhail and Alex are the best people to decide on this.They are literally the two people who know this code best :-) Sure they are. That's why I've asked. They both have opposite POVs though. -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [classlib][java.math] optimization of BigInteger.modPow and BigInteger.pow
Hi Alexey, yes we often tested the speed in our several attempts to improve performance. Comparing modPow before and after this new patch gave us the following figures: size before after 16 5.636e+05 6.351e+05 32 9.727e+04 1.293e+05 48 3.225e+04 4.623e+04 64 1.436e+04 2.148e+04 128 19413114 192590 970 256252 420 384 75127 512 32 55 where the first column shows the size of the arguments in bytes and the other two the number of modPow operations per 100 seconds before and after the patch. The method modPow is used in cryptography, we tested several cryptographic algorithms obtaining in all cases figures in favor of the optimized version (the one in the patch). For instance, for RSA key generation we obtained: size before after 5123,00 2,06 102420,1713,58 2048 280,38 149,48 where the first column shows the length of the key in bits and the other two the time in seconds taken to perform 30 iterations of the key generation algorithm before and after the patch. Thanks, Daniel On 11/3/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Hi, Daniel. Great job! Have you made any performance testing to understand how much the patch increases the speed of the methods? SY, Alexey 2006/11/3, Daniel Fridlender [EMAIL PROTECTED]: Hi, We have submitted in http://issues.apache.org/jira/browse/HARMONY-1981 an optimization of BigInteger methods modPow and pow. The optimization in modPow was achieved by introducing sliding windows instead of the square-and-multiply method. Some gain was obtained also from an optimized Montgomery multiplication used for computing squares. The method pow was optimized accordingly by improving the computation of squares. Thanks Daniel
Re: Interesting discoveries playing around with japitools
I've been following this thread as best I can from the archives. I suspect the results you're getting were from the last release of Japitools. I can't blame you for this - I ought to have made a new one long ago - but the last release has a bunch of known bugs compared to the current code. In particular the last release should definitely not be used for anything where 1.5 language features are present. The latest CVS code should be vastly improved; if you try this and you're still seeing unexplained discrepancies, please let me know. I'm planning to bundle up the current code into a new release in the next few days, and I'm also revamping the website with the intention to make it clear that the CVS code exists and is generally recommended. (The very-much-work-in-progress new site can be seen at http://sab39.netreach.com/japi). One particular issue of note, because it concerns an issue that I just (re)discovered on the Classpath results also: QName appears to trigger an ecj bug in certain versions which produces an invalid class file by incorrectly inheriting a generic parameter into a *static* inner class. Apparently the latest ecj fixes this. I'm not 100% sure that this is the issue that's causing it to be incorrectly reported missing - but it seems awfully coincidental that the very same class with that issue is the one that you're seeing problems on. I'd really love if some Harmony developers would join the japitools mailing list if you're interested in the Japi results and how to make best use of them. I plan to announce both the lists and the new website more prominently when I have a new release to announce as well, but seeing as there was active discussion going on right now, I didn't want to wait. (Yes, the japitools list is on an FSF server. I really really hope that this isn't going to be a political problem for you guys. I selected Savannah for hosting japitools before Harmony even existed, because it made most sense at the time when Classpath developers were the main users. Please don't let that hinder our ability to communicate on something that makes sense for all projects concerned) Stuart. -- http://sab39.dev.netreach.com/
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
On 11/6/06, Paulex Yang [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: did we decide not to go to TestNG? Sigh...I guess there must be too many ones have waited too long for TestNG...(including me) I don't understand - what do you mean? Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it cannot be used for months, so people may think let's just use JUnit instead... Ignore it, I'm all for TestNG...:) If you're looking for another opinion, I'm not convinced. JUnit 4.x seems just as capable as TestNG. -Nathan geir Paulex - being desperate -- Paulex Yang China Software Development Lab IBM
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
On 11/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: did we decide not to go to TestNG? Sigh...I guess there must be too many ones have waited too long for TestNG...(including me) I don't understand - what do you mean? Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it cannot be used for months, so people may think let's just use JUnit instead... What's left for j.u.c? I lost track of that Saga, IIRC. I believe we're down to agreeing to the Objects/Threads classes [1] in luni-kernel and getting them implemented in DRLVM and the donated IBM VM. I believe the Unsafe class needs to be re-implemented with these interfaces, but that may already be done. -Nathan [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/ Ignore it, I'm all for TestNG...:) geir Paulex - being desperate
Re: Interesting discoveries playing around with japitools
Stuart Ballard wrote: I've been following this thread as best I can from the archives. eheh, good luck with that. (I'm keeping you copied so that it's easier for you to follow) I suspect the results you're getting were from the last release of Japitools. I can't blame you for this - I ought to have made a new one long ago - but the last release has a bunch of known bugs compared to the current code. In particular the last release should definitely not be used for anything where 1.5 language features are present. ah-ha! awesome, I'll try that later. The latest CVS code should be vastly improved; if you try this and you're still seeing unexplained discrepancies, please let me know. oh, rest assure I will :-) I'm planning to bundle up the current code into a new release in the next few days, and I'm also revamping the website with the intention to make it clear that the CVS code exists and is generally recommended. (The very-much-work-in-progress new site can be seen at http://sab39.netreach.com/japi). very cool, a much needed revamp, if you ask me ;-) If you need some CSS/webdesign skills, I'll be happy to give a hand. One particular issue of note, because it concerns an issue that I just (re)discovered on the Classpath results also: QName appears to trigger an ecj bug in certain versions which produces an invalid class file by incorrectly inheriting a generic parameter into a *static* inner class. Apparently the latest ecj fixes this. I'm not 100% sure that this is the issue that's causing it to be incorrectly reported missing - but it seems awfully coincidental that the very same class with that issue is the one that you're seeing problems on. Interesting. I'd really love if some Harmony developers would join the japitools mailing list if you're interested in the Japi results and how to make best use of them. I plan to announce both the lists and the new website more prominently when I have a new release to announce as well, but seeing as there was active discussion going on right now, I didn't want to wait. oh, didn't even know one existed. (Yes, the japitools list is on an FSF server. I really really hope that this isn't going to be a political problem for you guys. I selected Savannah for hosting japitools before Harmony even existed, because it made most sense at the time when Classpath developers were the main users. Please don't let that hinder our ability to communicate on something that makes sense for all projects concerned) you kidding? of course I'll join. -- Stefano.
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
On 11/7/06, Nathan Beyer [EMAIL PROTECTED] wrote: On 11/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: did we decide not to go to TestNG? Sigh...I guess there must be too many ones have waited too long for TestNG...(including me) I don't understand - what do you mean? Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it cannot be used for months, so people may think let's just use JUnit instead... What's left for j.u.c? I lost track of that Saga, IIRC. I believe we're down to agreeing to the Objects/Threads classes [1] in luni-kernel and getting them implemented in DRLVM and the donated IBM VM. I believe the Unsafe class needs to be re-implemented with these interfaces, but that may already be done. Yes, I just run testNG successfully by appending suncompat.jar and luni-kernel-stubs.jar to bootclasspath ;-) -Nathan [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/ Ignore it, I'm all for TestNG...:) geir Paulex - being desperate -- Richard Liang China Development Lab, IBM
Re: [classlib][luni][charset]Strange behavior of UnicodeBig
On 11/6/06, Tony Wu [EMAIL PROTECTED] wrote: A bad news, ICU team refused to support UnicodeBig because it is not available in nio. A good news is that I realize there is a smooth way to support these charsets. I tried to implement a SPI to accept the name UnicodeBig and it worked. We could support any other charsets and fix the bug which ICU team hesitated to do this way. I think it also brings us the extensibility, do you have any concern about implementing a harmony SPI? I'll go on if no one objects. Hey Tony, if we only consider io/lang to support UnicodeBig, will the thing be simpler? On 10/19/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 10/19/06, Tony Wu [EMAIL PROTECTED] wrote: I think to support UnicodeBig in nio is not a bug but a feature. And the key point is how can I get UnicodeBig supportted in IO/Lang? If ICU/NIO supports UnicodeBig, wouldn't IO/LANG support UnicodeBig as well? On 10/19/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 10/19/06, Tony Wu [EMAIL PROTECTED] wrote: The implemetion is from ICU, so, I think we'd better not to wrap it by ourselves. I'll post to ICU mailing list and ask if they can help to supply these legacy charsets. Hey Tony, please keep in mind that following code[1] should print false and throw an UnsupportedCharsetException. If ICU provides UnicodeBig support, does it mean harmony nio also support UnicodeBig? [1] System.out.println(Charset.isSupported(UnicodeBig)); Charset.forName(UncodeBig); On 10/19/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 10/19/06, Tony Wu [EMAIL PROTECTED] wrote: Thank you all, It is not just an issue about name. The precondition of mapping is that ICU has really supported this charset. AFAIK UnicodeBig is not implemented by ICU, refer to [1]. Shall we map the UnicodeBitUnicodeLittle to UTF-16 as work around[2]? No, I don't think so. The only difference between UnicodeBig and UTF-16BE is with/without byte-order mark. So it should be easy to wrap UTF-16BE as UnicodeBig for java.io/java.lang. Just put 0xFE 0xFF at the begining of the bytes and then encode the buffer as UTF-16BE. Do I miss something? [1]http://dev.icu- project.org/cgi-bin/viewcvs.cgi/icu/source/data/mappings/convrtrs.txt?view=co [2] UTF-16 Sixteen-bit UCS Transformation Format, byte order identified by an optional byte-order mark UnicodeBig Sixteen-bit Unicode Transformation Format, big-endian byte order, with byte-order mark UnicodeLittle Sixteen-bit Unicode Transformation Format, little-endian byte order, with byte-order mark On 10/17/06, Paulex Yang [EMAIL PROTECTED] wrote: Tony Wu wrote: Thank you Andrew, I think I got the point. The j.l.String of RI uses the encoding of IO whereas Charset.forName use another of NIO. And the new problem is shall we follow the spec[1] to support the two suites of charset implemetation? I just have a look and find we does not support some Canonical Name for java.io and java.langAPI such as UnicodeBigUnmarked,UnicodeLittleUnmarked,UnicodeBig,Unicodelittle,etc. There is such a charset name mapping in InputStreamReader, I think we have no choice but to support these legacy charset names, you may need some refactory work to make these classes use the same mapping data. [1] http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 10/17/06, Leo Li [EMAIL PROTECTED] wrote: I think Harmony is more reasonable. As spec says, if Charset.forName(UnicodeBig) throws .UnsupportedCharsetException then no support for the named charset is available in this instance of the Java virtual machine. Then how can we get new String(b, UnicodeBig) without throwing UnsupportedCharsetException on the same jvm? The spec for String(byte[] bytes,String charsetName) also says if the named charset is not supported, UnsupportedCharsetException should be thrown out. UNICODEBIG is a java alias for UTF-16BE. I think we'd better support such mapping in String and follow RI. You can find the encoding set from spec. [1] [1] http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html On 10/17/06, Tony Wu [EMAIL PROTECTED] wrote: Hi all, I found this when I tried to
Re: [drlvm][jit] Moving jet to the top level of drlvm...
-1 to separating Jitrino.JET and Jitrino.OPT. As Mikhail and Alex said, JET and OPT share their code in many areas. So, to achieve true modularity separating them we'll need either to duplicate shared code or externalize internal JIT interfaces. The former is definitely bad and the latter implies introducing some public JIT-JIT interface and putting the shared code top-level as well. This shared code actually might not be necessary for other JIT implementations. So I'd leave Jitrino dir as a home for the Jitrino family. Any new JIT implementation which won't re-use internal Jitrino code may go to the top-level dir. Thank you, Pavel On 11/7/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Agreed. Without the explanation of JET as only a fast path, I also thought JET and OPT are two different JITs. And actually as I can recall, JET and OPT are indeed treated as two different JITs that the EM can select in the JITs chain. Honestly, different paths give me an impression that they are different JITs, unless they share many common compilation steps (passes). If they start from different IR and end in different emitter, it would be hard to convince people they are only different paths of the same JIT. But anyway, this is only my observation. JIT developers decide how to modularize JIT. Thanks, xiaofeng On 11/7/06, Pavel Pervov [EMAIL PROTECTED] wrote: Jet is a startup fast compilation path, not a seperate pluggable jit. So, while modularity and seperation are important requirements, they may not be needed here. JET can work standalone (-Xem:jet specified), OPT can work standalone (-Xem:opt), so from outside POV they are independent. Also, correct me if I'm wrong, OPT does not reuse the results of JET compilation when recompiling methods - it has its own completely independent pipeline. We have lots of GCs now but we only have one JIT although modularity concept of DRLVM allows to create different JITs. Also, Mikhail and Alex are the best people to decide on this.They are literally the two people who know this code best :-) Sure they are. That's why I've asked. They both have opposite POVs though. -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [drlvm] [ipf] I suggest a series of patches for ipf code generator
On the 0x216 day of Apache Harmony Konstantin Anisimov wrote:
Hi all,
I suggest new patch from the series Igor introdusced.
1. To move direct predicated calls in separete node. It allows to have under
predicate short branch instruction instead of call and thus
reduce possible misprediction penalty.
2. I have implemented new node merging algorithm. It is more effective than
previouc one and besides purging empty nodes.
All changes made in Code layouting and I suggest integrate them in one
patch.
Konstantin,
I took a quick look at the HARMONY-2061 you are introducing. Changes
look generally good to me, but I have some suggestions (some minor and
some requiring to update the patch).
Here they are for the easier reply. I'll duplicate them in JIRA for
the easier tracking.
Changes do *not* affect the IA-32 build. Which is great! (I verified
this)
I am slightly unhappy with changes like:
+++ include/IpfCodeLayouter.h (working copy)
@@ -17,7 +17,7 @@
/**
* @author Intel, Konstantin M. Anisimov, Igor V. Chebykin
- * @version $Revision$
+ * @version $Revision: 1.1.1.6 $
*
*/
is it easy to overcome them? maybe, remove the $Revision$ keyword at
all? too CVS-ish, not for today
Why do you use 'map' instead of more commonly used StlMap
(MemoryManager based)? For the sake of safety to memory leakage we
use memory managers (and allocate them on stack). I understand that
your map is allocated on stack, and, hence induces no memory leakage,
but it is not like the common style we use. Someone can allocate the
map in heap by mistake. Could you, please, make it an StlMap?
I see some bugfixes. Cool :)
here:
@@ -436,7 +538,8 @@
// Add branch to through edge target
Opnd*p0 = cfg.getOpndManager()-getP0();
NodeRef *targetNode = cfg.getOpndManager()-newNodeRef(target);
-node-addInst(new(mm) Inst(INST_BR, CMPLT_BTYPE_COND, p0, targetNode));
+//node-addInst(new(mm) Inst(mm, INST_BR, CMPLT_BTYPE_COND, CMPLT_WH_SPTK,
p0, targetNode));
+node-addInst(new(mm) Inst(mm, INST_BR, CMPLT_WH_SPTK, CMPLT_PH_FEW, p0,
targetNode));
does it make sense to leave this line commented-out? Please, remove it
completely.
Minor suggestion: please, provide patches for the working_vm
directory, or one level above, otherwise it needs an extra guess where
to apply it (this time it is vm/jitrino/src/codegenerator/ipf)
RegOpnd constructor signature changed, but no changes followed in the
implementation
(IpfOpnd.cpp). You probably forgot to include the file into the diff. Please,
update.
Do I get it right that the new CFG verifier is going to be put in the
IpfCfgVerifier.{cpp|h}? Is it going to be worked out soon? Who is
working on it?
Igor Chebykin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hello all,
I suggest a short series of patches for drlvm ipf code generator.
We have some improvements for jitrino/ipf
and would like to commit its to harmony.
All patches will change only vm/jitrino/src/codegenerator/ipf/* files,
therefore ia32 remains OK.
The first patch is about 67k size and contains following files:
IpfCfg.h, IpfCfg.cpp
methods added in Edge and Node classes
IpfCodeLayouter.h, IpfCodeLayouter.cpp
new BotomUp algorithm implementation
IpfEmitter.h, IpfEmitter.cpp
minor changes in logging, Emitter::registerDirectCall() and
debugging support
IpfIrPrinter.h, IpfIrPrinter.cpp
added method to print Node chains
IpfType.h
types to support Node chains added
IpfCfgVerifier.cpp
method cfg.getArgs() deprecated
IpfInst.cpp
methods to identify inst kind added (isBr, isCall
)
IpfRegisterAllocator.cpp
minor changes in logging
Thanks,
Igor.
--
Igor Chebykin, 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]
--
Egor Pasko
Re: [DRLVM] General stability
2006/11/7, Gregory Shimansky [EMAIL PROTECTED]: Weldon Washburn wrote: Folks, I have spent the last two months committing patches to the VM. While we have added a ton of much needed functionality, the stability of the system has been ignored. By chance, I looked at thread synchronization design problems this week. Its very apparent that we lack the regression testing to really find threading bugs, test the fixes and test against regression. No doubt there are similar problems in other VM subsystems. build test is necessary but not sufficient for where we need to go. In a sense, committing code with only build test to prevent regression is the equivalent to flying in the fog without instrumentation. So that we can get engineers focused on stability, I am thinking of coding the JIRAs that involve new features as later or even won't fix. Please feel free to comment. We also need to restart the old email threads on regression tests. For example, we need some sort of automated test script that runs Eclipse and tomcat, etc. in a deterministic fashion so that we can compare test results. It does not have to be perfect for starts, just repeatable and easy to use. Feel free to beat me to starting these threads :) In my experience on working with drlvm, stability problems are often discovered on the existing VM acceptance tests. Big applications like eclipse or tomcat with long workloads usually reveal problems like lack of class unloading unless they crash on something like threading problems. The acceptance VM tests that we have already are a good start to test stability if they are ran nonstop many times. Gregory, But do we have needed scripts/tools readily available to run and analyze such stability testing? I'm also pretty sure existing c-unit and smoke tests would help to reveal certain problems if run repeatedly - just need to add this stuff to CC and run it nightly. Anybody volunteer? And yet there are a lot of excluded tests in smoke suite... -- Alexey I don't say that we shouldn't have real application workloads. I just want to say that acceptance tests already usually reveal threading problems quite well if they are ran many times, and race conditions happen in some circumstances. However at the moment we already have failing tests, some of them like gc.LOS on WinXP don't need multiple times to make them fail. There's also java.lang.ThreadTest which fails for me on Windows 2003 server SP1 and now started to fail on Linux as well. -- Gregory
Re: [classlib][java.math] optimization of BigInteger.modPow and BigInteger.pow
Daniel, These results looks really cool! Could you please add this data or a link to this thread to the corresponding issue? And I'll look into the issue and applly it. SY, Alexey 2006/11/7, Daniel Fridlender [EMAIL PROTECTED]: Hi Alexey, yes we often tested the speed in our several attempts to improve performance. Comparing modPow before and after this new patch gave us the following figures: size before after 16 5.636e+05 6.351e+05 32 9.727e+04 1.293e+05 48 3.225e+04 4.623e+04 64 1.436e+04 2.148e+04 128 19413114 192590 970 256252 420 384 75127 512 32 55 where the first column shows the size of the arguments in bytes and the other two the number of modPow operations per 100 seconds before and after the patch. The method modPow is used in cryptography, we tested several cryptographic algorithms obtaining in all cases figures in favor of the optimized version (the one in the patch). For instance, for RSA key generation we obtained: size before after 5123,00 2,06 102420,1713,58 2048 280,38 149,48 where the first column shows the length of the key in bits and the other two the time in seconds taken to perform 30 iterations of the key generation algorithm before and after the patch. Thanks, Daniel On 11/3/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Hi, Daniel. Great job! Have you made any performance testing to understand how much the patch increases the speed of the methods? SY, Alexey 2006/11/3, Daniel Fridlender [EMAIL PROTECTED]: Hi, We have submitted in http://issues.apache.org/jira/browse/HARMONY-1981 an optimization of BigInteger methods modPow and pow. The optimization in modPow was achieved by introducing sliding windows instead of the square-and-multiply method. Some gain was obtained also from an optimized Montgomery multiplication used for computing squares. The method pow was optimized accordingly by improving the computation of squares. Thanks Daniel
RE: [classlib][java.math] optimization of BigInteger.modPow and BigInteger.pow
Good job, Daniel! -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Daniel Fridlender [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 3:22 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][java.math] optimization of BigInteger.modPow and BigInteger.pow Hi Alexey, yes we often tested the speed in our several attempts to improve performance. Comparing modPow before and after this new patch gave us the following figures: size before after 16 5.636e+05 6.351e+05 32 9.727e+04 1.293e+05 48 3.225e+04 4.623e+04 64 1.436e+04 2.148e+04 128 19413114 192590 970 256252 420 384 75127 512 32 55 where the first column shows the size of the arguments in bytes and the other two the number of modPow operations per 100 seconds before and after the patch. The method modPow is used in cryptography, we tested several cryptographic algorithms obtaining in all cases figures in favor of the optimized version (the one in the patch). For instance, for RSA key generation we obtained: size before after 5123,00 2,06 102420,1713,58 2048 280,38 149,48 where the first column shows the length of the key in bits and the other two the time in seconds taken to perform 30 iterations of the key generation algorithm before and after the patch. Thanks, Daniel On 11/3/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Hi, Daniel. Great job! Have you made any performance testing to understand how much the patch increases the speed of the methods? SY, Alexey 2006/11/3, Daniel Fridlender [EMAIL PROTECTED]: Hi, We have submitted in http://issues.apache.org/jira/browse/HARMONY-1981 an optimization of BigInteger methods modPow and pow. The optimization in modPow was achieved by introducing sliding windows instead of the square-and-multiply method. Some gain was obtained also from an optimized Montgomery multiplication used for computing squares. The method pow was optimized accordingly by improving the computation of squares. Thanks Daniel
Re: [drlvm][jit] Moving jet to the top level of drlvm...
Refactoring Pros: * more logical structure, looking cool Refactoring Cons: * takes time * cool look does not help to read the code * more interfaces, possible code duplication * many old patches become outdated because of massive file renaming So, I am (-1) for that kind of refactoring. I feel that nobody would benefit from additional modularity here because nobody suffers from it's absence. Let's fix problems as soon as they become relevant. Now there is a lot of work on stability, compatibility, etc. Rhetoric: Did we overcome all these hard issues and got a lot of time to discuss minor beautifications? On the 0x21A day of Apache Harmony Pavel Ozhdikhin wrote: -1 to separating Jitrino.JET and Jitrino.OPT. As Mikhail and Alex said, JET and OPT share their code in many areas. So, to achieve true modularity separating them we'll need either to duplicate shared code or externalize internal JIT interfaces. The former is definitely bad and the latter implies introducing some public JIT-JIT interface and putting the shared code top-level as well. This shared code actually might not be necessary for other JIT implementations. So I'd leave Jitrino dir as a home for the Jitrino family. Any new JIT implementation which won't re-use internal Jitrino code may go to the top-level dir. Thank you, Pavel On 11/7/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Agreed. Without the explanation of JET as only a fast path, I also thought JET and OPT are two different JITs. And actually as I can recall, JET and OPT are indeed treated as two different JITs that the EM can select in the JITs chain. Honestly, different paths give me an impression that they are different JITs, unless they share many common compilation steps (passes). If they start from different IR and end in different emitter, it would be hard to convince people they are only different paths of the same JIT. But anyway, this is only my observation. JIT developers decide how to modularize JIT. Thanks, xiaofeng On 11/7/06, Pavel Pervov [EMAIL PROTECTED] wrote: Jet is a startup fast compilation path, not a seperate pluggable jit. So, while modularity and seperation are important requirements, they may not be needed here. JET can work standalone (-Xem:jet specified), OPT can work standalone (-Xem:opt), so from outside POV they are independent. Also, correct me if I'm wrong, OPT does not reuse the results of JET compilation when recompiling methods - it has its own completely independent pipeline. We have lots of GCs now but we only have one JIT although modularity concept of DRLVM allows to create different JITs. Also, Mikhail and Alex are the best people to decide on this.They are literally the two people who know this code best :-) Sure they are. That's why I've asked. They both have opposite POVs though. -- Pavel Pervov, Intel Enterprise Solutions Software Division -- Egor Pasko
