Re: [drlvm][em64t] build fails
Stefano, (you guys rock, btw!) We do sometime. ;) and googling for hyzip doesn't yield anything interesting. Hyzlib is something that is build along with classlib (it is part of ZipSupport in classlib). As you didn't finish classlib build, you do not have hyzlib. But VMI requires hyzlib to link succesfully. Regards -- Pavel Pervov, Intel Enterprise Solutions Software Division
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/
It looks like host, which Gregory used for EM64T build, has svn of outdated version. Generally, version_svn_tag.h should not be committed at all. On 11/11/06, Stefano Mazzocchi [EMAIL PROTECTED] 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/vmcore/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? -- Stefano. -- Pavel Pervov, Intel Enterprise Solutions Software Division
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/
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. -- Gregory Shimansky, Intel Middleware Products Division
Re: [general] Sun will take GPL License?
Geir Magnusson Jr. geir at pobox.com writes: For example, see the Hibernate clarification to the LGPL, or how MySQL just basically told the FSF that the GPL *is* compatible with the Apache License. Judging from the FOSS exception license text[1], what MySQL did was to simply add an exception to the GPL, that permits software under a set of open source licenses to create derivative works. I believe that's what you meant, right? That wasn't my read - I read it that you can now combine software from MySQL that is under the GPL with software under the Apache License (for example), which is something that the FSF has explicitly prohibited. Oh, I just wanted to explain that MySQL didn't literally go out and tell the FSF that GPL and Apache License are compatible. It would be an odd claim to make for a third party that's not a steward of the licenses involved, anyway. I think we violently agree on the effects and motivations for the exception, and are getting way off-topic. ;) cheers, dalibor topic
Re: [general] creation of jdktools
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][em64t] build fails
Pavel Pervov wrote: Stefano, (you guys rock, btw!) We do sometime. ;) :-D and googling for hyzip doesn't yield anything interesting. Hyzlib is something that is build along with classlib (it is part of ZipSupport in classlib). As you didn't finish classlib build, you do not have hyzlib. But VMI requires hyzlib to link succesfully. ah-ha! that explains it thanks. So, it seems that I need to get the classlib fixed before I can attempt to move on. BTW, if people want to follow along, I have a cruisecontrol instance running on Geir's server that will try every 5 minutes to rebuild if there are some svn changes. Find it at http://67.86.14.213:10001/ BTW, I also managed to successfully cloned a full gump run from our ASF boxes, find it at http://67.86.14.213:1/gump/ but it's running with Sun's JVM. (currently running at around 79% completion) If you guys help me run harmony on x86_64, it will be a matter of minutes for me to get an harmony-powered gump going. -- Stefano.
RE: [classlib][swing] Serialization of Swing classes
Nathan, Yes, there is some harm - someone could change the classes in future and forget to change the serialVersionUID. Also adding serialVersionUID implies the serialization compatibility is important, which is not the case. Regards, Vasily Zakharov Intel Middleware Products Division -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Saturday, November 11, 2006 7:48 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] Serialization of Swing classes If there's no need for serialization compatability between VMs and versions of a VM, then is there any harm in adding explicit serialVersionUID fields? On 11/10/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Nathan, all, You shouldn't add explicit serialVersionUID because Sun explicitly states that serialized form of Swing classes maybe incompatible with future Swing releases. And there's no description of serialized form for any Swing class. I'm pretty sure Harmony is not compatible with Sun classes with regard to serialized from of Swing classes. And new fields can be added to a class or removed, which will break the serialized form. See the Warning in JTree JavaDoc: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JTree.html The serialVersionUID declarations were intentionally missed. Regards, Alexey. P.S. Thanks for cleaning up the code to use parameterized types where possible. I've looked through j.s.BasicSwingTestCase and restricted the type parameter, as well as refactored the code accessing Swing components so that it always runs on the Event Dispatch Thread. See https://issues.apache.org/jira/browse/HARMONY-2078. Also I've cleaned up some classes where I fixed bugs: https://issues.apache.org/jira/browse/HARMONY-2089 https://issues.apache.org/jira/browse/HARMONY-2119 https://issues.apache.org/jira/browse/HARMONY-2121 -- Alexey A. Ivanov Intel EnterpriseSolutions SoftwareDivision
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
hmmm strange. The patch was tested on multi-processor system running SUSE9. I will check if the patch misses something. Anyway, we need to wait with the patch submission until we 100% sure how hythread_monitor_init should behave. Thanks Evgueni On 11/11/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Friday 10 November 2006 17:45 Evgueni Brevnov wrote: Hi, While investigating deadlock scenario which is described in HARMONY-2006 I found out one interesting thing. It turned out that DRL implementation of hythread_monitor_init / hythread_monitor_init_with_name initializes and acquires a monitor. Original spec reads: Acquire and initialize a new monitor from the threading library AFAIU that doesn't mean to lock the monitor but get it from the threading library. So the hythread_monitor_init should not lock the monitor. Could somebody comment on that? It might be that semantic is different on different platforms which is probably even worse. Your patch in HARMONY-2149 breaks nearly all of acceptance tests on Linux while everything on Windows works (ok I tested on laptop with 1 processor while Linux was a HT server, sometimes it is important for threading). I think we need more investigation on whether or not the monitor has to be locked in init. -- Gregory Shimansky, Intel Middleware Products Division
Re: [classlib][swing] Serialization of Swing classes
Well, if a consumer is looking for 'serialVersionUID' fields to indicate the strength of the serialization contract, then they're going to be thrown off by the fact that the class implements Serializable in the first place. As for regenerating the 'serialVersionUID' field when a class is changed, I would consider this of little concern, since there are no guarantees between the serialization interop of VMs and the interop between different versions of a single VM. I would say there are really only two valid considerations in this discussion: code style and the possibility of a small runtime optimization. Code style - It would clean up the code a bit remove the fields, but I'd also add @SuppressWarnings() annotations to the respective classes, so if anyone doesn't like that it could weigh on this. Runtime optimization - I'm not positive of this, nor do I completely understand the actual affect, but wouldn't explicit 'serialVersionUID' fields mean that when those classes are actually serialized, a UID wouldn't need to be generated at runtime, correct? Now, I'll be the first to admit, this is a micro optimization, so it doesn't carry to much weight. However, I am curious about the details of the reality behind this thought, so if anyone knows, please post. -Nathan On 11/11/06, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Nathan, Yes, there is some harm - someone could change the classes in future and forget to change the serialVersionUID. Also adding serialVersionUID implies the serialization compatibility is important, which is not the case. Regards, Vasily Zakharov Intel Middleware Products Division -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Saturday, November 11, 2006 7:48 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] Serialization of Swing classes If there's no need for serialization compatability between VMs and versions of a VM, then is there any harm in adding explicit serialVersionUID fields? On 11/10/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Nathan, all, You shouldn't add explicit serialVersionUID because Sun explicitly states that serialized form of Swing classes maybe incompatible with future Swing releases. And there's no description of serialized form for any Swing class. I'm pretty sure Harmony is not compatible with Sun classes with regard to serialized from of Swing classes. And new fields can be added to a class or removed, which will break the serialized form. See the Warning in JTree JavaDoc: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JTree.html The serialVersionUID declarations were intentionally missed. Regards, Alexey. P.S. Thanks for cleaning up the code to use parameterized types where possible. I've looked through j.s.BasicSwingTestCase and restricted the type parameter, as well as refactored the code accessing Swing components so that it always runs on the Event Dispatch Thread. See https://issues.apache.org/jira/browse/HARMONY-2078. Also I've cleaned up some classes where I fixed bugs: https://issues.apache.org/jira/browse/HARMONY-2089 https://issues.apache.org/jira/browse/HARMONY-2119 https://issues.apache.org/jira/browse/HARMONY-2121 -- Alexey A. Ivanov Intel EnterpriseSolutions SoftwareDivision
Re: [general] creation of jdktools
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. 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). -Nathan
Re: [classlib][sql] package javax.sql.rowset.serial is missing in Harmony
Yep, definitely cool. I started working on javax.sql.rowset the other day and have what I've completed so far there, but I think there's still one more class and much more unit testing needed. Feel free to work there as well. -Nathan On 11/10/06, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/11/10, Andrew Zhang [EMAIL PROTECTED]: Hi folks, I noticed that package javax.sql.rowset.serial is missing in Harmony. Has anybody already been working on it? If no one holds implemented code in his hand, I'd like to start on this package. cool! Any suggestions/concerns/patches :-) ? Thanks! -- Best regards, Andrew Zhang
Re: [drlvm][build] everyday SVN conflict on the version_svn_tag.h file
To get rid of conflicts I think we should remove this file from revision control. +1 On 11/10/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Saturday 11 November 2006 01:12 Alexei Fedotov wrote: generate this file as part of the build process? +1 for autogeneration of version_svn_tag.h It is kind of autogenerated already. To get rid of conflicts I think we should remove this file from revision control. On 11/10/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: Hello everyone, When I do my morning SVN update of drlvm module I see the permanent conflict on the version_svn_tag.h file because this file is updated by build. Actually, it is not a big problem while it not breaks vm build. But it will be more convenient if these conflicts go out. Could we generate this file as part of the build process (it has only 4 strings)? May be some other solutions exists? I'm not too familiar with VM build so I'll be glad if somebody takes care about it :) -- Gregory Shimansky, Intel Middleware Products Division -- Thank you, Alexei
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Gregory, I have checked the patch. I like it. Here are few notes. * When I used ant there were no for tag [1]. I used autogenerated ant files to run something in a loop. Solution with for takes less place and is more readable. * From my perspective 3 min timeout for a smoke test should be decreased. I think there should be no stress/reliaiblity loads during acceptance testing. The reason is simple: complex loads demonstrate unpredicable behavior and do not reveal problems with 100% accuracy, so the bad patch pass such acceptance tests sooner or later. * As for TestNG concern, I don't think we need to stick to the harness. When the time comes, we will change the harness painlessly. 1. http://mail-archives.apache.org/mod_mbox/ant-user/200410.mbox/[EMAIL PROTECTED] On 11/10/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Thursday 02 November 2006 23:24 Geir Magnusson Jr. wrote: That's an understatement. Don't feel bad. I've never seen anything like it before. The idea of generating ant scripts on teh fly is very unconventional. . You don't have enough cuts and bruises from working with the DRLVM build :) 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. But I managed to cut away the loop over components looking at how test target in build.xml is written. I've also converted smoke.test target to the same way because both jvmti and smoke tests are meant for a whole VM, not some component of it. This also made a weird bug go away when of smoke tests were built and run in some random subdirectory of semis instead of being in vm when they were ran separately as build smoke.test. Tests should be in their own subdirectories (main test inclusion/exclusion loop is done over them), main Java class for application has to be equal to have package and name equal to its subdirectory. Otherwise the build system won't know what to run. Other files may have any kind of names. I wrote one simple JVMTI test to start the suite. Other tests which I've experimented with I cannot submit because I didn't write them. I think they'll appear later from JIRAs like one in HARMONY-2143 which were submitted to ASF. Take a look at HARMONY-2151 and say what you think. If I don't get much opposition I'll commit the patch on this weekend. Don't shoot me. Writing even that much of Ant took a lot of time, beer and hair on my head. I said I am not an ant guru, didn't I? -- Gregory Shimansky, Intel Middleware Products Division -- Thank you, Alexei
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Gregory Shimansky wrote: On Thursday 02 November 2006 23:24 Geir Magnusson Jr. wrote: That's an understatement. Don't feel bad. I've never seen anything like it before. The idea of generating ant scripts on teh fly is very unconventional. . You don't have enough cuts and bruises from working with the DRLVM build :) 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? But I managed to cut away the loop over components looking at how test target in build.xml is written. I've also converted smoke.test target to the same way because both jvmti and smoke tests are meant for a whole VM, not some component of it. This also made a weird bug go away when of smoke tests were built and run in some random subdirectory of semis instead of being in vm when they were ran separately as build smoke.test. Did you also fix the silliness of having to use annotations to exclude tests? Please? :) Tests should be in their own subdirectories (main test inclusion/exclusion loop is done over them), main Java class for application has to be equal to have package and name equal to its subdirectory. Otherwise the build system won't know what to run. Other files may have any kind of names. I wrote one simple JVMTI test to start the suite. Other tests which I've experimented with I cannot submit because I didn't write them. I think they'll appear later from JIRAs like one in HARMONY-2143 which were submitted to ASF. Take a look at HARMONY-2151 and say what you think. If I don't get much opposition I'll commit the patch on this weekend. Don't shoot me. Writing even that much of Ant took a lot of time, beer and hair on my head. I said I am not an ant guru, didn't I? I'm glad we have these tests, but really... I wish you hadn't invested the time integrating it into the DRLVM build system... geir
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/
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... geir
Re: [drlvm][test]Exclude some tests from build test target, make 'build test' pass
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: svn commit: r473588 - in /incubator/harmony/enhanced/drlvm/trunk/vm: interpreter/src/ port/src/lil/em64t/pim/ vmcore/include/ vmcore/src/util/em64t/base/
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 ;-) -- Stefano.
Re: [classlib][swing] Serialization of Swing classes
Nathan Beyer wrote: Runtime optimization - I'm not positive of this, nor do I completely understand the actual affect, but wouldn't explicit 'serialVersionUID' fields mean that when those classes are actually serialized, a UID wouldn't need to be generated at runtime, correct? Now, I'll be the first to admit, this is a micro optimization, so it doesn't carry to much weight. However, I am curious about the details of the reality behind this thought, so if anyone knows, please post. Take a look at the effect of java.io.ObjectStreamClass#lookup(Class) for types that have a SUID field and those that don't. The actual work is done in ObjectStreamClass#computeSerialVersionUID(Class, Field[]), which scans the fields looking for a serialVersionUID field first, and computing it if not found using some non-trivial algorithm. The lookup result is cached, so any saving will be only on the first time the class is seen. Whether the computation is noticeable will depend upon the set of classes of objects being serialized as well as the presence (or absence) of the SUID field. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
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/
Geir, Does SVN support some sort of exclude lists? On 11/12/06, Geir Magnusson Jr. [EMAIL PROTECTED] 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... geir -- Pavel Pervov, Intel Enterprise Solutions Software Division
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/
Or better call it ignore lists. On 11/12/06, Pavel Pervov [EMAIL PROTECTED] wrote: Geir, Does SVN support some sort of exclude lists? On 11/12/06, Geir Magnusson Jr. [EMAIL PROTECTED] 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... geir -- Pavel Pervov, Intel Enterprise Solutions Software Division -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [DRLVM][PORT] correct API to retrieve processor number
I added a patch 2154 to look in the Windows kernel32.dll for GetNativeSystemInfo first and use it and use GetSystemInfo otherwise. Because of the organization of 64 bit and 32 bit kernel dlls as kernel32.dll and WOW redirection of kernel32.dll in emulation mode, this should ensure that we get back the correct info. I also added an api port_Cores_number() for Core counting arounf GetLogicalProcessorInfo(). We can expand this api as we need to also return cache and NUMA information as we discover further requirements. On the Linux mailing lists it looks like sysconf() will expand to return cores info for multicore systems and the NUMA api's on Linux are a different bunch altogether. Thanks, Rana On 11/1/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Very informative! Thanks, Rana. -xiaofeng On 11/2/06, Rana Dasgupta [EMAIL PROTECTED] wrote: On Windows, there is a bunch of bugs. - On W2003 SP1, Vista, XP-64 GetLogicalProcessorInformation() is the recommended api. It returns # of cores on AMD and # of logical procs on Intel. - GetSystemInfo() is on XP-32 and Windows Server. It does not work in wow mode. I think GetNativeSystemInfo is needed. - For x64, the VC/VC++ the __cpuid() intrinsic returns wrong information The root cause is that the incorrect versions use the cpuid instruction incorrectly. __cpuid() uses old style cpuid and takes input from eax only instead of eax, ecx . GetSystemInfo() uses the registers in short mode when doing cpuid, so I think it fails for wow. It is amazing how Windows works at all! On 11/1/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: On 11/1/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Just a wild guess: this may be caused by x86 emulation on em64t (x86_64). SDK docs advise to use GetNativeSystemInfo() in such case, instead of currently used GetSystemInfo(). (See vm\port\src\misc\win\sysinfo.c). huh, I guess you are right, since my machine is X86-64bit. :-) I will try the API you pointed. Thanks, xiaofeng
Re: [DRLVM][PORT] correct API to retrieve processor number
I will try it, thanks! -xiaofeng On 11/12/06, Rana Dasgupta [EMAIL PROTECTED] wrote: I added a patch 2154 to look in the Windows kernel32.dll for GetNativeSystemInfo first and use it and use GetSystemInfo otherwise. Because of the organization of 64 bit and 32 bit kernel dlls as kernel32.dll and WOW redirection of kernel32.dll in emulation mode, this should ensure that we get back the correct info. I also added an api port_Cores_number() for Core counting arounf GetLogicalProcessorInfo(). We can expand this api as we need to also return cache and NUMA information as we discover further requirements. On the Linux mailing lists it looks like sysconf() will expand to return cores info for multicore systems and the NUMA api's on Linux are a different bunch altogether. Thanks, Rana On 11/1/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Very informative! Thanks, Rana. -xiaofeng On 11/2/06, Rana Dasgupta [EMAIL PROTECTED] wrote: On Windows, there is a bunch of bugs. - On W2003 SP1, Vista, XP-64 GetLogicalProcessorInformation() is the recommended api. It returns # of cores on AMD and # of logical procs on Intel. - GetSystemInfo() is on XP-32 and Windows Server. It does not work in wow mode. I think GetNativeSystemInfo is needed. - For x64, the VC/VC++ the __cpuid() intrinsic returns wrong information The root cause is that the incorrect versions use the cpuid instruction incorrectly. __cpuid() uses old style cpuid and takes input from eax only instead of eax, ecx . GetSystemInfo() uses the registers in short mode when doing cpuid, so I think it fails for wow. It is amazing how Windows works at all! On 11/1/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: On 11/1/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Just a wild guess: this may be caused by x86 emulation on em64t (x86_64). SDK docs advise to use GetNativeSystemInfo() in such case, instead of currently used GetSystemInfo(). (See vm\port\src\misc\win\sysinfo.c). huh, I guess you are right, since my machine is X86-64bit. :-) I will try the API you pointed. Thanks, xiaofeng
