Re: [Legal] Requirements for Committers
On Wed, 8 Jun 2005, Dalibor Topic wrote: Geir Magnusson Jr. wrote: a) Having a copy of src.jar on a computer as long as you never viewed or edited the contents of the file. At least in the Linux versions 1.5.0_03 and 1.4.2_05 of the J2SE SDK there is no file src.jar. However there seems to be a file src.zip. Maybe it is a good sign, that most folks here don't actually know, how the file is named. Uli
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Sun, 5 Jun 2005, Geir Magnusson Jr. wrote: Also from time to time the VM interface has to be extended for new VMs, which have different needs. This is one reason that the interface isn't yet stable, even for 1.4. It would be interesting to know why and how it was extended - there's something to learn there. I'm also interested in getting some input from the commercial VM developers. The new features in 1.5 varargs, enums, annotations, and generics required additions to the class file format. More changes appear to be introduced to improve debugging (type infos about local variables). Tom Tromey has already found a link to an updated class file description: http://java.sun.com/docs/books/vmspec/2nd-edition/UpdatedClassFileFormat.pdf Here is a short and probably incomplete overview over the changes: varargs:ACC_VARARGS, ACC_BRIDGE (?) enums: ACC_ENUM annotations:ACC_ANNOTATION New attributes: EnclosingMethod, Signature (for generics), LocalVariableTypeTable, RuntimeVisibleAnnotations, RuntimeInvisibleAnnotations, RumtimeVisibleParameterAnnotations, RumtimeInvisibleParameterAnnotations, Uli
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: Terminology etc
Steve, this clarification of terminology helped me a lot to understand your approach better. As Java-in-C camper I can even see now the advantages in the approach. But just let me add my 2 cents of pretty wild ideas. Having read your MMTk papers, it appears to me that the required JAVA extensions look a little bit like parts of P/Invoke* of Microsoft's Common Language Runtime. (P/Invoke is a convenient way to call C functions in the VM without the need to program glue code in C. It must allow memory access over pointers via a Marshal class. Security fanatics should recognize, that such a class can be implemented for Java using JNI.) A comparable mechanism in Harmony would not only be useful for the Java garbage collector but also the OS interface. Maybe it would be possible to extend the boot image approach to some kind of cached images of Java classes and packages, This would require some ELF-like format for compiled Java code. Such a feature might reduce the startup times of applications like Eclipse a lot. If I'm not misinformed the gcj developers want to build something like this. IMHO a self-hosting VM has the advantage, that performance is under your own control. Code in C will always depend on the optimizations provided by the C compiler being used. Additionally all the debugging/profiling/management code can be written in Java and can use the large Java class library. The class library itself provides also the platform abstractions, which will be needed to support Windows and POSIX platforms with the same code. But it might still be that C-implemented modules (particularly the GC) are faster than their Java-implemented counterparts, because they ignore array-index-checking, don't need write barriers and interface calls, etc... One could follow the strategy, that modules must support Java interfaces but might be implemented in C. This strategy would bring us back to an design that doesn't mandate which language has to be used to implement a certain module. Uli
