Re: [drlvm] release vs. debug
So, the time spent for pre-commit checks won't be a big problem in this case. Enabling JIT to be built in debug by default (what I think we should do) will add just 20-30% to this time. Thanks, Pavel On 11/10/06, Gregory Shimansky [EMAIL PROTECTED] wrote: Well I am always testing patches in _default_ mode which debug for VM, release for JIT and whatever it is for classlib. If defaults change then it will be some other conditions. Average time to run build test is ~60 minutes. Pavel Ozhdikhin wrote: Sure, contributors should check debug or even both debug and release builds and comment about this in JIRA. I'm talking about committers, will they test debug build which takes 5 times more time? And does it mean they will be able to apply 5 times less patches? Actually I'm fine if the committers will check both debug and release builds and I encourage them to check on all supported platforms. But I'm not a committer. :) Thanks, Pavel On 11/10/06, Rana Dasgupta [EMAIL PROTECTED] wrote: I can understand that the contributor may not have access to multiple platforms, but surely he can test using both debug and release builds :-) What do we gain by asking the contributor to test less? Rana On 11/9/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: +1 for debug testing before submitting a patch. But, for pre-commit testing we should be careful saying we'll test all the patches in debug mode. Though it imprves quality of checks, debug build is significantly slower then release, especially when running with interpreter or Jitrino.OPT. I ran build test on the DRLVM built in debug mode and it takes about 5 times more time than release version on my laptop, The times were as follows: build test, Windows XP/ IA32: DRLVM release: 22 min 55 sec DRLVM debug: 99 min 23 sec So, may be the good choice will be to ask patch submitters to check their patches on the debug build and, if the JIRA issue contains comments that this check is passed, committers may test it on release build only. Thanks, Pavel On 11/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Well, since the problem is repeatable :) Gregory Shimansky wrote: Geir Magnusson Jr. wrote: Alexei Zakharov wrote: Hi DRLVM fans, I encountered a rather strange problem while working on some class library tests. At least two tests from the beans module hang (or crash) while running on DRLVM debug builds but work fine on DRLVM release builds. I thought that debug build is something about adding debug symbols to VM binaries and this should not affect the functionality. Can someone shed a light on this? I would think it's just an assertion firing... Actually it is more than that. In debug mode TRACE statements are compiled and therefore produce executable code. There may also be some bugs in compiler generating code in different modes (although this usually happens for release). I don't know why hanging happens, but the difference in generated code is actually quite big. Also assertions or any crashes go to exceptions/signal handlers which may happen to loop infinitely, there were bugs like this happening on the current version of sources, look at HARMONY-2018 and HADMONY-2006. This is the first question. The second question - what we should do with such tests. The tests pass on the downloadable HDK and JRE snapshots as well as on classlib + j9. What should be the commit criteria for DRLVM – i.e. what is the *true* build? :) I think many people here currently use snapshots to test their patches. debug :) don't sweep the problems under the rug... +1 -- Gregory
Re: [drlvm] release vs. debug
On 11/10/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Sure, contributors should check debug or even both debug and release builds and comment about this in JIRA. As far as I understand the only person who answers for the commit is a committer. So I don't think that establishing a policy that shifts a part of responsibility from the committer is a good idea. Well, I have another silly question to gurus indeed. Is there any possibility that some piece of code can break / hang the release build if it passes ok on the debug build? Theoretically it is possible to have problems on release build even if debug build passes the checks. More sofisticated optimizations applied in release build may reveal some subtle error in the code. Practically tis is not a common case though. Thanks, Pavel Thanks, 2006/11/10, Pavel Ozhdikhin [EMAIL PROTECTED]: Sure, contributors should check debug or even both debug and release builds and comment about this in JIRA. I'm talking about committers, will they test debug build which takes 5 times more time? And does it mean they will be able to apply 5 times less patches? Actually I'm fine if the committers will check both debug and release builds and I encourage them to check on all supported platforms. But I'm not a committer. :) Thanks, Pavel On 11/10/06, Rana Dasgupta [EMAIL PROTECTED] wrote: I can understand that the contributor may not have access to multiple platforms, but surely he can test using both debug and release builds :-) What do we gain by asking the contributor to test less? Rana On 11/9/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: +1 for debug testing before submitting a patch. But, for pre-commit testing we should be careful saying we'll test all the patches in debug mode. Though it imprves quality of checks, debug build is significantly slower then release, especially when running with interpreter or Jitrino.OPT. I ran build test on the DRLVM built in debug mode and it takes about 5 times more time than release version on my laptop, The times were as follows: build test, Windows XP/ IA32: DRLVM release: 22 min 55 sec DRLVM debug: 99 min 23 sec So, may be the good choice will be to ask patch submitters to check their patches on the debug build and, if the JIRA issue contains comments that this check is passed, committers may test it on release build only. Thanks, Pavel On 11/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Well, since the problem is repeatable :) Gregory Shimansky wrote: Geir Magnusson Jr. wrote: Alexei Zakharov wrote: Hi DRLVM fans, I encountered a rather strange problem while working on some class library tests. At least two tests from the beans module hang (or crash) while running on DRLVM debug builds but work fine on DRLVM release builds. I thought that debug build is something about adding debug symbols to VM binaries and this should not affect the functionality. Can someone shed a light on this? I would think it's just an assertion firing... Actually it is more than that. In debug mode TRACE statements are compiled and therefore produce executable code. There may also be some bugs in compiler generating code in different modes (although this usually happens for release). I don't know why hanging happens, but the difference in generated code is actually quite big. Also assertions or any crashes go to exceptions/signal handlers which may happen to loop infinitely, there were bugs like this happening on the current version of sources, look at HARMONY-2018 and HADMONY-2006. This is the first question. The second question - what we should do with such tests. The tests pass on the downloadable HDK and JRE snapshots as well as on classlib + j9. What should be the commit criteria for DRLVM – i.e. what is the *true* build? :) I think many people here currently use snapshots to test their patches. debug :) don't sweep the problems under the rug... +1 -- Alexei Zakharov, Intel Enterprise Solutions Software Division
[classlib][sql] SerialJavaObject constructor throws SerialException when the object is unserializable?
Hi folks,
I'm confused by javax.sql.rowset.serial.SerialJavaObject spec. The spec of
SerialJavaObject constructor says throws SerialException if the object is
found to be unserializable. It also mentions Static or transient fields
cannot be serialized; an attempt to serialize them will result in a
SerialException object being thrown. . Does it mean to throw
SerialException if the object doesn't implement Serializable or it contains
static/transient fields? I tried some tests[1], but SerialException is never
thrown. Am I missing something? Thank you in advance for your help!
[1] SerialJavaObject constructor test case:
public void test_Constructor() throws Exception {
Object obj = new NonSerializableClass();
SerialJavaObject sjo = new SerialJavaObject(obj);
}
static class NonSerializableClass {
public static int i;
public static Thread t;
public transient String s;
NonSerializableClass() {
}
}
--
Best regards,
Andrew Zhang
Re: [general] creation of jdktools
Hi, see below. On 11/12/06, Nathan Beyer [EMAIL PROTECTED] wrote: On 11/11/06, Ilya Neverov [EMAIL PROTECTED] wrote: On 10/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: [skip] Assumptions which look reasonable for jdktool's build subsystem: 1) it works in presence of built classlib (as HDK binaries or as a result of classlib phase of overall build); yes - think of the same trick we do w/ DRLVM to reach over to find it. I'd imagine the federated build to then have : trunk/ working_classlib/ working_vm/ working_jdktools/ Commiters, Could you please create empty directory trunk/working_jdktools. I need it to check building jdktools as part of the federated build. Without having the working_jdktools/ in the repository the moving sources and patching buiild files would require additional manual steps. Thank you. -Ilya Are you sure? Assuming you checkout the trunk folder, can't you just create the working_jdktools folder in your working copy and svn add it and then perform all of the moves, etc and then create the diff from that. I may be wrong, but I think I've done this before with SVN. I tried that way but got the svn error on Windows 2003: ... Atrunk\sandbox\geir\build.xml Checked out revision 473980. mkdir trunk\working_jdktools svn add trunk\working_jdktools A trunk\working_jdktools svn switch -r HEAD https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jdktools/trunk; trunk\working_jdktools svn: Failed to add directory 'trunk\working_jdktools': object of the same name already exists Looks like that 'svn switch' can be done for committed dir only; probably the ' schedule=add ' attribute is erased during the switch operation. I'm trying to prepare modifications which can be committed at once to create single revision for the jdktools source move. Currently I use simple 'svn co /jdktools/trunk trunk\working_jdktools' for build checks and such workspace structure would require separate commits for trunk/working_jdktools and for jdktools/trunk. So I have to ask for this preparation step. If not, we can certainly whip it up quick. Would you mind posting the full URL of the folder to create, so we don't screw it up (meaning, so I don't screw it up). Empty dir https://svn.apache.org/repos/asf/incubator/harmony/enhanced/trunk/working_jdktools is asked to be created. -Nathan Thank you -Ilya
Re: svn commit: r473588 - in /incubator/harmony/enhanced/drlvm/trunk/vm: interpreter/src/ port/src/lil/em64t/pim/ vmcore/include/ vmcore/src/util/em64t/base/
Pavel Pervov wrote: Geir, Does SVN support some sort of exclude lists? Of course, http://svnbook.red-bean.com/en/1.1/ch07s02.html (look for the svn:ignore property) -- Stefano.
Re: [general] creation of jdktools
Thanks for trying. I've created the folder. It's at revision 474016. -Nathan On 11/12/06, Ilya Neverov [EMAIL PROTECTED] wrote: Hi, see below. On 11/12/06, Nathan Beyer [EMAIL PROTECTED] wrote: On 11/11/06, Ilya Neverov [EMAIL PROTECTED] wrote: On 10/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: [skip] Assumptions which look reasonable for jdktool's build subsystem: 1) it works in presence of built classlib (as HDK binaries or as a result of classlib phase of overall build); yes - think of the same trick we do w/ DRLVM to reach over to find it. I'd imagine the federated build to then have : trunk/ working_classlib/ working_vm/ working_jdktools/ Commiters, Could you please create empty directory trunk/working_jdktools. I need it to check building jdktools as part of the federated build. Without having the working_jdktools/ in the repository the moving sources and patching buiild files would require additional manual steps. Thank you. -Ilya Are you sure? Assuming you checkout the trunk folder, can't you just create the working_jdktools folder in your working copy and svn add it and then perform all of the moves, etc and then create the diff from that. I may be wrong, but I think I've done this before with SVN. I tried that way but got the svn error on Windows 2003: ... Atrunk\sandbox\geir\build.xml Checked out revision 473980. mkdir trunk\working_jdktools svn add trunk\working_jdktools A trunk\working_jdktools svn switch -r HEAD https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jdktools/trunk; trunk\working_jdktools svn: Failed to add directory 'trunk\working_jdktools': object of the same name already exists Looks like that 'svn switch' can be done for committed dir only; probably the ' schedule=add ' attribute is erased during the switch operation. I'm trying to prepare modifications which can be committed at once to create single revision for the jdktools source move. Currently I use simple 'svn co /jdktools/trunk trunk\working_jdktools' for build checks and such workspace structure would require separate commits for trunk/working_jdktools and for jdktools/trunk. So I have to ask for this preparation step. If not, we can certainly whip it up quick. Would you mind posting the full URL of the folder to create, so we don't screw it up (meaning, so I don't screw it up). Empty dir https://svn.apache.org/repos/asf/incubator/harmony/enhanced/trunk/working_jdktools is asked to be created. -Nathan Thank you -Ilya
Re: svn commit: r473588 - in /incubator/harmony/enhanced/drlvm/trunk/vm: interpreter/src/ port/src/lil/em64t/pim/ vmcore/include/ vmcore/src/util/em64t/base/
I deleted the file and added it to the ignore property. For those not familiar with SVN, I would strongly encourage reading the first couple chapters of the book [1]. It's a very quick read and extremely helpful. -Nathan [1] http://svnbook.red-bean.com/ On 11/12/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Pavel Pervov wrote: Geir, Does SVN support some sort of exclude lists? Of course, http://svnbook.red-bean.com/en/1.1/ch07s02.html (look for the svn:ignore property) -- Stefano.
Re: svn commit: r473588 - in /incubator/harmony/enhanced/drlvm/trunk/vm: interpreter/src/ port/src/lil/em64t/pim/ vmcore/include/ vmcore/src/util/em64t/base/
Thats what I thought I suggested, but don't see the email now... Stefano Mazzocchi wrote: Geir Magnusson Jr. wrote: Gregory Shimansky wrote: On Saturday 11 November 2006 04:28 Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: Author: gshimansky Date: Fri Nov 10 16:17:50 2006 New Revision: 473588 URL: http://svn.apache.org/viewvc?view=revrev=473588 Log: Applied HARMONY-2152 [drlvm][em64t] build is broken after 1558 have been committed Since x86_64 is not yet fully supported and patch touched only x86_64 files no tests were ran. When I tried acceptance tests on em64t server I effectively shut it down. Modified: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag. h URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vm core/include/version_svn_tag.h?view=diffrev=473588r1=473587r2=473588 = = --- incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag. h (original) +++ incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag. h Fri Nov 10 16:17:50 2006 @@ -18,6 +18,6 @@ #ifndef _VERSION_SVN_TAG_ #define _VERSION_SVN_TAG_ -#define VERSION_SVN_TAG 473506 +#define VERSION_SVN_TAG svn: This client is too old to work with working copy '.'; please get a newer Subversion client uh? Ok it seems like svn version on the x86_64 server was too old for the checked out repository. Don't worry, the version file will be fixed with a next commit to VM. It looks like we should really autogenerate it and remove it from svn as was suggested in another thread. It is autogenerated. We just need to stop committing it... ehm, how about using svn:ignore then ;-)
Re: [general] creation of jdktools
Can you please give us an idea of what you have right now? There's no way we can participate with you if we don't have an idea of current status... geir Ilya Neverov wrote: On 10/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: [skip] Assumptions which look reasonable for jdktool's build subsystem: 1) it works in presence of built classlib (as HDK binaries or as a result of classlib phase of overall build); yes - think of the same trick we do w/ DRLVM to reach over to find it. I'd imagine the federated build to then have : trunk/ working_classlib/ working_vm/ working_jdktools/ Commiters, Could you please create empty directory trunk/working_jdktools. I need it to check building jdktools as part of the federated build. Without having the working_jdktools/ in the repository the moving sources and patching buiild files would require additional manual steps. Thank you. -Ilya
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
On Sunday 12 November 2006 00:39 Geir Magnusson Jr. wrote: Ok I think I've come up with a reasonable compromise. I still used the whole system of converting XML and all the stuff. It does quite a lot of things in setup and init targets and using select is convenient. I don't know how to untangle all of the setup and not do a lot of duplication in ant scripting which I am not big expert in. Why? Why do we want to persist with this system, when WE ARE GOING TO GET RID OF IT at some point? One reason would be is that I don't know ant well enough to redesign the whole stuff all together. I used the existing setup and init targets which take care of including ancontrip and cctask jars. If you ask me, I'd prefer make in the first place, ant is just too foreign to me. There is no reason to use caps, we didn't even start to discuss how we want to see drlvm build and when WE ARE GOING TO GET RID OF IT at some point. Did you also fix the silliness of having to use annotations to exclude tests? Please? :) No, the patch has an exclude example using and exclude statement in patternset in its beginning. I'm glad we have these tests, but really... I wish you hadn't invested the time integrating it into the DRLVM build system... Even if we write a new one from scratch I want the tests right now. There were several times when JVMTI was broken since there were no tests for it at all since it is a special VM mode no one usually uses. The time invested, well... I learned a lot since the last time I used ant. Maybe one day I'll be able to write something as impressive and unmaintainable as the current drlvm built :) Seriously, if we're going to change it, let's discuss it how we want it to look like and which tool we'll use. I vote for make (gnu version, that is gmake), even on win32 it exists in cygwin and mingw. -- Gregory Shimansky, Intel Middleware Products Division
Re: [testing] harmonytest.org new features
Great Job. ;-) Anton Luht wrote: Hello, Yesterday I've deployed a new version to harmonytest.org New features include: - packages/suites/tests tree-like navigation (as in local JUnit html results).Tree navigation populated to old results, too. - the first page only includes 50 latest test runs, link to archive search added (includes search by uploader's name - request by Tony Wu) - filter diff results by test name (request by Alexei Fedotov) - detection of crashes - sometimes when suite crashes, there is an empty TEST-suite-name.xml file in the run results. If such file is found, all tests from this suite (detected from previous runs) are marked as crashed in this run. Bugs fixed: - duplicates in the results (if any) are merged (bug report by Tony Wu - test count on the site was bigger than real one) - there was a problem in uploading large files - ~ 5Mb - the results were not imported - playing with the configuration solved this problem - at least my test 11Mb file that broke the upload now uploads correctly. Please report bugs and send feature requests. -- Richard Liang China Software Development Lab, IBM
Re: Harmony passes all tests of Maven 2.0.4
Cool ;-) Leo Li wrote: Hi, all: Harmony classlib at revision 473150 passes all tests of Maven 2.0.4 on windows xp, redhat enterprise 4, unbuntu 6.0.6 and suse 10. As for drlvm, it passes on windows xp but fails on redhat linux enterprise 4. If somebody can reproduce it, I will report it as a application-oriented bug to jira. For detailed information, pls refer to http://wiki.apache.org/harmony/Apache_Maven. -- Richard Liang China Software Development Lab, IBM
Re: Harmony passes all tests of Maven 2.0.4
Ok. Posted it on wiki. On 11/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: w00t! Log it on the wiki! (and please prefix your subject lines with ??? right now, we have [testing] listed on http://incubator.apache.org/harmony/mailing.html but maybe we need to add [app-testing] ? geir Leo Li wrote: Hi, all: Harmony classlib at revision 473150 passes all tests of Maven 2.0.4on windows xp, redhat enterprise 4, unbuntu 6.0.6 and suse 10. As for drlvm, it passes on windows xp but fails on redhat linux enterprise 4. If somebody can reproduce it, I will report it as a application-oriented bug to jira. For detailed information, pls refer to http://wiki.apache.org/harmony/Apache_Maven. -- Leo Li China Software Development Lab, IBM
Re: [drlvm] release vs. debug
Any assert(expr) can change a control flow of the debug build On 11/12/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: On 11/10/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Sure, contributors should check debug or even both debug and release builds and comment about this in JIRA. As far as I understand the only person who answers for the commit is a committer. So I don't think that establishing a policy that shifts a part of responsibility from the committer is a good idea. Well, I have another silly question to gurus indeed. Is there any possibility that some piece of code can break / hang the release build if it passes ok on the debug build? Theoretically it is possible to have problems on release build even if debug build passes the checks. More sofisticated optimizations applied in release build may reveal some subtle error in the code. Practically tis is not a common case though. Thanks, Pavel Thanks, 2006/11/10, Pavel Ozhdikhin [EMAIL PROTECTED]: Sure, contributors should check debug or even both debug and release builds and comment about this in JIRA. I'm talking about committers, will they test debug build which takes 5 times more time? And does it mean they will be able to apply 5 times less patches? Actually I'm fine if the committers will check both debug and release builds and I encourage them to check on all supported platforms. But I'm not a committer. :) Thanks, Pavel On 11/10/06, Rana Dasgupta [EMAIL PROTECTED] wrote: I can understand that the contributor may not have access to multiple platforms, but surely he can test using both debug and release builds :-) What do we gain by asking the contributor to test less? Rana On 11/9/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: +1 for debug testing before submitting a patch. But, for pre-commit testing we should be careful saying we'll test all the patches in debug mode. Though it imprves quality of checks, debug build is significantly slower then release, especially when running with interpreter or Jitrino.OPT. I ran build test on the DRLVM built in debug mode and it takes about 5 times more time than release version on my laptop, The times were as follows: build test, Windows XP/ IA32: DRLVM release: 22 min 55 sec DRLVM debug: 99 min 23 sec So, may be the good choice will be to ask patch submitters to check their patches on the debug build and, if the JIRA issue contains comments that this check is passed, committers may test it on release build only. Thanks, Pavel On 11/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Well, since the problem is repeatable :) Gregory Shimansky wrote: Geir Magnusson Jr. wrote: Alexei Zakharov wrote: Hi DRLVM fans, I encountered a rather strange problem while working on some class library tests. At least two tests from the beans module hang (or crash) while running on DRLVM debug builds but work fine on DRLVM release builds. I thought that debug build is something about adding debug symbols to VM binaries and this should not affect the functionality. Can someone shed a light on this? I would think it's just an assertion firing... Actually it is more than that. In debug mode TRACE statements are compiled and therefore produce executable code. There may also be some bugs in compiler generating code in different modes (although this usually happens for release). I don't know why hanging happens, but the difference in generated code is actually quite big. Also assertions or any crashes go to exceptions/signal handlers which may happen to loop infinitely, there were bugs like this happening on the current version of sources, look at HARMONY-2018 and HADMONY-2006. This is the first question. The second question - what we should do with such tests. The tests pass on the downloadable HDK and JRE snapshots as well as on classlib + j9. What should be the commit criteria for DRLVM – i.e. what is the *true* build? :) I think many people here currently use snapshots to test their patches. debug :) don't sweep the problems under the rug... +1 -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [drlvm] release vs. debug
When the spec doesn't specify expression evaluation order debug and release can behave differently. I got into such situation once... :-( On 11/13/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Any assert(expr) can change a control flow of the debug build On 11/12/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: On 11/10/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Sure, contributors should check debug or even both debug and release builds and comment about this in JIRA. As far as I understand the only person who answers for the commit is a committer. So I don't think that establishing a policy that shifts a part of responsibility from the committer is a good idea. Well, I have another silly question to gurus indeed. Is there any possibility that some piece of code can break / hang the release build if it passes ok on the debug build? Theoretically it is possible to have problems on release build even if debug build passes the checks. More sofisticated optimizations applied in release build may reveal some subtle error in the code. Practically tis is not a common case though. Thanks, Pavel Thanks, 2006/11/10, Pavel Ozhdikhin [EMAIL PROTECTED]: Sure, contributors should check debug or even both debug and release builds and comment about this in JIRA. I'm talking about committers, will they test debug build which takes 5 times more time? And does it mean they will be able to apply 5 times less patches? Actually I'm fine if the committers will check both debug and release builds and I encourage them to check on all supported platforms. But I'm not a committer. :) Thanks, Pavel On 11/10/06, Rana Dasgupta [EMAIL PROTECTED] wrote: I can understand that the contributor may not have access to multiple platforms, but surely he can test using both debug and release builds :-) What do we gain by asking the contributor to test less? Rana On 11/9/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: +1 for debug testing before submitting a patch. But, for pre-commit testing we should be careful saying we'll test all the patches in debug mode. Though it imprves quality of checks, debug build is significantly slower then release, especially when running with interpreter or Jitrino.OPT. I ran build test on the DRLVM built in debug mode and it takes about 5 times more time than release version on my laptop, The times were as follows: build test, Windows XP/ IA32: DRLVM release: 22 min 55 sec DRLVM debug: 99 min 23 sec So, may be the good choice will be to ask patch submitters to check their patches on the debug build and, if the JIRA issue contains comments that this check is passed, committers may test it on release build only. Thanks, Pavel On 11/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Well, since the problem is repeatable :) Gregory Shimansky wrote: Geir Magnusson Jr. wrote: Alexei Zakharov wrote: Hi DRLVM fans, I encountered a rather strange problem while working on some class library tests. At least two tests from the beans module hang (or crash) while running on DRLVM debug builds but work fine on DRLVM release builds. I thought that debug build is something about adding debug symbols to VM binaries and this should not affect the functionality. Can someone shed a light on this? I would think it's just an assertion firing... Actually it is more than that. In debug mode TRACE statements are compiled and therefore produce executable code. There may also be some bugs in compiler generating code in different modes (although this usually happens for release). I don't know why hanging happens, but the difference in generated code is actually quite big. Also assertions or any crashes go to exceptions/signal handlers which may happen to loop infinitely, there were bugs like this happening on the current version of sources, look at HARMONY-2018 and HADMONY-2006. This is the first question. The second question - what we should do with such tests. The tests pass on the downloadable HDK and JRE snapshots as well as on classlib + j9. What should be the commit criteria for DRLVM – i.e. what is the *true* build? :) I think many people here currently use snapshots to test their patches. debug :) don't sweep the problems under the rug... +1 -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [Cocoon] Cocoon 2.1.9 works on Harmony
I've run the Cocoon htmlunit tests. There are failures in tests, the most common problem is jpeg codec. Some tests fail because they test redirection which it is disabled. I'm seeking where to turn it on. Test run hangs both on RI and Harmony at org.apache.cocoon.CachingPipelineTestCase. I have not currently found a way to exclude it. :( 2006/11/9, Tim Ellison [EMAIL PROTECTED]: Anton Rusanov wrote: Cocoon 2.1.9 now works on Harmony (IBM VME + Classlib)! It starts and works normally. Are you running the Cocoon test suites? We should declare 'it works' when it passes all it's own test cases when running on Harmony. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Thanks, Anton
Re: [general] Sun will take GPL License?
Mark Reinhold's blog has confirmed this news. He said: ... Sun is open-sourcing its entire Java stack―ME, SE, and EE―under the GNU General Public License, version 2. The license choice―which has taken many by surprise (gotcha!)―is a giant leap. For more on the big picture, including a link to tomorrow's webcast announcement, please see http://sun.com/opensource/java. ... link: http://blogs.sun.com/mr/entry/one_giant_leap
Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
There is one more PRO for the second approach.
There is already some implementation of required functionality in svn.
It is being controlled by exe_notify_compile_method_load flag.
The patch with this flag attached to the JIRA issue.
It appends exe_notify_compile_method_load flag into the
OpenMethodExecutionParam struct (FALSE by default).
When the flag is turned on code emitter runs sendCompiledMethodLoadEvent
for each method that was compiled during current compilation session.
Here is the current implementation of sendCompiledMethodLoadEvent (in
DrlVMInterface.cpp):
void DrlVMCompilationInterface::sendCompiledMethodLoadEvent(MethodDesc *
methodDesc,
uint32 codeSize, void* codeAddr, uint32 mapLength,
AddrLocation* addrLocationMap, void* compileInfo) {
// VM-JIT interface function should be called here instead of logging
if (Log::isEnabled()) {
Log::out() ** Inlined method:
methodDesc-getName() std::endl;
Log::out() ** Number of locations: mapLength
std::endl;
}
}
sendCompiledMethodLoadEvent ‘s signature AFAIU is exactly the same as
the one from SPEC.
So all we need IMO is to insert into sendCompiledMethodLoadEvent a call
to VM that raises necessary event. (as it was supposed in the comment in
sendCompiledMethodLoadEvent)
Is the extension of the OpenMethodExecutionParam struct appropriate?
Which call should be inserted into sendCompiledMethodLoadEvent at place
of logging?
Eugene Ostrovsky wrote:
Opended issue
*HARMONY-2145https://issues.apache.org/jira/browse/HARMONY-2145
* .
To support the feature VM need to know about those inlined methods. Right
now I can see two possible approaches:
1. When VM initiates method compilation, it can ask the jit about methods
that were inlined to compiled method and report all of them.
2. JIT itself can notify VM about every compiled method by calling some
special interface function after the method compilation.
Re: [drlvm] Class unloading support
Weldon, I've created separate jira H-2158 called native resource cleanup. So you can proceed with closing H-2000. Aleksey. On 11/10/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 11/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I wonder if you might want to create a new JIRA that's clear about what the point is, and close the class unload JIRa for now. I was hoping someone would suggest closing HARMONY-2000. Unless there are objections in the next 24 hours, consider it done. geir Pavel Pervov wrote: On 11/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Hang on - we aren't going to consider this patch quite yet, are we? We have a very active and fruitful discussion going on regarding alternate approaches? geir This part of the patch does not contain class unloading implementation but instead contain native resources cleanup code, which is required by any choosen class unloading design to be implemented in DRLVM. So, my +1 to commit this part, and hold on with the second, until harmony-dev derives the decision. Regards -- Weldon Washburn Intel Enterprise Solutions Software Division
Re: [testing] Tests scores on http://harmonytest.org Was: [DRLVM] General stability
Alexei, I like your approach to result comparison. 10% can be default value for some form field - anyone can change it if needed. OK, let's try it and see if it satisfies the community/ Probably more conventional would be to parse system-out![CDATA[]]/system-out for some metric. Does the site already parse TEST-* files? It parses TESTS-TestSuites.xml - as far as I can see, it contains the same information as TEST-* files. Is there a common format of output of stress tests you're talking about? Thank you, Alexei On 11/10/06, Anton Luht [EMAIL PROTECTED] wrote: Hello, Alexei, I have related question. How can we improve http://harmonytest.org to make it possible to publish not just pass, fail, or error but numeric test scores? Easily - test results in JUnit reports have 'time' property - execution time in seconds. We can import and show them in the results. What else is needed? Maybe add something like 'show regressions' to the the 'compare runs' page? For example, show tests that increased execution time by more than 10% sorted by increase rate desc? -- Regards, Anton Luht, Intel Java XML Engineering -- Thank you, Alexei -- Regards, Anton Luht, Intel Java XML Engineering
Re: [general] Sun will take GPL License?
Oops！GPL v2? I can hardly believe it! Does it mean, all codes using Sun's JDK have to take GPL? Crazy and unbelieveable... However I like GPL ;) 在06-11-13，Jin Mingjian [EMAIL PROTECTED] 写道： Mark Reinhold's blog has confirmed this news. He said: ... Sun is open-sourcing its entire Java stack―ME, SE, and EE―under the GNU General Public License, version 2. The license choice―which has taken many by surprise (gotcha!)―is a giant leap. For more on the big picture, including a link to tomorrow's webcast announcement, please see http://sun.com/opensource/java. ... link: http://blogs.sun.com/mr/entry/one_giant_leap -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [drlvm][test]Exclude some tests from build test target, make 'build test' pass
HI, Do we have strong reasons to run all kernel tests in three different modes before commit? Probably, it makes sense to choose two or three most powerful tests and include them to smoke? Evgueni On 11/12/06, Pavel Pervov [EMAIL PROTECTED] wrote: In addition to excluding some tests, I would suggest removing smoke/classloader/ClassTestGetDeclaringClass as it is exact copy of kernel test with the same name. Also, smoke/classloader/ExceptionInInitializerTest must be returned to acceptance runs. Pavel. On 10/25/06, Volynets, Vera [EMAIL PROTECTED] wrote: Geir Some tests launched by command build test fail. The idea of build test is to run it before each commit. In this way you can catch regressions. In order to effectively catch regressions, i.e. tests that started to fail after some change, it's necessary to have 'build test' pass in a stable way. One of the ways to achieve stable state is to exclude failing tests or tests which show unstable behavior. So I analysed statistics of test runs on win ia32 platform and made up a list of tests to be excluded: 1) smoke *** gc.LOS fails always on jitrino and interpreter, debug and release 2) kernel *** java.lang.ClasssGenericsTest and *** java.lang.ClassGenericsTest4 fail because of timeout, so I increase timeout in kernel.test.xml *** java.lang.ObjectTest fail on interpreter with following message: Testsuite: java.lang.ObjectTest Tests run: 18, Failures: 1, Errors: 0, Time elapsed: 6.109 sec Testcase: testWait1(java.lang.ObjectTest): FAILED An InterruptedException must be thrown in test thread! junit.framework.AssertionFailedError: An InterruptedException must be thrown in test thread! See HARNONY-1966 issue with attached patch. Vera Volynets Intel Middleware ProductsDivision -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [general] Sun will take GPL License?
GPL is not very compatible with Apache License. So, I guess Sun want to prevent Harmony from using any codes they owned?! Very Very Very... 在 06-11-13，LvJimmy，Jing[EMAIL PROTECTED] 写道： Oops！GPL v2? I can hardly believe it! Does it mean, all codes using Sun's JDK have to take GPL? Crazy and unbelieveable... However I like GPL ;) 在06-11-13，Jin Mingjian [EMAIL PROTECTED] 写道： Mark Reinhold's blog has confirmed this news. He said: ... Sun is open-sourcing its entire Java stack―ME, SE, and EE―under the GNU General Public License, version 2. The license choice―which has taken many by surprise (gotcha!)―is a giant leap. For more on the big picture, including a link to tomorrow's webcast announcement, please see http://sun.com/opensource/java. ... link: http://blogs.sun.com/mr/entry/one_giant_leap -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
[doc] Anybody tried DRLVM+Eclipse and can share? [WAS: Re: FW: [build] Building on Eclipse - FYI]
Resending the email. Really sad that we haven't received any feedback yet. Thank you, Nadya Morozova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 11:11 PM To: harmony-dev@incubator.apache.org Subject: Anybody tried DRLVM+Eclipse and can share? [WAS: Re: FW: [build] Building on Eclipse - FYI] Folks, Has anybody tried working with DRLVM in Eclipse? did you have to screw it before it ran ok? Do you have anything to share? Let's write a doc! Background We've been trying to gather useful info on working with Eclipse and our code base. Eclipse+classlib page has been updated, see JIRA H2009. The only drlvm-oriented doc that mentions Eclipse is Getting Started with DRLVM. The doc is terrifically outdated. If anybody has relevant updates, we could update the document/write a new one/add to eclipse+classlib page to make it cover both vm and classlib. Volunteers? Thank you, Nadya Morozova ps: I'm just rewriting Egor's idea from the email below to attract more people's attention -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Thursday, November 09, 2006 7:41 PM To: harmony-dev@incubator.apache.org Subject: Re: FW: [build] Building on Eclipse - FYI On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote: Egor Pasko wrote: On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote: Egor Pasko wrote: On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote: Egor Pasko wrote: On the 0x21C day of Apache Harmony Sian January wrote: Hello again, I have had a closer look at the Developing Apache Harmony Class-library Code with Eclipse page, and I have noticed that the Configuring Eclipse and Develop and Test Code sections are quite class-library specific. Would it be better to leave those sections as they are and add a Developing DRLVM with Eclipse section on the same page? To the moment I am not aware of anybody who would use Eclipse for DRLVM development. So, it's too early to add a page like this. This will ensure that no one does then - if it's simple to add, lets add it... Does it help anybody? I see no point in doing redundant work even if it is small. Why is it redundant? Nobody uses, nobody reads - redundant. Am I missing something? :) if we don't have it, of course nobody uses or reads it... OK. Let me put it the other way. If someone has something valuable, not obvious to write about DRLVM+Eclipse, I am for it. If the page is going to be just a long-living stub, I am not happy. -- Egor Pasko
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Gregory Shimansky wrote: On Sunday 12 November 2006 00:39 Geir Magnusson Jr. wrote: Ok I think I've come up with a reasonable compromise. I still used the whole system of converting XML and all the stuff. It does quite a lot of things in setup and init targets and using select is convenient. I don't know how to untangle all of the setup and not do a lot of duplication in ant scripting which I am not big expert in. Why? Why do we want to persist with this system, when WE ARE GOING TO GET RID OF IT at some point? One reason would be is that I don't know ant well enough to redesign the whole stuff all together. I used the existing setup and init targets which take care of including ancontrip and cctask jars. If you ask me, I'd prefer make in the first place, ant is just too foreign to me. There is no reason to use caps, we didn't even start to discuss how we want to see drlvm build and when WE ARE GOING TO GET RID OF IT at some point. The caps were to get your attention. I thought you had a nice way to create a standalone testbed and then hook that in. Did you also fix the silliness of having to use annotations to exclude tests? Please? :) No, the patch has an exclude example using and exclude statement in patternset in its beginning. Yay! I'm glad we have these tests, but really... I wish you hadn't invested the time integrating it into the DRLVM build system... Even if we write a new one from scratch I want the tests right now. There were several times when JVMTI was broken since there were no tests for it at all since it is a special VM mode no one usually uses. That's not the issue - we all agree we need the tests right now. What I'm arguing about is doing the tests, and then doing the integration into a build system we don't want. The time invested, well... I learned a lot since the last time I used ant. Maybe one day I'll be able to write something as impressive and unmaintainable as the current drlvm built :) Seriously, if we're going to change it, let's discuss it how we want it to look like and which tool we'll use. I vote for make (gnu version, that is gmake), even on win32 it exists in cygwin and mingw. I think that we should simply use the same tooling that we're using now in classlib. geir
Re: [general] Sun will take GPL License?
LvJimmy，Jing wrote: Oops！GPL v2? I can hardly believe it! Why? Does it mean, all codes using Sun's JDK have to take GPL? No. geir Crazy and unbelieveable... However I like GPL ;) 在06-11-13，Jin Mingjian [EMAIL PROTECTED] 写道： Mark Reinhold's blog has confirmed this news. He said: ... Sun is open-sourcing its entire Java stack―ME, SE, and EE―under the GNU General Public License, version 2. The license choice―which has taken many by surprise (gotcha!)―is a giant leap. For more on the big picture, including a link to tomorrow's webcast announcement, please see http://sun.com/opensource/java. ... link: http://blogs.sun.com/mr/entry/one_giant_leap
Re: [general] Sun will take GPL License?
Jin Mingjian wrote: GPL is not very compatible with Apache License. So, I guess Sun want to prevent Harmony from using any codes they owned?! Very Very Very... No - it was simply about control. geir 在 06-11-13，LvJimmy，Jing[EMAIL PROTECTED] 写道： Oops！GPL v2? I can hardly believe it! Does it mean, all codes using Sun's JDK have to take GPL? Crazy and unbelieveable... However I like GPL ;) 在06-11-13，Jin Mingjian [EMAIL PROTECTED] 写道： Mark Reinhold's blog has confirmed this news. He said: ... Sun is open-sourcing its entire Java stack―ME, SE, and EE―under the GNU General Public License, version 2. The license choice―which has taken many by surprise (gotcha!)―is a giant leap. For more on the big picture, including a link to tomorrow's webcast announcement, please see http://sun.com/opensource/java. ... link: http://blogs.sun.com/mr/entry/one_giant_leap -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [doc] Anybody tried DRLVM+Eclipse and can share? [WAS: Re: FW: [build] Building on Eclipse - FYI]
it's only been a few days, and you did it over a weekend... Morozova, Nadezhda wrote: Resending the email. Really sad that we haven't received any feedback yet. Thank you, Nadya Morozova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 11:11 PM To: harmony-dev@incubator.apache.org Subject: Anybody tried DRLVM+Eclipse and can share? [WAS: Re: FW: [build] Building on Eclipse - FYI] Folks, Has anybody tried working with DRLVM in Eclipse? did you have to screw it before it ran ok? Do you have anything to share? Let's write a doc! Background We've been trying to gather useful info on working with Eclipse and our code base. Eclipse+classlib page has been updated, see JIRA H2009. The only drlvm-oriented doc that mentions Eclipse is Getting Started with DRLVM. The doc is terrifically outdated. If anybody has relevant updates, we could update the document/write a new one/add to eclipse+classlib page to make it cover both vm and classlib. Volunteers? Thank you, Nadya Morozova ps: I'm just rewriting Egor's idea from the email below to attract more people's attention -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Thursday, November 09, 2006 7:41 PM To: harmony-dev@incubator.apache.org Subject: Re: FW: [build] Building on Eclipse - FYI On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote: Egor Pasko wrote: On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote: Egor Pasko wrote: On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote: Egor Pasko wrote: On the 0x21C day of Apache Harmony Sian January wrote: Hello again, I have had a closer look at the Developing Apache Harmony Class-library Code with Eclipse page, and I have noticed that the Configuring Eclipse and Develop and Test Code sections are quite class-library specific. Would it be better to leave those sections as they are and add a Developing DRLVM with Eclipse section on the same page? To the moment I am not aware of anybody who would use Eclipse for DRLVM development. So, it's too early to add a page like this. This will ensure that no one does then - if it's simple to add, lets add it... Does it help anybody? I see no point in doing redundant work even if it is small. Why is it redundant? Nobody uses, nobody reads - redundant. Am I missing something? :) if we don't have it, of course nobody uses or reads it... OK. Let me put it the other way. If someone has something valuable, not obvious to write about DRLVM+Eclipse, I am for it. If the page is going to be just a long-living stub, I am not happy.
