From: Chris H. <hof...@cs...> - 2003-06-27 17:42:19
|
1) The default value, "RVM_FOR_SINGLE_VIRTUAL_PROCESSOR=0", causes problems on our i686 machines. Jikes goes into an infinite loop as soon as it starts. We've had to set this to '1'. Perhaps that should be made the default again? king:/build$ uname -a Linux king 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown 2) jBuildClasspathJar contains a line that sources the RVM_HOST_CONFIG. When doing 'jbuild -booter' in a cross-platform build, this is wrong! It should be the TARGET config. In fact, jbuild has properly sourced the target config and then jBuildClasspathJar clobbers that with the host config settings. My simple fix was just to remove that line, as I don't call jBuildClasspathJar outside of jbuild. If you want to include a sanity check, perhaps replacing this line with a check that HOST_JAR, HOST_JIKES, etc, are set rather than doing the actual evaluation of a config file would be better. c) Not a bug, but an observation. Though Jikes RVM has said it required Java 1.4 to build, Java 1.3 continued to work for us. As of a few days ago this is no longer true! Chris -- Chris Hoffmann -- Dept. of Computer Science/UMass at Amherst http://www-ali.cs.umass.edu/~hoffmann |
From: David P G. <gr...@us...> - 2003-06-27 18:10:34
|
.(1) One of the reasons for changing the default is that Jikes RVM is more functional in this mode and we believe that RedHat 7.3 or better is fairly wide spread. Overall, we think its better to default to a version of Jikes RVM that can run eclipse successfully on what we think is the majority of the platforms. (2) Yes. jBuildClassPathJar.... this should be fixed...I've fixed this at least once in the past and I guess it crept back in again. (3) interesting...I don't think we intentionally broke 1.3 builds...what is the symptom? --dave |
From: Chris H. <hof...@cs...> - 2003-06-27 19:02:44
|
David P Grove wrote: > > .(1) One of the reasons for changing the default is that Jikes RVM is > more functional in this mode and we believe that RedHat 7.3 or better > is fairly wide spread. Overall, we think its better to default to a > version of Jikes RVM that can run eclipse successfully on what we > think is the majority of the platforms. Fair enough, but could there be a check in jbuild, or at least some documentation in the User's Guide about what might cause this symptom? My apologies if there already is, though that points out the flaw in relying on people reading the User's Guide before building Jikes. Especially those of us who think we know what we're doing! > (2) Yes. jBuildClassPathJar.... this should be fixed...I've fixed this > at least once in the past and I guess it crept back in again. Thanks > (3) interesting...I don't think we intentionally broke 1.3 > builds...what is the symptom? I've attached the end of an RVM.trace file. I tried a variety of things to fix this until I realized that my machine was still configured to use java 1.3. I believe the problem has to do with the introduction of the Reference classes, as it started about that time. A full set of logs can be found in: ftp://ftp.cs.umass.edu/pub/osl/jikes-regression/archive.Tuesday.ppc-Linux.tar.gz ------------------------------------------------------ BootImageWriter: (java.lang.Class)java.util.ResourceBundle.securityClass --> (< SystemCL, [Ljava/lang/Object; >)java.lang.Class.signers: field not in host jdk, writing a null BootImageWriter: (java.util.HashMap)java.util.ResourceBundle.resourceBundleCache --> ([Ljava.util.HashMap$HashEntry;)java.util.HashMap.buckets --> (java.util.HashMap$HashEntry)[Ljava.util.HashMap$HashEntry;[0] --> (java.util.HashMap)java.util.AbstractMap$BasicMapEntry.value --> ([Ljava.util.HashMap$HashEntry;)java.util.HashMap.buckets --> (java.util.HashMap$HashEntry)[Ljava.util.HashMap$HashEntry;[1] --> (java.lang.String)java.util.AbstractMap$BasicMapEntry.key --> (< SystemCL, I >)java.lang.String.cachedHashCode: field not in host jdk, writing a null Exception in thread "main" java.lang.ClassCastException: java.text.resources.LocaleElements at BootImageWriter.copyToBootImage(BootImageWriter.java:1440) at BootImageWriter.copyToBootImage(BootImageWriter.java:1466) at BootImageWriter.copyToBootImage(BootImageWriter.java:1308) at BootImageWriter.copyToBootImage(BootImageWriter.java:1466) at BootImageWriter.copyToBootImage(BootImageWriter.java:1466) at BootImageWriter.copyToBootImage(BootImageWriter.java:1308) at BootImageWriter.copyToBootImage(BootImageWriter.java:1466) at BootImageWriter.main(BootImageWriter.java:501) make: *** [/exp/dodo/ali/home/hoffmann/ppc-regression/test_area//images/BaseAdaptiveSemiSpace/RVM.image] Error 1 jbuild.linkImage: A command I just ran (probably with a final argument of /exp/dodo/ali/home/hoffmann/ppc-regression/test_area//images/BaseAdaptiveSemiSpace/RVM.image) exited with status 2. Something is broken; I give up. 198 s jbuild: Trouble while running "./jbuild.linkImage -trace -demographics" (exit status 2); aborting execution -- Chris Hoffmann -- Dept. of Computer Science/UMass at Amherst http://www-ali.cs.umass.edu/~hoffmann |
From: Steve B. <Ste...@an...> - 2003-06-28 07:45:06
|
If 1.4 now required (or at least recommended), I think the the config files should be changed to refect this. I am happy to do so. A related point is more generally how to chose the defaults for these files. Since I need to use 1.4.1 to use the new linux threads (with RH 9 etc), I use the rpm provided by Sun: j2sdk-1.4.1_03-fcs. This installs itself in /usr/java/j2sdk1.4.1_03 Currently the config file has /opt/IBMJava2-13 as the default. This is what I used until the shift to 1.4.1. Any thoughts? --Steve |
From: Steven A. <au...@us...> - 2003-06-29 00:49:40
|
At a bare minimum, the config file should certainly point one to the blackdown jdk, version 1.4.x. Unless someone has a good reason not to do it, I'd encourage you to make the change. Also (as I learned this weekend), the comments in the config file for the watson dist. have diverged from the ones for the generic i686 config. The useful info in the Watson one should certainly be available in the generic x86 one. --Steve Augart Steve Blackburn <Ste...@an...> Sent by: jik...@ww... 06/28/2003 12:44 AM Please respond to jikesrvm-core To: jik...@ww... cc: Subject: Re: [Jikesrvm-core] Problems with latest CVS head If 1.4 now required (or at least recommended), I think the the config files should be changed to refect this. I am happy to do so. A related point is more generally how to chose the defaults for these files. Since I need to use 1.4.1 to use the new linux threads (with RH 9 etc), I use the rpm provided by Sun: j2sdk-1.4.1_03-fcs. This installs itself in /usr/java/j2sdk1.4.1_03 Currently the config file has /opt/IBMJava2-13 as the default. This is what I used until the shift to 1.4.1. Any thoughts? --Steve _______________________________________________ Jikesrvm-core mailing list Jik...@ww... http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-core |
From: Steve B. <Ste...@an...> - 2003-06-29 04:04:30
|
> At a bare minimum, the config file should certainly point one to the > blackdown jdk, version 1.4.x. Unless someone has a good reason not to > do it, I'd encourage you to make the change. This sounds fine. I recently shifted to the Sun VM (not entirely sure where the difference is...), because they ship an RPM. However, I'm very happy to use the Blackdown VM, moreover I think it is important that users use the same one that is used in all of our testing, so I'll move over. One issue that this raises is what directory to place the VM in---the Blackdown VM asks the user to simply unpack it in the appropriate directory. I understood that /opt was appropriate. Any thoughts, preferences, objections? > Also (as I learned this weekend), the comments in the config file for > the watson dist. have diverged from the ones for the generic i686 > config. The useful info in the Watson one should certainly be available > in the generic x86 one. When I do it I'll try to bring this up to date. I'll wait till I get some feedback on the above before I go and make the change. Cheers, --Steve |
From: Steven A. <au...@us...> - 2003-06-30 21:19:11
|
I know that the Blackdown organization focuses on the Linux platform and that they base their distro. on Sun code. I don't know much more than that. As Dave Grove wrote, without reason, there's no point in breaking compatibility with 1.3.x JDKs, so that should be fixed before the next release. I personally put Blackdown in /usr/local/j2sdk1.4.1, which I have symlinked to /usr/local/Blackdown-j2sdk1.4.1/j2sdk1.4.1. . Our servers have it in ~jalapeno/contrib/j2sdk1.4.1. With competition like that, I doubt anyone will be too picky about whatever name you use. --Steve Augart Steve Blackburn <Ste...@an...> Sent by: jik...@ww... 06/28/2003 09:04 PM Please respond to jikesrvm-core To: jik...@os... cc: Subject: Re: [Jikesrvm-core] Problems with latest CVS head > At a bare minimum, the config file should certainly point one to the > blackdown jdk, version 1.4.x. Unless someone has a good reason not to > do it, I'd encourage you to make the change. This sounds fine. I recently shifted to the Sun VM (not entirely sure where the difference is...), because they ship an RPM. However, I'm very happy to use the Blackdown VM, moreover I think it is important that users use the same one that is used in all of our testing, so I'll move over. One issue that this raises is what directory to place the VM in---the Blackdown VM asks the user to simply unpack it in the appropriate directory. I understood that /opt was appropriate. Any thoughts, preferences, objections? > Also (as I learned this weekend), the comments in the config file for > the watson dist. have diverged from the ones for the generic i686 > config. The useful info in the Watson one should certainly be available > in the generic x86 one. When I do it I'll try to bring this up to date. I'll wait till I get some feedback on the above before I go and make the change. Cheers, --Steve _______________________________________________ Jikesrvm-core mailing list Jik...@ww... http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-core |
From: Steve B. <Ste...@an...> - 2003-07-01 05:35:29
|
I just helped someone start out with Jikes RVM from scratch using the current head and things wound up in a heap. I remembered this thread and went and installed 1.4.1 on the machine being used, and sure enough that solved the problem. The problem arose when doing a simple BaseBaseSemiSpace build on a RedHat 9.0 machine using Blackdown 1.3.1. The problem disappeared by simply installing Blackdown 1.4.1 and changing the config file to reflect this. Is there a good reason why we can't run on 1.3.1, or do folks think this is a bug? Cheers, --Steve Building /home/andrewg/devel/jmtk/support/lib/classpathsrc.jar jbuild.expand: (templates cleaned) 340 s jbuild.copy: (sources cleaned)340 s jbuild.compile: (classes cleaned) 340 s jbuild.linkImage: (primordials cleaned) (bootimage cleaned) 340 s jbuild.linkBooter: (booter cleaned) 340 s jbuild.expand: (classloader templates expanded) 345 s preprocessModifiedFiles.C:23:30: warning: multi-line string literals are depreca ted (preprocessor built)(classpath.jar copied) 351 s jbuild.compile: (classes compiled) (jksvm.jar built) (jksvmsrc.jar built) 360 s jbuild.linkImage: (bootimage cleaned) (primordials updated) (built workaround zi p) WARNING java.lang.ref.Reference.enqueue ()Z: contains call to interruptible m ethod java.lang.ref.ReferenceQueue.enqueue (Ljava/lang/ref/Reference;)V Exception in thread "main" java.lang.ClassCastException: java.text.resources.Loc aleElements at BootImageWriter.copyToBootImage(BootImageWriter.java:1440) at BootImageWriter.copyToBootImage(BootImageWriter.java:1466) at BootImageWriter.copyToBootImage(BootImageWriter.java:1308) at BootImageWriter.copyToBootImage(BootImageWriter.java:1466) at BootImageWriter.copyToBootImage(BootImageWriter.java:1466) at BootImageWriter.copyToBootImage(BootImageWriter.java:1308) at BootImageWriter.copyToBootImage(BootImageWriter.java:1466) at BootImageWriter.main(BootImageWriter.java:501) make: *** [/home/andrewg/devel/jmtk/BaseBaseSemiSpace.i686/RVM.image] Error 1 jbuild.linkImage: some command we just ran (probably with a final argument of "") exited with status 2, possibly in source file line # 351 I give up; aborting execution. Exiting due to an error 378 s jbuild: Trouble while running "./jbuild.linkImage" (exit status 2); aborting exe cution |
From: David P G. <gr...@us...> - 2003-07-01 16:21:51
|
I opened a defect for this (not building with 1.3.1) It is at least something we need to understand. I can imagine a few whacky ways in which adding 1.4 level weak references to Jikes RVM could break a 1.3.X host JDK, but none of them seem that likely. So, it may be something that can actually be fixed if we put a little time into understanding it. --dave |
From: Chris H. <hof...@cs...> - 2003-07-01 16:54:20
|
It occurs to me that although the timing makes me suspect this is related to the inclusion of weak references, it's probably not quite as simple as that. When I was developing the weak reference code I'd still have been using Java 1.3.1, and I didn't see any problems. So either the timing of the appearance of the bug is pure coincidence, or adding the weak references has exposed a problem that was created between the time I developed the code and when it was added to your CVS repository. I think I contributed the code around May 16, and I know I synched my rvm area with your CVS head before sending it off to IBM. Or possibly some of changes Perry made to my code are the trigger, though it didn't sound like anything he did should be a problem. Chris David P Grove wrote: > > I opened a defect for this (not building with 1.3.1) > > It is at least something we need to understand. I can imagine a few > whacky ways in which adding 1.4 level weak references to Jikes RVM > could break a 1.3.X host JDK, but none of them seem that likely. So, > it may be something that can actually be fixed if we put a little time > into understanding it. > > --dave -- Chris Hoffmann -- Dept. of Computer Science/UMass at Amherst http://www-ali.cs.umass.edu/~hoffmann |