Re: Wiki: VM page
Henri Yandell wrote: Also, is there a different VM to J9 in the IBM JDK? Yes. The VM (and JIT) provided in the IBM JDK offering (at least for Linux) is a different one than J9. If you do java -version, you'll see something like IBM J9SE VM (build 2.2, J2RE 1.4.2 IBM J9 2.2 Linux amd64-64 j9xa64142sr1a-20050225 (JIT enabled) for the J9 offering and Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia321420-20040626 (JIT enabled: jitc)) for the IBM JDK. -- Karl T [1] http://www-106.ibm.com/developerworks/java/jdk/linux140/
[arch] questions about adding detail to the wiki harmonyArchitecture page
Dims, I would like to start filling out the modules and interfaces part of harmonyArchitecture wiki page. I looked at the wiki revision history and noticed that you were the last person to modify the page. Do you know if there is a protocol for modifying this document. Do people just make changes or is there a gatekeeper who must be notified. If there is no gatekeeper, I volunteer for this job. There are two sections on modules and interfaces. They overlap. Ultimately we need one section. Should I add my detail to my section and leave the resolution of overlap to another time? Thanks Weldon
Re: [arch] questions about adding detail to the wiki harmonyArchitecture page
Weldon, +1 for you to be the gatekeeper. Sure, please clean it up as you see fit. We should not lose the details that's all. thanks, dims On 5/27/05, Weldon Washburn [EMAIL PROTECTED] wrote: Dims, I would like to start filling out the modules and interfaces part of harmonyArchitecture wiki page. I looked at the wiki revision history and noticed that you were the last person to modify the page. Do you know if there is a protocol for modifying this document. Do people just make changes or is there a gatekeeper who must be notified. If there is no gatekeeper, I volunteer for this job. There are two sections on modules and interfaces. They overlap. Ultimately we need one section. Should I add my detail to my section and leave the resolution of overlap to another time? Thanks Weldon -- Davanum Srinivas - http://webservices.apache.org/~dims/
[arch] VM/Classlibrary interface
I think that this is a good topic that many around here have experience with and can get involved in. I think that it's not breaking new ground to say that we'll need a standard interface between the VM and the classlibrary, to let people integrate the various VMs and class libraries that we'll probably see. The GNU Classpath project has documented what they need http://www.gnu.org/software/classpath/docs/vmintegration.html and this seems to break down to : 1) Some sort of initialization protocol (currently seems to be defined in code, and only up to v1.1 - that may be stale docs...) 2) Core classes implemented by the VM for class-library usage - standard - things that you expect in java.lang (java.lang.Object) - non-standard - extension to java.lang (java.lang.VMObject) 3) VM hooks into the classlib 4) RMI stuff Clearly this is one model, and one that works because it's been used by many integrations. Now, questions : 0) Standing back from this specific model, can the model be generalized? 1) Are there other models? How do some of the commercial VMs do it? 2) Are there things that the GNU Classpath model is missing due to the version of the API it's implementing? (I.e. they don't realize they need it yet...) 3) I was uncomfortable with extending java.lang. I understand the argument - that as they are package private, the language can be depended upon to keep them safe from user code using them rather than some security infrastructure. However, isn't this a bit dangerous in terms of standard java.lang changes colliding? I'd like to drive to a standard interface that we can all agree on, and hopefully GNU Classpath will support it. This would insulate us from the ongoing legal discussion surrounding the license, and let us get on with using it directly. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] VM/Classlibrary interface
Geir == Geir Magnusson [EMAIL PROTECTED] writes: Geir 4) RMI stuff On irc Geir said that he meant JNI here. Basically what this means, I think, is that Classpath has an implementation of jni.h, but the VM has to provide certain typedefs, e.g., jint. Geir 2) Are there things that the GNU Classpath model is missing due to Geirthe version of the API it's implementing? (I.e. they don't realize Geirthey need it yet...) Yeah, there are some needed additions for 1.5. E.g., annotations require new reflection info, and in the Classpath model this comes from the VM layer. This will all show up eventually, perhaps on the generics branch. Geir 3) I was uncomfortable with extending java.lang. I understand the Geirargument - that as they are package private, the language can be Geirdepended upon to keep them safe from user code using them rather Geirthan some security infrastructure. However, isn't this a bit Geirdangerous in terms of standard java.lang changes colliding? I don't think there is a killer failure mode. First, note that it is both the language and the VM that implement this protection. This is crucial, as otherwise someone could easily circumvent the protection at runtime. Second, suppose Sun adds java.lang.VMObject to their public API. What then? * A program written against Sun's new release that uses this feature will not work against our old release. But that is already the case -- a program using a new API won't work against an older Classpath that doesn't implement it. The choice of name doesn't matter. * A program written against Sun's new release that uses this feature also won't compile against our old release. But this won't work anyway either. * To implement this new feature we would have to rename our VMObject and thus change the VM interface. But that is also not a huge problem. The VM interface can't remain fixed in general, because sometimes new features (see the 1.5 example) require additions to it. (This does mean some churn for VM implementors, and it is inconvenient. But it only breaks the VM, not anything else.) * Finally, there's no way to compile a program against Classpath that uses the Classpath VMObject, due to the access protection. So failures the other way aren't possible. Geir I'd like to drive to a standard interface that we can all agree on, Geir and hopefully GNU Classpath will support it. Experience has shown that the Classpath approach is pretty flexible. A wide range of VMs already use it. Also we're pretty open to specific needed changes. Tom
how to get involved
Hi guys, I've got a few questions, regarding the Harmony project: 1. How can one get involved? 2. How many hours a week, on the average, is it required? 3. What kind of background is it needed? thanks, Enrico
Re: [arch] VM/Classlibrary interface
Geir Magnusson Jr. wrote: 2) Core classes implemented by the VM for class-library usage - standard - things that you expect in java.lang (java.lang.Object) - non-standard - extension to java.lang (java.lang.VMObject) 3) I was uncomfortable with extending java.lang. I understand the argument - that as they are package private, the language can be depended upon to keep them safe from user code using them rather than some security infrastructure. However, isn't this a bit dangerous in terms of standard java.lang changes colliding? In general a VMInterface class resides as a package private class in the package that the class they help implement resides in. Using package private, not-user-visible classes seems to be pefectly valid way to do get similar things done in other, officially certified as compatible implementations[1], so I don't think that having package private classes means someone is extending the package's namespace, given that the VMInterface classes are not exported to user code to compile against. Therefore I think the term 'extension' is misplaced in this context. The VMInterface classes are an internal (and very useful in practice) detail of this particular class library implementation that does not extend the namespace available to user code to link against. Extending the name spaces would not be clever for all the obvious binary compatibility reasons, after all. The JCP may eventually specify classes in the future with the same names. That could happen, and would be just fine. The JCP is obviously free to call the specified classes any way they want, and if for some reason the JCP decides to call some future 1.6 Object class VMObject, so be it. :) The internal GNU Classpath VM interface for Object would have to change at that point, and things would move on just as they do all the time someone changes the VM interface for a different reason. It currently changes rather frequently in some areas, as people figure out new ways how to implement the respective classes in a better fashion. cheers, dalibor topic [1] http://forum.java.sun.com/thread.jspa?threadID=591979messageID=3091404 see java.io.UnixFileSystem class in the stack trace.
JavaONE - anyone going? Last day for early bird reg.
Sorry, this is a bit off-topic. Is anyone else planning to go to the JavaONE conference (June 25-30 San Francisco, CA)? By the way, today is the last day to register with the early bird discount. Regards Dmitry
Re: JavaONE - anyone going? Last day for early bird reg.
--- Dmitry Serebrennikov [EMAIL PROTECTED] wrote: Sorry, this is a bit off-topic. Not really OT at all, considering that Geir is to lead a session about Harmony at JavaONE. Alas, I won't be there. -Matt Is anyone else planning to go to the JavaONE conference (June 25-30 San Francisco, CA)? By the way, today is the last day to register with the early bird discount. Regards Dmitry __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: JavaONE - anyone going? Last day for early bird reg.
Nope. Too expensive, too big, too crowded. I'll stick with the No Fluff Just Stuff series, thanks. On 5/27/05, Dmitry Serebrennikov [EMAIL PROTECTED] wrote: Sorry, this is a bit off-topic. Is anyone else planning to go to the JavaONE conference (June 25-30 San Francisco, CA)? By the way, today is the last day to register with the early bird discount. Regards Dmitry
Re: Work items
Raffaele Castagno wrote: There's not only the need to start implementing code. I'm (slowly) translating some of the wiki documentation to Italian, but someone could also create a webpage for the Incubator site, or sort alphabetically the People page, organize the reference documentation, or simply change the layout of the wiki to make it more accessibile and good looking. These are tasks that anyone could take in charge, but that are somehow important anyway. Absolutely!!! This is invaluable to the project! --Steve
Re: Terminology etc
On Thu, 2005-05-26 at 15:43 -0400, Geir Magnusson Jr. wrote: This isn't an immediate goal, but certainly would be something to keep in mind when architecting ? I mean, you can certainly see VMs being incorporated into the OS? Hmmm. Interesting... You are talking about a VM becoming part of the kernel? java.ko? So you can now distribute your hardware drivers as Java classes? But why stop there. How about making the whole operating system a VM? Sure you need some extensions to handle interrupts, DMA, hardware registers and the like. But Java programs will also start so much quicker. Making this a real time system could be interesting. :) Although obviously not a goal for Harmony, I wouldn't be surprised if someone is already researching the concept. - Matthew
Re: Work items
On May 27, 2005, at 6:09 PM, Raffaele Castagno wrote: 2005/5/27, Steve Blackburn [EMAIL PROTECTED]: Hi all, I imagine I'm not alone in thinking that there are a great many concrete things people can be working on right away, even while discussion on key design issues continues. It would be good to have a My 2 (euro)cents: There's not only the need to start implementing code. I'm (slowly) translating some of the wiki documentation to Italian, but someone could also create a webpage for the Incubator site, We'll put up a webpage to track incubator status, but we also need to decide on how we want to do the project website. Ideas? I've used simple xdoc, maven and forrest, and I think that simple xdoc is the most straightforward. or sort alphabetically the People page, organize the reference documentation, or simply change the layout of the wiki to make it more accessibile and good looking. These are tasks that anyone could take in charge, but that are somehow important anyway. indeed. thanks geir Best Regards Raffaele -- If you want a GMail account, send me an E-Mail. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Terminology etc
On May 27, 2005, at 6:12 PM, Matthew French wrote: On Thu, 2005-05-26 at 15:43 -0400, Geir Magnusson Jr. wrote: This isn't an immediate goal, but certainly would be something to keep in mind when architecting ? I mean, you can certainly see VMs being incorporated into the OS? Hmmm. Interesting... You are talking about a VM becoming part of the kernel? java.ko? So you can now distribute your hardware drivers as Java classes? I was thinking being able to run java programs as first class citizens in the OS. Never thought about Java for device drivers... But why stop there. How about making the whole operating system a VM? Sure you need some extensions to handle interrupts, DMA, hardware registers and the like. But Java programs will also start so much quicker. Making this a real time system could be interesting. :) Although obviously not a goal for Harmony, I wouldn't be surprised if someone is already researching the concept. They are certainly out there... one has been mentioned here... I forget what it is called... geir - Matthew -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] VM/Classlibrary interface
Geir Magnusson Jr. wrote: (Tomcat : I'd bet they fixed that (or will fix...)) It doesn't seem so. The SSL code has been in Tomcat versions 4.1.x to 5.5.9 and I just saw that also the LDAP code in Tomcat 5.5.9 uses classes in com.sun. Well, can't the VM just prevent non-kernel code from using them? Maybe overhead too high? How do you distinguish kernel code and non-kernel code? From the VM point of view, the classes in the java(x).* packages do not differ from user code classes and it is also possible to bootstrap the VM and replace java(x).* classes with own implementations. Been there, done that. Tor
Re: [arch] VM/Classlibrary interface
On May 27, 2005, at 6:25 PM, Tor-Einar Jarnbjo wrote: Geir Magnusson Jr. wrote: (Tomcat : I'd bet they fixed that (or will fix...)) It doesn't seem so. The SSL code has been in Tomcat versions 4.1.x to 5.5.9 and I just saw that also the LDAP code in Tomcat 5.5.9 uses classes in com.sun. Amazing. Jetty was doing the same thing until we asked them to fix it. They did, and all is well now. Well, can't the VM just prevent non-kernel code from using them? Maybe overhead too high? How do you distinguish kernel code and non-kernel code? From the VM point of view, the classes in the java(x).* packages do not differ from user code classes and it is also possible to bootstrap the VM and replace java(x).* classes with own implementations. Been there, done that. I meant execution context. Is there a clear boundary between code thats executing in the context of the VM and code that's executing in the context of the 'user' app? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Harmony Meetup at JavaOne (Was Re: JavaONE - anyone going? Last day for early bird reg.)
I would be interested in dropping by, but don't know how much I can contribute in terms of useful ideas and experience :) I'm just a lowly Java architect/developer working on applications here and there. That and some C experience with a strong interest in helping out on this VM project. Daytime on Sunday before the conference works for me, but I'm open otherwise. Thanks! Dmitry. Geir Magnusson Jr. wrote: Speaking of JavaOne : Shall we plan a Harmony get-together and drink beer^H^H^H^H^H^H^H^H discuss architecture? It can be before, during or after JavaOne... geir On May 27, 2005, at 3:02 PM, Dmitry Serebrennikov wrote: Sorry, this is a bit off-topic. Is anyone else planning to go to the JavaONE conference (June 25-30 San Francisco, CA)? By the way, today is the last day to register with the early bird discount. Regards Dmitry
Re: [arch] VM/Classlibrary interface
On Fri, 27 May 2005, Geir Magnusson Jr. wrote:
(Tomcat : I'd bet they fixed that (or will fix...))
Well, can't the VM just prevent non-kernel code from using them? Maybe
overhead too high?
You could play class loader games, however those could be
circumvented by just another customized class loader.
Doug Lea discussed the general issue in a message to this mailing
list already. IMHO the problem is, that you can make a class only
public, package-private or visible for a single class (e.g.
private static). Some finer grained controls might be usefil like
exporting a class to a particular package.
Doug referenced the paper
http://www.research.ibm.com/people/d/dgrove/papers/oopsla03.html
that discuesses a number of the issues involved and proposes a
solution based on a module concept. He referenced this page
http://www.cs.utah.edu/flux too.
He mentioned also that such features are planned for Java version 7.
Another approach right now might be to use metadata in the following way:
@Export(java.lang.*) public class VMObject {...
The bytecode linker could interpret the @Export annotation as an
override of public during resolution and prevent classes outside
of java.lang.* from linking VMObject by throwing a subclass
instance of IllegalAccessError. The compiler used should also be aware
of the @Export annotation.
If the @Export annotation is not supported by the VM or the
compiler a public class can still be linked from outside the
package, a package-private class will not. This way the author of
the class has even control over the failure mode.
Assuming that Harmony will support annotations, it shouldn't be to
complex to implement the feature, which doesn't require some
hard-coded magic or some new kind of configuration files.
Uli
Re: [arch] VM/Classlibrary interface
Geir Magnusson Jr. wrote: I meant execution context. Is there a clear boundary between code thats executing in the context of the VM and code that's executing in the context of the 'user' app? Usually not, but it might be possible to emulate something similar using several classloaders or implement the necessary mechanisms in the default classloader. One similar example can be taken from Java applets. They are of course not allowed to load and execute native code, as the VM can't enforce any privilege checks on what the native code is doing, still though, the applet must of course be allowed to indirectly execute native code through the standard API, e.g. to gain allowed network access. In this case, the applet classes are loaded by a restricted classloader, which does not allow direct access to native code, while the standard API classes are loaded by a privileged classloader, which grants all privileges on kernel level and relies on the implementation of the classes to enforce the necessary security checks. All this magic is however implemented using the mechanisms in the security manager and since an application must be allowed to use its own security manager, I don't see how it could be possible to prevent an application to break through such a protection either. Tor
Re: Work items
Latelly I've been playing with a toy JITer written in java (like jikesRVM baseline compiler) for x86 on windows. It works on a single pass and perform no optimizations at all, but the generated code is correct. The parts missing are the hard ones, object allocation and exception handling. Next time I'm going to implement something in line with jikesRVM`s vmmagic (more like stealing the whole concept) and maybe give a try with self-hosting. Steve, do you have some pointers about how jikesRVM or OVM does that? Rodrigo On 5/27/05, Steve Blackburn [EMAIL PROTECTED] wrote: Hi all, . prototype backend generator [prototype] Explore Ertl Gregg's work to develop a backend generator which leverages the portability of gcj to automatically generate backends for a simple JIT. The semantics of Java bytecodes are expressed using Java code, and then gcj is used to generate code fragments which are then captured for use by a simple JIT (Ertl Gregg used C and gcc, but with vmmagic support, Java and gcj would be nicer). See also http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mbox/[EMAIL PROTECTED]
Re: [arch] VM/Classlibrary interface
On 5/27/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On May 27, 2005, at 4:34 PM, Rodrigo Kumpera wrote: We should provide wrappers to classes for the sake of compatibility. Are there any legal problems with doing so? Why would we do that? We don't want to encourage such misbehavior...? geir There are two kinds of compatibility: by specification, the TCK buy us that; and pragmatic, and this is having software just work. Look around for all FOSS that are made to be an alternative to proprietary software, they all have kludges to be implementation compatible to the non-free counterpart. Last time I checked, no one, nether me or you, is developing code agains the TCK, but to a real JVM. And as hard as we may try, sometimes we end with software that depends on unspecified behavior. So it's better try to be bug compatible too.
Re: Work items
Tom Tromey wrote: Don't forget hacking on Classpath :-) Gosh no!! ;-) Obviously that should very much be on the work list. I suspect that for the work items at peer projects (classpath, mmtk, gcj, jikesrvm etc), that when possible the worklist just provide links to work items maintained by the associated project. Dave Grove has started constructing a list for the opt compiler, so once that's available we can remove the jikes rvm items and replace them with a link to the jikes rvm list. Steve . bytecode optimization [reserach] Something interesting sort of related to this area is vmgen. This seems like a nice way to build interpreters. Thanks for pointing that out! This is actually the same work as the first item on the list I sent out (prototype backend generator), only I was unaware of vmgen (Anton Ertl). I only knew about the paper with Gregg. vmgen appears to be GPLed. It looks interesting. http://www.complang.tuwien.ac.at/anton/vmgen/ http://www.complang.tuwien.ac.at/anton/ http://www.complang.tuwien.ac.at/projects/backends.html --Steve
