From gbenson at redhat.com Fri Jun 1 07:57:04 2007 From: gbenson at redhat.com (Gary Benson) Date: Fri, 1 Jun 2007 15:57:04 +0100 Subject: Hotspot on PPC In-Reply-To: <465F289A.8070906@sun.com> References: <465F289A.8070906@sun.com> Message-ID: <20070601145704.GJ4088@redhat.com> Bob Vandette wrote: > When we did the original IA64 port of Hotspot, we decided to use > a "C" interpreter in order to get the port done quicker. On > architectures with many CPU registers, the "C" interpreter is > actually just as fast or even faster than the generated assembly > version. We use the GCC computed goto in order to avoid the typical > dispatching overhead of switch statements. This interpreter is in > hotspot/src/share/vm/interpreter/cInterpretMethod.hpp. The problem > is that the only architecture that uses the cInterpreter is IA64 and > as far as I know, this code isn't open sourced. You'd need to see > the glue logic that exists in the CPU directory to use this > interpreter. That's interesting. I found an environment variable that seems to switch it on, CC_INTERP, but it's still trying to suck in machine- dependent stuff. Am I missing something, or is it simply that the build system is not set up to build without the JITs? Also, does this mean you have a working IA64 JDK internally? Does it exclusively use the C interpreter or was a JIT written later? If it's possible to run OpenJDK with a C interpreter then of course I'd love to know :) > I don't know if you are aware of a Java 5 version of PowerPC that > is on our Java SE Embedded site. It is a hotspot implementation > of Java SE 5.0 for Linux platforms. It uses the Hotspot client > JIT compiler and is only 32 bit but it has passed the fully JCK > certification. Interesting. Are there any plans to open source it? Cheers, Gary From Paul.Hohensee at Sun.COM Fri Jun 1 08:15:07 2007 From: Paul.Hohensee at Sun.COM (Paul Hohensee - Java SE) Date: Fri, 01 Jun 2007 11:15:07 -0400 Subject: Hotspot on PPC In-Reply-To: <20070601145704.GJ4088@redhat.com> References: <465F289A.8070906@sun.com> <20070601145704.GJ4088@redhat.com> Message-ID: <466037FB.9040801@sun.com> CC_INTERP must be set to build the C++ interpreter, but you also need some machine-dependent assembly code glue to make it work. We haven't open sourced the latter since we don't support the former. You can build a vm without the compilers. Use one of the 'core' targets like 'productcore'. We supported ia64 in 1.4.2, but dropped it in 5.0, so yes, we have old ia64 sources. The ia64 vm was a server-only 64-bit vm, which means it incorporated the server optimizing compiler. It used a C++ interpreter instead of what we call a template interpreter, which latter is an interpreter written in assembly code. The other platforms we support (sparc32, sparc64, x86 and x64) all use template interpreters for performance. We used a C++ interpreter for ia64 for time-to-market reasons (as Bob said): it already existed as a skunk works project and correct ia64 assembly is 'interesting' to write. I'm not aware of any plans to open source the PPC 5.0 port. Paul Gary Benson wrote: > Bob Vandette wrote: > >> When we did the original IA64 port of Hotspot, we decided to use >> a "C" interpreter in order to get the port done quicker. On >> architectures with many CPU registers, the "C" interpreter is >> actually just as fast or even faster than the generated assembly >> version. We use the GCC computed goto in order to avoid the typical >> dispatching overhead of switch statements. This interpreter is in >> hotspot/src/share/vm/interpreter/cInterpretMethod.hpp. The problem >> is that the only architecture that uses the cInterpreter is IA64 and >> as far as I know, this code isn't open sourced. You'd need to see >> the glue logic that exists in the CPU directory to use this >> interpreter. >> > > That's interesting. I found an environment variable that seems to > switch it on, CC_INTERP, but it's still trying to suck in machine- > dependent stuff. Am I missing something, or is it simply that the > build system is not set up to build without the JITs? > > Also, does this mean you have a working IA64 JDK internally? Does > it exclusively use the C interpreter or was a JIT written later? > If it's possible to run OpenJDK with a C interpreter then of course > I'd love to know :) > > >> I don't know if you are aware of a Java 5 version of PowerPC that >> is on our Java SE Embedded site. It is a hotspot implementation >> of Java SE 5.0 for Linux platforms. It uses the Hotspot client >> JIT compiler and is only 32 bit but it has passed the fully JCK >> certification. >> > > Interesting. Are there any plans to open source it? > > Cheers, > Gary > From gbenson at redhat.com Fri Jun 1 08:43:18 2007 From: gbenson at redhat.com (Gary Benson) Date: Fri, 1 Jun 2007 16:43:18 +0100 Subject: Hotspot on PPC In-Reply-To: <466037FB.9040801@sun.com> References: <465F289A.8070906@sun.com> <20070601145704.GJ4088@redhat.com> <466037FB.9040801@sun.com> Message-ID: <20070601154318.GL4088@redhat.com> Paul Hohensee - Java SE wrote: > CC_INTERP must be set to build the C++ interpreter, but you also > need some machine-dependent assembly code glue to make it work. We > haven't open sourced the latter since we don't support the former. Fair enough. > You can build a vm without the compilers. Use one of the 'core' > targets like 'productcore'. I was just reading that in hotspot/build/linux/Makefile ;) > We supported ia64 in 1.4.2, but dropped it in 5.0, so yes, we have > old ia64 sources. Ok, I understand a bit better now. Has the C++ interpreter been used in anger since then? > correct ia64 assembly is 'interesting' to write. So I've heard :) > I'm not aware of any plans to open source the PPC 5.0 port. Ok. Does the fact that it's only 5.0 mean you've dropped PPC? Thanks, Gary From Paul.Hohensee at Sun.COM Fri Jun 1 08:51:15 2007 From: Paul.Hohensee at Sun.COM (Paul Hohensee - Java SE) Date: Fri, 01 Jun 2007 11:51:15 -0400 Subject: Hotspot on PPC In-Reply-To: <20070601154318.GL4088@redhat.com> References: <465F289A.8070906@sun.com> <20070601145704.GJ4088@redhat.com> <466037FB.9040801@sun.com> <20070601154318.GL4088@redhat.com> Message-ID: <46604073.8030509@sun.com> The C++ interpreter hasn't been used for any platform but ia64. No, we've no plans to drop PPC support. We sell the it for use in embedded environments. If there's enough market demand we'd likely roll the port forward to jdk7 (which mostly == openjdk). Paul Gary Benson wrote: > Paul Hohensee - Java SE wrote: > >> CC_INTERP must be set to build the C++ interpreter, but you also >> need some machine-dependent assembly code glue to make it work. We >> haven't open sourced the latter since we don't support the former. >> > > Fair enough. > > >> You can build a vm without the compilers. Use one of the 'core' >> targets like 'productcore'. >> > > I was just reading that in hotspot/build/linux/Makefile ;) > > >> We supported ia64 in 1.4.2, but dropped it in 5.0, so yes, we have >> old ia64 sources. >> > > Ok, I understand a bit better now. Has the C++ interpreter been used > in anger since then? > > >> correct ia64 assembly is 'interesting' to write. >> > > So I've heard :) > > >> I'm not aware of any plans to open source the PPC 5.0 port. >> > > Ok. Does the fact that it's only 5.0 mean you've dropped PPC? > > Thanks, > Gary > From gbenson at redhat.com Fri Jun 1 10:48:48 2007 From: gbenson at redhat.com (Gary Benson) Date: Fri, 1 Jun 2007 18:48:48 +0100 Subject: Hotspot on PPC In-Reply-To: <46604073.8030509@sun.com> References: <465F289A.8070906@sun.com> <20070601145704.GJ4088@redhat.com> <466037FB.9040801@sun.com> <20070601154318.GL4088@redhat.com> <46604073.8030509@sun.com> Message-ID: <20070601174848.GA11951@redhat.com> Cool. Thanks for your help, and have a good weekend! Gary Paul Hohensee: > The C++ interpreter hasn't been used for any platform but ia64. > > No, we've no plans to drop PPC support. We sell the it for use in > embedded environments. If there's enough market demand we'd likely > roll the port forward to jdk7 (which mostly == openjdk). > > Paul > > Gary Benson wrote: > > Paul Hohensee - Java SE wrote: > > > CC_INTERP must be set to build the C++ interpreter, but you also > > > need some machine-dependent assembly code glue to make it work. > > > We haven't open sourced the latter since we don't support the > > > former. > > > > Fair enough. > > > > > You can build a vm without the compilers. Use one of the 'core' > > > targets like 'productcore'. > > > > I was just reading that in hotspot/build/linux/Makefile ;) > > > > > We supported ia64 in 1.4.2, but dropped it in 5.0, so yes, we > > > have old ia64 sources. > > > > Ok, I understand a bit better now. Has the C++ interpreter been > > used in anger since then? > > > > > correct ia64 assembly is 'interesting' to write. > > > > So I've heard :) > > > > > I'm not aware of any plans to open source the PPC 5.0 port. > > > > Ok. Does the fact that it's only 5.0 mean you've dropped PPC? > > > > Thanks, > > Gary From kirill.kononenko at gmail.com Fri Jun 1 16:33:38 2007 From: kirill.kononenko at gmail.com (Kirill Kononenko) Date: Sat, 2 Jun 2007 03:33:38 +0400 Subject: HotSpot on PPC In-Reply-To: <20070531131429.GG3856@redhat.com> References: <20070531131429.GG3856@redhat.com> Message-ID: Hi Gary, May I ask you a personal question? How will RedHat make money of this? Will it sell HotSpot in these beautiful colorful packages with the software that everyone can download? Will this version of HotSpot be open sourced? Cheers, Kirill On 31/05/07, Gary Benson wrote: > Hi all, > > This is just a quick introduction to say who I am and what I'm doing, > and hopefully to get in touch with people who can help or advise or > whatever. I wasn't at FOSDEM or JavaOne so I don't really know who's > who. > > So, I'm Gary, I work for Red Hat, and my job for the moment is to get > OpenJDK working on PPC. > > One specific question is that a couple of people have mentioned a > portable (non-JIT) interpreter. Can anybody tell me anything more? > > Cheers, > Gary > > From gbenson at redhat.com Mon Jun 4 08:31:53 2007 From: gbenson at redhat.com (Gary Benson) Date: Mon, 4 Jun 2007 16:31:53 +0100 Subject: HotSpot on PPC In-Reply-To: References: <20070531131429.GG3856@redhat.com> Message-ID: <20070604153153.GC32143@redhat.com> Kirill Kononenko wrote: > May I ask you a personal question? How will RedHat make money of > this? Will it sell HotSpot in these beautiful colorful packages > with the software that everyone can download? Will this version > of HotSpot be open sourced? I can't comment on Red Hat's business, but the plan is to package OpenJDK for Fedora and eventually RHEL. Cheers, Gary From twisti at complang.tuwien.ac.at Wed Jun 6 03:06:25 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Wed, 06 Jun 2007 12:06:25 +0200 Subject: CACAO 0.98 "Free all JITs!" released. Message-ID: <1181124385.12015.6.camel@localhost.localdomain> Hi! Probably some people here are interested. If not, sorry for the spam. - twisti --- CACAO 0.98 "Free all JITs!" released. This is a major feature enhancement and bug-fix release. Here is a short list of the most important changes: * ARM and MIPS32 code generators are now open-source. * PowerPC64 code generator was added. * Sun's phoneme CLDC-1.1 classes can now be used as Java core library. * Exception throwing code was completely rewritten, this saves JIT code size from 20% up to 50%. * Lock-record code was rewritten and a memory leak was fixed. * Threads code has been reworked and improved. * Exception code has been reworked and improved. * Implemented Class/Method/Field getSignature. * A lot of stuff has been reworked, fixed or improved in the whole VM code. * Fixed memory leak in threads code. This release supports GNU Classpath 0.92 or higher and was tested on some platforms against GNU Classpath 0.95. Starting with this release, CACAO can also use Sun's phoneme CLDC-1.1 classes as Java core library. You can build a CLDC CACAO with or without JNI support (--disable-jni). A very short HOWTO on building a CLDC CACAO can be found here: https://c1.complang.tuwien.ac.at/cacaowiki/CLDC1.1 CACAO uses GNU Classpath as default Java core library and supports upstream releases or CVS snapshots. CACAO's ./configure has some options for classpath configuration, namely: --with-classpath= --with-classpath-prefix= --with-classpath-classes= --with-classpath-libdir= --with-classpath-includedir= For detailed information, use ./configure --help. This release adds support for the powerpc64-unknown-linux-gnu architecture. Currently supported JIT compiler architectures are: * alpha-unknown-freebsd5.4 * alpha-unknown-linux-gnu * arm-unknown-linux-gnu * i386-apple-darwin8.8.1 * i386-unknown-freebsd5.3 * i686-pc-linux-gnu * mips-sgi-irix6.5 * mips-unknown-linux-gnu * powerpc-apple-darwin7.2.0 * powerpc-unknown-linux-gnu * powerpc64-unknown-linux-gnu * x86_64-unknown-linux-gnu Information about working applications and some screenshots can be found on http://www.cacaojvm.org/ The CACAO wiki can be found here: http://c1.complang.tuwien.ac.at/cacaowiki/ The CACAO mailing list can be found here: http://c1.complang.tuwien.ac.at/mailman/listinfo/cacao/ Daily test runs with CACAO SVN trunk, GNU Classpath CVS head and Mauve CVS head can be found on http://www.cacaojvm.org/tgolem/ CACAO 0.98 can be downloaded from http://www.cacaojvm.org/download/cacao-0.98/ File : cacao-0.98.tar.bz2 md5sum : 8b8907c8b925761c9410bcadb9705346 sha1sum: 2adfc4c4514cb29fd15052ad28323eb35824e8b5 Enjoy! The CACAO Team cacao at cacaojvm.org From antonone at gmail.com Wed Jun 6 09:51:18 2007 From: antonone at gmail.com (Grzegorz Antoniak) Date: Wed, 6 Jun 2007 16:51:18 +0000 (UTC) Subject: accessing the operand stack using jvmti/jwdp/jdi Message-ID: Hello. I'm sorry if this will be the second post on the same issue. I've already sent a post on this group with the same topic, but it seems it has been lost somewhere. Anyway, the question which I would ask is: is it possible to access (read/write) the operand stack of a frame using JVMTI interface? I just want to be able to see the local variables in the function in compiled classes, without having any debug info (that is, classes compiled with -g:none). I'm using JDI interface, but since JDI is using JWDP, and JWDP uses JVMTI, then it all comes down to JVMTI, doesn't it? I've found some topics on sun's forums and some entries in the bug database, but some of them are already a few years old. From there I read that there is no possibility to access the operand stack in the current state of the JVM. Is this true? And, if it is, do you plan to implement this feature in JDK6, or 7? -- Best regards, a1. PGP/GPG: 78737BF9 From jim.holmlund at sun.com Thu Jun 7 09:40:13 2007 From: jim.holmlund at sun.com (Jim Holmlund) Date: Thu, 7 Jun 2007 09:40:13 -0700 Subject: accessing the operand stack using jvmti/jwdp/jdi References: Message-ID: <18024.13549.932734.711337@gargle.gargle.HOWL> Hello Grzegorz. We have a different alias for debugging, profiling, etc. It is serviceability-dev at openjdk.java.net. You can see descriptions of all the aliases here: http://mail.openjdk.java.net/mailman/listinfo Regarding accessing the operand stack, we have this RFE: 4508774: Would like the function GetOperandStack in jvmti to be implemented We are hoping to implement this(and the corresponding features in JDWP and JDI) for JDK 7, but plans are still in flux. Jim Holmlund - JPDA Team, Java Software, Sun Microsystems, Inc. mailto:jim.holmlund at sun.com http://java.sun.com/javase/technologies/core/toolsapis/jpda Grzegorz Antoniak writes: > Hello. > > I'm sorry if this will be the second post on the same issue. I've > already sent a post on this group with the same topic, but it seems it > has been lost somewhere. > > Anyway, the question which I would ask is: is it possible to access > (read/write) the operand stack of a frame using JVMTI interface? I just > want to be able to see the local variables in the function in compiled > classes, without having any debug info (that is, classes compiled with > -g:none). I'm using JDI interface, but since JDI is using JWDP, and > JWDP uses JVMTI, then it all comes down to JVMTI, doesn't it? > > I've found some topics on sun's forums and some entries in the bug > database, but some of them are already a few years old. From there I > read that there is no possibility to access the operand stack in the > current state of the JVM. Is this true? And, if it is, do you plan to > implement this feature in JDK6, or 7? > > -- > Best regards, a1. > PGP/GPG: 78737BF9 > > > From flameeyes at gmail.com Sat Jun 9 14:55:35 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Sat, 9 Jun 2007 23:55:35 +0200 Subject: [PATCH] Respect STATIC_CXX value when linking libjvm Message-ID: <20070609235535.4b13622f@enterprise.flameeyes.is-a-geek.org> Hello, the attached patch makes the libjvm link stage respect the STATIC_CXX value passed by the user during build. While it's true that a package that should be deployed on heterogeneous systems is best linked statically to GCC's libstdc++, as the ABI is susceptible to changes, distributions tend to be able to take care of their ABI and their dependencies on their own, so linking shared for them is an advantage. At the moment, although some parts of openjdk actually follow the STATIC_CXX value, libjvm will not link to libstdc++ dynamically, that's why the patch is needed. HTH, -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: dynamic-libstdc++.patch Type: text/x-patch Size: 801 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070609/bc8dfc88/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070609/bc8dfc88/attachment-0001.bin From gbenson at redhat.com Tue Jun 12 05:15:23 2007 From: gbenson at redhat.com (Gary Benson) Date: Tue, 12 Jun 2007 13:15:23 +0100 Subject: C++ interpreter question Message-ID: <20070612121523.GA3910@redhat.com> Hi all, The C++ interpreter is full of references to the following methods: expr_index_at expr_tag_index_at local_index_at local_tag_index_at The existing platform-specific interpreter_.hpp files contain these methods: expr_offset_in_bytes expr_tag_offset_in_bytes I'm guessing something was refactored after the ia64 port was dropped. Does anyone know how the old methods relate to the new ones? Cheers, Gary From cunningh at cboe.com Tue Jun 12 07:26:38 2007 From: cunningh at cboe.com (Cunningham, Ryan) Date: Tue, 12 Jun 2007 09:26:38 -0500 Subject: Time Stamps Message-ID: In the output of the java process's activity there are timestamps, "6.074: [GC {Heap before gc invocations=0:", and the 6.074 is time after start of process and I want to change that to human time. I am not really sure where to go from here. I have searched the files and have a vague idea of where it comes from. Ryan P Cunningham CBOE cunningh at cboe.com From Peter.Kessler at Sun.COM Tue Jun 12 14:01:17 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Tue, 12 Jun 2007 14:01:17 -0700 Subject: Time Stamps In-Reply-To: References: Message-ID: <466F099D.5070707@Sun.COM> Cunningham, Ryan wrote: > In the output of the java process's activity there are timestamps, "6.074: [GC {Heap before gc invocations=0:", and the 6.074 is time after start of process and I want to change that to human time. I am not really sure where to go from here. I have searched the files and have a vague idea of where it comes from. > > Ryan P Cunningham > CBOE > cunningh at cboe.com If you can wait for build 14, you'll find that I've added -XX:+PrintGCDateStamps as a fix for 6517301: There should be a -XX:+PrintGCDateStamps http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6517301 which will put an ISO-8601 date and time on the GC output. E.g., 2007-06-09T12:57:35.093-0700: [GC [PSYoungGen: 4064K->1552K(4928K)] 38770K->36258K(63232K), 0.0590532 secs] [Times: user=0.08 sys=0.00, real=0.06 secs] Is that what you wanted to do? If so, I apologize for preempting your doing it, but we already had a bunch of customers that wanted that feature. (Some from large financial traders in Chicago. :-) You wouldn't have liked it anyway, since the obvious solution of using strftime(3C) doesn't work on Windows. ... peter From Thomas.Rodriguez at Sun.COM Tue Jun 12 14:54:39 2007 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 12 Jun 2007 14:54:39 -0700 Subject: Time Stamps In-Reply-To: <466F099D.5070707@Sun.COM> References: <466F099D.5070707@Sun.COM> Message-ID: <466F161F.6000401@sun.com> The hotspot.log also contains a reference timestamp telling when the VM started. time_ms is the same value System.currentTimeMillis() would have returned at the point we started the JVM. All the timestamps should be relative to that time so you should be able to convert from that. Normally the hotspot.log isn't written to disk so you'd need to add -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput if you want to get at it. tom Peter B. Kessler wrote: > Cunningham, Ryan wrote: > >> In the output of the java process's activity there are timestamps, >> "6.074: [GC {Heap before gc invocations=0:", and the 6.074 is time >> after start of process and I want to change that to human time. I am >> not really sure where to go from here. I have searched the files and >> have a vague idea of where it comes from. >> >> Ryan P Cunningham >> CBOE >> cunningh at cboe.com > > If you can wait for build 14, you'll find that I've added > > -XX:+PrintGCDateStamps > > as a fix for > > 6517301: There should be a -XX:+PrintGCDateStamps > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6517301 > > which will put an ISO-8601 date and time on the GC output. E.g., > > 2007-06-09T12:57:35.093-0700: [GC [PSYoungGen: 4064K->1552K(4928K)] > 38770K->36258K(63232K), 0.0590532 secs] [Times: user=0.08 sys=0.00, > real=0.06 secs] > > Is that what you wanted to do? If so, I apologize for preempting > your doing it, but we already had a bunch of customers that wanted > that feature. (Some from large financial traders in Chicago. :-) > You wouldn't have liked it anyway, since the obvious solution of > using strftime(3C) doesn't work on Windows. > > ... peter From ted at tedneward.com Thu Jun 14 19:53:32 2007 From: ted at tedneward.com (Ted Neward) Date: Thu, 14 Jun 2007 19:53:32 -0700 Subject: Time Stamps In-Reply-To: <466F161F.6000401@sun.com> Message-ID: <01bd01c7aef8$5dd2ffa0$802ca8c0@XPWork> Quick clarification: what does UnlockDiagnosticVMOptions do? Does that turn on non-product -XX options in the product builds or something? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev- > bounces at openjdk.java.net] On Behalf Of Tom Rodriguez > Sent: Tuesday, June 12, 2007 2:55 PM > To: Peter B. Kessler > Cc: hotspot-dev at openjdk.java.net; Cunningham, Ryan > Subject: Re: Time Stamps > > The hotspot.log also contains a reference timestamp telling when the VM > started. > > > > time_ms is the same value System.currentTimeMillis() would have returned > at the > point we started the JVM. All the timestamps should be relative to that > time so > you should be able to convert from that. Normally the hotspot.log isn't > written > to disk so you'd need to add -XX:+UnlockDiagnosticVMOptions - > XX:+LogVMOutput if > you want to get at it. > > tom > > Peter B. Kessler wrote: > > Cunningham, Ryan wrote: > > > >> In the output of the java process's activity there are timestamps, > >> "6.074: [GC {Heap before gc invocations=0:", and the 6.074 is time > >> after start of process and I want to change that to human time. I am > >> not really sure where to go from here. I have searched the files and > >> have a vague idea of where it comes from. > >> > >> Ryan P Cunningham > >> CBOE > >> cunningh at cboe.com > > > > If you can wait for build 14, you'll find that I've added > > > > -XX:+PrintGCDateStamps > > > > as a fix for > > > > 6517301: There should be a -XX:+PrintGCDateStamps > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6517301 > > > > which will put an ISO-8601 date and time on the GC output. E.g., > > > > 2007-06-09T12:57:35.093-0700: [GC [PSYoungGen: 4064K->1552K(4928K)] > > 38770K->36258K(63232K), 0.0590532 secs] [Times: user=0.08 sys=0.00, > > real=0.06 secs] > > > > Is that what you wanted to do? If so, I apologize for preempting > > your doing it, but we already had a bunch of customers that wanted > > that feature. (Some from large financial traders in Chicago. :-) > > You wouldn't have liked it anyway, since the obvious solution of > > using strftime(3C) doesn't work on Windows. > > > > ... peter > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.472 / Virus Database: 269.8.13/843 - Release Date: 6/10/2007 > 1:39 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.15/848 - Release Date: 6/13/2007 12:50 PM From Jon.Masamitsu at Sun.COM Thu Jun 14 20:16:13 2007 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Thu, 14 Jun 2007 20:16:13 -0700 Subject: Time Stamps In-Reply-To: <01bd01c7aef8$5dd2ffa0$802ca8c0@XPWork> References: <01bd01c7aef8$5dd2ffa0$802ca8c0@XPWork> Message-ID: <4672047D.1070405@sun.com> Ted Neward wrote: >Quick clarification: what does UnlockDiagnosticVMOptions do? Does that turn >on non-product -XX options in the product builds or something? > Flags in globals.hpp (and friends) that that are declared diagnostics (e.g., diagnostic(bool, VerifyAfterGC, false, \ "Verify memory system after GC") \ will be recognized in a product build if UnlockDiagnosticVMOptions is turned on. I believe it has to be turned on before turning on a diagnostic flag. > >Ted Neward >Java, .NET, XML Services >Consulting, Teaching, Speaking, Writing >http://www.tedneward.com > > > >>-----Original Message----- >>From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev- >>bounces at openjdk.java.net] On Behalf Of Tom Rodriguez >>Sent: Tuesday, June 12, 2007 2:55 PM >>To: Peter B. Kessler >>Cc: hotspot-dev at openjdk.java.net; Cunningham, Ryan >>Subject: Re: Time Stamps >> >>The hotspot.log also contains a reference timestamp telling when the VM >>started. >> >> >> >>time_ms is the same value System.currentTimeMillis() would have returned >>at the >>point we started the JVM. All the timestamps should be relative to that >>time so >>you should be able to convert from that. Normally the hotspot.log isn't >>written >>to disk so you'd need to add -XX:+UnlockDiagnosticVMOptions - >>XX:+LogVMOutput if >>you want to get at it. >> >>tom >> >>Peter B. Kessler wrote: >> >> >>>Cunningham, Ryan wrote: >>> >>> >>> >>>>In the output of the java process's activity there are timestamps, >>>>"6.074: [GC {Heap before gc invocations=0:", and the 6.074 is time >>>>after start of process and I want to change that to human time. I am >>>>not really sure where to go from here. I have searched the files and >>>>have a vague idea of where it comes from. >>>> >>>>Ryan P Cunningham >>>>CBOE >>>>cunningh at cboe.com >>>> >>>> >>>If you can wait for build 14, you'll find that I've added >>> >>> -XX:+PrintGCDateStamps >>> >>>as a fix for >>> >>> 6517301: There should be a -XX:+PrintGCDateStamps >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6517301 >>> >>>which will put an ISO-8601 date and time on the GC output. E.g., >>> >>> 2007-06-09T12:57:35.093-0700: [GC [PSYoungGen: 4064K->1552K(4928K)] >>>38770K->36258K(63232K), 0.0590532 secs] [Times: user=0.08 sys=0.00, >>>real=0.06 secs] >>> >>>Is that what you wanted to do? If so, I apologize for preempting >>>your doing it, but we already had a bunch of customers that wanted >>>that feature. (Some from large financial traders in Chicago. :-) >>>You wouldn't have liked it anyway, since the obvious solution of >>>using strftime(3C) doesn't work on Windows. >>> >>> ... peter >>> >>> >>No virus found in this incoming message. >>Checked by AVG Free Edition. >>Version: 7.5.472 / Virus Database: 269.8.13/843 - Release Date: 6/10/2007 >>1:39 PM >> >> >> > >No virus found in this outgoing message. >Checked by AVG Free Edition. >Version: 7.5.472 / Virus Database: 269.8.15/848 - Release Date: 6/13/2007 >12:50 PM > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070614/f90b4791/attachment.html From vezina.sebastien.2 at courrier.uqam.ca Fri Jun 15 10:46:42 2007 From: vezina.sebastien.2 at courrier.uqam.ca (Sebastien Vezina) Date: Fri, 15 Jun 2007 13:46:42 -0400 Subject: HotSpot/CoreLibraries Interface documentation Message-ID: <4672D082.20403@courrier.uqam.ca> Hi, I've been looking for documentation on the VM/CoreLibrary interface in OpenJDK. I looked in the Core Libraaries doc and in the HotSpot doc and didn't find anything on the subject. My goal would be to be able to use the core libraries with a different VM. Can anyone point me to any documentation on the subject. Thanks. -- Sebastien Vezina vezina.sebastien.2 at courrier.uqam.ca From jim.holmlund at sun.com Fri Jun 15 13:45:08 2007 From: jim.holmlund at sun.com (Jim Holmlund) Date: Fri, 15 Jun 2007 13:45:08 -0700 Subject: HotSpot/CoreLibraries Interface documentation References: <4672D082.20403@courrier.uqam.ca> Message-ID: <18034.64084.129571.494459@gargle.gargle.HOWL> Hello Sebastien. In case it helps, you can find information on APIs implemented in HotSpot and used by tools in the J2SE repository here: http://openjdk.java.net/groups/hotspot/docs/Serviceability.html We are in the process of adding a link to the above page in the HotSpot page: http://openjdk.java.net/groups/hotspot/ HTH - jjh Jim Holmlund - JPDA Team, Java Software, Sun Microsystems, Inc. mailto:jim.holmlund at sun.com http://java.sun.com/javase/technologies/core/toolsapis/jpda Sebastien Vezina writes: > Hi, > > I've been looking for documentation on the VM/CoreLibrary interface in > OpenJDK. I looked in the Core Libraaries doc and in the HotSpot doc and > didn't find anything on the subject. My goal would be to be able to use > the core libraries with a different VM. Can anyone point me to any > documentation on the subject. > > Thanks. > > -- > Sebastien Vezina > vezina.sebastien.2 at courrier.uqam.ca > From jim.holmlund at sun.com Fri Jun 15 14:03:52 2007 From: jim.holmlund at sun.com (Jim Holmlund) Date: Fri, 15 Jun 2007 14:03:52 -0700 Subject: Time Stamps References: <466F161F.6000401@sun.com> <01bd01c7aef8$5dd2ffa0$802ca8c0@XPWork> Message-ID: <18034.65208.392364.707920@gargle.gargle.HOWL> Hello Ted. Look at line 203 here: http://opengrok.neojava.org/hotspot/xref/src/share/vm/runtime/globals.hpp Be sure to note the caveat that these flags are not intended for use in production or for tuning etc. You can search for 'diagnostic' in globals.hpp to see the diagnostic flags and brief descriptions. If you have a fastdebug JDK build available, you can see the diagnostic options by doing this for example: $j6/fastdebug/bin/java -Xprintflags | fgrep -i diagnostic HTH - jjh Jim Holmlund - JPDA Team, Java Software, Sun Microsystems, Inc. mailto:jim.holmlund at sun.com http://java.sun.com/javase/technologies/core/toolsapis/jpda Ted Neward writes: > Quick clarification: what does UnlockDiagnosticVMOptions do? Does that turn > on non-product -XX options in the product builds or something? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > -----Original Message----- > > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev- > > bounces at openjdk.java.net] On Behalf Of Tom Rodriguez > > Sent: Tuesday, June 12, 2007 2:55 PM > > To: Peter B. Kessler > > Cc: hotspot-dev at openjdk.java.net; Cunningham, Ryan > > Subject: Re: Time Stamps > > > > The hotspot.log also contains a reference timestamp telling when the VM > > started. > > > > > > > > time_ms is the same value System.currentTimeMillis() would have returned > > at the > > point we started the JVM. All the timestamps should be relative to that > > time so > > you should be able to convert from that. Normally the hotspot.log isn't > > written > > to disk so you'd need to add -XX:+UnlockDiagnosticVMOptions - > > XX:+LogVMOutput if > > you want to get at it. > > > > tom > > > > Peter B. Kessler wrote: > > > Cunningham, Ryan wrote: > > > > > >> In the output of the java process's activity there are timestamps, > > >> "6.074: [GC {Heap before gc invocations=0:", and the 6.074 is time > > >> after start of process and I want to change that to human time. I am > > >> not really sure where to go from here. I have searched the files and > > >> have a vague idea of where it comes from. > > >> > > >> Ryan P Cunningham > > >> CBOE > > >> cunningh at cboe.com > > > > > > If you can wait for build 14, you'll find that I've added > > > > > > -XX:+PrintGCDateStamps > > > > > > as a fix for > > > > > > 6517301: There should be a -XX:+PrintGCDateStamps > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6517301 > > > > > > which will put an ISO-8601 date and time on the GC output. E.g., > > > > > > 2007-06-09T12:57:35.093-0700: [GC [PSYoungGen: 4064K->1552K(4928K)] > > > 38770K->36258K(63232K), 0.0590532 secs] [Times: user=0.08 sys=0.00, > > > real=0.06 secs] > > > > > > Is that what you wanted to do? If so, I apologize for preempting > > > your doing it, but we already had a bunch of customers that wanted > > > that feature. (Some from large financial traders in Chicago. :-) > > > You wouldn't have liked it anyway, since the obvious solution of > > > using strftime(3C) doesn't work on Windows. > > > > > > ... peter > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.472 / Virus Database: 269.8.13/843 - Release Date: 6/10/2007 > > 1:39 PM > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.472 / Virus Database: 269.8.15/848 - Release Date: 6/13/2007 > 12:50 PM > > > From mark at klomp.org Sat Jun 16 07:05:43 2007 From: mark at klomp.org (Mark Wielaard) Date: Sat, 16 Jun 2007 14:05:43 +0000 (UTC) Subject: HotSpot/CoreLibraries Interface documentation References: <4672D082.20403@courrier.uqam.ca> Message-ID: Sebastien Vezina writes: > I've been looking for documentation on the VM/CoreLibrary interface in > OpenJDK. I looked in the Core Libraaries doc and in the HotSpot doc and > didn't find anything on the subject. My goal would be to be able to use > the core libraries with a different VM. Can anyone point me to any > documentation on the subject. If you read http://planet.classpath.org/ you can see that several GNU Classpath based runtimes are experimenting with adopting all or parts of the OpenJDK core libraries. If no documentation exists it might be interesting to pull together the knowledge of the ikvm, jamaica, cacao and openjdk hackers to get an overview how to do this. For GNU Classpath we have a vm/platform interface as described at http://www.gnu.org/software/classpath/docs/vmintegration.html It would be nice to have a interoperability layer for the various free software runtimes to share. At the moment I believe Cacao is the most completely integrated (others are not using the whole openjdk core class library as is, but combine it with with GNU Classpath or their own internal VM specific class library extensions). Inspecting the cacao sources at http://b2.complang.tuwien.ac.at/cgi-bin/viewcvs.cgi/cacao/ might help since they can not only use the OpenJDK core libraries as is, but also the GNU Classpath and the phoneme CLDC-1.1 classes as core class library. For more info see http://www.cacaojvm.org/ Hope that helps. Cheers, Mark From rgougol at email.sjsu.edu Sat Jun 16 21:24:23 2007 From: rgougol at email.sjsu.edu (Nima Rouhollah Gougol) Date: Sat, 16 Jun 2007 21:24:23 -0700 Subject: Link List in Assembly Interpreter Message-ID: <4674B777.2030500@email.sjsu.edu> Hello everybody, Again this is Nima Gougol. I am seriously working on HotSpot toward my Masters' thesis at SJSU. Currently, I am trying to enhance HotSpot invocation threshold and compilation triggering with dynamic invocation threshold instead the static CompileThreshold which is 10,000 in server mode. Any feedback regarding any of the following questions will be extremely appreciated. My question is how I may store and access some data as a link list (or a grow able array) from Assembly interpreter? I am already storing data within JavaThread structure of the thread that is running interpreter. Can I access a static member of JavaThread in assembly interpreter? Can I reloce, grow or shrink an array structure within JavaThread from assembly interpreter? Can call a C method of JavaThread that is running the interpreter from assembly interpreter? For example, can I get the entry point of a C method of JavaThread and call it with __ call() method of assembly? Can I generate a grow able array or link list inside the heap of Java Virtual Machine from assembly interpreter? Sincerely, Nima R. Gougol From chenj at lemote.com Mon Jun 18 00:49:19 2007 From: chenj at lemote.com (chenjie) Date: Mon, 18 Jun 2007 15:49:19 +0800 Subject: Is anybody interested in porting the JDK6 to MIPS arch Message-ID: <467638FF.5090306@lemote.com> I have completed porting the JVM5 c1 on Loongson(MIPSIII instruction set), and now I am porting the JVM6. If I got more hands, I will speed up the porting progress.by the way, I found it is difficult to debug JVM by the current tools: gdb, JVM -XX parameter, crash reports. do anybody get some better ideas to debug? From chenj at lemote.com Mon Jun 18 00:37:20 2007 From: chenj at lemote.com (chenjie) Date: Mon, 18 Jun 2007 15:37:20 +0800 Subject: Is anybody interested in porting the JDK6 to MIPS arch Message-ID: <46763630.4000809@lemote.com> I have completed porting the JVM5 c1 on Loongson(MIPSIII instruction set), and now I am porting the JVM6. If I got more hands, I will speed up the porting progress.by the way, I found it is difficult to debug JVM by the current tools: gdb, JVM -XX parameter, crash reports. do anybody get some better ideas to debug? From Peter.Kessler at Sun.COM Mon Jun 18 10:02:07 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Mon, 18 Jun 2007 10:02:07 -0700 Subject: Is anybody interested in porting the JDK6 to MIPS arch In-Reply-To: <467638FF.5090306@lemote.com> References: <467638FF.5090306@lemote.com> Message-ID: <4676BA8F.4060405@Sun.COM> chenjie wrote: > I have completed porting the JVM5 c1 on Loongson(MIPSIII instruction set), and now I > am porting the JVM6. If I got more hands, I will speed up the porting progress.by the way, > I found it is difficult to debug JVM by the current tools: gdb, JVM -XX parameter, > crash reports. do anybody get some better ideas to debug? This is interesting, but JDK5 and JDK6 have not (yet) been open sourced. Are you working from the jdk6.dev.java.net sources under the Java Research License? ... peter From Kelly.Ohair at Sun.COM Mon Jun 18 10:02:56 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 18 Jun 2007 10:02:56 -0700 Subject: Is anybody interested in porting the JDK6 to MIPS arch In-Reply-To: <467638FF.5090306@lemote.com> References: <467638FF.5090306@lemote.com> Message-ID: <4676BAC0.2010703@sun.com> The free Sun Studio 12 compilers are available for Linux X86. I'm not sure if the dbx in it can debug a g++ built app (it can debug a gcc or plain C build app), dbx might be a better answer than gdb, if it could understand the g++ debug information. The other possibility would be to try and build Hotspot with the Sun Studio 12 Linux compilers, then the dbx will definitely work, but I don't know of anyone that has done that yet. We want to try this at some point, to see if the performance might improve over g++/gcc, but I haven't had the time to try it. I'd welcome someone giving it a try. -kto chenjie wrote: > I have completed porting the JVM5 c1 on Loongson(MIPSIII instruction > set), and now I > am porting the JVM6. If I got more hands, I will speed up the porting > progress.by the way, > I found it is difficult to debug JVM by the current tools: gdb, JVM -XX > parameter, > crash reports. do anybody get some better ideas to debug? > > From neojia at gmail.com Mon Jun 18 10:23:45 2007 From: neojia at gmail.com (Neo Jia) Date: Mon, 18 Jun 2007 12:23:45 -0500 Subject: Fwd: Is anybody interested in porting the JDK6 to MIPS arch In-Reply-To: <5d649bdb0706180734g3a4dafb3x63cf58676755d35c@mail.gmail.com> References: <467638FF.5090306@lemote.com> <5d649bdb0706180734g3a4dafb3x63cf58676755d35c@mail.gmail.com> Message-ID: <5d649bdb0706181023t432f9a97h38f8bd30dd00efa2@mail.gmail.com> Sorry, I forget to CC to the mailing list. Thanks, Neo ---------- Forwarded message ---------- From: Neo Jia Date: Jun 18, 2007 9:34 AM Subject: Re: Is anybody interested in porting the JDK6 to MIPS arch To: chenjie On 6/18/07, chenjie wrote: > I have completed porting the JVM5 c1 on Loongson(MIPSIII instruction > set), and now I > am porting the JVM6. If I got more hands, I will speed up the porting > progress.by the way, > I found it is difficult to debug JVM by the current tools: gdb, JVM -XX > parameter, I am debugging hotspot by gdb and it works fine. What is your problem? Thanks, Neo > crash reports. do anybody get some better ideas to debug? > > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! From chenj at lemote.com Mon Jun 18 17:39:27 2007 From: chenj at lemote.com (chenjie) Date: Tue, 19 Jun 2007 08:39:27 +0800 Subject: Is anybody interested in porting the JDK6 to MIPS arch In-Reply-To: <4676BA8F.4060405@Sun.COM> References: <467638FF.5090306@lemote.com> <4676BA8F.4060405@Sun.COM> Message-ID: <467725BF.2010405@lemote.com> Not currently, I just porting for research now, I will port open JDK under GPL in the future Peter B. Kessler ??: > chenjie wrote: > >> I have completed porting the JVM5 c1 on Loongson(MIPSIII instruction >> set), and now I >> am porting the JVM6. If I got more hands, I will speed up the porting >> progress.by the way, >> I found it is difficult to debug JVM by the current tools: gdb, JVM >> -XX parameter, >> crash reports. do anybody get some better ideas to debug? > > > This is interesting, but JDK5 and JDK6 have not (yet) been > open sourced. Are you working from the jdk6.dev.java.net > sources under the Java Research License? > > ... peter > > > From Thomas.Rodriguez at Sun.COM Tue Jun 19 11:33:19 2007 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 19 Jun 2007 11:33:19 -0700 Subject: Link List in Assembly Interpreter In-Reply-To: <4674B777.2030500@email.sjsu.edu> References: <4674B777.2030500@email.sjsu.edu> Message-ID: <4678216F.2070003@sun.com> There's nothing stopping your from doing any of these things, assuming you can write the code. Anything that involves malloc or free obviously needs to be done by calling C code. The assembly interpreter calls out to helper C functions all the time and that's generally the normal way of doing anything which is too complicated to do from assembly. You can't call virtuals or member functions from the interpreter though. I'd probably break it down into putting elements into arrays or linked lists from assembly but any resizing of the data structures would be done from C. Actually I'd probably start with calling into C as much as possible and only go the way of assembly if it was absolutely necessary for speed. There should be lots of examples of calling C you can copy from. In particular method entries and backedges already have callouts in them for invocation counter overflows. tom Nima Rouhollah Gougol wrote: > Hello everybody, Again this is Nima Gougol. I am seriously working on > HotSpot toward my Masters' thesis at SJSU. Currently, I am trying to > enhance HotSpot invocation threshold and compilation triggering with > dynamic invocation threshold instead the static CompileThreshold which > is 10,000 in server mode. Any feedback regarding any of the following > questions will be extremely appreciated. > > My question is how I may store and access some data as a link list (or a > grow able array) from Assembly interpreter? I am already storing data > within JavaThread structure of the thread that is running interpreter. > Can I access a static member of JavaThread in assembly interpreter? Can > I reloce, grow or shrink an array structure within JavaThread from > assembly interpreter? Can call a C method of JavaThread that is running > the interpreter from assembly interpreter? For example, can I get the > entry point of a C method of JavaThread and call it with __ call() > method of assembly? Can I generate a grow able array or link list inside > the heap of Java Virtual Machine from assembly interpreter? > > Sincerely, > > Nima R. Gougol From Nikolay.Igotti at Sun.COM Wed Jun 20 03:08:18 2007 From: Nikolay.Igotti at Sun.COM (Nikolay Igotti) Date: Wed, 20 Jun 2007 14:08:18 +0400 Subject: [Fwd: [PATCH] Respect STATIC_CXX value when linking libjvm] In-Reply-To: <4677E682.3070300@Sun.COM> References: <4677E682.3070300@Sun.COM> Message-ID: <4678FC92.2070201@Sun.Com> Diego, I will sponsor your patch for intergation into VM. For your reference bug id is: 6570964: support for dynamical linking of libstdc++ in VM build on Linux Thanks, Nikolay > Hello, > > the attached patch makes the libjvm link stage respect the STATIC_CXX > value passed by the user during build. While it's true that a package > that should be deployed on heterogeneous systems is best linked > statically to GCC's libstdc++, as the ABI is susceptible to changes, > distributions tend to be able to take care of their ABI and their > dependencies on their own, so linking shared for them is an advantage. > > At the moment, although some parts of openjdk actually follow the > STATIC_CXX value, libjvm will not link to libstdc++ dynamically, that's > why the patch is needed. > > HTH, > > ------------------------------------------------------------------------ > > Index: openjdk-b13/hotspot/build/linux/makefiles/vm.make > =================================================================== > --- openjdk-b13.orig/hotspot/build/linux/makefiles/vm.make > +++ openjdk-b13/hotspot/build/linux/makefiles/vm.make > @@ -151,8 +151,14 @@ else > # JVM is statically linked with libgcc[_s] and libstdc++; this is needed to > # get around library dependency and compatibility issues. Must use gcc not > # g++ to link. > - LFLAGS_VM += $(STATIC_LIBGCC) > - LIBS_VM += $(STATIC_STDCXX) $(LIBS) > + ifeq ($(STATIC_CXX), true) > + LFLAGS_VM += $(STATIC_LIBGCC) > + LIBS_VM += $(STATIC_STDCXX) > + else > + LIBS_VM += -lstdc++ > + endif > + > + LIBS_VM += $(LIBS) > endif > > LINK_VM = $(LINK_LIB.c) > From Steve.Goldman at Sun.COM Thu Jun 21 11:00:44 2007 From: Steve.Goldman at Sun.COM (steve goldman) Date: Thu, 21 Jun 2007 14:00:44 -0400 Subject: _LP64 and vm defines Message-ID: <467ABCCC.6080605@sun.com> [ I orginally sent this to internal Sun hotspot-dev alias even though it was more appropriate for here. Old habits and such... ] I was surprised yesterday with an episode with the use of _LP64. In the i486/amd64 register change I found that in the register_ files that _LP64 was not defined. I got around that by testing AMD64 (which in fact may have been more appropriate) but was mystified by the lack of _LP64 in a LP64 build. It turns out that with some investigating by Tom that if you don't include certain standard include files (say stdio.h) that even if you do CC -xarch=amd64 or -xarch=v9 you don't get _LP64 defined. The "register_" files are so simple that they don't do the prerequisite includes. In my case I was lucky in that the lack of the define caused a compile error. We might not always be so lucky since we don't really control _LP64. This has me thinking that hotspot should really not be using _LP64 at all. I'm kind of queasy about the build process defining it since it would seem to be the prerogative of the compiler/standard include files (though the adlc build does). I was wondering if maybe we should use a hotspot specific define like VM64 or some such. As far as _LP64 in the vm I think we don't reall care about "L64" but really only "P64" since we should be using intptr_t's to hold pointers as integers. Though I wouldn't be surprised if we had latent bugs in the regard. The use of something like VM64 might be trickier yet with a compressed oop jvm, I don't know. Another issue is the AMD64 define and possibly the IA32 define. There are a few places that do "defined(IA32) || defined(AMD64)" that would really seem to mean "defined(X86)" and that there are rare cases where AMD64 would really mean "defined(X86) && defined(VM64)" instead of just "defined(VM64)". -- Steve From patrick.mcnally at pomona.edu Thu Jun 21 11:27:45 2007 From: patrick.mcnally at pomona.edu (Patrick McNally) Date: Thu, 21 Jun 2007 11:27:45 -0700 Subject: extending the constant pool Message-ID: <30BF6ED5-733F-4282-BD11-C1E20068D707@pomona.edu> Hello! I'm playing with the class file parser at the moment and I could use some help. Specifically, I am trying to use annotations to modify bytecode and the constant pool. Byte code turns out to be pretty easy, since it and the annotations are parsed at basically the same point. But the constant pool has already been parsed and finalized by the time the class file parser gets around to parsing my annotations. So what I've been doing is creating a new constant pool with the extra number of entries, adding what I want to this new pool and then reassigning the original constant pool's handle to point to my new one. This works fine for a few lines after parse_methods returns, but then all of a sudden my new constant pool seems to get garbage collected as any reference I try to make to it returns garbage. I'm pretty fuzzy about the hotspot garbage collector, so any suggestions about how to get a new constant pool to stick around would be much appreciated. I've basically just reused the new constant pool instantiation code from the parse_constantpool method. ------------------------------------------------------------- This message has been scanned by Postini anti-virus software. From patrick.mcnally at pomona.edu Thu Jun 21 11:30:39 2007 From: patrick.mcnally at pomona.edu (Patrick McNally) Date: Thu, 21 Jun 2007 11:30:39 -0700 Subject: extending the constant pool continued Message-ID: <08FCFE32-B41D-4E8F-9121-0D3FE697E5CC@pomona.edu> Hello! (and sorry about the previous premature message) I'm playing with the class file parser at the moment and I could use some help. Specifically, I am trying to use annotations to modify bytecode and the constant pool. Byte code turns out to be pretty easy, since it and the annotations are parsed at basically the same point. But the constant pool has already been parsed and finalized by the time the class file parser gets around to parsing my annotations. So what I've been doing is creating a new constant pool with the extra number of entries, adding what I want to this new pool and then reassigning the original constant pool's handle to point to my new one. This works fine for a few lines after parse_methods returns, but then all of a sudden my new constant pool seems to get garbage collected as any reference I try to make to it returns garbage. I'm pretty fuzzy about the hotspot garbage collector, so any suggestions about how to get a new constant pool to stick around would be much appreciated. I've basically just reused the new constant pool instantiation code from the parse_constantpool method. Any help would be much appreciated! Thanks! Patrick ------------------------------------------------------------- This message has been scanned by Postini anti-virus software. From Tim.Bell at Sun.COM Thu Jun 21 11:40:47 2007 From: Tim.Bell at Sun.COM (Tim Bell) Date: Thu, 21 Jun 2007 11:40:47 -0700 Subject: extending the constant pool continued In-Reply-To: <08FCFE32-B41D-4E8F-9121-0D3FE697E5CC@pomona.edu> References: <08FCFE32-B41D-4E8F-9121-0D3FE697E5CC@pomona.edu> Message-ID: <467AC62F.30607@sun.com> Hi Patrick: > modify bytecode and the constant pool. That sounds vaguely similar to what Java Virtual Machine Tool Interface (JVM TI) calls Retransform or Redefine Class: http://java.sun.com/javase/6/docs/platform/jvmti/jvmti.html#RetransformClasses http://java.sun.com/javase/6/docs/platform/jvmti/jvmti.html#RedefineClasses There is code in JVM TI to change method bodies, the constant pool and attributes. Have you looked at that? HTH - Tim From Thomas.Rodriguez at Sun.COM Thu Jun 21 12:49:33 2007 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 21 Jun 2007 12:49:33 -0700 Subject: extending the constant pool continued In-Reply-To: <08FCFE32-B41D-4E8F-9121-0D3FE697E5CC@pomona.edu> References: <08FCFE32-B41D-4E8F-9121-0D3FE697E5CC@pomona.edu> Message-ID: <467AD64D.7050103@sun.com> Patrick McNally wrote: > So what I've > been doing is creating a new constant pool with the extra number of > entries, adding what I want to this new pool and then reassigning the > original constant pool's handle to point to my new one. What do you mean by this? Handles aren't like reference parameters where you can assign to them and have every piece of code which referred the old handle refer to the new one. You have to make sure that the code is structured so that every user picks up the new one either by returning the new one or reloading it from the class. Also there are cross links between the class and the constant pool and you'll need to update those. It's a little hard to tell you what you're doing wrong without the actual code too. As Tim pointed out there are ways using JVMTI and java.lang.instrument.Instrumentation to do bytecode rewriting without modifying the JVM which might be easier and more appropriate. tom From Peter.Kessler at Sun.COM Thu Jun 21 14:58:29 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Thu, 21 Jun 2007 14:58:29 -0700 Subject: extending the constant pool In-Reply-To: <30BF6ED5-733F-4282-BD11-C1E20068D707@pomona.edu> References: <30BF6ED5-733F-4282-BD11-C1E20068D707@pomona.edu> Message-ID: <467AF485.4080407@Sun.COM> Patrick McNally wrote: > Hello! > > I'm playing with the class file parser at the moment and I could use > some help. Specifically, I am trying to use annotations to modify > bytecode and the constant pool. Byte code turns out to be pretty easy, > since it and the annotations are parsed at basically the same point. But > the constant pool has already been parsed and finalized by the time the > class file parser gets around to parsing my annotations. So what I've > been doing is creating a new constant pool with the extra number of > entries, adding what I want to this new pool and then reassigning the > original constant pool's handle to point to my new one. This works fine > for a few lines after parse_methods returns, but then all of a sudden my > new constant pool seems to get garbage collected as any reference I try > to make to it returns garbage. I'm pretty fuzzy about the hotspot > garbage collector, so any suggestions about how to get a new constant > pool to stick around would be much appreciated. I've basically just > reused the new constant pool instantiation code from the > parse_constantpool method. I can't say if what you are doing is right way to extend a constant pool, but I'll try to address the garbage collector issue you seem to be having. If you have a constantPoolHandle, then the collector will know that your constantPool is live and everything should be fine. If the collector needs to relocate your constantPool it will, and will adjust the constantPoolHandle accordingly. If you only have a constantPoolOop, or if you "unwrap" the constantPoolHandle and get a constantPoolOop, then you cannot safely hold that oop across a garbage collection, because the collector will not know to adjust the constantPoolOop if the constantPool gets moved. Or the collector may decide that the constantPool is unreferenced and recycle the space for it. Things go downhill after that. ... peter From jackieict at gmail.com Thu Jun 21 18:32:25 2007 From: jackieict at gmail.com (zhang Jackie) Date: Fri, 22 Jun 2007 09:32:25 +0800 Subject: how to get sun implementation classes such as sun.nio.* and sun.rmi.*, etc ? Message-ID: <13432ab00706211832q2a2ca070h19a1d35e9ac4cf28@mail.gmail.com> hi, Do someone know how to get sun implementation classes such as sun.nio.* and sun.rmi.*,etc ? I cant find them in hotspot source code and src.zip of jdk. who produced these classes? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070622/769c3b79/attachment.html From mr at sun.com Thu Jun 21 19:45:05 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 21 Jun 2007 19:45:05 -0700 Subject: how to get sun implementation classes such as sun.nio.* and sun.rmi.*, etc ? In-Reply-To: jackieict@gmail.com; Fri, 22 Jun 2007 09:32:25 +0800; <13432ab00706211832q2a2ca070h19a1d35e9ac4cf28@mail.gmail.com> Message-ID: <20070622024505.1C4DC6482@callebaut.niobe.net> > Date: Fri, 22 Jun 2007 09:32:25 +0800 > From: zhang Jackie > Do someone know how to get sun implementation classes such as sun.nio.* and > sun.rmi.*,etc ? I cant find them in hotspot source code and src.zip of jdk. > who produced these classes? These are not part of HotSpot, nor are they in the src.zip file shipped in the JDK binary distribution. You'll find them in the "j2se" subdirectory of the full sources. The sun.nio package, e.g., is in j2se/src/share/classes/sun/nio, or just go here: https://openjdk.dev.java.net/source/browse/openjdk/jdk/trunk/j2se/src/share/classes/sun/nio/ - Mark From jackieict at gmail.com Fri Jun 22 01:22:36 2007 From: jackieict at gmail.com (zhang Jackie) Date: Fri, 22 Jun 2007 16:22:36 +0800 Subject: about socket reuse in RMI Message-ID: <13432ab00706220122ue390e86o3691d004fa1e15ef@mail.gmail.com> hi socket reuse in RMI confused me much for several reasons: In my opionion, one socket is boud some information about server and port(right?), how such socket can be reused to communicate to another server,just change the IP address and port number? Is it possible to do so in user space of linux? ServerSocket is used to accept new connection, one ServerSocket instance can fit the need of application, why reuse is needed. What the socket reuse of RMI means? Some one give me such a comment: *RMI will reuse sockets if the socket was created by the same socket factory. So, if two remote object's socket factories that are .equal() then RMI will reuse a client's socket to talk with each RMI object. It will also reuse that socket for multiple calls to those remote objects.* So this is not socket factory reuse ,rather than socket reuse. I was confused greatly, Do everyone can give me a clear explanation about this topic? thanks for any reply! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070622/eab04ffb/attachment.html From Peter.Kessler at Sun.COM Fri Jun 22 11:43:47 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Fri, 22 Jun 2007 11:43:47 -0700 Subject: about socket reuse in RMI In-Reply-To: <13432ab00706220122ue390e86o3691d004fa1e15ef@mail.gmail.com> References: <13432ab00706220122ue390e86o3691d004fa1e15ef@mail.gmail.com> Message-ID: <467C1863.5050901@Sun.COM> hotspot-dev at openjdk.java.net is for discussions about the HotSpot virtual machine under the Java platform libraries. Your question seems to be about the RMI libraries, not the virtual machine itself. I would suggest asking on the core-libs-dev at openjdk.java.net mailing list (cc'd) whose home page http://openjdk.java.net/groups/core-libs/ says they cover the java.rmi package. ... peter zhang Jackie wrote: > hi > socket reuse in RMI confused me much for several reasons: > > In my opionion, one socket is boud some information about server and > port(right?), how such socket can be reused to communicate to another > server,just change the IP address and port number? Is it possible to do > so in user space of linux? ServerSocket is used to accept new > connection, one ServerSocket instance can fit the need of application, > why reuse is needed. What the socket reuse of RMI means? > > Some one give me such a comment: > *RMI will reuse sockets if the socket was created by the same socket > factory. So, if two remote object's socket factories that are .equal() > then RMI will reuse a client's socket to talk with each RMI object. It > will also reuse that socket for multiple calls to those remote objects. * > > So this is not socket factory reuse ,rather than socket reuse. > > I was confused greatly, Do everyone can give me a clear explanation > about this topic? > > thanks for any reply! From James.Dougherty at Micronas.com Fri Jun 22 10:29:24 2007 From: James.Dougherty at Micronas.com (Dougherty James) Date: Fri, 22 Jun 2007 10:29:24 -0700 Subject: mipsel-linux port Message-ID: Hi Folks, I've started porting the Hotspot and OpenJDK for MIPS32 architecture, have created the Makefiles And build infrastructure, and now I'm at the point Where the .ad files need to be made for MIPS32 (4KeC). Has anyone worked on a MIPS port? If not, how can I develop The .ad files to port to my target architecture? Thank you very much! -James From betelgeuse at gentoo.org Fri Jun 22 12:12:44 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Fri, 22 Jun 2007 22:12:44 +0300 Subject: b14 fails to link launcher and as such fails to build Message-ID: <467C1F2C.60801@gentoo.org> Linking vm... /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. { \ echo Linking launcher...; \ \ gcc -m32 -march=i586 -Xlinker -O1 -m32 -march=i586 -export-dynamic -L `pwd` -o gamma launcher.o -ljvm -lm -ldl -lpthread; \ \ } Linking launcher... /home/betelgeuse/btdown/openjdk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/libjvm.so: undefined reference to `ParScanClosure::do_oop_work(oopDesc**, bool, bool)' collect2: ld returned 1 exit status My gcc version is: betelgeuse at pena ~/btdown/openjdk/control/make $ gcc --version gcc (GCC) 4.1.2 (Gentoo 4.1.2) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It doesn't make a difference whether I use the huge patch pile we have or not. Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070622/63a9971e/attachment.bin From Steve.Goldman at Sun.COM Fri Jun 22 12:20:17 2007 From: Steve.Goldman at Sun.COM (steve goldman) Date: Fri, 22 Jun 2007 15:20:17 -0400 Subject: mipsel-linux port In-Reply-To: References: Message-ID: <467C20F1.6000303@sun.com> Dougherty James wrote: > Hi Folks, > > I've started porting the Hotspot and OpenJDK for > MIPS32 architecture, have created the Makefiles > And build infrastructure, and now I'm at the point > Where the .ad files need to be made for MIPS32 (4KeC). Really? You have the assembler and the interpreter (and stubs) done? If not I suggest you build the compiler-less version of the jvm first (formerly know as the core build). The target for those builds are jvmgcore, fastdebugcore, or productcore. > > Has anyone worked on a MIPS port? If not, how can I develop > The .ad files to port to my target architecture? Not much docmentation on the .ad files. Best thing is to look at the .ad files from the existing architectures and pick the one closest to your architecture and start hacking. -- Steve From Peter.Kessler at Sun.COM Fri Jun 22 12:26:40 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Fri, 22 Jun 2007 12:26:40 -0700 Subject: b14 fails to link launcher and as such fails to build In-Reply-To: <467C1F2C.60801@gentoo.org> References: <467C1F2C.60801@gentoo.org> Message-ID: <467C2270.7010506@Sun.COM> Can you tell where the reference to ParScanClosure::do_oop_work is coming from? That method is declared in hotspot/share/vm/memory/genOopClosures.hpp (hmm, but it's not declared "inline"), and is then defined inline in hotspot/share/vm/memory/genOopClosures.inline.hpp Maybe we are missing an entry in the includeDB's to tell someone that they depend on genOopClosures.inline.hpp? ... peter Petteri R?ty wrote: > Linking vm... > /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/ld: > warning: creating a DT_TEXTREL in object. > { \ > echo Linking launcher...; \ > \ > gcc -m32 -march=i586 -Xlinker -O1 -m32 -march=i586 > -export-dynamic -L `pwd` -o gamma launcher.o -ljvm -lm -ldl -lpthread; \ > \ > } > Linking launcher... > /home/betelgeuse/btdown/openjdk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/libjvm.so: > undefined reference to `ParScanClosure::do_oop_work(oopDesc**, bool, bool)' > collect2: ld returned 1 exit status > > My gcc version is: > betelgeuse at pena ~/btdown/openjdk/control/make $ gcc --version > gcc (GCC) 4.1.2 (Gentoo 4.1.2) > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > It doesn't make a difference whether I use the huge patch pile we have > or not. > > Regards, > Petteri From Nikolay.Igotti at Sun.COM Fri Jun 22 12:31:38 2007 From: Nikolay.Igotti at Sun.COM (Nikolay Igotti) Date: Fri, 22 Jun 2007 23:31:38 +0400 Subject: b14 fails to link launcher and as such fails to build In-Reply-To: <467C2270.7010506@Sun.COM> References: <467C1F2C.60801@gentoo.org> <467C2270.7010506@Sun.COM> Message-ID: <467C239A.8060404@sun.com> I already fixed and integrated this bug: 6567018: Hotspot build fails with gcc4 so you should see it in the next push. Nikolay. Peter B. Kessler wrote: > Can you tell where the reference to ParScanClosure::do_oop_work is > coming from? That method is declared in > > hotspot/share/vm/memory/genOopClosures.hpp > > (hmm, but it's not declared "inline"), and is then defined inline > in > > hotspot/share/vm/memory/genOopClosures.inline.hpp > > Maybe we are missing an entry in the includeDB's to tell someone > that they depend on genOopClosures.inline.hpp? > > ... peter > > Petteri R?ty wrote: > >> Linking vm... >> /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/ld: >> >> warning: creating a DT_TEXTREL in object. >> { \ >> echo Linking launcher...; \ >> \ >> gcc -m32 -march=i586 -Xlinker -O1 -m32 -march=i586 >> -export-dynamic -L `pwd` -o gamma launcher.o -ljvm -lm -ldl >> -lpthread; \ >> \ >> } >> Linking launcher... >> /home/betelgeuse/btdown/openjdk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/libjvm.so: >> >> undefined reference to `ParScanClosure::do_oop_work(oopDesc**, bool, >> bool)' >> collect2: ld returned 1 exit status >> >> My gcc version is: >> betelgeuse at pena ~/btdown/openjdk/control/make $ gcc --version >> gcc (GCC) 4.1.2 (Gentoo 4.1.2) >> Copyright (C) 2006 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There >> is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> >> It doesn't make a difference whether I use the huge patch pile we have >> or not. >> >> Regards, >> Petteri > From springer at reservoir.com Fri Jun 22 14:13:00 2007 From: springer at reservoir.com (Jonathan Springer) Date: Fri, 22 Jun 2007 16:13:00 -0500 Subject: mipsel-linux port In-Reply-To: <467C20F1.6000303@sun.com> References: <467C20F1.6000303@sun.com> Message-ID: <467C3B5C.6010106@reservoir.com> Hi James and chenjie, Reservoir Labs is currently working on an OpenJDK MIPS port. We started with the assembler, stubs, and interpreter, as Steve mentions. We plan to do the compiler after that. We are targeting MIPS64, though the MIPS32 holes are ifdefed in the right places (and we use things like ld_long where appropriate). Hopefully it can be integrated into the Sun distribution at some point. We plan to maintain the port. Jonathan -- Jonathan Springer | Reservoir Labs, Inc. | http://www.reservoir.com/ From springer at reservoir.com Fri Jun 22 14:43:54 2007 From: springer at reservoir.com (Jonathan Springer) Date: Fri, 22 Jun 2007 16:43:54 -0500 Subject: mipsel-linux port In-Reply-To: References: Message-ID: <467C429A.6070404@reservoir.com> It's not working yet. We don't even have "hello world" -- though this requires quite a bit of correctness already. We're getting there, and it shouldn't be much longer. Also, I'm not sure about how to do collaboration prior to it being merged into the mainline. There might be IP issues (from our side, not Sun's). I will try to get that figured out. But I thought people would be interested in a heads up. Dougherty James wrote: > Thanks Jonathan, > > How could we get access to the port? Definitely would like > To try it out with our Hardware :-) > > Thanks! > -james > > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net > [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Jonathan > Springer > Sent: Friday, June 22, 2007 2:13 PM > To: hotspot-dev at openjdk.java.net > Subject: Re: mipsel-linux port > > Hi James and chenjie, > > Reservoir Labs is currently working on an OpenJDK MIPS port. We started > with the > assembler, stubs, and interpreter, as Steve mentions. We plan to do the > compiler after > that. We are targeting MIPS64, though the MIPS32 holes are ifdefed in > the right places > (and we use things like ld_long where appropriate). > > Hopefully it can be integrated into the Sun distribution at some point. > We plan to > maintain the port. > > Jonathan -- Jonathan Springer | Reservoir Labs, Inc. | http://www.reservoir.com/ From James.Dougherty at Micronas.com Fri Jun 22 14:19:35 2007 From: James.Dougherty at Micronas.com (Dougherty James) Date: Fri, 22 Jun 2007 14:19:35 -0700 Subject: mipsel-linux port In-Reply-To: <467C3B5C.6010106@reservoir.com> Message-ID: Thanks Jonathan, How could we get access to the port? Definitely would like To try it out with our Hardware :-) Thanks! -james -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Springer Sent: Friday, June 22, 2007 2:13 PM To: hotspot-dev at openjdk.java.net Subject: Re: mipsel-linux port Hi James and chenjie, Reservoir Labs is currently working on an OpenJDK MIPS port. We started with the assembler, stubs, and interpreter, as Steve mentions. We plan to do the compiler after that. We are targeting MIPS64, though the MIPS32 holes are ifdefed in the right places (and we use things like ld_long where appropriate). Hopefully it can be integrated into the Sun distribution at some point. We plan to maintain the port. Jonathan -- Jonathan Springer | Reservoir Labs, Inc. | http://www.reservoir.com/ From betelgeuse at gentoo.org Fri Jun 22 14:55:34 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Sat, 23 Jun 2007 00:55:34 +0300 Subject: b14 fails to link launcher and as such fails to build In-Reply-To: <467C239A.8060404@sun.com> References: <467C1F2C.60801@gentoo.org> <467C2270.7010506@Sun.COM> <467C239A.8060404@sun.com> Message-ID: <467C4556.8020806@gentoo.org> Nikolay Igotti kirjoitti: > I already fixed and integrated this bug: 6567018: Hotspot build fails > with gcc4 > so you should see it in the next push. > > Nikolay. > Testing the patch from the bug report. Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070623/478a4630/attachment.bin From twisti at complang.tuwien.ac.at Sat Jun 23 07:22:20 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Sat, 23 Jun 2007 16:22:20 +0200 Subject: mipsel-linux port In-Reply-To: References: Message-ID: <1182608540.3414.7.camel@localhost.localdomain> On Fri, 2007-06-22 at 10:29 -0700, Dougherty James wrote: > Hi Folks, > > I've started porting the Hotspot and OpenJDK for > MIPS32 architecture, have created the Makefiles > And build infrastructure, and now I'm at the point > Where the .ad files need to be made for MIPS32 (4KeC). > > Has anyone worked on a MIPS port? If not, how can I develop > The .ad files to port to my target architecture? Hi! This is not actually what you want but it might help a lot in porting the whole stuff. Yesterday I've commited the stuff that is required to let CACAO[1] use the OpenJDK libraries as Java core libraries. I've only tried it with PowerPC yet[2], but it should work on MIPS too (when the j2se stuff builds). As I said, it's not HotSpot running on MIPS, but you can see if j2se builds and runs ok, which might help a lot to find bugs. I'm collecting the bits required to build j2se here[3], but it's not finished yet. [1] http://www.cacaojvm.org/ [2] http://www.advogato.org/person/twisti/diary.html?start=2 [3] https://c1.complang.tuwien.ac.at/cacaowiki/OpenJDK - twisti From twisti at complang.tuwien.ac.at Sun Jun 24 05:01:48 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Sun, 24 Jun 2007 14:01:48 +0200 Subject: R: Porting on mipsel/debian In-Reply-To: <20070529081151.E51C84346@netra.tizianodinca.com> References: <20070529081151.E51C84346@netra.tizianodinca.com> Message-ID: <1182686508.3370.0.camel@localhost.localdomain> On Tue, 2007-05-29 at 10:11 +0200, Luigi De Don? wrote: > >Actually, I _think_ MIPSEL refers to little-endianess MIPS. > Yes, I mean that ! > > >I'm personally not aware of a Hotspot port to MIPS within Sun. But, the > source is out there so, if you're > >feeling brave, give it a go! :-) > I think about GNU Classpath/GCJ, it runs on MIPS... My question is if it > possible to use the OpenJDK's runtime libraries with gcj until someone will > release a OpenJDK complete HotSpot for MIPS... It is that a difficult > effort? Hi Luigi! Maybe this is interesting for you: http://mail.openjdk.java.net/pipermail/hotspot-dev/2007-June/000081.html - twisti From springer at reservoir.com Mon Jun 25 07:39:42 2007 From: springer at reservoir.com (Jonathan Springer) Date: Mon, 25 Jun 2007 09:39:42 -0500 Subject: mipsel-linux port In-Reply-To: <1182608540.3414.7.camel@localhost.localdomain> References: <1182608540.3414.7.camel@localhost.localdomain> Message-ID: <467FD3AE.3050309@reservoir.com> Christian Thalinger wrote: > On Fri, 2007-06-22 at 10:29 -0700, Dougherty James wrote: > >>Hi Folks, >> >>I've started porting the Hotspot and OpenJDK for >>MIPS32 architecture, have created the Makefiles >>And build infrastructure, and now I'm at the point >>Where the .ad files need to be made for MIPS32 (4KeC). >> >>Has anyone worked on a MIPS port? If not, how can I develop >>The .ad files to port to my target architecture? > > Hi! > > This is not actually what you want but it might help a lot in porting > the whole stuff. Yesterday I've commited the stuff that is required to > let CACAO[1] use the OpenJDK libraries as Java core libraries. I've > only tried it with PowerPC yet[2], but it should work on MIPS too (when > the j2se stuff builds). > > As I said, it's not HotSpot running on MIPS, but you can see if j2se > builds and runs ok, which might help a lot to find bugs. > > I'm collecting the bits required to build j2se here[3], but it's not > finished yet. > > [1] http://www.cacaojvm.org/ > [2] http://www.advogato.org/person/twisti/diary.html?start=2 > [3] https://c1.complang.tuwien.ac.at/cacaowiki/OpenJDK I'd be interested if anyone has tried it using a technique like this. But I'm expecting that the only real problems will be the three object code binary plug files that have been mentioned on this list previously: -- libt2k (font rendering) -- libdcpr (some low-level graphics2D code) -- libjsound If someone has addressed these, that would be the most useful. -- Jonathan Springer | Reservoir Labs, Inc. | http://www.reservoir.com/