Re: Cross plaform issues
Garrett Rooney wrote: access to scalable IO facilities (IOCP, epoll, kqueue, etc...) See the apr_pool API, which uses epoll, kqueue, etc on the backend if available. Now that my message finally makes it through the ASF mail system, I notice that typo... That should be apr_poll, not apr_pool ;-) -garrett
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
I think everyone shall read this first http://jikesrvm.sourceforge.net/info/overview.shtml . If performance will not be a problem then the product based on Jikes can be an alternative to Sun`s JVM. Personally Java is the language I feel myself most confortable and I think most of the people here feels the same. This is also an advantage which will shorten the development time if Java language is used. Ozgur Akan Geir Magnusson Jr. wrote: We've been talking about two threads of discussion, one working with a C/C++ based VM, one w/ Java. Here's a Java one for discussion (just want to focus threads...) geir
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Geir Magnusson Jr. wrote: On May 18, 2005, at 2:18 AM, Ozgur Akan wrote: I think everyone shall read this first http:// jikesrvm.sourceforge.net/info/overview.shtml . If performance will not be a problem then the product based on Jikes can be an alternative to Sun`s JVM. Can we put the performance question to rest once and for all? The rules of programming are transitory; only Tao is eternal. Therefore you must contemplate Tao before you receive enlightenment. But how will I know when I have received enlightenment? asked the novice. Your program will then run correctly, replied the master. So I agree wit Geir, for an enlightenment, the first rule is to run it correctly. Speaking on performance before a single line of code in not Tao! Regards, Mladen.
Re: Against using Java to implement Java
There is an old document describing a JIT interface though ORP should be more advanced, for example, as having GC interface. The JIT Compiler Interface Specification http://java.sun.com/docs/jit_interface.html Sun's Classic VM, which was a reference VM, of JDK 1.0.2 and 1.1.X implements this interface and it was modified a bit for J2SDK 1.2. There were actually multiple JIT compilers based on this JIT interface including Symantec JIT, OpenJIT, shuJIT and TYA. This interface is not enough to support advanced optimizations including adaptive compilation, which today's Sun's and IBM's runtimes do. Adaptive compilation needs cooperation by an interpreter (or a baseline compiler) and I am not sure whether it can be factored out from the JVM core. From: Tom Tromey [EMAIL PROTECTED] David Maybe a concrete example would help. Let's say you have a GC module David written in C. One of it's API calls is to allocate a new object. How David is your JIT module going to produce code to use that API? Via a C David function pointer? Yes. One way is to mandate link- or compile-time pluggability only. Then this can be done by name. Your JIT just references 'harmony_allocate_object' in its source and uses this pointer in the code it generates. The other way is to have the JIT call some central function to get a pointer to the allocator function (or functions, in libgcj it turned out to be useful to have several). This only needs to be done once, at startup. For folks interested in pluggability, I advise downloading a copy of ORP and reading through it. ORP already solved these problems in a fairly reasonable way. Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
Re: Developing Harmony
Stefano Mazzocchi wrote: Bryce Leo wrote: Now don't go too crazy for my suggesting this, but why not pascal? If we're considering C as it is this really isn't a terrible suggestion. I know it's fallen out of favor with most of you guys but it compiles quickly and supports a good number of operating systems and types of hardware, like arm and AMD64 (referencing Free Pascal that is). I'm betting that you guys won't like it but I think the option should be listed. Opinions? Can we stop this language madness thing, please? We are *NOT* going to be writing a JVM from scratch, we are open for donations. Says who? If people here want to write a VM, are you going to stop them? I hope you wouldn't even try. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Cross plaform issues
Rodrigo Kumpera wrote: A quick look at APR reveal that it doesn´t provide all OS abstraction that a JVM needs. I tend to disagree with you. The only thing the APR doesn't offer is GUI abstraction. There are no functions to mark pages as executable, Like Garrett said, those functionality was not needed. Not sure if it can be added in a portable fashion to APR or if this should be kept as separate lib. scalable IO facilities (IOCP, epoll, kqueue, etc...) or workarounds for small diferences on syscalls or libC implementation. Take a look at: jakarta-tomcat-connectors/jni It uses APR in a way the Sun does for it's low level I/O. On windows, APR currently uses select, but we are discussing to use the IOCP for quite some time. On other platforms, either poll, epoll or kqueue are used. Regards, Mladen.
RE: Introduction, and a question
What you are suggesting would be a definite must-have if we want to try for a
distributable JVM.
I will read up on the links supplied and get back on this.
Regards
~s
-Original Message-
From: Brad Cox [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 18, 2005 4:40 AM
To: harmony-dev@incubator.apache.org
Subject: Re: Introduction, and a question
My ambitions were far more modest, cutting down on startup overhead in
apps coded like this
static Foo aFoo = new Foo();
public void main(String args[])
{
checkpoint();
// on with the show
}
But JVM/instance persistence would certainly be nice (if hard to provide
reliably).
Subramanian, Sundar wrote:
My original intention of having a snapshot was not so much as to have a quick
restart but to be able to migrate apps a la distributed JVM efforts
(http://djvm.anu.edu.au/) as Steve has mentioned in this thread earlier.
As you say I guess persistence along with machine specific JIT code might be a
hard problem to solve. Sun's efforts in this direction is a good partial
solution. But taking care of the environmental parameters like open JDBC
connections etc would also have to be implemented if any movement in this
direction is to be expected.
Regards
~sundar
-Original Message-
From: Nick Lothian [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 17, 2005 10:36 AM
To: harmony-dev@incubator.apache.org
Subject: RE: Introduction, and a question
El lun, 16-05-2005 a las 16:08 +0530, Subramanian, Sundar escribió:
(...)
I guess what Brad is asking is for a snapshot of the state of JVM.
This
would be really useful to migrate stuff from one environment to
another preserving the underlying state.
I have mixed feelings about having a save image __a la__
Smalltalk, if this is what you are meaning. While delivering
an image looks tempting, state gets corrupt in unpredictable
ways, and having ways to track changes becomes a nightmare.
The Smalltalk community has worked hard in this (hard)
problem, but I'm still not sure if it would make sense in the
java world. Java is a system-oriented language, and the
ability to save the whole VM state and recover from this
saved image would bring additional constraints to the Virtual
Machine implementation. For instance, machine specific JIT
code should be invalidated upon save, negating a substantial
part of the advantages of a saved image (faster startup).
This said, if VM implementors out there find easy ways to
meet these constraints w/o burdening runtime or memory
requirements, it could be an area for experimenting.
This looks like it would be related to the stuff Sun has done with class data
sharing in the 1.5 JVMs:
When the JRE is installed on 32-bit platforms using the Sun provided
installer, the installer loads a set of classes from the system jar file into
a private internal representation, and dumps that representation to a file,
called a shared archive. Class data sharing is not supported in Microsoft
Windows 95/98/ME. If the Sun JRE installer is not being used, this can be done
manually, as explained below. During subsequent JVM invocations, the shared
archive is memory-mapped in, saving the cost of loading those classes and
allowing much of the JVM's metadata for these classes to be shared among
multiple JVM processes. [1]
This isn't quite the same as saving JIT'ed code, but it sounds like it is
saving the pre-parsed and verified class files.
Nick
[1] http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html
IMPORTANT: This e-mail, including any attachments, may contain private or
confidential information. If you think you may not be the intended recipient,
or if you have received this e-mail in error, please contact the sender
immediately and delete all copies of this e-mail. If you are not the intended
recipient, you must not reproduce any part of this e-mail or disclose its
contents to any other party.
This email represents the views of the individual sender, which do not
necessarily reflect those of education.au limited except where the sender
expressly states otherwise.
It is your responsibility to scan this email and any files transmitted with it
for viruses or any other defects.
education.au limited will not be liable for any loss, damage or consequence
caused directly or indirectly by this email.
Re: Introduction, and a question
On Wed, May 18, 2005 at 10:40:41AM +0900, [EMAIL PROTECTED] wrote: Newbie question: What is to stop us from caching JITed code? .NET/ mono does this as far as I know? We can do it even in the forthcoming Harmony runtime. On the other hand, an apparent drawback is disk consumption. Generally, JITted native code takes 3 times or more as much as bytecode takes. I think Parrot can do this. Parrot might not be an obvious VM to throw into the ring but I think it should be given serious consideration. To have a common VM across two of the most commonly used languages would be politically very appealing from an open source perspective. It also has clear technical merits in that there'd only be one VM, so on a modern os that would just be the one executable image in memory. Parrot also has .NET like qualities in that multiple languages can be used to build your app since they all compile down to the same bytecode. I think it's definitely worth taking a look at. Leon Brocard write a Java-Parrot bytecode converted quite early on in the life of Parrot. It might not be much work to bring it up to speed. -- Paul Richards
Re: Developing Harmony
Tom Tromey wrote: Ben == Ben Laurie [EMAIL PROTECTED] writes: I'm pretty sure we want a framework in C/C++, whatever components are developed in. Umm. Why? Ben So it can run everywhere. FWIW, writing a VM in java doesn't make this harder per se. In fact, in a way it is easier as you are already writing a compiler, so you don't need another one for your target. The way JikesRVM works, as I understand it, is that you bootstrap it on some other VM. This makes an image, which is just plain old executable code, which is the actual VM. Then you can run your java programs using this image. This has to be a VM that produces native code, right? In any case, here I am with a platform that currently has no VM, but does have a C compiler. What do I do? In your world, I first port some other VM, then port Harmony. I don't understand why this is not harder? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Intro to Classpath
And i ll add one thing more! when u get it up, you will see many more alternative implementations will be sumbited to harmony, so let me dream for that :) and it is what we called power of OSS. i mean actually in future we can then replace the implementation of such API's which are based on Service Provider interfaces could be avialable as alternative bases. On 5/17/05, Sven de Marothy [EMAIL PROTECTED] wrote: On Tue, 2005-05-17 at 11:46 -0300, Rodrigo Kumpera wrote: I'm wondering, some parts of the JDK seens to be product features and not a standard. For examples, the sound system should use arts, esd or alsa (I believe Sun support the last 2). The printing system should support cups, lprng or both? Such matters are of course not part of the Java spec and are completely up to the implementation. There would be no point in having a Java API for these things if a certain underlying API was required. The same goes for the crypto algorithms on the pack. No. Although parts of crypto (like so much of the newer APIs) is behind a Service Provider Interface, you still want to provide everything Sun does, because applications will expect those algorithms to be available. While I'm not sure this is required for strict-TCK compatibility, it is certainly a compatibility issue for real-world apps. /Sven -- Usman Bashir Certified IBM XML Solution Developer Certified UML Developer Brainbench Certified Internet Perfessional[advance](BCIP) Brainbench Certified Java Perfessional (BCJP) Brainbench Certified .NET Perfessional Brainbench Ceritified C++ Perfessional (BCCP) Software engineer IT24 Faculty Member Operation Badar Lahore
Re: Developing Harmony
Mark Brooks wrote: C++, just C++, is a recipe for trouble. Most projects that use it define a subset to make development a less painfull talk. Usually operator overloading, templates and virtual inheritance are discarded. Rodrigo Agreed. If the decision is to go with C++, it will need to be a subset of C++ for sanity. I still think that, at most, a minimal C kernel and the rest in Java is a better option. As I said before, don't assume we're all Java fans here. I'm far more familiar with C++ than I am with Java. snip Ben. If you aren't a Java fan, why are you interested in Harmony? Or am I misinterpreting what you meant there? Surely I don't have to rate Java as the best language for everything in order to be interested in Harmony? I don't think HTTP or SSL are the best ways to do things, either, but I've spent an enormous amount of time on both of them. There's all sorts of reasons I'm interested in Harmony. a) I recently tried Eclipse, and discovered it removed a major source of Java irritation (excessive amounts of redundant typing). In fact, I love Eclipse. If only I could get it working on FreeBSD :-) b) I'm interested in capability-secure versions of popular languages. Java is a popular language. c) I'm interested in security generally. d) I'm interested in compilers. e) I'm interested in VMs. f) I'm interested in modularity. g) I'm interested in portability. So, in summary, my interest is in the nuts and bolts of Harmony far more than in writing things in Java. That said, I do write things in Java :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
It seems good geir ! and also seems to be following what we planned for harmony, and it could be a good starting point for us, later on we can make required changes as we moves on, and it will also help to impatients to work on and see some thing written down from the air to papers :) On 5/18/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: For those that want meaningful subjects lines, here it is and for those that are waiting for an architecture discussion - here it is. Here's the first of the offered VMs. (I've privately mailed Tom van Dijck about mudGE so we can look at something else) I've downloaded and will begin playing with today. Archie, can you give a brief overview of structure? Can we get some discussion about this from those that know about about VM architecture? geir On May 16, 2005, at 3:22 PM, Archie Cobbs wrote: As mentioned before, and/all of JC [1] is available and I'll be happy to relicense it. All of the code was written by me (though I didn't invent all of the algorithms of course). Some bits I can think of that may be useful, roughly ordered from smaller and more likely to larger and less likely... - Splay tree implementation (splay.c) - String/UTF-8 functions (string.c, utf.c) - ZIP file reader (zip.c) - Class file parser (cf_parse.c) - Native local and global reference code (native_ref.c) - Per-classloader memory allocator (cl_alloc.c) - SableVM thin lock algorithm (lock.c) - Native library loader (native_lib.c) - VM Bootstrap code (vm.c, bootstrap.c) - JNI support (jni_invoke.c, jni_native.c) - Reflection support (reflect.c) - Dynamic invoker (invoke.c) - Threading support (thread.c) - Heap structure and garbage collector (heap.c, gc_root.c, gc_scan.c). - Bytecode interpreter (interp.c) - Class loading, derivation, and resolution (load2.c, derive2.c, resolve.c) There's also an ELF object loader and DWARF2 parser if you need those :-) -Archie [1] http://jcvm.sourceforge.net/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Usman Bashir Certified IBM XML Solution Developer Certified UML Developer Brainbench Certified Internet Perfessional[advance](BCIP) Brainbench Certified Java Perfessional (BCJP) Brainbench Certified .NET Perfessional Brainbench Ceritified C++ Perfessional (BCCP) Software engineer IT24 Faculty Member Operation Badar Lahore
Re: Developing Harmony
Ben Laurie wrote: Mark Brooks wrote: C++, just C++, is a recipe for trouble. Most projects that use it define a subset to make development a less painfull talk. Usually operator overloading, templates and virtual inheritance are discarded. Rodrigo Agreed. If the decision is to go with C++, it will need to be a subset of C++ for sanity. I still think that, at most, a minimal C kernel and the rest in Java is a better option. As I said before, don't assume we're all Java fans here. I'm far more familiar with C++ than I am with Java. snip Ben. If you aren't a Java fan, why are you interested in Harmony? Or am I misinterpreting what you meant there? Surely I don't have to rate Java as the best language for everything in order to be interested in Harmony? I don't think HTTP or SSL are the best ways to do things, either, but I've spent an enormous amount of time on both of them. There's all sorts of reasons I'm interested in Harmony. a) I recently tried Eclipse, and discovered it removed a major source of Java irritation (excessive amounts of redundant typing). In fact, I love Eclipse. If only I could get it working on FreeBSD :-) Since the java/eclipse port is working fine, I assume you want to use it with another JVM than java/jdk14? If so, and since this is something I was contemplating these days, under which JVM would you want to use it? Kaffe? GCJ? JC? JikesRVM? -- Panagiotis Astithas EBS, Electronic Business Systems Ltd. 18 Evgenidou Street, 115 25, Athens GREECE Phone: +30 210 674 7631 Fax: +30 210 674 7601 http://www.ebs.gr
Re: Against using Java to implement Java (Was: Java)
I think it's too slow to have the overhead of a function call for every object allocation. This is the cost of modularization. I doubt any of the mainstream JVMs you are competing with do this. Cheers, Dave On 17 May 2005 18:27:42 -0600, Tom Tromey [EMAIL PROTECTED] wrote: David == David Griffiths [EMAIL PROTECTED] writes: David Maybe a concrete example would help. Let's say you have a GC module David written in C. One of it's API calls is to allocate a new object. How David is your JIT module going to produce code to use that API? Via a C David function pointer? Yes. One way is to mandate link- or compile-time pluggability only. Then this can be done by name. Your JIT just references 'harmony_allocate_object' in its source and uses this pointer in the code it generates. The other way is to have the JIT call some central function to get a pointer to the allocator function (or functions, in libgcj it turned out to be useful to have several). This only needs to be done once, at startup. For folks interested in pluggability, I advise downloading a copy of ORP and reading through it. ORP already solved these problems in a fairly reasonable way. Tom
RE: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
Hi, I've had some time today to cleanup and make the VM a standalone thing, since it pretty much was designed to work together with our Game Engine. Full game engine (forgive me my commercial plug on the list) can be licensed as well. It's been used for Red Ninja: End of Honor and several other games. Please bare in mind that in our Game Engine we use java as a scripting language, NOT as our main development language, and thus use a very restricted and small runtime. We do NOT fully implement the J2SE API, nor do we have any intensions to do so. Anyway, the standalone VM is available on www.mudge.nl/java/ It is distributed under a somewhat modified version of the ZLIB license, so for use as reference or as a base for harmony there should be no problem whatsoever. If there are any problems with the license please let me know so we can negotiate, all I want is to be notified about what happens to my code and who uses it. Tom van Dijck mudGE Entertainment -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 6:35 AM To: harmony-dev@incubator.apache.org Subject: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/ For those that want meaningful subjects lines, here it is and for those that are waiting for an architecture discussion - here it is. Here's the first of the offered VMs. (I've privately mailed Tom van Dijck about mudGE so we can look at something else) I've downloaded and will begin playing with today. Archie, can you give a brief overview of structure? Can we get some discussion about this from those that know about about VM architecture? geir On May 16, 2005, at 3:22 PM, Archie Cobbs wrote: As mentioned before, and/all of JC [1] is available and I'll be happy to relicense it. All of the code was written by me (though I didn't invent all of the algorithms of course). Some bits I can think of that may be useful, roughly ordered from smaller and more likely to larger and less likely... - Splay tree implementation (splay.c) - String/UTF-8 functions (string.c, utf.c) - ZIP file reader (zip.c) - Class file parser (cf_parse.c) - Native local and global reference code (native_ref.c) - Per-classloader memory allocator (cl_alloc.c) - SableVM thin lock algorithm (lock.c) - Native library loader (native_lib.c) - VM Bootstrap code (vm.c, bootstrap.c) - JNI support (jni_invoke.c, jni_native.c) - Reflection support (reflect.c) - Dynamic invoker (invoke.c) - Threading support (thread.c) - Heap structure and garbage collector (heap.c, gc_root.c, gc_scan.c). - Bytecode interpreter (interp.c) - Class loading, derivation, and resolution (load2.c, derive2.c, resolve.c) There's also an ELF object loader and DWARF2 parser if you need those :-) -Archie [1] http://jcvm.sourceforge.net/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Against using Java to implement Java
Well that's the theory but I think you'll find in practice that real JITs cheat and inline object allocation using their knowledge of the GC internals. And there is no way that a JIT is going to implement synchronized methods by doing a monitorEnter function call! Dave On 5/18/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: There is an old document describing a JIT interface though ORP should be more advanced, for example, as having GC interface. The JIT Compiler Interface Specification http://java.sun.com/docs/jit_interface.html Sun's Classic VM, which was a reference VM, of JDK 1.0.2 and 1.1.X implements this interface and it was modified a bit for J2SDK 1.2. There were actually multiple JIT compilers based on this JIT interface including Symantec JIT, OpenJIT, shuJIT and TYA. This interface is not enough to support advanced optimizations including adaptive compilation, which today's Sun's and IBM's runtimes do. Adaptive compilation needs cooperation by an interpreter (or a baseline compiler) and I am not sure whether it can be factored out from the JVM core. From: Tom Tromey [EMAIL PROTECTED] David Maybe a concrete example would help. Let's say you have a GC module David written in C. One of it's API calls is to allocate a new object. How David is your JIT module going to produce code to use that API? Via a C David function pointer? Yes. One way is to mandate link- or compile-time pluggability only. Then this can be done by name. Your JIT just references 'harmony_allocate_object' in its source and uses this pointer in the code it generates. The other way is to have the JIT call some central function to get a pointer to the allocator function (or functions, in libgcj it turned out to be useful to have several). This only needs to be done once, at startup. For folks interested in pluggability, I advise downloading a copy of ORP and reading through it. ORP already solved these problems in a fairly reasonable way. Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
RE: GCJ ABI (Re: Trampoline)
Yeah John, that will be great Thanks ~sundar -Original Message- From: John Wilson [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 4:25 PM To: harmony-dev@incubator.apache.org Subject: Re: GCJ ABI (Re: Trampoline) On 18 May 2005, at 11:44, Subramanian, Sundar wrote: I think the paper is behind a protected ftp which requires login and password. I am unable to get to it. It's Ok from here - would you like me to email you a copy? John Wilson The Wilson Partnership http://www.wilson.co.uk
Re: Developing Harmony
We shouldl design in such a way that , we should get some interfacing/bootstrapping issues in C (can be C++ but i think due to its direct linking to natives C will be prefered i can present more argo over it though ;) ) and then come back to java again until we feel ctuck some where (though what my experiance suggest and i have looked it into the presented projects, we can get rid of those concerete walls if any one we have to have face in the running of time ) so what i am saying i m summing it up write in java using C. java provides us all those features which we need to go to this road , from the management, maintianbility and other stuffs (i m not writting SE book though ha ha ha) u all knows better. so what u think comment ? On 5/18/05, Panagiotis Astithas [EMAIL PROTECTED] wrote: Ben Laurie wrote: Mark Brooks wrote: C++, just C++, is a recipe for trouble. Most projects that use it define a subset to make development a less painfull talk. Usually operator overloading, templates and virtual inheritance are discarded. Rodrigo Agreed. If the decision is to go with C++, it will need to be a subset of C++ for sanity. I still think that, at most, a minimal C kernel and the rest in Java is a better option. As I said before, don't assume we're all Java fans here. I'm far more familiar with C++ than I am with Java. snip Ben. If you aren't a Java fan, why are you interested in Harmony? Or am I misinterpreting what you meant there? Surely I don't have to rate Java as the best language for everything in order to be interested in Harmony? I don't think HTTP or SSL are the best ways to do things, either, but I've spent an enormous amount of time on both of them. There's all sorts of reasons I'm interested in Harmony. a) I recently tried Eclipse, and discovered it removed a major source of Java irritation (excessive amounts of redundant typing). In fact, I love Eclipse. If only I could get it working on FreeBSD :-) Since the java/eclipse port is working fine, I assume you want to use it with another JVM than java/jdk14? If so, and since this is something I was contemplating these days, under which JVM would you want to use it? Kaffe? GCJ? JC? JikesRVM? -- Panagiotis Astithas EBS, Electronic Business Systems Ltd. 18 Evgenidou Street, 115 25, Athens GREECE Phone: +30 210 674 7631 Fax: +30 210 674 7601 http://www.ebs.gr -- Usman Bashir Certified IBM XML Solution Developer Certified UML Developer Brainbench Certified Internet Perfessional[advance](BCIP) Brainbench Certified Java Perfessional (BCJP) Brainbench Certified .NET Perfessional Brainbench Ceritified C++ Perfessional (BCCP) Software engineer IT24 Faculty Member Operation Badar Lahore
Re: Digest list?
Send e-mail to [EMAIL PROTECTED] (subject and body don't really matter) for info on how to set your subscription into digest mode. Cheers, Leo On 18-05-2005 12:29, Simon Cooper [EMAIL PROTECTED] wrote: Is there any chance of setting up a digest of the mailing list? I'm interested in the project but wont really be contributing for a month or so, and atm im having trouble wading through all the emails Simon Cooper
Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
Tom, Thanks! =) Doesn't compile on my powerbook, but it doesn't look like it would be *too* hard to get working (but I've no real coding experience (CS student) and have only read the win32/* code) Will it? --Royce On 18/05/2005, at 4:27 PM, Tom van Dijck wrote: Hi, I've had some time today to cleanup and make the VM a standalone thing, since it pretty much was designed to work together with our Game Engine. Full game engine (forgive me my commercial plug on the list) can be licensed as well. It's been used for Red Ninja: End of Honor and several other games. Please bare in mind that in our Game Engine we use java as a scripting language, NOT as our main development language, and thus use a very restricted and small runtime. We do NOT fully implement the J2SE API, nor do we have any intensions to do so. Anyway, the standalone VM is available on www.mudge.nl/java/ It is distributed under a somewhat modified version of the ZLIB license, so for use as reference or as a base for harmony there should be no problem whatsoever. If there are any problems with the license please let me know so we can negotiate, all I want is to be notified about what happens to my code and who uses it. Tom van Dijck mudGE Entertainment -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 6:35 AM To: harmony-dev@incubator.apache.org Subject: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/ For those that want meaningful subjects lines, here it is and for those that are waiting for an architecture discussion - here it is. Here's the first of the offered VMs. (I've privately mailed Tom van Dijck about mudGE so we can look at something else) I've downloaded and will begin playing with today. Archie, can you give a brief overview of structure? Can we get some discussion about this from those that know about about VM architecture? geir On May 16, 2005, at 3:22 PM, Archie Cobbs wrote: As mentioned before, and/all of JC [1] is available and I'll be happy to relicense it. All of the code was written by me (though I didn't invent all of the algorithms of course). Some bits I can think of that may be useful, roughly ordered from smaller and more likely to larger and less likely... - Splay tree implementation (splay.c) - String/UTF-8 functions (string.c, utf.c) - ZIP file reader (zip.c) - Class file parser (cf_parse.c) - Native local and global reference code (native_ref.c) - Per-classloader memory allocator (cl_alloc.c) - SableVM thin lock algorithm (lock.c) - Native library loader (native_lib.c) - VM Bootstrap code (vm.c, bootstrap.c) - JNI support (jni_invoke.c, jni_native.c) - Reflection support (reflect.c) - Dynamic invoker (invoke.c) - Threading support (thread.c) - Heap structure and garbage collector (heap.c, gc_root.c, gc_scan.c). - Bytecode interpreter (interp.c) - Class loading, derivation, and resolution (load2.c, derive2.c, resolve.c) There's also an ELF object loader and DWARF2 parser if you need those :-) -Archie [1] http://jcvm.sourceforge.net/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Against using Java to implement Java (Was: Java)
David Griffiths wrote: By having the JIT produce code to inline the object allocation using its knowledge of the GC internals. I'm not recommending this approach, just saying that this is how things tend to be done in practice. And if you want to compete on speed then you're going to have to address the issue. (This seems to be an area where Java in Java wins if I understand it right, ie you can have your modularity cake and eat it too). Well, inlining stuff sometimes makes things faster (though it sometimes doesn't). But I'd be seriously surprised if object allocation was simple enough to make it worthwhile. I do take the point, however, that using dispatch tables without embellishment does preclude inlining. It doesn't take me a huge leap to imagine including a function in the dispatch table that would do inlining instead of finding the appropriate function, though. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Developing Harmony
Paul Richards wrote: a) I recently tried Eclipse, and discovered it removed a major source of Java irritation (excessive amounts of redundant typing). In fact, I love Eclipse. If only I could get it working on FreeBSD :-) The FreeBSD Eclipse port just worked for me. Just goes to show that ports aren't as reliable as one might hope, then, coz it didn't work for me. Repeatedly. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Gosling on Harmony
At first I want to cite myself: Sun have given with OpenOffice.org the OpenSource-community a lot. But with Java, it looks a little bit diffrent. And the reason is, that Java _is_ already popular. So they see no need to make it more popular. [...] The idea behind it is clear: Letting a platform closed source or commercial (Java by Sun, Windows/.net by Microsoft) and give products which run on this platform away for free or OpenSource, to make the platform more public. For this here is a new article: http://software.newsforge.com/article.pl?sid=05/05/16/1358227from=rss It seems, that now Sun want to bring more and more parts of OOo2 to the Java-platform. Greatings theuserbl
Re: Gosling on Harmony
On 5/18/05, theUser BL [EMAIL PROTECTED] wrote: For this here is a new article: http://software.newsforge.com/article.pl?sid=05/05/16/1358227from=rss It seems, that now Sun want to bring more and more parts of OOo2 to the Java-platform. Greatings theuserbl how does this article says that Sun want to bring more and more parts of OOo2 to the Java-platform, quite the contrary, this will lead to less dependency on Sun's JVM and we will start to take other opensource JVM's more seriously
Re: Against using Java to implement Java (Was: Java)
On 5/18/05, David Griffiths [EMAIL PROTECTED] wrote: I think it's too slow to have the overhead of a function call for every object allocation. This is the cost of modularization. I doubt any of the mainstream JVMs you are competing with do this. Yes. I agree. A clean interface would have a function call for every object allocation. However if the allocation code itself is only a few lines of assemby, it can be inlined by the JIT. Using a moving GC, it is possible to get the allocation sequence down to a bump the pointer and a compare to see if you have run off the end of the allocation area. Cheers, Dave On 17 May 2005 18:27:42 -0600, Tom Tromey [EMAIL PROTECTED] wrote: David == David Griffiths [EMAIL PROTECTED] writes: David Maybe a concrete example would help. Let's say you have a GC module David written in C. One of it's API calls is to allocate a new object. How David is your JIT module going to produce code to use that API? Via a C David function pointer? Yes. One way is to mandate link- or compile-time pluggability only. Then this can be done by name. Your JIT just references 'harmony_allocate_object' in its source and uses this pointer in the code it generates. The other way is to have the JIT call some central function to get a pointer to the allocator function (or functions, in libgcj it turned out to be useful to have several). This only needs to be done once, at startup. For folks interested in pluggability, I advise downloading a copy of ORP and reading through it. ORP already solved these problems in a fairly reasonable way. Tom
[arch] mudGE VM ( was Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/)
On May 18, 2005, at 4:27 AM, Tom van Dijck wrote: Hi, I've had some time today to cleanup and make the VM a standalone thing, since it pretty much was designed to work together with our Game Engine. Full game engine (forgive me my commercial plug on the list) can be licensed as well. It's been used for Red Ninja: End of Honor and several other games. Please bare in mind that in our Game Engine we use java as a scripting language, NOT as our main development language, and thus use a very restricted and small runtime. We do NOT fully implement the J2SE API, nor do we have any intensions to do so. Anyway, the standalone VM is available on www.mudge.nl/java/ It is distributed under a somewhat modified version of the ZLIB license, so for use as reference or as a base for harmony there should be no problem whatsoever. If there are any problems with the license please let me know so we can negotiate, all I want is to be notified about what happens to my code and who uses it. Tom, thanks for this. Comments? geir Tom van Dijck mudGE Entertainment -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 6:35 AM To: harmony-dev@incubator.apache.org Subject: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/ For those that want meaningful subjects lines, here it is and for those that are waiting for an architecture discussion - here it is. Here's the first of the offered VMs. (I've privately mailed Tom van Dijck about mudGE so we can look at something else) I've downloaded and will begin playing with today. Archie, can you give a brief overview of structure? Can we get some discussion about this from those that know about about VM architecture? geir On May 16, 2005, at 3:22 PM, Archie Cobbs wrote: As mentioned before, and/all of JC [1] is available and I'll be happy to relicense it. All of the code was written by me (though I didn't invent all of the algorithms of course). Some bits I can think of that may be useful, roughly ordered from smaller and more likely to larger and less likely... - Splay tree implementation (splay.c) - String/UTF-8 functions (string.c, utf.c) - ZIP file reader (zip.c) - Class file parser (cf_parse.c) - Native local and global reference code (native_ref.c) - Per-classloader memory allocator (cl_alloc.c) - SableVM thin lock algorithm (lock.c) - Native library loader (native_lib.c) - VM Bootstrap code (vm.c, bootstrap.c) - JNI support (jni_invoke.c, jni_native.c) - Reflection support (reflect.c) - Dynamic invoker (invoke.c) - Threading support (thread.c) - Heap structure and garbage collector (heap.c, gc_root.c, gc_scan.c). - Bytecode interpreter (interp.c) - Class loading, derivation, and resolution (load2.c, derive2.c, resolve.c) There's also an ELF object loader and DWARF2 parser if you need those :-) -Archie [1] http://jcvm.sourceforge.net/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Developing Harmony
But I guess the language will just depend on who donates a JVM. - Jónas Tryggvi Since somebody(s) are in conversation with FSF about Classpath, has anyone started a conversation with IBM research about Jikes RVM? Just a prelimininary sort of if we were interested what would be involved sort of thing. I think Geir has said that we are looking at jcvm as well since a list member has offered to donate it and place it under the apache license. _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: [arch] mudGE VM ( was Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/)
Tom, I tried to build and got this : BUILD FAILED /Users/geir/dev/apache/harmony/mudGE/mudJavaRuntime/build.xml:35: Execute failed: java.io.IOException: /Users/geir/dev/apache/harmony/ mudGE/mudJavaRuntime/JavaPack.exe: not found I asked privately, but might as well ask here for the benefit of others... geir On May 18, 2005, at 8:57 AM, Geir Magnusson Jr. wrote: On May 18, 2005, at 4:27 AM, Tom van Dijck wrote: Hi, I've had some time today to cleanup and make the VM a standalone thing, since it pretty much was designed to work together with our Game Engine. Full game engine (forgive me my commercial plug on the list) can be licensed as well. It's been used for Red Ninja: End of Honor and several other games. Please bare in mind that in our Game Engine we use java as a scripting language, NOT as our main development language, and thus use a very restricted and small runtime. We do NOT fully implement the J2SE API, nor do we have any intensions to do so. Anyway, the standalone VM is available on www.mudge.nl/java/ It is distributed under a somewhat modified version of the ZLIB license, so for use as reference or as a base for harmony there should be no problem whatsoever. If there are any problems with the license please let me know so we can negotiate, all I want is to be notified about what happens to my code and who uses it. Tom, thanks for this. Comments? geir Tom van Dijck mudGE Entertainment -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 6:35 AM To: harmony-dev@incubator.apache.org Subject: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/ For those that want meaningful subjects lines, here it is and for those that are waiting for an architecture discussion - here it is. Here's the first of the offered VMs. (I've privately mailed Tom van Dijck about mudGE so we can look at something else) I've downloaded and will begin playing with today. Archie, can you give a brief overview of structure? Can we get some discussion about this from those that know about about VM architecture? geir On May 16, 2005, at 3:22 PM, Archie Cobbs wrote: As mentioned before, and/all of JC [1] is available and I'll be happy to relicense it. All of the code was written by me (though I didn't invent all of the algorithms of course). Some bits I can think of that may be useful, roughly ordered from smaller and more likely to larger and less likely... - Splay tree implementation (splay.c) - String/UTF-8 functions (string.c, utf.c) - ZIP file reader (zip.c) - Class file parser (cf_parse.c) - Native local and global reference code (native_ref.c) - Per-classloader memory allocator (cl_alloc.c) - SableVM thin lock algorithm (lock.c) - Native library loader (native_lib.c) - VM Bootstrap code (vm.c, bootstrap.c) - JNI support (jni_invoke.c, jni_native.c) - Reflection support (reflect.c) - Dynamic invoker (invoke.c) - Threading support (thread.c) - Heap structure and garbage collector (heap.c, gc_root.c, gc_scan.c). - Bytecode interpreter (interp.c) - Class loading, derivation, and resolution (load2.c, derive2.c, resolve.c) There's also an ELF object loader and DWARF2 parser if you need those :-) -Archie [1] http://jcvm.sourceforge.net/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Intro to Classpath
On Wed, 2005-05-18 at 13:15 +0500, usman bashir wrote: And i ll add one thing more! when u get it up, you will see many more alternative implementations will be sumbited to harmony, so let me dream for that :) and it is what we called power of OSS. i mean actually in future we can then replace the implementation of such API's which are based on Service Provider interfaces could be avialable as alternative bases. Oh, absolutely! We're already doing this to a small extent already in Classpath; for java.nio.charset, we have a set of character set converters written in Java, and another provider based on the libiconv library. /Sven
Re: Against using Java to implement Java (Was: Java)
This subject has been covered in detail at least twice already. There is no need for any function call on the fast path of the allocation sequence. In a Java in Java VM the allocation sequence is inlined into the user code. This has considerable advantages over a few lines of assembler. Aside from the obvious advantage of not having to express your allocator in assembler, using Java also compiles to better code since the code can be optimized in context (register allocation, constant folding etc), producing much better code than hand crafted assembler. However this is small fry compared to the importance of compiling write barriers correctly (barriers are used by most high performance GCs and are executed far more frequently than allocations). The same argument applies though. The barrier expressed in Java is inlined insitu, and the optimizing compiler is able to optimize in context. Modularization does not imply any of this. --Steve Weldon Washburn wrote: On 5/18/05, David Griffiths [EMAIL PROTECTED] wrote: I think it's too slow to have the overhead of a function call for every object allocation. This is the cost of modularization. I doubt any of the mainstream JVMs you are competing with do this. Yes. I agree. A clean interface would have a function call for every object allocation. However if the allocation code itself is only a few lines of assemby, it can be inlined by the JIT. Using a moving GC, it is possible to get the allocation sequence down to a bump the pointer and a compare to see if you have run off the end of the allocation area.
Re: Gosling on Harmony
Hi Danese, Since the VOTE on the proposal has closed with a positive result. I'd love to hear with your INTEL hat on :) -- dims On 5/18/05, Danese Cooper [EMAIL PROTECTED] wrote: Much as I admire James, I have to say that the responses from enterprise developers of which he presumably speaks were carefully choreographed by the organizers of JavaONE (who are of course Sun employees). Its the old story...you can't ask a question without influencing the answer. When Sun asks they often hear what they want to hear. When Tim O'Reilly asked the same question a month later at OSCON he got the opposite answer (of course). I spent 6 years at Sun asking the question every chance I got and probably because of who I am I heard clear support for a *compatible* open J2SE...which is what Harmony is trying to be (and why I'm a supporter) :-)... In my experience, James is a fair-minded guy and I believe that a strong, ethical and hard-working Harmony community is bound to impress him over time. Danese (still speaking on my own and neither on behalf of my former nor my current employer) On May 17, 2005, at 4:11 PM, Ahmed Saad wrote: The clear need that Magnusson cites is anything but clear to Gosling, who says Sun has received negative response from the enterprise development community regarding the idea of open-source Java. welcome to the matrix, guys ;) On 5/17/05, Tomer Barletz [EMAIL PROTECTED] wrote: http://www.devx.com/Java/Article/28125?trk=DXRSS_JAVA Looks like Doc java is pretty upset... -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Against using Java to implement Java (Was: Java)
I know, but despite the subject line my original point was about the problem of modularizing a VM written in C. Cheers, Dave On 5/18/05, Steve Blackburn [EMAIL PROTECTED] wrote: This subject has been covered in detail at least twice already. There is no need for any function call on the fast path of the allocation sequence. In a Java in Java VM the allocation sequence is inlined into the user code. This has considerable advantages over a few lines of assembler. Aside from the obvious advantage of not having to express your allocator in assembler, using Java also compiles to better code since the code can be optimized in context (register allocation, constant folding etc), producing much better code than hand crafted assembler. However this is small fry compared to the importance of compiling write barriers correctly (barriers are used by most high performance GCs and are executed far more frequently than allocations). The same argument applies though. The barrier expressed in Java is inlined insitu, and the optimizing compiler is able to optimize in context. Modularization does not imply any of this. --Steve Weldon Washburn wrote: On 5/18/05, David Griffiths [EMAIL PROTECTED] wrote: I think it's too slow to have the overhead of a function call for every object allocation. This is the cost of modularization. I doubt any of the mainstream JVMs you are competing with do this. Yes. I agree. A clean interface would have a function call for every object allocation. However if the allocation code itself is only a few lines of assemby, it can be inlined by the JIT. Using a moving GC, it is possible to get the allocation sequence down to a bump the pointer and a compare to see if you have run off the end of the allocation area.
Fwd: [VOTE RESULT] Apache Harmony (was Re: [VOTE]: On PROPOSAL : Apache Harmony - J2SE 5 Project)
FYI -- Forwarded message -- From: Geir Magnusson Jr. [EMAIL PROTECTED] Date: May 18, 2005 8:44 AM Subject: [VOTE RESULT] Apache Harmony (was Re: [VOTE]: On PROPOSAL : Apache Harmony - J2SE 5 Project) To: general@incubator.apache.org Here are the results from the voting on Apache Harmony. The proposal passes. Note that I screwed up and started voting on the Proposal thread, and many followed suit. With the intention of recognizing the intent of the voters, all are included here. I hope I got everyone. +1 for Vote thread == Noel Bergman (binding) Alex Karasulu Davanum Srinivas (binding) Geir Magnusson (binding) Paul Hammant (binding)* * provided copyright and trademark issues appropriately considered +0 from Vote thread === Niclas Hedhman -1 from Vote thread === none +1 from Proposal thread === Danese Cooper Erik Hatcher (binding) Roy Fielding (binding) Cliff Schmidt (binding) Sam Ruby (binding) Bruce Snyder Ted Leung (binding) Graham Legett Clinton Begin Steven Noels (binding) Jim Jagielski (binding) We already have the mail list and wiki resources. I'll be getting the rest (svn, etc) done ASAP. geir On May 6, 2005, at 7:18 PM, Noel J. Bergman wrote: +1 --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Developing Harmony
Ozgur Akan wrote: JVM in Java will be the slower then Sun`s JVM. C or C++ is a better choice. You have to undertand that written in Java does *NOT* equate necessarely as will be run as interpreted bytecode. -- Stefano.
Re: Developing Harmony
Ben Laurie wrote: Stefano Mazzocchi wrote: Bryce Leo wrote: Now don't go too crazy for my suggesting this, but why not pascal? If we're considering C as it is this really isn't a terrible suggestion. I know it's fallen out of favor with most of you guys but it compiles quickly and supports a good number of operating systems and types of hardware, like arm and AMD64 (referencing Free Pascal that is). I'm betting that you guys won't like it but I think the option should be listed. Opinions? Can we stop this language madness thing, please? We are *NOT* going to be writing a JVM from scratch, we are open for donations. Says who? If people here want to write a VM, are you going to stop them? I hope you wouldn't even try. I'll discuss that when it happens ;-) -- Stefano.
Re: Against using Java to implement Java (Was: Java)
Steve == Steve Blackburn [EMAIL PROTECTED] writes: Steve There is no need for any function call on the fast path of the Steve allocation sequence. [ ... ] Steve However this is small fry compared to the importance of compiling Steve write barriers correctly (barriers are used by most high performance Steve GCs and are executed far more frequently than allocations). [ ... ] Steve Modularization does not imply any of this. I wanted to mention a few things on what modularity is not. Just because we have some tunable knob, it does not imply that we must support all possible settings of that knob. And, likewise, we are not compelled to support every possible combination of settings of all the knobs. Finally, modularity does not imply that all aspects of the VM will be selectable at runtime. It is completely reasonable to require compile-time choices. So, in this case, it isn't as if we would have to design an allocation interface that allows all possible choices. It can merely allow the subset we know to be immediately usable. Tom
Re: [arch] VM Candidate : JNode
[EMAIL PROTECTED] wrote: Those scores seems to be produced by HotSpot Client VM. If HotSpot Server VM was used, the score of Sun J2SDK 1.4.2 will be higher than 7500. I have not verified the numbers myself, since I do not currently have a machine where it runs out of the box (network drivers are quite limited). (*1) TYA: a JIT compiler, http://sax.sax.de/~adlibit However, a generic JIT-plugin framework would be quite interesting. -- Thorbjørn
Re: Developing Harmony
Ben == Ben Laurie [EMAIL PROTECTED] writes: Ben This has to be a VM that produces native code, right? Yes. Ben In any case, here I am with a platform that currently has no VM, but Ben does have a C compiler. What do I do? One answer is, cross-build the VM from another machine that it does work on. This is one way people bring up GCC on a new machine as well. Tom
Re: Harmony Project Structure Attempt
Steve Blackburn wrote: Over time we learned certain idioms which on one hand meant we tended to get reasonable performance first shot, but on the other may have undermined the natural Java style we started with. Do you have a summary of this available somewhere on the net? If I understand you correctly, you have found that you need to code in a special way to get the best code out of it. Is this generically for java or just the compiler you used? -- Thorbjørn
Re: Against using Java to implement Java (Was: Java)
Weldon, One way to handle this is to write something up on the wiki (http://wiki.apache.org/harmony/) and ask people to comment and then incorporate the comments back. So that we have a record of the discussion and the conclusions. Yes, we need to stick to harmony-dev for now. Thanks, dims On 5/18/05, Weldon Washburn [EMAIL PROTECTED] wrote: On 17 May 2005 18:27:42 -0600, Tom Tromey [EMAIL PROTECTED] wrote: David == David Griffiths [EMAIL PROTECTED] writes: David Maybe a concrete example would help. Let's say you have a GC module David written in C. One of it's API calls is to allocate a new object. How David is your JIT module going to produce code to use that API? Via a C David function pointer? Yes. One way is to mandate link- or compile-time pluggability only. Then this can be done by name. Your JIT just references 'harmony_allocate_object' in its source and uses this pointer in the code it generates. The other way is to have the JIT call some central function to get a pointer to the allocator function (or functions, in libgcj it turned out to be useful to have several). This only needs to be done once, at startup. For folks interested in pluggability, I advise downloading a copy of ORP and reading through it. ORP already solved these problems in a fairly reasonable way. Thanks. I am more than willing to respond to questions about ORP. Since ORP was last posted to open source, I have done some additional thinking about interfaces as well as JVM and .NET design in general. I really look forward to discussing these ideas. It would be great if we can quickly get to the point where we can discuss interface details. For example, I would like to start a detailed discussion on JIT and GC interface header files. Should we start this on the general harmony-dev list? Weldon Tom -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Gosling on Harmony
Danese Cooper wrote: Yup in a nutshell. I'd like to see James keynote at ApacheCon one of these years soon :-) What *I*'d like to see is *our* keynote at JavaOne :-) -- Stefano, who was part of a javaone keynote already once and would not mind doing it again :-)
Re: [VOTE RESULT] Apache Harmony (was Re: [VOTE]: On PROPOSAL : Apache Harmony - J2SE 5 Project)
congratulations geir and all and now we have to prove our selves as well !!! On 5/18/05, Davanum Srinivas [EMAIL PROTECTED] wrote: FYI -- Forwarded message -- From: Geir Magnusson Jr. [EMAIL PROTECTED] Date: May 18, 2005 8:44 AM Subject: [VOTE RESULT] Apache Harmony (was Re: [VOTE]: On PROPOSAL : Apache Harmony - J2SE 5 Project) To: general@incubator.apache.org Here are the results from the voting on Apache Harmony. The proposal passes. Note that I screwed up and started voting on the Proposal thread, and many followed suit. With the intention of recognizing the intent of the voters, all are included here. I hope I got everyone. +1 for Vote thread == Noel Bergman (binding) Alex Karasulu Davanum Srinivas (binding) Geir Magnusson (binding) Paul Hammant (binding)* * provided copyright and trademark issues appropriately considered +0 from Vote thread === Niclas Hedhman -1 from Vote thread === none +1 from Proposal thread === Danese Cooper Erik Hatcher (binding) Roy Fielding (binding) Cliff Schmidt (binding) Sam Ruby (binding) Bruce Snyder Ted Leung (binding) Graham Legett Clinton Begin Steven Noels (binding) Jim Jagielski (binding) We already have the mail list and wiki resources. I'll be getting the rest (svn, etc) done ASAP. geir On May 6, 2005, at 7:18 PM, Noel J. Bergman wrote: +1 --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas - http://webservices.apache.org/~dims/ -- Usman Bashir Certified IBM XML Solution Developer Certified UML Developer Brainbench Certified Internet Perfessional[advance](BCIP) Brainbench Certified Java Perfessional (BCJP) Brainbench Certified .NET Perfessional Brainbench Ceritified C++ Perfessional (BCCP) Software engineer IT24 Faculty Member Operation Badar Lahore
Re: Developing Harmony
Tom Tromey wrote: Ben == Ben Laurie [EMAIL PROTECTED] writes: Ben This has to be a VM that produces native code, right? Yes. Ben In any case, here I am with a platform that currently has no VM, but Ben does have a C compiler. What do I do? One answer is, cross-build the VM from another machine that it does work on. This is one way people bring up GCC on a new machine as well. I'm going to stop beating on this dead horse: you'll be happy if we can implement the VM in Java. I'll be happy if we can implement it in C. We'll both be happy if we can implement it in either. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [VOTE RESULT] Apache Harmony (was Re: [VOTE]: On PROPOSAL : Apache Harmony - J2SE 5 Project)
Good news. Congratulations - Original Message - From: Davanum Srinivas [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Sent: Wednesday, May 18, 2005 4:21 PM Subject: Fwd: [VOTE RESULT] Apache Harmony (was Re: [VOTE]: On PROPOSAL : Apache Harmony - J2SE 5 Project) FYI -- Forwarded message -- From: Geir Magnusson Jr. [EMAIL PROTECTED] Date: May 18, 2005 8:44 AM Subject: [VOTE RESULT] Apache Harmony (was Re: [VOTE]: On PROPOSAL : Apache Harmony - J2SE 5 Project) To: general@incubator.apache.org Here are the results from the voting on Apache Harmony. The proposal passes. Note that I screwed up and started voting on the Proposal thread, and many followed suit. With the intention of recognizing the intent of the voters, all are included here. I hope I got everyone. +1 for Vote thread == Noel Bergman (binding) Alex Karasulu Davanum Srinivas (binding) Geir Magnusson (binding) Paul Hammant (binding)* * provided copyright and trademark issues appropriately considered +0 from Vote thread === Niclas Hedhman -1 from Vote thread === none +1 from Proposal thread === Danese Cooper Erik Hatcher (binding) Roy Fielding (binding) Cliff Schmidt (binding) Sam Ruby (binding) Bruce Snyder Ted Leung (binding) Graham Legett Clinton Begin Steven Noels (binding) Jim Jagielski (binding) We already have the mail list and wiki resources. I'll be getting the rest (svn, etc) done ASAP. geir On May 6, 2005, at 7:18 PM, Noel J. Bergman wrote: +1 --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Gosling on Harmony
LOL, I'm not exactly in a position to influence that anymore, Stefano :-) What say you, Simon Phipps? Danese On May 18, 2005, at 12:54 PM, Stefano Mazzocchi wrote: Danese Cooper wrote: Yup in a nutshell. I'd like to see James keynote at ApacheCon one of these years soon :-) What *I*'d like to see is *our* keynote at JavaOne :-) -- Stefano, who was part of a javaone keynote already once and would not mind doing it again :-)
Re: Gosling on Harmony
Stefano Mazzocchi wrote: Danese Cooper wrote: Yup in a nutshell. I'd like to see James keynote at ApacheCon one of these years soon :-) What *I*'d like to see is *our* keynote at JavaOne :-) What I'd like to see is a keynote where someone covers M.A.R.R.S. 'Pump Up The Volume' in true Atari Teenage Riot style with distorted mobile phones, Jonathan Schwartz does the vocals and Steve Ballmer does the dancing. cheers, dalibor topic
Re: [arch] VM Candidate : JNode
Can the VM be tweaked to work on standard OSs? On May 18, 2005, at 7:33 AM, Thorbjørn Ravn Andersen wrote: I would like to mention the JNode VM. It is written in Java with a platform specific nanokernel (currently a stable x86 and a development X86_64) with the direct aim of running a full Java enviroment on the bare metal. The performance figures show that the JIT gives performance higher than 50% of the 1.4.2 hotspot. http://jnode.sourceforge.net/portal/node/51 It is currently rather hungry for memory and has a suboptimal GC. A patched GNU Classpath is used. -- Thorbjørn -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Gosling on Harmony
On May 18, 2005, at 10:54 AM, Simon Phipps wrote: I completely agree with this. I regret that James showed how out of touch he was with real open source practice (crazy answer about put- backs), but my interactions with him (most recently at Cafe Brasil where he also met with Dalibor and Geir) suggest that he's interested in code alone, not in either Sun of FOSS politics, and that positive results will get positive support. Lets make this a goal too :) Lets get James as a Harmony fan :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Against using Java to implement Java (Was: Java)
Or post to the dev list first so everyone can see it, and then take a summary to the wiki. On May 18, 2005, at 2:43 PM, Davanum Srinivas wrote: Weldon, One way to handle this is to write something up on the wiki (http://wiki.apache.org/harmony/) and ask people to comment and then incorporate the comments back. So that we have a record of the discussion and the conclusions. Yes, we need to stick to harmony-dev for now. Thanks, dims On 5/18/05, Weldon Washburn [EMAIL PROTECTED] wrote: On 17 May 2005 18:27:42 -0600, Tom Tromey [EMAIL PROTECTED] wrote: David == David Griffiths [EMAIL PROTECTED] writes: David Maybe a concrete example would help. Let's say you have a GC module David written in C. One of it's API calls is to allocate a new object. How David is your JIT module going to produce code to use that API? Via a C David function pointer? Yes. One way is to mandate link- or compile-time pluggability only. Then this can be done by name. Your JIT just references 'harmony_allocate_object' in its source and uses this pointer in the code it generates. The other way is to have the JIT call some central function to get a pointer to the allocator function (or functions, in libgcj it turned out to be useful to have several). This only needs to be done once, at startup. For folks interested in pluggability, I advise downloading a copy of ORP and reading through it. ORP already solved these problems in a fairly reasonable way. Thanks. I am more than willing to respond to questions about ORP. Since ORP was last posted to open source, I have done some additional thinking about interfaces as well as JVM and .NET design in general. I really look forward to discussing these ideas. It would be great if we can quickly get to the point where we can discuss interface details. For example, I would like to start a detailed discussion on JIT and GC interface header files. Should we start this on the general harmony-dev list? Weldon Tom -- Davanum Srinivas - http://webservices.apache.org/~dims/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Against using Java to implement Java (Was: Java)
On 5/18/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On May 18, 2005, at 9:36 AM, Steve Blackburn wrote: This subject has been covered in detail at least twice already. There is no need for any function call on the fast path of the allocation sequence. In a Java in Java VM the allocation sequence is inlined into the user code. This has considerable advantages over a few lines of assembler. Aside from the obvious advantage of not having to express your allocator in assembler, using Java also compiles to better code since the code can be optimized in context (register allocation, constant folding etc), producing much better code than hand crafted assembler. However this is small fry compared to the importance of compiling write barriers correctly (barriers are used by most high performance GCs and are executed far more frequently than allocations). The same argument applies though. The barrier expressed in Java is inlined insitu, and the optimizing compiler is able to optimize in context. Modularization does not imply any of this. I assume you mean that Modularization is orthogonal to this - that they are independent aspects? Modularization always interacts with performance. I believe empirical evidence suggests that the performance impact of splitting out the JIT and GC as separate modules is in the noise. I suspect the internal JVM support for java.lang.Thread, java.lang.Object can also be split off as a separate module with very little performance impact. It might even be possible to include java.util.concurrent support in the same threads module. Elaborating on a previous comment about inlining allocation/write barrier sequences. First design step: the GC team hand optimizes an assembly sequence while making sure the functionality is absolutely correct. Second step: the JIT team blindly inlines the GC team's assembly code and starts doing performance analysis. Third step: the JIT team integrates the inline sequence(s) into the IR so that all the optimizations can be performed. Perhaps these steps are the same for both a JVM written in Java as well as C/C++. I am curious if a JVM written in Java must break type-safety. Does anyone know? For example, the new bytecode will need to manipulate (gasp!) raw C pointers. In specific, Java code will need to scribble on free memory to slice off X untyped bytes and return a raw pointer to the base of chunk of memory. Then the java code will need to use the raw pointer to install stuff like a vtable pointer. Once the object is setup, the Java code can revert to running code that can actually be verified. Also does anyone know the current state of research on formally proving a GC written in Java is type-safe? geir --Steve Weldon Washburn wrote: On 5/18/05, David Griffiths [EMAIL PROTECTED] wrote: I think it's too slow to have the overhead of a function call for every object allocation. This is the cost of modularization. I doubt any of the mainstream JVMs you are competing with do this. Yes. I agree. A clean interface would have a function call for every object allocation. However if the allocation code itself is only a few lines of assemby, it can be inlined by the JIT. Using a moving GC, it is possible to get the allocation sequence down to a bump the pointer and a compare to see if you have run off the end of the allocation area. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Against using Java to implement Java (Was: Java)
Steve, Very interesting. Please point me to the web pages that show SpecJAppServer/JBB/JVM... numbers for Jikes. I see some mention of magic types. Does this work around the java verifier by coercing a reference pointer into a Java int and vice-versa? This could be done by calling a non-verifiable chunk of code written in Java. Something like Object int2ref(int x); and int ref2obj(Object z). The net result sort of C++-izes java without having to modify the language. If we are going to entertain writing most of the JVM in a type-safe language, we should also consider the proposed ECMA C++/CLI. From what I understand, it standardizes a form of type-safe C++. It has the promise of keeping both the Java and C camps happy. Regarding the inlining of assembly in the JIT. You point out that this code can be written in Java then fed to the JIT. Do you see any reason why this code can not be written in C/C++, C#, etc? On 5/18/05, Steve Blackburn [EMAIL PROTECTED] wrote: Hi Weldon, It seems we have similar experiences with modularity, you in ORP, me in Jikes RVM and MMTk. Elaborating on a previous comment about inlining allocation/write barrier sequences. First design step: the GC team hand optimizes an assembly sequence while making sure the functionality is absolutely correct. Second step: the JIT team blindly inlines the GC team's assembly code and starts doing performance analysis. Third step: the JIT team integrates the inline sequence(s) into the IR so that all the optimizations can be performed. Perhaps these steps are the same for both a JVM written in Java as well as C/C++. No. It is as I stated in the post to which you were responding. In MMTk, we express the barriers and allocation sequences in Java and then the opt compiler inlines them and optimizes them. The first Jikes RVM collectors used assembler for the barriers, but we transitioned to expressing them in Java a long time ago. This gives us much greater expressibility on the GC side of the fence, greater portability (MMTk is totally architecture neutral), and better performance because it presents better opportunities for optimization to the compiler (constant folding etc etc). I am curious if a JVM written in Java must break type-safety. Does anyone know? For example, the new bytecode will need to manipulate (gasp!) raw C pointers. In specific, Java code will need to scribble on free memory to slice off X untyped bytes and return a raw pointer to the base of chunk of memory. Then the java code will need to use the raw pointer to install stuff like a vtable pointer. Once the object is setup, the Java code can revert to running code that can actually be verified. Also does anyone know the current state of research on formally proving a GC written in Java is type-safe? Yes. We put a lot of work into making MMTk type safe. Type safety is key. Perry Cheng was the person who initially did all the hard work on this. We have introduced new magic types for Address (think void*), Word (think 32 or 64 bit unsigned values), ObjectReference (abstract notion of a refernce to an object, could in principle be a handle, for Jikes RVM it is an Address), etc etc. Each of these looks like a heavyweight regular Java type, but our compiler knows about them and folds them into primitives. The fact that we *do* preserve type safety is what allows the opt compiler to be as agressive as it is in compiling across barriers and allocations. I've provided pointers to this previously. Jnode has been using these magic types for a while now (for the same reasons). http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html I would like (not now, I need to run) to discuss different notions of modularity and modular design. We have approached it very differently to you and I think it would be profitable for us all to share our thoughts. Cheers, --Steve
