Re: half-baked idea? j2me
Archie Cobbs wrote: Robin Garner wrote: Actually my colleagues at ANU and I were remarking last week that all the recent discussion on the Harmony list (configure scripts, packed structs etc etc) were close to being proof that Java was the easier way to go. Here's some idle speculating about writing a JVM in Java... Start by asking this question: if you could design a new language expressly for the purpose of implementing JVM's, what would that language look like? Java is almost the right language.. but not quite. You need to be able to do C-like stuff as well. One can imagine something that is mostly like Java, but has some additional features that allows C like functionality, for example: - Augment the Java type system with C-like "structs". These are like Java objects in that they can be allocated on the Java heap (as an option) but have no Object header (you can't synchronize on them directly and they have no associated Class). Then the in-memory representation of an Object is a special case of one of these structures, containing a lockword and vtable pointer. - Define a new "word" primitive type that corresponds to the machine-specific word size (i.e., 32 or 64 bit unsigned int). Corresponds to SableVM's _svm_word and JC's _jc_word. - Language would include primitives for compare-and-swap of a word, memory barriers, etc. - The language would include the ability to cast between any types as you can do in C (e.g., struct -> Object, word -> Object pointer). - Allow C function calls to be expressed in the language, passing as parameters any Java type, or a struct. This "compiles" directly into a C function call using the platform's normal C calling conventions. - Extend the class file format in a corresponding manner. Call this language "Java++" (or whatever). Then the 95% of the JVM can be written in this language.. and 95% of that would be normal Java. This is exactly how we see the dialect of Java that MMTk is written in. The non-java extensions are the org.vmmagic classes. The key difference is that our types are represented as 'unboxed' objects, which gives us more flexibility to define operations on them. cheers
Re: half-baked idea? j2me
Robin Garner wrote: Actually my colleagues at ANU and I were remarking last week that all the recent discussion on the Harmony list (configure scripts, packed structs etc etc) were close to being proof that Java was the easier way to go. Here's some idle speculating about writing a JVM in Java... Start by asking this question: if you could design a new language expressly for the purpose of implementing JVM's, what would that language look like? Java is almost the right language.. but not quite. You need to be able to do C-like stuff as well. One can imagine something that is mostly like Java, but has some additional features that allows C like functionality, for example: - Augment the Java type system with C-like "structs". These are like Java objects in that they can be allocated on the Java heap (as an option) but have no Object header (you can't synchronize on them directly and they have no associated Class). Then the in-memory representation of an Object is a special case of one of these structures, containing a lockword and vtable pointer. - Define a new "word" primitive type that corresponds to the machine-specific word size (i.e., 32 or 64 bit unsigned int). Corresponds to SableVM's _svm_word and JC's _jc_word. - Language would include primitives for compare-and-swap of a word, memory barriers, etc. - The language would include the ability to cast between any types as you can do in C (e.g., struct -> Object, word -> Object pointer). - Allow C function calls to be expressed in the language, passing as parameters any Java type, or a struct. This "compiles" directly into a C function call using the platform's normal C calling conventions. - Extend the class file format in a corresponding manner. Call this language "Java++" (or whatever). Then the 95% of the JVM can be written in this language.. and 95% of that would be normal Java. Then writing the JVM boils down to this: - Define this language and modify an existing Java compiler to understand and compile it. - Write a JIT engine and/or interpreter that understands how to execute this stuff, supported by a small C support library that handles the low level stuff like atomic ops, dynamic dispatch (the equivalent of libffi), exception throwing & catching, etc. - The JIT could be written in two parts: - First part converts normal class files into Java++ class files, in the process converting all high level stuff (like virtual method dispatch, instanceof, etc.) into low level stuff that the second part of the JIT can understand (call this "Java--"). This part could also do all the fancy runtime JIT optimizations like method inlining, devirtualization, etc. - Second part converts Java-- into machine code. This would be a fairly "direct" conversion. - Write the JVM proper in Java++ (it would mostly be pure Java). Re-use existing JVM's written in C by porting them to Java++. - To bootstrap the JVM, require all bootstrap code be written in Java-- (i.e., no virtual dispatch, etc.). Then the system can be bootstrapped using only the simper, "direct" part of the JIT. This is similar to other JVM's written in Java, but would have a more natual and understandable interface between the Java part and the non-Java part. Just a thought... :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: half-baked idea? j2me
Rodrigo Kumpera wrote: On 11/1/05, Robin Garner <[EMAIL PROTECTED]> wrote: On 11/1/05, Robin Garner <[EMAIL PROTECTED]> wrote: Rodrigo Kumpera wrote: AFAIK IKVM, sablevm and jamvm all run on portable devices. Developing a j2me jvm is not as easier as it seens, first, the footprint and execution performance must be really optimized, so expect a LOT of assembly coding. Back to the language wars again :) This does not necessarily follow. Try googling for the 'squawk' VM - they had a poster at OOPSLA last week. This is a java-in-java virtual machine targetted at embedded devices. The core VM runs in 80KB of memory. Device drivers are all written in Java. Robin, With a java-in-java VM even if you don't write directly in assembly you still need to generate machine code with java anyway, and that will look a lot like asm (JikesRVM baseline JITer for example). With C, for example, you can get away using just an interpreter. My mistake, obviously. When you said "performance must be really optimized, so expect a LOT of assembly coding", I assumed you were saying that large chunks of the VM would need to be written in assembler in order to get adequate performance. So what _was_ the point you were making ? cheers I was just trying to say that a decent j2me VM is not as simple as David suggested. Not that C or Java would be more suited to implement it. As a matter of fact, I think that java-in-java VMs can be as good as C/C++ based JVMs or better. But one thing is hard to deny, a simple JVM, like bootJVM, is a lot easier to write in C than in java (not using an AOT compiler). And that was my point, C/C++ sounds to be the easy path to start with. Actually my colleagues at ANU and I were remarking last week that all the recent discussion on the Harmony list (configure scripts, packed structs etc etc) were close to being proof that Java was the easier way to go. Another data point (FWIW) - joeq, excluding the compiler and the class library interface comes in at ~39,000 lines of code. bootJVM is already over 50,000. I know that KLOC is a pretty bogus measure of complexity, but it certainly says _something_. And Joeq is a fully functioning VM. cheers
Re: [jchevm]
Jean-frederic Clere wrote: Just a question... How to build it? My tries with aclocal/autoconf/automake shows missing elements. It doesn't build yet.. what was submitted is stripped down from the full original. Soon I will work on reconstituting it so it actually builds and works (waiting on commit access). This will be as an interpreter only, which will result in discarding a bunch of unrelated stuff like the Java-to-C code generator (I'm planning on keeping the ELF loader for now, as it could conceivably someday be used as a way of loading disk-cached JIT output). Of course anything that's discarded will really still be there in SVN. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
[jchevm]
Hi all, Just a question... How to build it? My tries with aclocal/autoconf/automake shows missing elements. Cheers Jean-Frederic
[jira] Updated: (HARMONY-10) configure for [BootJVM]
[ http://issues.apache.org/jira/browse/HARMONY-10?page=all ] Jean-Frederic Clere updated HARMONY-10: --- Attachment: config_try.tar.gz now togother with the Makefile to build bootJVM for svn source is that easy as: sh buildconf.sh ./configure --with-java=/home/jfclere/JAVA/j2sdk1.4.2_06 --with-heap=simple --with-gc=stub make > configure for [BootJVM] > > > Key: HARMONY-10 > URL: http://issues.apache.org/jira/browse/HARMONY-10 > Project: Harmony > Type: New Feature > Environment: any unix based machine (and cygwin). > Reporter: Jean-Frederic Clere > Assignee: Geir Magnusson Jr > Attachments: config_try.tar.gz, config_try.tar.gz > > Allow to use a "standard" way of building BootJVM: > ../configure --with-java=$JAVA_HOME --with-heap=HEAD_TYPE --with-gc=GC_TYPE > make > make install -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [BootJVM] jvm/src/opcode.c patch
Geir Magnusson Jr. wrote:
what about "exit()" ? :)
making a core allows to back trace the call stack.
geir
On Oct 31, 2005, at 7:25 PM, [EMAIL PROTECTED] wrote:
Jean-Frederic,
This is the area of the code I am working on
fast and furious. I have used this macro as
a place holder to say, "Stop the world! It
doesn't work yet!" I am hoping to get all
of these STUB instances removed in the next
week or so when I get all the code done that
it stubs out. Any change here will be removed
anyway because the code will be implemented.
If you want to do this locally, it might mean
something to you, but overall, the need for it
will be going away soon.
Dan Lydick
-Original Message-
From: Jean-frederic Clere <[EMAIL PROTECTED]>
Sent: Oct 31, 2005 4:47 PM
To: harmony-dev@incubator.apache.org
Subject: [BootJVM] jvm/src/opcode.c patch
Hi,
I would like to propose the following patch:
+++
[EMAIL PROTECTED]:~/harmony/enhanced/trunk/sandbox/contribs/bootjvm/
bootJVM>
svn diff jvm/src/opcode.c
Index: jvm/src/opcode.c
===
--- jvm/src/opcode.c(revision 329310)
+++ jvm/src/opcode.c(working copy)
@@ -985,7 +985,7 @@
* creating better readability of the code.
*/
-static void dummy1(void) { char *p, *dummy2; dummy2 = p; dummy1(); }
+static void dummy1(void) { void (*p)()=NULL; p(); }
#define STUB { dummy1(); }
switch(opcode)
+++
The idea is to core ASAP when we reach a not yet supported opcode, any
comment?
Cheers
Jean-Frederic
Dan Lydick
Re: [jira] Closed: (HARMONY-13) test issue to ensure JIRA notifications going to dev list
thanks for fixing that Geir. Tim Geir Magnusson Jr (JIRA) wrote: > [ http://issues.apache.org/jira/browse/HARMONY-13?page=all ] > > Geir Magnusson Jr closed HARMONY-13: > > > Resolution: Fixed > > testing > > >>test issue to ensure JIRA notifications going to dev list >>- >> >> Key: HARMONY-13 >> URL: http://issues.apache.org/jira/browse/HARMONY-13 >> Project: Harmony >>Type: Bug >>Reporter: Geir Magnusson Jr >>Assignee: Geir Magnusson Jr > > > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[jira] Closed: (HARMONY-13) test issue to ensure JIRA notifications going to dev list
[ http://issues.apache.org/jira/browse/HARMONY-13?page=all ] Geir Magnusson Jr closed HARMONY-13: Resolution: Fixed testing > test issue to ensure JIRA notifications going to dev list > - > > Key: HARMONY-13 > URL: http://issues.apache.org/jira/browse/HARMONY-13 > Project: Harmony > Type: Bug > Reporter: Geir Magnusson Jr > Assignee: Geir Magnusson Jr > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: half-baked idea? j2me
On 11/1/05, Robin Garner <[EMAIL PROTECTED]> wrote: > > On 11/1/05, Robin Garner <[EMAIL PROTECTED]> wrote: > >> Rodrigo Kumpera wrote: > >> > >> >AFAIK IKVM, sablevm and jamvm all run on portable devices. > >> > > >> >Developing a j2me jvm is not as easier as it seens, first, the > >> >footprint and execution performance must be really optimized, so > >> >expect a LOT of assembly coding. > >> > > >> > > >> Back to the language wars again :) This does not necessarily follow. > >> Try googling for the 'squawk' VM - they had a poster at OOPSLA last > >> week. This is a java-in-java virtual machine targetted at embedded > >> devices. The core VM runs in 80KB of memory. Device drivers are all > >> written in Java. > >> > > > > Robin, > > > > With a java-in-java VM even if you don't write directly in assembly > > you still need to generate machine code with java anyway, and that > > will look a lot like asm (JikesRVM baseline JITer for example). With > > C, for example, you can get away using just an interpreter. > > My mistake, obviously. When you said "performance must be really > optimized, so expect a LOT of assembly coding", I assumed you were saying > that large chunks of the VM would need to be written in assembler in order > to get adequate performance. > > So what _was_ the point you were making ? > > cheers > > I was just trying to say that a decent j2me VM is not as simple as David suggested. Not that C or Java would be more suited to implement it. As a matter of fact, I think that java-in-java VMs can be as good as C/C++ based JVMs or better. But one thing is hard to deny, a simple JVM, like bootJVM, is a lot easier to write in C than in java (not using an AOT compiler). And that was my point, C/C++ sounds to be the easy path to start with.
Re: half-baked idea? j2me
>> On 11/1/05, Robin Garner <[EMAIL PROTECTED]> wrote: >>> Rodrigo Kumpera wrote: >>> >>> >AFAIK IKVM, sablevm and jamvm all run on portable devices. >>> > >>> >Developing a j2me jvm is not as easier as it seens, first, the >>> >footprint and execution performance must be really optimized, so >>> >expect a LOT of assembly coding. >>> > >>> > >>> Back to the language wars again :) This does not necessarily follow. >>> Try googling for the 'squawk' VM - they had a poster at OOPSLA last >>> week. This is a java-in-java virtual machine targetted at embedded >>> devices. The core VM runs in 80KB of memory. Device drivers are all >>> written in Java. >>> >> >> Robin, >> >> With a java-in-java VM even if you don't write directly in assembly >> you still need to generate machine code with java anyway, and that >> will look a lot like asm (JikesRVM baseline JITer for example). With >> C, for example, you can get away using just an interpreter. > > My mistake, obviously. When you said "performance must be really > optimized, so expect a LOT of assembly coding", I assumed you were saying > that large chunks of the VM would need to be written in assembler in order > to get adequate performance. > > So what _was_ the point you were making ? Actually to be more constructive, I think there is a deeper issue here. If an interpreter will give adequate performance, then it can certainly be written in an ahead-of-time compiled language with little or no call to do any assembly-like coding. If you actually need the additional performance you can get from a compiler, then there is no alternative to writing assembler in some shape or other. The JikesRVM compilers are good examples of the extremes here - the baseline compiler is virtually straight assembler (or a java representation thereof), while the opt compilers use all sorts of techniques to avoid actually specifying machine instructions directly. So while all compilers need to emit machine instructions (after all, that's what they do), there is very little need (given an adequate compiler) to write code in assembler, no matter what language it is written in. There's a perfectly adequate AOT java compiler out there, so anything you can do in C can be done in Java with a little assistance from the compiler. cheers
Re: half-baked idea? j2me
> On 11/1/05, Robin Garner <[EMAIL PROTECTED]> wrote: >> Rodrigo Kumpera wrote: >> >> >AFAIK IKVM, sablevm and jamvm all run on portable devices. >> > >> >Developing a j2me jvm is not as easier as it seens, first, the >> >footprint and execution performance must be really optimized, so >> >expect a LOT of assembly coding. >> > >> > >> Back to the language wars again :) This does not necessarily follow. >> Try googling for the 'squawk' VM - they had a poster at OOPSLA last >> week. This is a java-in-java virtual machine targetted at embedded >> devices. The core VM runs in 80KB of memory. Device drivers are all >> written in Java. >> > > Robin, > > With a java-in-java VM even if you don't write directly in assembly > you still need to generate machine code with java anyway, and that > will look a lot like asm (JikesRVM baseline JITer for example). With > C, for example, you can get away using just an interpreter. My mistake, obviously. When you said "performance must be really optimized, so expect a LOT of assembly coding", I assumed you were saying that large chunks of the VM would need to be written in assembler in order to get adequate performance. So what _was_ the point you were making ? cheers
Re: half-baked idea? j2me
On 11/1/05, Robin Garner <[EMAIL PROTECTED]> wrote: > Rodrigo Kumpera wrote: > > >AFAIK IKVM, sablevm and jamvm all run on portable devices. > > > >Developing a j2me jvm is not as easier as it seens, first, the > >footprint and execution performance must be really optimized, so > >expect a LOT of assembly coding. > > > > > Back to the language wars again :) This does not necessarily follow. > Try googling for the 'squawk' VM - they had a poster at OOPSLA last > week. This is a java-in-java virtual machine targetted at embedded > devices. The core VM runs in 80KB of memory. Device drivers are all > written in Java. > Robin, With a java-in-java VM even if you don't write directly in assembly you still need to generate machine code with java anyway, and that will look a lot like asm (JikesRVM baseline JITer for example). With C, for example, you can get away using just an interpreter.
Re: JIRA mailbot (was: Re: [BootJVM] configure)
I was fooled into thinking it was because I was getting jiras that had my name associated w/ it. I know what the problem is and will fix... geir On Nov 1, 2005, at 3:34 AM, Tim Ellison wrote: Shouldn't the creation of JIRA issues result in an automated message posted to this list? Tim Geir Magnusson Jr. wrote: Thanks! Keep it coming! geir On Oct 28, 2005, at 5:17 PM, Jean-frederic Clere wrote: Geir Magnusson Jr. wrote: If you wish to contribute this, could you post it to a JIRA? Until I get commit rights ;-) It is now: http://issues.apache.org/jira/browse/HARMONY-10 Now I go for the Makefiles or the build.xml. make is more strandard for C project but ant is probably before the harmony community. Any commit? Cheers Jean-Frederic On Oct 27, 2005, at 6:09 PM, Jean-frederic Clere wrote: Hi, I am now building the config/config.h using the configure files I have prepared. The BootJVM specific options of the configure are: --with-java=DIR Specify the location of your JDK installation --with-heap=TYPEHeap allocation method: simple, bimodal or other. --with-gc=TYPE Garbage collection method: stub or other. The new file are in http://people.apache.org/~jfclere/ config_try.jar.gz Any comments? Cheers Jean-Frederic -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Questions about GC implementations
thanks On Oct 31, 2005, at 10:57 PM, Robin Garner wrote: Done. This is issue #11. cheers Geir Magnusson Jr. wrote: Robin - can you post this to a JIRA please? geir On Oct 29, 2005, at 1:57 AM, Robin Garner wrote: In the garbage collectors I've worked with, the essential design is: - 'new' allocates space on the heap. - The header of each object contains a pointer (or equiv) to a per-class data structure, that points to the GC map for the object (and virtual dispatch tables etc etc) - Reference fields in objects contain pointers directly to the heap objects they reference. - Pointer loads and stores are (optionally) performed via barriers - the terminology is a little confusing: these are not synchronization barriers, but opportunities for the GC to intercept the load/store and do some additional processing. Write barriers are common, read barriers less so. This is also the approach I have taken, so I think we are on the same page. I think we are just saying the same thing in different words. When an object is to be allocated, its pointer will be set by the allocator. This pointer is 'robject.pgarbage' and is found in 'jvm/src/object.h'. The reason you did not find one is because I have only provided a stub GC implementation. The 'new' operation is performed by object_instance_new() in 'jvm/src/object.c' and includes a call to GC_OBJECT_NEW(). Ok, so now I understand what the 'robject.pgarbage' pointer is - this is the pointer to the body of an object. So do I understand correctly that the body of an array is pointed to by a different pointer in an object header ? Do you realise that this means that a GETFIELD requires two indirections ? Do you realise that your object header is somewhere in the vicinity of 40 bytes ? The average payload of a java object (at least for SPECjvm98) is 16 bytes. Many of the fields in the bootJVM object header are actually constant across all objects of a class. The object table needs to go - I think this is a fundamental enough design feature that it needs to be removed as soon as possible. An object header should be 2 words at the most (3 for arrays), and they should be contiguous with the object. Any time a reference to that object is made, its object hash, of type 'jvm_object_hash' has a reference recorded by GC_OBJECT_MKREF_FROM_OBJECT() or GC_OBJECT_FIELD_MKREF() or GC_OBJECT_MKREF_FROM_JVM(). These are for internal JVM references, references from Java object reference variables, and references from Java local method reference variables, respectively. When the reference is no longer needed, such as when an object is destroyed or when a local method returns, the reference is no longer needed. When this occurs, then GC_OBJECT_RMREF_FROM_OBJECT() or GC_OBJECT_FIELD_RMREF() or GC_OBJECT_RMREF_FROM_JVM() are called, respectively. When an object is no longer used, then GC_OBJECT_DELETE() is called. So these I guess are what we would refer to in the GC world as barriers. My confusion is that a) they don't have enough parameters, and b) there are too many of them. Am I right in assuming that you are invoking a barrier on every update to a local variable, every update to a stack ? This is going to be way too inefficient. For a stop the world GC, what is needed is a barrier on a PUTFIELD and AASTORE, and a way that the GC can query the current pointers that the VM has into the heap when it starts a collection. Optionally, we can also have a PUTSTATIC barrier, and corresponding read barriers. I also don't get the distinction between the classes and objects. Either a class is an object, and lives in the heap - in which case it can be treated as an object - or it isn't and lives in the VM. When a local methods is called, GC_STACK_NEW() is invoked to set up GC for that stack frame. Adding and removing objects is done per above. Adding and removing references to objects is done with GC_STACK_MKREF_FROM_JVM() and GC_STACK_RMREF_FROM_JVM(). When it returns, GC_STACK_DELETE() is called. This is way too heavyweight. Stack manipulation is fast-path code, and shouldn't have to call out to the GC all the time. - There are many styles of collector, but the most common class uses tracing, in which a root set of pointers is used to determine an initial set of live objects, and the collector performs a transitive closure over this set to establish the set of all live objects. The root set is commonly the thread stacks and the static pointer fields. The macro GC_RUN() refers to the collector. The stub implementation shows what it is supposed to do. The OBJECT_STATUS_GCREQ status bit controls when an object needs collecting. So where does OBJECT_STATUS_GCREQ get set ? It's the GC (and only the GC) that knows when an object is alive or not (unless we do reachability analysis in the compiler/interpreter). All of the above setting up and tearing down of objects
Re: [BootJVM] jvm/src/opcode.c patch
what about "exit()" ? :)
geir
On Oct 31, 2005, at 7:25 PM, [EMAIL PROTECTED] wrote:
Jean-Frederic,
This is the area of the code I am working on
fast and furious. I have used this macro as
a place holder to say, "Stop the world! It
doesn't work yet!" I am hoping to get all
of these STUB instances removed in the next
week or so when I get all the code done that
it stubs out. Any change here will be removed
anyway because the code will be implemented.
If you want to do this locally, it might mean
something to you, but overall, the need for it
will be going away soon.
Dan Lydick
-Original Message-
From: Jean-frederic Clere <[EMAIL PROTECTED]>
Sent: Oct 31, 2005 4:47 PM
To: harmony-dev@incubator.apache.org
Subject: [BootJVM] jvm/src/opcode.c patch
Hi,
I would like to propose the following patch:
+++
[EMAIL PROTECTED]:~/harmony/enhanced/trunk/sandbox/contribs/bootjvm/
bootJVM>
svn diff jvm/src/opcode.c
Index: jvm/src/opcode.c
===
--- jvm/src/opcode.c(revision 329310)
+++ jvm/src/opcode.c(working copy)
@@ -985,7 +985,7 @@
* creating better readability of the code.
*/
-static void dummy1(void) { char *p, *dummy2; dummy2 = p; dummy1(); }
+static void dummy1(void) { void (*p)()=NULL; p(); }
#define STUB { dummy1(); }
switch(opcode)
+++
The idea is to core ASAP when we reach a not yet supported opcode, any
comment?
Cheers
Jean-Frederic
Dan Lydick
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
Re: half-baked idea? j2me
Hi, J2ME is split into two things, the VM specification and the profile. MIDP is the profile, not the VM. The VM follows either the CDC specification (Connected Device) or the CLDC specification (Connected Limited Device). Here again, we now have two versions, 1.0 and 1.1 (CLDC1.1 is specified in JSR 139). Most phones were originally CLDC1.0/MIDP1.0. However, newer devices are all MIDP2.0. CLDC 1.0 was integer only, but 1.1 supports floating-point. It also supports weak references -- this is a subset of the J2SE weak reference classes, so the gap is getting smaller. Rob. On 11/1/05, David N. Welton <[EMAIL PROTECTED]> wrote: > Geir Magnusson Jr. wrote: > > Do you really mean J2ME for a specific purpose? > > Yes, 'j2me' is vague... Since MIDP is the lowest common denominator, I'd > start with that. > > > What we want to do here is a modular system to which you can easily > > replace parts as appropriate for your usage, either to port to a new > > platform or usage/performance profile > > MIDP has a lot of things missing - you need to make sure you don't have > any of that deeply mixed up in your core, or else ripping it out gets to > be difficult. No floats, no doubles, no reflection, just off the top of > my head. > > -- > David N. Welton > - http://www.dedasys.com/davidw/ > > Linux, Open Source Consulting > - http://www.dedasys.com/ >
Re: half-baked idea? j2me
Geir Magnusson Jr. wrote: > Do you really mean J2ME for a specific purpose? Yes, 'j2me' is vague... Since MIDP is the lowest common denominator, I'd start with that. > What we want to do here is a modular system to which you can easily > replace parts as appropriate for your usage, either to port to a new > platform or usage/performance profile MIDP has a lot of things missing - you need to make sure you don't have any of that deeply mixed up in your core, or else ripping it out gets to be difficult. No floats, no doubles, no reflection, just off the top of my head. -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/
Re: half-baked idea? j2me
Robin Garner wrote: > Rodrigo Kumpera wrote: > >> AFAIK IKVM, sablevm and jamvm all run on portable devices. >> >> Developing a j2me jvm is not as easier as it seens, first, the >> footprint and execution performance must be really optimized, so >> expect a LOT of assembly coding. A serious JIT compiler is going to require some low level work as well. I think the strategy would be to provide an optimized C reference version and then let people provide further optimizations to that as they see fit. > Back to the language wars again :) This does not necessarily follow. > Try googling for the 'squawk' VM - they had a poster at OOPSLA last > week. This is a java-in-java virtual machine targetted at embedded > devices. The core VM runs in 80KB of memory. Device drivers are all > written in Java. The first thing you'd probably want to do in any case is an emulator... although this already exists and is quite nice: http://www.barteo.net/microemulator/ >From my quick glance at the code, I don't think it's checking to make sure that you stick to the MIDP profile - it's basically just an implementation of the lcdui GUI code. -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/
Re: [BootJVM] configure
[EMAIL PROTECTED] wrote: Jean-Frederic, I see. I can agree with your question here, but notice that all this is doing is setting a shell variable whose contents are to be places into an included Makefile further down. With this syntax, that Makefile is dependent on a specific JAVA_HOME in the environment, yet another in its included file. That is whay my concern was. Notice that the existing 'config.sh' asks for which JAVA_HOME is desired. I think that it may actually be a good idea review this whole question about what it does and how it does it. I would, however, like to verify in a new autoconf-style configurator that the 'javac' and 'jar' utilities are present, just like the current 'config.sh' does. No problem (I just have to make a copy+paste from one m4 file of jakarta/daemon). I've taken a look at your 'config_try.tar' file and worked it up some. Notice that 'support/apjava.m4' lines 40 and 43 contain extraneous ';;' statements. Fixed thanks. (Also notice that the recent updates, including the new 'refcount' GC algorithm is not represented here. I will add it. Please see my SVN updates from Friday afternoon, latest rev being 329319.) Let's talk some more about your autoconf code. I think it makes a nice candidate for a powerful configurator. Dan Lydick -Original Message- From: Jean-frederic Clere <[EMAIL PROTECTED]> Sent: Oct 31, 2005 1:48 PM To: harmony-dev@incubator.apache.org Subject: Re: [BootJVM] configure [EMAIL PROTECTED] wrote: Jean-Frederic, I personally would rather see the Makefile pick up the $(JAVA_HOME) environment variable instead of the configuration shell script. By doing it this way, you don't have to run the configuration again when or if JAVA_HOME changes, lest the result be a mixture of two JDK versions. Does this make sense? My idea is to use autoconf... In this case it is very easy to redo configure: "./configure --with-java=$JAVA_HOME2 ..." Of course the JAVA_HOME have to be in a .in file included in Makefile for example Makedefs.in +++ [EMAIL PROTECTED]@ +++ The problem in the current config.sh is that it contains a Makefile syntax in a shell script... Dan Lydick Dan Lydick
Re: [BootJVM] configure
Geir Magnusson Jr. wrote:
Any chance of a JIRA so that doesn't fall through the cracks? :)
Done (See http://issues.apache.org/jira/browse/HARMONY-12)
Cheers
Jean-Frederic
geir
On Oct 30, 2005, at 12:33 PM, Jean-frederic Clere wrote:
Jean-frederic Clere wrote:
[EMAIL PROTECTED] wrote:
Jean-Frederic,
The _first_ thin to do is:
$ svn update
$ rm -rf ./config
$ ./config.sh
You will notice some changes, per harmony-commits@
list.
The gmake complains about:
DIRNAME:=$(shell expr $(PWD) : '\(.*[^/]\)/*$' : '.*/\(..*\)')
And the correction is:
+++
[EMAIL PROTECTED]:~/harmony/enhanced/trunk/sandbox/contribs/bootjvm/
bootJVM> svn diff MakeSetup
Index: MakeSetup
===
--- MakeSetup (revision 329310)
+++ MakeSetup (working copy)
@@ -64,7 +64,7 @@
#
# Base name of this directory and of parent directory
#
-DIRNAME:=$(shell expr $(PWD) : '\(.*[^/]\)/*$' : '.*/\(..*\)')
+DIRNAME:=$(shell expr $(PWD) : '\(.*[^/]\)/*$$' : '.*/\(..*\)')
PROJECTNAME:=
ifeq ("src","$(DIRNAME)")
+++
Cheers
Jean-Frederic
After doing SVN update, removing the existing
configuration and starting _completely_ over will show
you where I have changed things. The other thing
you could do would be,
$ mv ./config ./config.save
$ ./config.sh
$ diff ./config.save ./config
This would show you what changed in the SVN update
in the results it produces.
Dan Lydick
-Original Message-
From: Jean-frederic Clere <[EMAIL PROTECTED]>
Sent: Oct 28, 2005 4:55 PM
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Re: [BootJVM] configure
[EMAIL PROTECTED] wrote:
Jean-Frederic,
Take a look at the new Makefiles in the top
level directory and each source directory.
These should provide all functionality that
I see for the time being with the exception
of distribution rules, whose requirements
may change over time. Notice that one
important requirement is to be able to run
the documentation compiler 'doxygen',
which requires an explicit list of files. The
current 'config.sh' provides these to both
the Makefiles and Doxygen (via 'bootjvm.dox')
as include files.
+++
[EMAIL PROTECTED]:~/harmony/enhanced/trunk/sandbox/contribs/
bootjvm/bootJVM> make
/bin/sh: -c: line 1: unexpected EOF while looking for matching `''
/bin/sh: -c: line 2: syntax error: unexpected end of file
MakeSetup:98: config/config_build_steps.mak: No such file or
directory
Makefile:163: config/config_dox_setup.mak: No such file or directory
make: *** No rule to make target `config/config_dox_setup.mak'.
Stop.
+++
Ok: I see that configure have to create config/
config_build_steps.mak and config/config_dox_setup.mak
"/bin/sh: -c: line 1/2" strange.
I'll take a look at your configuration proposal
soon.
Great-
Dan Lydick
-Original Message-
From: Jean-frederic Clere <[EMAIL PROTECTED]>
Sent: Oct 28, 2005 4:17 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [BootJVM] configure
Geir Magnusson Jr. wrote:
If you wish to contribute this, could you post it to a JIRA?
Until I get commit rights ;-)
It is now: http://issues.apache.org/jira/browse/HARMONY-10
Now I go for the Makefiles or the build.xml.
make is more strandard for C project but ant is probably before
the harmony community.
Any commit?
Cheers
Jean-Frederic
...snip...
Dan Lydick
JIRA mailbot (was: Re: [BootJVM] configure)
Shouldn't the creation of JIRA issues result in an automated message posted to this list? Tim Geir Magnusson Jr. wrote: > Thanks! Keep it coming! > > geir > > > On Oct 28, 2005, at 5:17 PM, Jean-frederic Clere wrote: > >> Geir Magnusson Jr. wrote: >> >> >>> If you wish to contribute this, could you post it to a JIRA? >>> >> >> Until I get commit rights ;-) >> >> It is now: http://issues.apache.org/jira/browse/HARMONY-10 >> Now I go for the Makefiles or the build.xml. >> make is more strandard for C project but ant is probably before the >> harmony community. >> >> Any commit? >> >> Cheers >> >> Jean-Frederic >> >> >>> >>> >>> On Oct 27, 2005, at 6:09 PM, Jean-frederic Clere wrote: >>> >>> Hi, I am now building the config/config.h using the configure files I have prepared. The BootJVM specific options of the configure are: --with-java=DIR Specify the location of your JDK installation --with-heap=TYPEHeap allocation method: simple, bimodal or other. --with-gc=TYPE Garbage collection method: stub or other. The new file are in http://people.apache.org/~jfclere/ config_try.jar.gz Any comments? Cheers Jean-Frederic >>> >>> >> >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
