Re: compiling bootJVM with MSVC
Hi Geir, On Mon, 2005-11-07 at 06:44 -0500, Geir Magnusson Jr. wrote: On Nov 7, 2005, at 5:40 AM, Mark Wielaard wrote: On Sun, 2005-11-06 at 08:44 -0500, Geir Magnusson Jr. wrote: Lets not count our chickens here. The LGPL policy is still in the works, and may not allow anything but limited-time optional dependencies, and no re-distrubution of LGPL-ed artifacts. But that is all we need for now don't we? No, because we want to be able to distribute complete tested implementations of J2SE, right? :) It is a start don't you agree? And one that would help us forward now. In the end we want to combine all the projects to make up a complete free J2SE replacement. That will indeed take more work and cooperation. But this seems like a nice start. Of course we should lobby for more freedom. I won't take that bait :0 I am not sure I am following you. If it is the word freedom, then replace it with flexibility. What we want if that the board allows us to combine and distribute the various projects. The above is a good first step since lots of people want to use and depend on LGPL-covered works. Over time we would like to have more compromises of course. Just like we compromised with GNU Classpath and added an exception statement to the GPLv2. If we could get something similar for the ASL to make it compatible with the GPL for the harmony code covered by the ASLv2 that would be ideal imho. But the main thing is to make sure there are no roadblocks for collaboration between the different free sofware projects. Indeed! That's why I'm so certain that interoperability of modules and componentization will be so beneficial for us. Sure, but then we must be sure that we can combine these modules and components into a larger work in a way that makes both the GNU and Apache communities happy. If the board really refuses to allow us to distributed a fully integrated system containing all parts we can always put the whole collection up somewhere else. But we will cross that bridge when we get there. Lets first put together the whole system. Someone can always take the various works and post somewhere else, but we'll distribute what we test, and we won't be able to use Apache TCKs to test something we're not distributing from here. Then lets make sure we can all distribute it from here. But also think carefully whether we are a development group or a distributor. Most GNU/Linux distributions are much better at shipping stuff then we development communities. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: VM/Class Library Interface (or Storming the Gates! Take 3!)
Hi Graeme, On Mon, 2005-11-07 at 17:03 -0500, Graeme Johnson wrote: Split-class (ClassX VMClassX) or customized-class solutions (Tim E's Kernel classes) are different approaches to solving the same problem. Not completely. I think they complement each other. The ClassX VMClassX split describes at a high (java) level what the responsibilities of an runtime/execution-model are. Then the VMClasses are more like the customized-class solutions in case you have a traditional execution-model that is based on JNI/Posix like platforms. Of the two approaches I believe that the customized-class solution delivers simpler code and shorter call-paths as it avoids the need for any runtime redirection. That can be an issue indeed. But by marking the VMClasses package private and final (or just have list in the jit/compiler) all calls to them should be able to be optimized away if needed. In either case I think we want to determine how to build customized versions of a reference implementation without resorting to cut'n'paste duplication. IMO making the build process responsible for creating customized versions of VM-dependent classes from a master version puts the complexity in the right place (build-time vs runtime). Yes, that is mostly how it works with GNU Classpath based runtimes. At build time each runtime overrides/changes the few VMClasses for which it cannot use the vm/reference version. This seems to work nicely and makes it possible to share almost all of the glibj.zip classes as is. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: Code contribution to harmony
Hi, On Tue, 2005-11-08 at 16:13 +, Stefano Mazzocchi wrote: Tim Ellison wrote: I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. Let's the harmonization process begin :-) Right! I have been thinking on how to move forward with this. And I am excited to see some core class library code since that is where my expertise is. Obviously we should be able to extend this easily with parts of the GNU Classpath library like awt, beans, corba, crypto, swing, sql, most of javax, imageio, naming, etc and the 1.5 additions we have plus the generic classes from the classpath-generics branch. At the same time we can merge the kernel classes to get the best of both implementations. But it seems we still have the original roadblock to harmony cooperation, the incompatible licenses. Since this contribution is marked as ASLv2 which is incompatible with GPLv2 so we won't be able to share this easily. So lets try to get that away now. Would IBM be willing to assign this code to the FSF for inclusion in GNU Classpath or contribute it under a GPL-compatible license like MIT/X, W3C, etc. so that it can be mixed and merged with the GNU Classpath core library and used in larger GPL-compatible works like gcj, kaffe, etc? That would be really fun. I remember when I joined the GNU Classpath group and we merged the libgcj and classpath code bases. That was really a good way to lift up both projects since you can compare ideas and code to create something that is bigger then the original things. And you will always learn things from trying to merge two similar but slightly different code bases. I am looking forward to going through each of the core packages to see which implementation is best if we can get the this license issue out of the way. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
The Unofficial Harmony, Licensing, the Universe and everything FAQ
I keep getting lost in the licensing discussions. I *think* the below accurately represents where we are right now. = The Unofficial Harmony, Licensing, the Universe and everything FAQ = version 0.0.0.1-SNAPSHOT Q: What do you mean, unofficial A: Not written by someone with a clue about legal stuff, not reviewed by the ASF legal team or anyone else with enough of a brain to understand this stuff enough, not even reviewed by most of the harmony crew. Its UNOFFICIAL, okay? Its also not legal advice. I Am Not A Lawyer. I don't play one on tv either, though I played one on stage the other day. Q: under what license is the harmony code? A: the Apache License, version 2.0. Parts of our code are licensed to the ASF under the terms of its Contributor License Agreement and/or its Corporate Contributor License Agreement, licenses which allow the ASF to sublicense those contributions to its users under the terms of the Apache License, version 2.0. Parts of our code may be licensed under terms which allow sublicensing of under the terms of the Apache License. Such licenses include the MIT/X License and the modified BSD license, and potentially others. Parts of our code may be dependent on binaries licensed under terms which allow sublicensing of those binaries under the Apache License and for which the source code of those binaries is licensed under an open source license. Such licenses include the MPL version 1.1, the CDDL version 1.0, and potentially others. Parts of our code may have optional dependencies on binaries or source code licensed under other terms. For example, the Microsoft Windows version of harmony obviously depends on the availability of Microsoft Windows, which, the last time we checked, was not available under an open source license. You can use these individual parts seperately under whatever terms apply to them. We are making an effort to track the licenses that apply to all significant individual parts of our code. However, the full combined work is always licensed under the Apache License, version 2.0. Q: does or will harmony contain code licensed under other terms? A: No. Q: does or will harmony contain code licensed under the LGPL? A: No. Q: does or will harmony depend on code licensed under the LGPL? A: Maybe. The ASF is working on a specific policy for allowing ASF projects to have optional dependencies on binaries licensed under the LGPL. Q: does or will harmony contain code licensed under the GPL? A: No. Q: does or will harmony code depend on code licensed under the GPL? A: No. Q: does or will harmony code depend on GNU Classpath? A: Maybe. Once the ASF and FSF legal teams settle the LGPL stuff described above, hopefully more attention will turn to answering whether we can / want to depend on Classpath (from the legal perspective). (GNU Classpath is licensed under the GPL but has a special exception: http://www.gnu.org/software/classpath/license.html ) which may or may not turn out to be acceptable. Even if the exception is not suitable in its current form the ASF will try to work with the FSF and the GNU Classpath developers to figure out some kind of workable arrangement. It is rather certain that some of our code will, while in development inside our SVN trees or inside our issue tracker or on our mailing list or elsewhere, have optional and/or non-optional dependencies on GNU Classpath. We certainly hope to produce code that allows end users to combine harmony code or binaries with GNU Classpath code or binaries, using GNU Classpath as the class library. Whether we can ship such a thing as the default and/or call it java (because it is certified by Sun) is a lot more uncertain. It is also not unlikely that harmony develops an alternative class library implementation licensed under the Apache License or similar terms. However, even if that were to happen we are hoping that all the legal stuff can be resolved so we can use GNU Classpath, se we can offer our users a choice. Choice is good. Q: does or will harmony code depend on external JVM X? A: No. Harmony will contain its own JVM implementation, or more likely we will have several. However, we do hope to interoperate with various other open source JVM implementations and work with their developers as much as possible. If we for example develop an alternative class library we would hope to make that available for use with other JVMs. We might also provide ways in which you can swap out harmony's JVM implementation or pieces of it with external code. In general harmony will reuse or integrate with existing open source components whenever we can. Just about the only barrier that keeps us from such reuse or integration is the licensing one. Q: does or will harmony code
Re: VM/Class Library Interface (or Storming the Gates! Take 3!)
Mark Wielaard wrote: Hi Graeme, On Mon, 2005-11-07 at 17:03 -0500, Graeme Johnson wrote: Split-class (ClassX VMClassX) or customized-class solutions (Tim E's Kernel classes) are different approaches to solving the same problem. Not completely. I think they complement each other. The ClassX VMClassX split describes at a high (java) level what the responsibilities of an runtime/execution-model are. Then the VMClasses are more like the customized-class solutions in case you have a traditional execution-model that is based on JNI/Posix like platforms. I'm assuming that ClassX and VMClassX are quite closely coupled, so that other types in the package don't make internal API calls on VMClassX directly? If that is true it's also worth pointing out that the (ClassX + VMClassX) combination will simply look like a kernel version of ClassX to the rest of the classlibrary code -- it's a pretty minor difference at that level. Of the two approaches I believe that the customized-class solution delivers simpler code and shorter call-paths as it avoids the need for any runtime redirection. That can be an issue indeed. But by marking the VMClasses package private and final (or just have list in the jit/compiler) all calls to them should be able to be optimized away if needed. Agreed. What you are pointing out is that the JIT will roll the code defined in two classes into the moral-equivalent of one class anyway ;-) Most JITs will do the method inlining out of the box, and the same thing could happen for storage too if the VM/JIT is aware of the pattern -- the VM/JIT could allocate storage for the common code and delegate contiguously; and make that assumption. Without such an awareness you would require two objects, with a read-barrier to access the delegate, and may suffer from data locality probs if they end up miles apart. [thinking aloud: I don't think you could use subclassing to solve the problem, since if the common code is declared as the supertype (ObjectThreadVMThread) applications would need to call the constructor on the VM-type, and if it was the other way around (ObjectVMThreadThread) that would break the spec. for the common type.] In either case I think we want to determine how to build customized versions of a reference implementation without resorting to cut'n'paste duplication. IMO making the build process responsible for creating customized versions of VM-dependent classes from a master version puts the complexity in the right place (build-time vs runtime). Yes, that is mostly how it works with GNU Classpath based runtimes. At build time each runtime overrides/changes the few VMClasses for which it cannot use the vm/reference version. This seems to work nicely and makes it possible to share almost all of the glibj.zip classes as is. I'd claim that we both have the same goals of a small set of customized types. One solution was formulated at build-time and the other at runtime. Seems like a small distinction though, and the interop is simple enough. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: compiling bootJVM with MSVC
On Nov 9, 2005, at 5:59 AM, Mark Wielaard wrote: Hi Geir, On Mon, 2005-11-07 at 06:44 -0500, Geir Magnusson Jr. wrote: On Nov 7, 2005, at 5:40 AM, Mark Wielaard wrote: On Sun, 2005-11-06 at 08:44 -0500, Geir Magnusson Jr. wrote: Lets not count our chickens here. The LGPL policy is still in the works, and may not allow anything but limited-time optional dependencies, and no re-distrubution of LGPL-ed artifacts. But that is all we need for now don't we? No, because we want to be able to distribute complete tested implementations of J2SE, right? :) It is a start don't you agree? And one that would help us forward now. In the end we want to combine all the projects to make up a complete free J2SE replacement. That will indeed take more work and cooperation. But this seems like a nice start. Yes, it's certainly a start. Of course we should lobby for more freedom. I won't take that bait :0 I am not sure I am following you. If it is the word freedom, then replace it with flexibility. What we want if that the board allows us to combine and distribute the various projects. The above is a good first step since lots of people want to use and depend on LGPL-covered works. Ah! That's the key though - I don't think we are going to see ASF projects with unrestricted LGPL-ed dependencies. Maybe optional ones, but there will be limits. Over time we would like to have more compromises of course. Just like we compromised with GNU Classpath and added an exception statement to the GPLv2. If we could get something similar for the ASL to make it compatible with the GPL for the harmony code covered by the ASLv2 that would be ideal imho. This is a long subject, maybe for another post. But the main thing is to make sure there are no roadblocks for collaboration between the different free sofware projects. Indeed! That's why I'm so certain that interoperability of modules and componentization will be so beneficial for us. Sure, but then we must be sure that we can combine these modules and components into a larger work in a way that makes both the GNU and Apache communities happy. We have no problem if, for example, standard APIs like javax.persistence are implemented under LGPL or -ish, because the user has full freedom to find a replacement for that LGPL-ed work and retains functionality. So that's what my vision for this is - a set of interfaces that we create/adopt together, and the give us each freedom to implement under our own license and users to choose and mix and match. If the board really refuses to allow us to distributed a fully integrated system containing all parts we can always put the whole collection up somewhere else. But we will cross that bridge when we get there. Lets first put together the whole system. Someone can always take the various works and post somewhere else, but we'll distribute what we test, and we won't be able to use Apache TCKs to test something we're not distributing from here. Then lets make sure we can all distribute it from here. But also think carefully whether we are a development group or a distributor. Most GNU/Linux distributions are much better at shipping stuff then we development communities. Yes, but the ASF does act as the primary distributor for it's project releases. Others can as well, and do. I have no problem, of course, of others re-using our work in ways that they choose that are legal geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Code contribution to harmony
On Nov 9, 2005, at 6:17 AM, Mark Wielaard wrote: Hi, On Tue, 2005-11-08 at 16:13 +, Stefano Mazzocchi wrote: Tim Ellison wrote: I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. Let's the harmonization process begin :-) Right! I have been thinking on how to move forward with this. And I am excited to see some core class library code since that is where my expertise is. Obviously we should be able to extend this easily with parts of the GNU Classpath library like awt, beans, corba, crypto, swing, sql, most of javax, imageio, naming, etc and the 1.5 additions we have plus the generic classes from the classpath-generics branch. At the same time we can merge the kernel classes to get the best of both implementations. But it seems we still have the original roadblock to harmony cooperation, the incompatible licenses. Since this contribution is marked as ASLv2 which is incompatible with GPLv2 so we won't be able to share this easily. So lets try to get that away now. Would IBM be willing to assign this code to the FSF for inclusion in GNU Classpath or contribute it under a GPL-compatible license like MIT/X, W3C, etc. so that it can be mixed and merged with the GNU Classpath core library and used in larger GPL-compatible works like gcj, kaffe, etc? Mark, speaking with my IBM hat on, I will say that as I promised yesterday to you, I'll certainly get a discussion started inside IBM, but can't answer this now. Also, please understand that sometimes things can move very slowly. geir That would be really fun. I remember when I joined the GNU Classpath group and we merged the libgcj and classpath code bases. That was really a good way to lift up both projects since you can compare ideas and code to create something that is bigger then the original things. And you will always learn things from trying to merge two similar but slightly different code bases. I am looking forward to going through each of the core packages to see which implementation is best if we can get the this license issue out of the way. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: VM/Class Library Interface (or Storming the Gates! Take 3!)
On Nov 9, 2005, at 9:14 AM, Tim Ellison wrote: Mark Wielaard wrote: That can be an issue indeed. But by marking the VMClasses package private and final (or just have list in the jit/compiler) all calls to them should be able to be optimized away if needed. Agreed. What you are pointing out is that the JIT will roll the code defined in two classes into the moral-equivalent of one class anyway ;-) joke Now, if this is GPL-ed code, wouldn't that be a derivative work, thus requiring the entire application to be re-licensed under the GPL? /joke -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Code contribution to harmony
On Nov 9, 2005, at 10:37 AM, Geir Magnusson Jr. wrote: On Nov 9, 2005, at 6:17 AM, Mark Wielaard wrote: Hi, On Tue, 2005-11-08 at 16:13 +, Stefano Mazzocchi wrote: Tim Ellison wrote: I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. Let's the harmonization process begin :-) Right! I have been thinking on how to move forward with this. And I am excited to see some core class library code since that is where my expertise is. Obviously we should be able to extend this easily with parts of the GNU Classpath library like awt, beans, corba, crypto, swing, sql, most of javax, imageio, naming, etc and the 1.5 additions we have plus the generic classes from the classpath-generics branch. At the same time we can merge the kernel classes to get the best of both implementations. But it seems we still have the original roadblock to harmony cooperation, the incompatible licenses. Since this contribution is marked as ASLv2 which is incompatible with GPLv2 so we won't be able to share this easily. So lets try to get that away now. Would IBM be willing to assign this code to the FSF for inclusion in GNU Classpath or contribute it under a GPL-compatible license like MIT/X, W3C, etc. so that it can be mixed and merged with the GNU Classpath core library and used in larger GPL-compatible works like gcj, kaffe, etc? Mark, speaking with my IBM hat on, I will say that as I promised yesterday to you, I'll certainly get a discussion started inside IBM, but can't answer this now. Also, please understand that sometimes things can move very slowly. And to really put a fine point on this, I work for IBM, work in things like this for IBM, represent our community interests inside IBM and IBMs interests here (to some degree), but I don't speak for or represent IBM in general, or on this matter specifically. geir geir That would be really fun. I remember when I joined the GNU Classpath group and we merged the libgcj and classpath code bases. That was really a good way to lift up both projects since you can compare ideas and code to create something that is bigger then the original things. And you will always learn things from trying to merge two similar but slightly different code bases. I am looking forward to going through each of the core packages to see which implementation is best if we can get the this license issue out of the way. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: compiling bootJVM with MSVC
-Original Message- From: Mark Wielaard [EMAIL PROTECTED] Sent: Nov 5, 2005 5:09 AM To: harmony-dev@incubator.apache.org Subject: Re: compiling bootJVM with MSVC Hi Tim, On Fri, 2005-11-04 at 22:29 +, Tim Ellison wrote: ...snip... Lets make Harmony into that collaborative project that we envisioned when we started it and be open to the whole community. Absolutely! Cheers, Mark -- Dan Lydick
Re: Code contribution to harmony
On Nov 9, 2005, at 10:37 AM, Geir Magnusson Jr. wrote: On Nov 9, 2005, at 6:17 AM, Mark Wielaard wrote: Would IBM be willing to assign this code to the FSF for inclusion in GNU Classpath or contribute it under a GPL-compatible license like MIT/X, W3C, etc. so that it can be mixed and merged with the GNU Classpath core library and used in larger GPL-compatible works like gcj, kaffe, etc? Mark, speaking with my IBM hat on, I will say that as I promised yesterday to you, I'll certainly get a discussion started inside IBM, but can't answer this now. Also, please understand that sometimes things can move very slowly. I'd like to re-clarify my statement as I don't wish to create any false expectations or misinterpretations. What I was trying to say : I'm simply going to communicate this question inside IBM, and can promise no answer - we will go forward with what we have now under the terms we have now IBM's contribution was made only under the Apache License, and there are no plans for doing anything else with respect to a change or addition in licensing. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Code contribution to harmony
Mark Wielaard wrote: Hi, On Tue, 2005-11-08 at 16:13 +, Stefano Mazzocchi wrote: Tim Ellison wrote: I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. Let's the harmonization process begin :-) Right! I have been thinking on how to move forward with this. And I am excited to see some core class library code since that is where my expertise is. Obviously we should be able to extend this easily with parts of the GNU Classpath library like awt, beans, corba, crypto, swing, sql, most of javax, imageio, naming, etc and the 1.5 additions we have plus the generic classes from the classpath-generics branch. Great. That will be a good opportunity to work together on a class library componentization story too! At the same time we can merge the kernel classes to get the best of both implementations. But it seems we still have the original roadblock to harmony cooperation, the incompatible licenses. Since this contribution is marked as ASLv2 which is incompatible with GPLv2 so we won't be able to share this easily. So lets try to get that away now. Would IBM be willing to assign this code to the FSF for inclusion in GNU Classpath or contribute it under a GPL-compatible license like MIT/X, W3C, etc. so that it can be mixed and merged with the GNU Classpath core library and used in larger GPL-compatible works like gcj, kaffe, etc? I agree that getting a resolution to the community/licensing differences would be fantastic. I don't see that happening quickly, and I don't want to see the success or failure of a development project gated upon it. IMHO resolving license issues is a board-level objective, not a J2SE-project objective. We can hack code and live in hope :-) That would be really fun. I remember when I joined the GNU Classpath group and we merged the libgcj and classpath code bases. That was really a good way to lift up both projects since you can compare ideas and code to create something that is bigger then the original things. And you will always learn things from trying to merge two similar but slightly different code bases. I am looking forward to going through each of the core packages to see which implementation is best if we can get the this license issue out of the way. I think we should actively seek out opportunities for collaboration. There is every reason to ensure that we don't end up with gratuitious architectural differences that prevent users combining code from GNU Classpath and Harmony. If it turns out that interoperability requires releasing some subset of code under a different license then that is a discussion to be had between the projects (independently of which way the code is flowing). I don't think that point has come. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: bootJVM successfully compiled and linked with MSVC
Enrico, Good work! Sorry for the delayed reply, I've been having an e-mail issue. -Original Message- From: Enrico Migliore [EMAIL PROTECTED] Sent: Nov 8, 2005 12:57 AM To: harmony-dev@incubator.apache.org Subject: bootJVM successfully compiled and linked with MSVC Hi, I finally compiled and linked the source tree ..\bootJVM\\jvm\src, with MSVC, and using the pthreadVC2.dll library. To produce a successfull build, I had to slightly adapt the source code and comment out, at the moment, the getwd( ) UNIX function, located in classfile.c If you could post to JIRA the things you did to make this happen, they could be evaluated as to what should be done, if anything, to roll this into the source base. The best way to report the source changes for something like this is probably to use an 'svn diff' report on that change. Since, tomorrow I'm going to do some debugging, I wanted know if someone can address me where to start from. Should I debug something like java HelloWorld.class? Am I supposed to define a sort of CLASSPATH environment variable where the bootJVM will look for system classes? Running 'config.sh' is supposed to ask for that. Since you are using MSVC, I presume you have not done a whole lot with it beyond running it under CygWin to set up 'config/config.h' and friends. That's okay, because part of the package is setting up a temporary CLASSPATH internally using the 'bootclasspath' facility. If you answer 'yes' to the configuration question to set it up, selected classes from your _current_ JDK will be incorporated into a 'bootclasspath' subdirectory at the top level, namely, the same level as the 'config' directory. Look for 'bootclasspath' in both UPPER and lower case in the scripts and source for details. Concerning debugging 'HelloWorld.class', I am still in the midst of finishing up the remaining Java opcodes in 'jvm/src/opcode.c' and you will need this update before you will be able to run any code. Stay tuned to The List for details. I've got another question. I've noticed that, along with bootJVM, there is more than one source code contribution: am I compiling and debugging the right source code? There's lots of goodies to look at, with more coming. We are in a gathering phase for code contributions and mine is one among several. thanks for any help, Enrico Dan Lydick
Re: compiling bootJVM with MSVC
Sebastian Hartte wrote: Enrico Migliore wrote: Sebastian Hartte wrote: Hi you two, I tried a similar thing (using Visual Studio 2005 Professional). The empty structs are still an error in that compiler version (What do you need empyt structs for anyway? Allocation a zero byte memory region doesn't make much sense to me). I think that those structs are empty because are a placeholder for fields that will be defined in the future. But i also run into problems with pthread.h since that doesn't exist on Windows. Either i screwed up and included the wrong header files (but i think jvm.h belongs to the project) or the threading is entirely based on pthreads. Isn't there some form of platform independent threading in the apache httpd project that could be used over here? After all refactoring is cool ;-) For a win32 pthread implementation, try this: http://sources.redhat.com/pthreads-win32/ There are two libraries I downloaded this one: pthreadVC2.lib To be honest i don't like the requirement of yet another library to compile it on Windows. The big question here would be how closely the threading api is tied into the JVM. I would certainly prefer a platform independent solution. Is any Apache2 developer around who knows how the threading mpm does it? Sebastian, At the risk of preempting the acceptance of HARMONY-14... take a look at the thread library that is in there, and described in the doxygen pages that you will find in Harmony/doc/vm_doc/html/group__Thread.html. That contains a bunch of threading calls that should be of use to the bootJVM port, and there is an impl for the MSVC compiler on Windows. bye, Sebastian Enrico -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Code contribution to harmony
Tim, Looks like the project team is going to be getting _very_ busy, and soon! Thanks for going the extra mile in putting together this contribution! Dan Lydick -Original Message- From: Tim Ellison [EMAIL PROTECTED] Sent: Nov 8, 2005 4:49 AM To: harmony-dev harmony-dev@incubator.apache.org Subject: Code contribution to harmony -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. The code comprises a concrete implementation of the interface between virtual machine and class library that we have been discussing recently, together with a set of core Java classes. The aim is to ground the discussion in reality and provide an opportunity for people to collaborate on enhancements and improvements to actual code. The Java classes are a subset of Java SE 1.4.2 APIs sufficient to run Ant and the Eclipse Java compiler, to provide a basic self-hosting environment. Some of the types are simply stubs to enable full recompilation of the Java code. The ZIP also includes HTML documentation for the VM interface. I've uploaded the contribution here: http://issues.apache.org/jira/browse/HARMONY-14 The expected MD5 sums are: 73ade240df20dec481806130fc8b4875 *Harmony-contribution_Part-1-of-2.zip bc9117d9b4af113eaf5250883d1ce669 *Harmony-contribution_Part-2-of-2.zip A number of people were involved with getting the code ready for contribution (too many to name individually!), and they have done a fine job. There is still plently of work to do; for example, we renamed some code to Hy, but some still has a com.ibm prefix. The code needs bringing up to the project goal of supporting 5.0 APIs. It is targeted at Windows and Linux on Intel 32-bit machines. Now it is everyone's code, join in! In the meantime we are working on making a VM available for download (under a binary evaluation license) from IBM's DeveloperWorks site that implements the class library interface. By getting the VM and unzipping into the same directory you can run the contributed code and try out your changes. I'll post the URL for the VM download (as soon as I know it) as a follow-up to this mail -- it could take a couple of days to organize. Just to avoid confusion, the DeveloperWorks VM not a regular IBM JRE. It is a VM being made available to enable Harmony development and is _not_ a contribution. Regards, Tim - -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDcILEQeoJoFeTSY8RAosaAJ4wnnCaMDb9faTA52UGfxUGLqEOEgCg4ByR lCoq7wUHcDbd/sJxWBiLs60= =E8W4 -END PGP SIGNATURE-
Re: compiling bootJVM with MSVC
-Original Message- From: Tim Ellison [EMAIL PROTECTED] Sent: Nov 9, 2005 11:07 AM To: harmony-dev@incubator.apache.org Subject: Re: compiling bootJVM with MSVC Sebastian Hartte wrote: Enrico Migliore wrote: Sebastian Hartte wrote: ...snip... For a win32 pthread implementation, try this: http://sources.redhat.com/pthreads-win32/ There are two libraries I downloaded this one: pthreadVC2.lib To be honest i don't like the requirement of yet another library to compile it on Windows. The big question here would be how closely the threading api is tied into the JVM. I would certainly prefer a platform independent solution. Is any Apache2 developer around who knows how the threading mpm does it? Sebastian, At the risk of preempting the acceptance of HARMONY-14... take a look at the thread library that is in there, and described in the doxygen pages that you will find in Harmony/doc/vm_doc/html/group__Thread.html. That contains a bunch of threading calls that should be of use to the bootJVM port, and there is an impl for the MSVC compiler on Windows. Sebastian, I would gladly entertain your proposal on how to thread BootJVM with MSVC facilities as a part of the overall porting effort. If you have some specific ideas here, perhaps a JIRA posting woud be the place to start. Thanks for your help. Dan Lydick
[jira] Updated: (HARMONY-12) [BootJVM] MakeSetup contains an uncorrectly escaped shell command
[ http://issues.apache.org/jira/browse/HARMONY-12?page=all ] Geir Magnusson Jr updated HARMONY-12: - Component: VM [BootJVM] MakeSetup contains an uncorrectly escaped shell command - Key: HARMONY-12 URL: http://issues.apache.org/jira/browse/HARMONY-12 Project: Harmony Type: Bug Components: VM Environment: any Reporter: Jean-Frederic Clere Assignee: Geir Magnusson Jr Attachments: MakeSetup.patch DIRNAME:=$(shell expr $(PWD) : '\(.*[^/]\)/*$' : '.*/\(..*\)') should be DIRNAME:=$(shell expr $(PWD) : '\(.*[^/]\)/*$$' : '.*/\(..*\)') -- 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
[jira] Updated: (HARMONY-10) configure for [BootJVM]
[ http://issues.apache.org/jira/browse/HARMONY-10?page=all ] Geir Magnusson Jr updated HARMONY-10: - Component: VM configure for [BootJVM] Key: HARMONY-10 URL: http://issues.apache.org/jira/browse/HARMONY-10 Project: Harmony Type: New Feature Components: VM Environment: any unix based machine (and cygwin). Reporter: Jean-Frederic Clere Assignee: Geir Magnusson Jr Attachments: config_try.tar.gz, config_try.tar.gz Allow to use a standard way of building BootJVM: ../configure --with-java=$JAVA_HOME --with-heap=HEAD_TYPE --with-gc=GC_TYPE make make install -- 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
Re: Compilers and configuration tools
Leo Simons wrote: Whoohooh! An actual vi-vs-emacs discussion! Now we are *really* getting started! vi is quite a lot ahead of emacs. http://jvi.sourceforge.net/ versus http://jemacs.sourceforge.net/ But anyone who chooses either must love to type a *lot* :) -- Thorbjørn
Re: Code contribution to harmony
Note when doing ant I get the following: +++ cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -DHYPORT_LIBRARY_DEFINE -I../include -c -o hyvmem.o hyvmem.c hyvmem.c: In function `hyvmem_reserve_memory': hyvmem.c:311: `SHM_HUGETLB' undeclared (first use in this function) hyvmem.c:311: (Each undeclared identifier is reported only once hyvmem.c:311: for each function it appears in.) make[1]: Leaving directory `/home/jfclere/harmony/Harmony/native-src/linux.IA32/port' make[1]: *** [hyvmem.o] Error 1 make: *** [_port] Error 2 +++ So the requirements on Linux are a 2.6.x kernel, aren't they? Cheers Jean-Frederic
Re: Code contribution to harmony
Jean-frederic Clere wrote: Note when doing ant I get the following: +++ cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -DHYPORT_LIBRARY_DEFINE -I../include -c -o hyvmem.o hyvmem.c hyvmem.c: In function `hyvmem_reserve_memory': hyvmem.c:311: `SHM_HUGETLB' undeclared (first use in this function) hyvmem.c:311: (Each undeclared identifier is reported only once hyvmem.c:311: for each function it appears in.) make[1]: Leaving directory `/home/jfclere/harmony/Harmony/native-src/linux.IA32/port' make[1]: *** [hyvmem.o] Error 1 make: *** [_port] Error 2 +++ So the requirements on Linux are a 2.6.x kernel, aren't they? No, should work ok on 2.4 (e.g. RHEL3) What are you compiling on? The platforms we are using include: - Red Hat EL3 Update 5 - Red Hat EL4 Update 1 - SLES 9 SP1 (on Pentium III, Pentium 4, and Pentium Xeon processors). Regards, Tim Cheers Jean-Frederic -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Code contribution to harmony
Tim Ellison wrote: Jean-frederic Clere wrote: Note when doing ant I get the following: +++ cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -DHYPORT_LIBRARY_DEFINE -I../include -c -o hyvmem.o hyvmem.c hyvmem.c: In function `hyvmem_reserve_memory': hyvmem.c:311: `SHM_HUGETLB' undeclared (first use in this function) hyvmem.c:311: (Each undeclared identifier is reported only once hyvmem.c:311: for each function it appears in.) make[1]: Leaving directory `/home/jfclere/harmony/Harmony/native-src/linux.IA32/port' make[1]: *** [hyvmem.o] Error 1 make: *** [_port] Error 2 +++ So the requirements on Linux are a 2.6.x kernel, aren't they? No, should work ok on 2.4 (e.g. RHEL3) What are you compiling on? Suse 8.1: +++ [EMAIL PROTECTED]:~/harmony/Harmony more /etc/SuSE-release SuSE Linux 8.1 (i386) VERSION = 8.1 +++ I have added: #define SHM_HUGETLB 04000 /* segment will use huge TLB pages */ in native-src/linux.IA32/port/hyvmem.c to work-round the problem. The next problem is: +++ [EMAIL PROTECTED]:~/harmony/Harmony ./deploy/jre/bin/java --help Failed to open JVM DLL: /home/jfclere/harmony/Harmony/deploy/jre/bin/default/clearvm (/home/jfclere/harmony/Harmony/deploy/jre/bin/default/libclearvm.so: cannot open shared object file: No such file or directory) +++ The platforms we are using include: - Red Hat EL3 Update 5 - Red Hat EL4 Update 1 - SLES 9 SP1 (on Pentium III, Pentium 4, and Pentium Xeon processors). Regards, Tim Cheers Jean-Frederic
Re: Code contribution to harmony
Hi Jean-Frederic, It sounds like you do not have a compatible VM to run with (i.e. a VM that implements the proposed interface to the class libraries). As mentioned by Tim the other day you can obtain one from the IBM developerWorks site at http://www.ibm.com/developerworks/java/jdk/harmony If you unzip the archive from the above link into the same directory that you unzipped the code contribution to then the current problem should be sorted. Note that the VM is not part of the code contribution and is only available in binary form under an evaluation license. Hope this helps, George Jean-frederic Clere [EMAIL PROTECTED] 09/11/2005 22:56 Please respond to harmony-dev@incubator.apache.org To harmony-dev@incubator.apache.org cc Subject Re: Code contribution to harmony Tim Ellison wrote: Jean-frederic Clere wrote: Note when doing ant I get the following: +++ cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -DHYPORT_LIBRARY_DEFINE -I../include -c -o hyvmem.o hyvmem.c hyvmem.c: In function `hyvmem_reserve_memory': hyvmem.c:311: `SHM_HUGETLB' undeclared (first use in this function) hyvmem.c:311: (Each undeclared identifier is reported only once hyvmem.c:311: for each function it appears in.) make[1]: Leaving directory `/home/jfclere/harmony/Harmony/native-src/linux.IA32/port' make[1]: *** [hyvmem.o] Error 1 make: *** [_port] Error 2 +++ So the requirements on Linux are a 2.6.x kernel, aren't they? No, should work ok on 2.4 (e.g. RHEL3) What are you compiling on? Suse 8.1: +++ [EMAIL PROTECTED]:~/harmony/Harmony more /etc/SuSE-release SuSE Linux 8.1 (i386) VERSION = 8.1 +++ I have added: #define SHM_HUGETLB 04000 /* segment will use huge TLB pages */ in native-src/linux.IA32/port/hyvmem.c to work-round the problem. The next problem is: +++ [EMAIL PROTECTED]:~/harmony/Harmony ./deploy/jre/bin/java --help Failed to open JVM DLL: /home/jfclere/harmony/Harmony/deploy/jre/bin/default/clearvm (/home/jfclere/harmony/Harmony/deploy/jre/bin/default/libclearvm.so: cannot open shared object file: No such file or directory) +++ The platforms we are using include: - Red Hat EL3 Update 5 - Red Hat EL4 Update 1 - SLES 9 SP1 (on Pentium III, Pentium 4, and Pentium Xeon processors). Regards, Tim Cheers Jean-Frederic
Re: Code contribution to harmony
Hi Jean-Frederic, My understanding is that while huge TLB pages support was new in the 2.6 kernel it was made available as a backport in the RHEL3 2.4 kernel. Not sure if this also made it into the 2.4 kernel for SuSE 8.1. Might be worthwhile checking the documentation for your distribution. Best regards, George George Harley1/UK/[EMAIL PROTECTED] 09/11/2005 23:54 Please respond to harmony-dev@incubator.apache.org To harmony-dev@incubator.apache.org cc Subject Re: Code contribution to harmony Hi Jean-Frederic, It sounds like you do not have a compatible VM to run with (i.e. a VM that implements the proposed interface to the class libraries). As mentioned by Tim the other day you can obtain one from the IBM developerWorks site at http://www.ibm.com/developerworks/java/jdk/harmony If you unzip the archive from the above link into the same directory that you unzipped the code contribution to then the current problem should be sorted. Note that the VM is not part of the code contribution and is only available in binary form under an evaluation license. Hope this helps, George Jean-frederic Clere [EMAIL PROTECTED] 09/11/2005 22:56 Please respond to harmony-dev@incubator.apache.org To harmony-dev@incubator.apache.org cc Subject Re: Code contribution to harmony Tim Ellison wrote: Jean-frederic Clere wrote: Note when doing ant I get the following: +++ cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -DHYPORT_LIBRARY_DEFINE -I../include -c -o hyvmem.o hyvmem.c hyvmem.c: In function `hyvmem_reserve_memory': hyvmem.c:311: `SHM_HUGETLB' undeclared (first use in this function) hyvmem.c:311: (Each undeclared identifier is reported only once hyvmem.c:311: for each function it appears in.) make[1]: Leaving directory `/home/jfclere/harmony/Harmony/native-src/linux.IA32/port' make[1]: *** [hyvmem.o] Error 1 make: *** [_port] Error 2 +++ So the requirements on Linux are a 2.6.x kernel, aren't they? No, should work ok on 2.4 (e.g. RHEL3) What are you compiling on? Suse 8.1: +++ [EMAIL PROTECTED]:~/harmony/Harmony more /etc/SuSE-release SuSE Linux 8.1 (i386) VERSION = 8.1 +++ I have added: #define SHM_HUGETLB 04000 /* segment will use huge TLB pages */ in native-src/linux.IA32/port/hyvmem.c to work-round the problem. The next problem is: +++ [EMAIL PROTECTED]:~/harmony/Harmony ./deploy/jre/bin/java --help Failed to open JVM DLL: /home/jfclere/harmony/Harmony/deploy/jre/bin/default/clearvm (/home/jfclere/harmony/Harmony/deploy/jre/bin/default/libclearvm.so: cannot open shared object file: No such file or directory) +++ The platforms we are using include: - Red Hat EL3 Update 5 - Red Hat EL4 Update 1 - SLES 9 SP1 (on Pentium III, Pentium 4, and Pentium Xeon processors). Regards, Tim Cheers Jean-Frederic
