Fwd: [jira] Created: (HARMONY-6) Contribution of JVM Source Code
Something is fubar w/ JIRA and this didn't seem to make it to the list. Daniel is a man I've been badgering, cajoling, pleading, begging, harrassing, bothering, hounding, nagging, wheedling and coaxing for a while with this, and I'm really happy he got it far enough so that he's comfortable sharing it with us. I'm excited to work further with Dan, and how we can compare and contrast this with Archie's code too. geir Begin forwarded message: From: "Daniel Lydick (JIRA)" <[EMAIL PROTECTED]> Date: September 30, 2005 8:06:51 PM EDT To: [EMAIL PROTECTED] Subject: [jira] Created: (HARMONY-6) Contribution of JVM Source Code Contribution of JVM Source Code --- Key: HARMONY-6 URL: http://issues.apache.org/jira/browse/HARMONY-6 Project: Harmony Type: New Feature Components: Misc Reporter: Daniel Lydick Assigned to: Geir Magnusson Jr Dear friends at ASF, Here is a contribution to the Harmony project of a basic Java Virtual Machine entitled the "Apache Harmony Bootstrap JVM." It is my hope that this implementation of a JVM will spur significant discussions to "bootstrap" the core architectural component designs for the Harmony JVM component(s), whether or not this particular code is used in any of them. I also hope it will provide a substantial learning experience for those who are not acquainted with the way a JVM does or could work. Finally, I hope that this program might serve as a "bootstrap" and for a runtime framework from which to start up what becomes the program code of one or more JVM's that the Harmony project ultimately produces. That is, if it has any functions that would help that process along, I would hope that at least part of the code might be usable in the final result(s). If any of these goals are met, then my purpose is accomplished. In any event, here 'tis. Enjoy. Dan Lydick September 30, 2005 --- Please see the file 'harmony/bootJVM/README' to learn what is contained in this program, including the design goals and rationale for its implementation. Two distribution files are included. The first contains the entire documentation suite in ready-to-read form. The second is the source distribution that also contains this same documentation, but which is _not_ readily accessible until after configuration. Both are provided as .tar.gz files. To read the documentation in either Unix man, TeX, or as HTML, follow portions of this procedure. A 'harmony/bootJVM-0.0.0' directory will be created: $ cat bootJVM-doc-0.0.0.tar.gz | gunzip | tar xf - man: $ setenv MANPATH=`pwd`/harmony/bootJVM-0.0.0/doc.ORIG/man $ man -s 3 jvm.c $ man -s 3 README $ man -s 3 INSTALL TeX: $ info `pwd`/harmony/bootJVM-0.0.0/doc.ORIG/latex/index.tex HTML: $ # Web browser entry: `pwd`/harmony/bootJVM-0.0.0/doc.ORIG/ html/index.html The documentation is also found in XML and RTF format in the 'doc.ORIG' directory. To unpack the source distribution, follow this procedure. A 'harmony-bootJVM' directory will be created: $ cat bootJVM-src-0.0.0.tar.gz | gunzip | tar xf - $ cd harmony/bootJVM $ more INSTALL Follow the installation procedure from there. EOF -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] Accept JIRA contribution HARMONY-3 : Archie Cobbs' Contribution of JCVM
+1 code. Geir Magnusson Jr. wrote: +1 from me I was concerned about the provenance given some of the statement found in the contribution, but Archie's explanation and statement of it being his original work based on exposure to only open-source implementations is fine for me. This is going into the sandbox - if we happen to discover an issue about this in the near future, we can simply fix it. On Sep 30, 2005, at 5:18 PM, Geir Magnusson Jr. wrote: Archie Cobbs has offered the JCVM project under the Apache License to Apache Harmony. It can be found here : http://issues.apache.org/jira/browse/HARMONY-3 [ ] +1 Accept the code into the project sandbox [ ] -1 Don't accept the code. Reason : This vote will close 72 hours from now. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed.
Re: [vote] Accept JIRA contribution HARMONY-3 : Archie Cobbs' Contribution of JCVM
+1 from me I was concerned about the provenance given some of the statement found in the contribution, but Archie's explanation and statement of it being his original work based on exposure to only open-source implementations is fine for me. This is going into the sandbox - if we happen to discover an issue about this in the near future, we can simply fix it. On Sep 30, 2005, at 5:18 PM, Geir Magnusson Jr. wrote: Archie Cobbs has offered the JCVM project under the Apache License to Apache Harmony. It can be found here : http://issues.apache.org/jira/browse/HARMONY-3 [ ] +1 Accept the code into the project sandbox [ ] -1 Don't accept the code. Reason : This vote will close 72 hours from now. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
RE: [vote] Accept JIRA contribution HARMONY-3 : Archie Cobbs' Contribution of JCVM
+1 (non-binding) Dan Lydick > [Original Message] > From: Geir Magnusson Jr. <[EMAIL PROTECTED]> > To: > Date: 9/30/05 4:18:14 PM > Subject: [vote] Accept JIRA contribution HARMONY-3 : Archie Cobbs' Contribution of JCVM > > Archie Cobbs has offered the JCVM project under the Apache License to > Apache Harmony. It can be found here : > > http://issues.apache.org/jira/browse/HARMONY-3 > > [ ] +1 Accept the code into the project sandbox > [ ] -1 Don't accept the code. Reason : > > This vote will close 72 hours from now. > > geir > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > >
Re: [vote] Accept JIRA contribution HARMONY-3 : Archie Cobbs' Contribution of JCVM
Geir Magnusson Jr. wrote: Archie Cobbs has offered the JCVM project under the Apache License to Apache Harmony. It can be found here : http://issues.apache.org/jira/browse/HARMONY-3 [ ] +1 Accept the code into the project sandbox [ ] -1 Don't accept the code. Reason : This vote will close 72 hours from now. geir +1 Regards John
Re: [vote] Accept JIRA contribution HARMONY-3 : Archie Cobbs' Contribution of JCVM
+1 from me. On 9/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > Archie Cobbs has offered the JCVM project under the Apache License to > Apache Harmony. It can be found here : > > http://issues.apache.org/jira/browse/HARMONY-3 > > [ ] +1 Accept the code into the project sandbox > [ ] -1 Don't accept the code. Reason : > > This vote will close 72 hours from now. > > geir > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > > -- Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
[vote] Accept JIRA contribution HARMONY-3 : Archie Cobbs' Contribution of JCVM
Archie Cobbs has offered the JCVM project under the Apache License to Apache Harmony. It can be found here : http://issues.apache.org/jira/browse/HARMONY-3 [ ] +1 Accept the code into the project sandbox [ ] -1 Don't accept the code. Reason : This vote will close 72 hours from now. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] Accept JIRA contribution HARMONY-5 : David Tanzer's proof-of-concept component model
Guys! It's for the sandbox! No one is going to reject contributions to the sandbox except for reasons of code provenance - i.e. "Hey, that's Sun's source!" - or complete misalignment with project, such as someone donating an EJB container or something. Further down the road, when we are at work on our "complete platform" for J2SE, rejecting the inclusion of code _from_ the sandbox _into_ the main platform is reasonable, and I personally can't wait until we are that far along that we can have those discussions :) geir On Sep 30, 2005, at 8:41 AM, [EMAIL PROTECTED] wrote: Oh gosh, it is way too early to reject things for such reasons. Instead of being a roadblock, contribute patches. That is the affirmative thing to do rather than starting out with the hammer. It is really hard to start a project in the fashion of harmony (w/o initial codebase) because so many initial decisions in any project must favor "the least thing that could possibly work" -- beyond this you take into concern "other things". For instance, I'm quite interested in a VM that sucks less than IBM's for the AIX P5 platform, but I'm not going to "-1 this won't work on AIX". I guarantee no code submitted will be perfect and some won't even be immediately portable especially in the early stages. PEEEAAASE take an affirmative view rather than a "code by committee" negative view. -Andy David Tanzer wrote: On Fri, 2005-09-30 at 02:58 -0400, Geir Magnusson Jr. wrote: On Sep 30, 2005, at 2:51 AM, Mladen Turk wrote: Geir Magnusson Jr. wrote: David Tanzer has offered his proof-of-concept component model to the project. It can be found here : http://issues.apache.org/jira/browse/HARMONY-5 [ ] +1 Accept the code into the project [X] -1 Don't accept the code. Reason : The code itself is posix only. It's a proof of concept for the sandbox! This isn't a commitment to the idea or the implementation, but just getting it in so people can play Right, that's what my intention was, nothing more. If we continue this way, porting to the other platforms will become impossible. Even the simple posix itself is incompatible between various flavors. For example on AIX there is 'archive.a(dso.so)' and dlopen needs 'RTLD_NOW | RTLD_GLOBAL | RTDL_MEMBER' flags. Some platforms like HPUX use the shl_load, not to mention the Windows or Netware. The actual code itself exists, and is very much mature within Apache2, and module dependencies are implemented within apr-iconv project, so perhaps this would be a way to go. APR? I think that we'll leverage APR heavily. Whether or not the APR API is the one we use as the standard porting layer API remains to be seen. If not, I'm certain will used it for platform implementations of the porting layer... There are several places in the code where I've added comments about things that have to be changed if we really use this component model. Note that there are also serious concerns about performance in a runtime-configurable component model and Robin Garner suggested to aim for compile time configurability (See [1]). APR would definitely be a better choice than posix, but AFAICS the decision about what our portability layer will be has not been made yet. Also, what about coding style guide? That's a good question, and something I assume we'll converge around as we get moving. I totally agree with that. I discussed earlier with Weldon Washburn and Geir about using the Java Coding Conventions where possible (See [2] and follow-ups), but this still doesn't cover things like directory structure, some aspects of documentation policy, etc., and there was no decision yet. Regards, David. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 200509.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 200508.mbox/[EMAIL PROTECTED] geir Regards, Mladen. -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] Accept JIRA contribution HARMONY-5 : David Tanzer's proof-of-concept component model
Again we agree. +1 from me. " Instead of being a roadblock, contribute patches" -- dims On 9/30/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Oh gosh, it is way too early to reject things for such reasons. Instead > of being a roadblock, contribute patches. That is the affirmative thing > to do rather than starting out with the hammer. It is really hard to > start a project in the fashion of harmony (w/o initial codebase) because > so many initial decisions in any project must favor "the least thing > that could possibly work" -- beyond this you take into concern "other > things". > > For instance, I'm quite interested in a VM that sucks less than IBM's > for the AIX P5 platform, but I'm not going to "-1 this won't work on > AIX". I guarantee no code submitted will be perfect and some won't even > be immediately portable especially in the early stages. PEEEAAASE > take an affirmative view rather than a "code by committee" negative view. > > -Andy > > David Tanzer wrote: > > On Fri, 2005-09-30 at 02:58 -0400, Geir Magnusson Jr. wrote: > > > >>On Sep 30, 2005, at 2:51 AM, Mladen Turk wrote: > >> > >> > >>>Geir Magnusson Jr. wrote: > >>> > >>> > David Tanzer has offered his proof-of-concept component model to > the project. It can be found here : > http://issues.apache.org/jira/browse/HARMONY-5 > [ ] +1 Accept the code into the project > [X] -1 Don't accept the code. Reason : > > >>> > >>>The code itself is posix only. > >> > >>It's a proof of concept for the sandbox! This isn't a commitment to > >>the idea or the implementation, but just getting it in so people can > >>play > > > > > > Right, that's what my intention was, nothing more. > > > > > >>>If we continue this way, porting to the other platforms will > >>>become impossible. > >>>Even the simple posix itself is incompatible between various > >>>flavors. For example on AIX there is 'archive.a(dso.so)' and > >>>dlopen needs 'RTLD_NOW | RTLD_GLOBAL | RTDL_MEMBER' flags. > >>>Some platforms like HPUX use the shl_load, not to mention the > >>>Windows or Netware. > >>> > >>>The actual code itself exists, and is very much mature within > >>>Apache2, and module dependencies are implemented within apr-iconv > >>>project, so perhaps this would be a way to go. > >>> > >> > >>APR? I think that we'll leverage APR heavily. Whether or not the > >>APR API is the one we use as the standard porting layer API remains > >>to be seen. If not, I'm certain will used it for platform > >>implementations of the porting layer... > > > > > > There are several places in the code where I've added comments about > > things that have to be changed if we really use this component model. > > Note that there are also serious concerns about performance in a > > runtime-configurable component model and Robin Garner suggested to aim > > for compile time configurability (See [1]). APR would definitely be a > > better choice than posix, but AFAICS the decision about what our > > portability layer will be has not been made yet. > > > > > >>>Also, what about coding style guide? > >> > >>That's a good question, and something I assume we'll converge around > >>as we get moving. > > > > > > I totally agree with that. I discussed earlier with Weldon Washburn > > and Geir about using the Java Coding Conventions where possible (See > > [2] and follow-ups), but this still doesn't cover things like directory > > structure, some aspects of documentation policy, etc., and there was no > > decision yet. > > > > Regards, > > David. > > > > [1] > > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL > > PROTECTED] > > [2] > > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL > > PROTECTED] > > > > > >>geir > >> > >> > >>>Regards, > >>>Mladen. > >>> > >>> > >> > > > -- > Andrew C. Oliver > SuperLink Software, Inc. > > Java to Excel using POI > http://www.superlinksoftware.com/services/poi > Commercial support including features added/implemented, bugs fixed. > > -- Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
Re: [vote] Accept JIRA contribution HARMONY-5 : David Tanzer's proof-of-concept component model
Oh gosh, it is way too early to reject things for such reasons. Instead of being a roadblock, contribute patches. That is the affirmative thing to do rather than starting out with the hammer. It is really hard to start a project in the fashion of harmony (w/o initial codebase) because so many initial decisions in any project must favor "the least thing that could possibly work" -- beyond this you take into concern "other things". For instance, I'm quite interested in a VM that sucks less than IBM's for the AIX P5 platform, but I'm not going to "-1 this won't work on AIX". I guarantee no code submitted will be perfect and some won't even be immediately portable especially in the early stages. PEEEAAASE take an affirmative view rather than a "code by committee" negative view. -Andy David Tanzer wrote: On Fri, 2005-09-30 at 02:58 -0400, Geir Magnusson Jr. wrote: On Sep 30, 2005, at 2:51 AM, Mladen Turk wrote: Geir Magnusson Jr. wrote: David Tanzer has offered his proof-of-concept component model to the project. It can be found here : http://issues.apache.org/jira/browse/HARMONY-5 [ ] +1 Accept the code into the project [X] -1 Don't accept the code. Reason : The code itself is posix only. It's a proof of concept for the sandbox! This isn't a commitment to the idea or the implementation, but just getting it in so people can play Right, that's what my intention was, nothing more. If we continue this way, porting to the other platforms will become impossible. Even the simple posix itself is incompatible between various flavors. For example on AIX there is 'archive.a(dso.so)' and dlopen needs 'RTLD_NOW | RTLD_GLOBAL | RTDL_MEMBER' flags. Some platforms like HPUX use the shl_load, not to mention the Windows or Netware. The actual code itself exists, and is very much mature within Apache2, and module dependencies are implemented within apr-iconv project, so perhaps this would be a way to go. APR? I think that we'll leverage APR heavily. Whether or not the APR API is the one we use as the standard porting layer API remains to be seen. If not, I'm certain will used it for platform implementations of the porting layer... There are several places in the code where I've added comments about things that have to be changed if we really use this component model. Note that there are also serious concerns about performance in a runtime-configurable component model and Robin Garner suggested to aim for compile time configurability (See [1]). APR would definitely be a better choice than posix, but AFAICS the decision about what our portability layer will be has not been made yet. Also, what about coding style guide? That's a good question, and something I assume we'll converge around as we get moving. I totally agree with that. I discussed earlier with Weldon Washburn and Geir about using the Java Coding Conventions where possible (See [2] and follow-ups), but this still doesn't cover things like directory structure, some aspects of documentation policy, etc., and there was no decision yet. Regards, David. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] geir Regards, Mladen. -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed.
Re: JCVM contribution
[EMAIL PROTECTED] wrote: > Does not appear so. I dinked around and tried to see if its actually > that big of a deal to port gcc since there is a powerpc arch...but for > some reason it hangs when trying to check for as. Cool stuff... Now I > remember the best thing about Javaant. gcc is the system compiler on OS X. :) there are glibc ports for powerpc-linux and to *BSD (see debian/K*BSD projects). I guess a clever combination of things from one place with things from another (Darwin is mildly FreeBSD based, it's largely based on lots of clever use of spit and glue;) would get you a long way ahead. cheers, dalibor topic
Re: JCVM contribution
[EMAIL PROTECTED] wrote: > Doh! Apparently there is no port of glibc for OS X! > > Can this be true? > > Andrew-Olivers-Computer:~/downloads/glibc/build acoliver$ > ../glibc-2.3.5/configure > checking build system type... powerpc-apple-darwin8.2.0 > checking host system type... powerpc-apple-darwin8.2.0 > *** The GNU C library is currently not available for this platform. > *** So far nobody cared to port it and if there is no volunteer it > *** might never happen. So, if you have interest to see glibc on > *** this platform visit > *** http://www.gnu.org/software/libc/porting.html > *** and join the group of porters > OK. File a bug in the JIRA, and someone will see to it. :) There was someone attempting a port at http://www.cygwin.com/ml/bug-glibc/2001-09/msg00053.html and afaict there is a sf.net project of the kind. cheers, dalibor topic
Re: [vote] Accept JIRA contribution HARMONY-5 : David Tanzer's proof-of-concept component model
On Fri, 2005-09-30 at 02:58 -0400, Geir Magnusson Jr. wrote: > On Sep 30, 2005, at 2:51 AM, Mladen Turk wrote: > > > Geir Magnusson Jr. wrote: > > > >> David Tanzer has offered his proof-of-concept component model to > >> the project. It can be found here : > >> http://issues.apache.org/jira/browse/HARMONY-5 > >> [ ] +1 Accept the code into the project > >> [X] -1 Don't accept the code. Reason : > >> > > > > The code itself is posix only. > > It's a proof of concept for the sandbox! This isn't a commitment to > the idea or the implementation, but just getting it in so people can > play Right, that's what my intention was, nothing more. > > If we continue this way, porting to the other platforms will > > become impossible. > > Even the simple posix itself is incompatible between various > > flavors. For example on AIX there is 'archive.a(dso.so)' and > > dlopen needs 'RTLD_NOW | RTLD_GLOBAL | RTDL_MEMBER' flags. > > Some platforms like HPUX use the shl_load, not to mention the > > Windows or Netware. > > > > The actual code itself exists, and is very much mature within > > Apache2, and module dependencies are implemented within apr-iconv > > project, so perhaps this would be a way to go. > > > > APR? I think that we'll leverage APR heavily. Whether or not the > APR API is the one we use as the standard porting layer API remains > to be seen. If not, I'm certain will used it for platform > implementations of the porting layer... There are several places in the code where I've added comments about things that have to be changed if we really use this component model. Note that there are also serious concerns about performance in a runtime-configurable component model and Robin Garner suggested to aim for compile time configurability (See [1]). APR would definitely be a better choice than posix, but AFAICS the decision about what our portability layer will be has not been made yet. > > Also, what about coding style guide? > > That's a good question, and something I assume we'll converge around > as we get moving. I totally agree with that. I discussed earlier with Weldon Washburn and Geir about using the Java Coding Conventions where possible (See [2] and follow-ups), but this still doesn't cover things like directory structure, some aspects of documentation policy, etc., and there was no decision yet. Regards, David. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] > geir > > > > > Regards, > > Mladen. > > > > > -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Jockey for Position Episode: Brain: Pinky, Are You Pondering What I'm Pondering? Pinky: Wuh, I think so, Brain, but isn't Regis Philbin already married? signature.asc Description: This is a digitally signed message part
