You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "David N. Welton" <da...@dedasys.com> on 2005/10/31 23:02:16 UTC
half-baked idea? j2me
Hello,
I'm interested in having a freely available Java system, which seemed as
good a reason as any to start lurking on this list lately.
I've been mulling over what I've seen in the archives here, what I know
of the free java world, free software, communities, marketing, and
various and sundry other things and an idea popped into my head.
Perhaps, like many others, it's a dumb one, but I thought I'd lob it out
there just the same:
Why not start out with j2me?
*) It'd be breaking new ground - something no one has done before in the
'free' world (to my knowledge at least). That, to me at least, would
increase the fun quotient.
*) It's small, which would make it easier to get running - or at least
easier to make it complete.
*) It's simple. To my knowledge, in order to stay small, most
implementations are interpreters (possibly assisted in hardware through
things like Jazelle).
*) Modulo space saving optimizations, it could then be used as a launch
pad for "bigger and better things" should we so desire.
*) Perhaps there are some financial incentives for corporations to get
involved. J2SE is "free beer", so the impetus to work on a free version
mostly comes from a desire to have an open source Java available,
without the practical incentives of a free beer system that other open
source projects have had working in their favor.
Just a thought...
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
Re: half-baked idea? j2me
Posted by Robin Garner <ro...@anu.edu.au>.
>> On 11/1/05, Robin Garner <Ro...@anu.edu.au> 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
Posted by Robin Garner <Ro...@anu.edu.au>.
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
Posted by Archie Cobbs <ar...@dellroad.org>.
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
Posted by Mark Wielaard <ma...@klomp.org>.
Hi Craig,
On Thu, 2005-11-03 at 09:06 -0800, Craig Blake wrote:
> In the course of various jobs I've had to look at lots of chunks of
> the Sun library sources and VM code. I was under the impression that
> this would be a problem?
Yes, studying proprietary source could while working for a similar Free
Software project could be troublesome. But it depends of course on the
situation. See for more background the GNU Classpath wiki:
http://developer.classpath.org/mediation/ClasspathFirstSteps
It also contains lots of suggestions for tasks and projects that would
be super useful and are fine to work on in any case, such as:
* write Mauve test cases
* write example applications demonstrating the usage of the API
* writing/fixing helper programs (like japitools) and scripts
* report bugs
* help fixing the documentation
* help in other Java-related Free software projects (e.g. virtual
machine development, Eclipse, GUMP, etc.)
Hope that helps.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: half-baked idea? j2me
Posted by Craig Blake <cr...@mac.com>.
In the course of various jobs I've had to look at lots of chunks of
the Sun library sources and VM code. I was under the impression that
this would be a problem?
Craig
On Nov 3, 2005, at 7:55 AM, Geir Magnusson Jr. wrote:
> Why are you too tainted?
>
> geir
>
> On Nov 2, 2005, at 11:11 PM, Craig Blake wrote:
>
>> Some of us are still hoping for a mostly Java based
>> implementation. While I am apparently too "tainted" to contribute
>> much, it will make it a lot more fun to play around with.
>>
>> Craig
>>
>> On Nov 1, 2005, at 6:05 PM, Robin Garner wrote:
>>
>>
>>> Rodrigo Kumpera wrote:
>>>
>>>
>>>> On 11/1/05, Robin Garner <ro...@anu.edu.au> wrote:
>>>>
>>>>
>>>>>> On 11/1/05, Robin Garner <Ro...@anu.edu.au> 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
>>>
>>
>>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
Re: half-baked idea? j2me
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Why are you too tainted?
geir
On Nov 2, 2005, at 11:11 PM, Craig Blake wrote:
> Some of us are still hoping for a mostly Java based
> implementation. While I am apparently too "tainted" to contribute
> much, it will make it a lot more fun to play around with.
>
> Craig
>
> On Nov 1, 2005, at 6:05 PM, Robin Garner wrote:
>
>
>> Rodrigo Kumpera wrote:
>>
>>
>>> On 11/1/05, Robin Garner <ro...@anu.edu.au> wrote:
>>>
>>>
>>>>> On 11/1/05, Robin Garner <Ro...@anu.edu.au> 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
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: half-baked idea? j2me
Posted by Craig Blake <cr...@mac.com>.
Some of us are still hoping for a mostly Java based implementation.
While I am apparently too "tainted" to contribute much, it will make
it a lot more fun to play around with.
Craig
On Nov 1, 2005, at 6:05 PM, Robin Garner wrote:
> Rodrigo Kumpera wrote:
>
>> On 11/1/05, Robin Garner <ro...@anu.edu.au> wrote:
>>
>>>> On 11/1/05, Robin Garner <Ro...@anu.edu.au> 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: half-baked idea? j2me
Posted by Robin Garner <ro...@anu.edu.au>.
>
> On Nov 4, 2005, at 3:20 AM, Robin Garner wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>
>>>
>>> On Nov 1, 2005, at 9:05 PM, 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.
>>>>
>>>
>>>
>>> C'mon... you still have to deal with that with a Java based VM
>>> because you still need the bootstrap stuff...
>>>
>>> geir
>>>
>>>
>>>
>> Yes, but only in a tiny percentage of the code, only for a handful
>> of API calls, and none of it performance critical.
>>
>
> And all of it requiring configure scripts? :)
>
> geir
Actually probably little enough problematic code that you could write a
separate version for every platform/compiler for comparable effort to
writing the configure script.
cheers
Re: half-baked idea? j2me
Posted by Craig Blake <cr...@mac.com>.
Seems like the difference is that once the little bootstrap piece is
done you wouldn't need to recompile it every time... heck, you might
not ever have to if you could just download a little binary for your
platform.
Craig
On Nov 4, 2005, at 4:21 AM, Geir Magnusson Jr. wrote:
>
> On Nov 4, 2005, at 3:20 AM, Robin Garner wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>
>>>
>>> On Nov 1, 2005, at 9:05 PM, 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.
>>>>
>>>
>>>
>>> C'mon... you still have to deal with that with a Java based VM
>>> because you still need the bootstrap stuff...
>>>
>>> geir
>>>
>>>
>>>
>> Yes, but only in a tiny percentage of the code, only for a handful
>> of API calls, and none of it performance critical.
>>
>
> And all of it requiring configure scripts? :)
>
> geir
>
>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
Re: half-baked idea? j2me
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Nov 4, 2005, at 3:20 AM, Robin Garner wrote:
> Geir Magnusson Jr. wrote:
>
>
>>
>> On Nov 1, 2005, at 9:05 PM, 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.
>>>
>>
>>
>> C'mon... you still have to deal with that with a Java based VM
>> because you still need the bootstrap stuff...
>>
>> geir
>>
>>
>>
> Yes, but only in a tiny percentage of the code, only for a handful
> of API calls, and none of it performance critical.
>
And all of it requiring configure scripts? :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: half-baked idea? j2me
Posted by Robin Garner <Ro...@anu.edu.au>.
Geir Magnusson Jr. wrote:
>
> On Nov 1, 2005, at 9:05 PM, 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.
>
>
> C'mon... you still have to deal with that with a Java based VM
> because you still need the bootstrap stuff...
>
> geir
>
>
Yes, but only in a tiny percentage of the code, only for a handful of
API calls, and none of it performance critical.
Re: half-baked idea? j2me
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Nov 1, 2005, at 9:05 PM, 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.
C'mon... you still have to deal with that with a Java based VM
because you still need the bootstrap stuff...
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: half-baked idea? j2me
Posted by Robin Garner <Ro...@anu.edu.au>.
Rodrigo Kumpera wrote:
>On 11/1/05, Robin Garner <ro...@anu.edu.au> wrote:
>
>
>>>On 11/1/05, Robin Garner <Ro...@anu.edu.au> 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: half-baked idea? j2me
Posted by Rodrigo Kumpera <ku...@gmail.com>.
On 11/1/05, Robin Garner <ro...@anu.edu.au> wrote:
> > On 11/1/05, Robin Garner <Ro...@anu.edu.au> 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
Posted by Robin Garner <ro...@anu.edu.au>.
> On 11/1/05, Robin Garner <Ro...@anu.edu.au> 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
Posted by Rodrigo Kumpera <ku...@gmail.com>.
On 11/1/05, Robin Garner <Ro...@anu.edu.au> 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: half-baked idea? j2me
Posted by Mark Wielaard <ma...@klomp.org>.
Hi David,
On Tue, 2005-11-01 at 10:12 +0100, David N. Welton wrote:
> 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/
As you might have seen on http://planet.classpath.org/ this emulator is
now working with the different GNU Classpath based runtimes:
http://www.spindazzle.org/green/index.php?p=67
It looks pretty.
And to confirm that we are serious about making sure our solution will
be as modular as possible there has now been an offer from a university
to explore the possibilities of a micro edition of GNU Classpath plus
the Cacao vm for which they want to sponsor some student work. See the
recent "J2ME classes in GNU classpath" thread on the mailinglist:
http://lists.gnu.org/archive/html/classpath/2005-11/
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: half-baked idea? j2me
Posted by "David N. Welton" <da...@dedasys.com>.
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: half-baked idea? j2me
Posted by Robin Garner <Ro...@anu.edu.au>.
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.
>After that, a jvm that runs in no device is pretty much useless, then
>we would need to test in the many devices we would support. Developing
>for a smartphone platform, like Symbian, BREW or Nokia Series 60
>(Symbian based) would make it easier, but not easy.
>
>But I cannot say that the idea is bad, as the j2me implementations out
>there are really bad comparing to the j2se offerings. Maybe with a
>FOSS jvm that is pretty solid, many vendors would stop bundling buggy
>software and more convergence of optional capabilities and bugs would
>happen.
>
>I'm just not sure that such project would fit the Harmony proposal, as
>the idea is to implement a j2se compatible jvm.
>
>
>
>On 10/31/05, David N. Welton <da...@dedasys.com> wrote:
>
>
>>Hello,
>>
>>I'm interested in having a freely available Java system, which seemed as
>>good a reason as any to start lurking on this list lately.
>>
>>I've been mulling over what I've seen in the archives here, what I know
>>of the free java world, free software, communities, marketing, and
>>various and sundry other things and an idea popped into my head.
>>Perhaps, like many others, it's a dumb one, but I thought I'd lob it out
>>there just the same:
>>
>>Why not start out with j2me?
>>
>>*) It'd be breaking new ground - something no one has done before in the
>>'free' world (to my knowledge at least). That, to me at least, would
>>increase the fun quotient.
>>
>>*) It's small, which would make it easier to get running - or at least
>>easier to make it complete.
>>
>>*) It's simple. To my knowledge, in order to stay small, most
>>implementations are interpreters (possibly assisted in hardware through
>>things like Jazelle).
>>
>>*) Modulo space saving optimizations, it could then be used as a launch
>>pad for "bigger and better things" should we so desire.
>>
>>*) Perhaps there are some financial incentives for corporations to get
>>involved. J2SE is "free beer", so the impetus to work on a free version
>>mostly comes from a desire to have an open source Java available,
>>without the practical incentives of a free beer system that other open
>>source projects have had working in their favor.
>>
>>Just a thought...
>>--
>>David N. Welton
>>- http://www.dedasys.com/davidw/
>>
>>Linux, Open Source Consulting
>>- http://www.dedasys.com/
>>
>>
>>
Re: half-baked idea? j2me
Posted by Rodrigo Kumpera <ku...@gmail.com>.
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.
After that, a jvm that runs in no device is pretty much useless, then
we would need to test in the many devices we would support. Developing
for a smartphone platform, like Symbian, BREW or Nokia Series 60
(Symbian based) would make it easier, but not easy.
But I cannot say that the idea is bad, as the j2me implementations out
there are really bad comparing to the j2se offerings. Maybe with a
FOSS jvm that is pretty solid, many vendors would stop bundling buggy
software and more convergence of optional capabilities and bugs would
happen.
I'm just not sure that such project would fit the Harmony proposal, as
the idea is to implement a j2se compatible jvm.
On 10/31/05, David N. Welton <da...@dedasys.com> wrote:
> Hello,
>
> I'm interested in having a freely available Java system, which seemed as
> good a reason as any to start lurking on this list lately.
>
> I've been mulling over what I've seen in the archives here, what I know
> of the free java world, free software, communities, marketing, and
> various and sundry other things and an idea popped into my head.
> Perhaps, like many others, it's a dumb one, but I thought I'd lob it out
> there just the same:
>
> Why not start out with j2me?
>
> *) It'd be breaking new ground - something no one has done before in the
> 'free' world (to my knowledge at least). That, to me at least, would
> increase the fun quotient.
>
> *) It's small, which would make it easier to get running - or at least
> easier to make it complete.
>
> *) It's simple. To my knowledge, in order to stay small, most
> implementations are interpreters (possibly assisted in hardware through
> things like Jazelle).
>
> *) Modulo space saving optimizations, it could then be used as a launch
> pad for "bigger and better things" should we so desire.
>
> *) Perhaps there are some financial incentives for corporations to get
> involved. J2SE is "free beer", so the impetus to work on a free version
> mostly comes from a desire to have an open source Java available,
> without the practical incentives of a free beer system that other open
> source projects have had working in their favor.
>
> Just a thought...
> --
> David N. Welton
> - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
> - http://www.dedasys.com/
>
Re: [modularity] OSGi or ? (was Re: half-baked idea? j2me)
Posted by Dalibor Topic <ro...@kaffe.org>.
Tim Ellison wrote:
> I understand that the topic relates to the mechanics of achieving the
> componentization rather than the content of the components, but I
> proposed a componentization split for the J2SE libraries a while ago [1]
> and the final version ended up on the Harmony wiki [2]. That was done
> only with J2SE in mind, by trying to define the large 'functional units'
> of the class library code. (I feel like I keep recycling old
> messages... so apologies for the repetition.)
I've had something like that in place for Kaffe for a while during a few
years, but I found the manual updating of component sets during the rush
of development on GNU Classpath to be, ugh, somewhat boring work, and
settled for for an approach where the list of classes to be compiled can
be pruned down, or left to the compiler to pull in the dependencies.
I am wondering if the osgi toolkits support some more automated ways of
partitioning libraries into separate, coupled artefacts. I've heard on
the classpath list, that such tools exist[1], but it seems that I've my
google skills are not good enough to locate them :)
cheers,
dalibor topic
[1] http://lists.gnu.org/archive/html/classpath/2005-10/msg00180.html
Re: [modularity] OSGi or ? (was Re: half-baked idea? j2me)
Posted by Tim Ellison <t....@gmail.com>.
I understand that the topic relates to the mechanics of achieving the
componentization rather than the content of the components, but I
proposed a componentization split for the J2SE libraries a while ago [1]
and the final version ended up on the Harmony wiki [2]. That was done
only with J2SE in mind, by trying to define the large 'functional units'
of the class library code. (I feel like I keep recycling old
messages... so apologies for the repetition.)
I think it would be quite a different story if the goal was to support
ME configurations, where there are (necessarily) limited capabilities as
well as limited sets of types. For example, you would like to be able
to define 'serialization' as a capability that j.u.Hashtable has in SE,
but not in CLDC. That would require a different form of modularity to
the definition that j.u.HashMap is defined in SE but not CLDC.
Regards,
Tim
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200507.mbox/browser
[2] http://wiki.apache.org/harmony/ClassLibrary
Mark Wielaard wrote:
> Hi Geir,
>
> On Thu, 2005-11-03 at 10:54 -0500, Geir Magnusson Jr. wrote:
>
>>On Nov 3, 2005, at 10:30 AM, Mark Wielaard wrote:
>>
>>>This is one of the "hot topic" on the GNU Classpath mailinglist.
>>>How do we define "bundles" so people can more easily mix and match precisely
>>>those core library parts they want. See the discussions on
>>>http://lists.gnu.org/archive/html/classpath/ if you are not yet
>>>subscribed. Maybe we could use something like OSGi bundles for
>>>this. But the core libraries are pretty interwoven so there is a lot of
>>>dicsussion what the right approach is.
>>
>>What other approaches have you been considering?
>
>
> Basically what people do now is solve it for their own platform
> separately. You can see examples of that for gcj which is of course
> ported to losts of different (small) devices. Best is to follow the
> discussion on the mailinglist, the last thread about this was stated by
> Peter Kriens (Using OSG for Classpath):
> http://lists.gnu.org/mailman/listinfo/classpath
>
> Cheers,
>
> Mark
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [modularity] OSGi or ? (was Re: half-baked idea? j2me)
Posted by Mark Wielaard <ma...@klomp.org>.
Hi Geir,
On Thu, 2005-11-03 at 10:54 -0500, Geir Magnusson Jr. wrote:
> On Nov 3, 2005, at 10:30 AM, Mark Wielaard wrote:
> > This is one of the "hot topic" on the GNU Classpath mailinglist.
> > How do we define "bundles" so people can more easily mix and match precisely
> > those core library parts they want. See the discussions on
> > http://lists.gnu.org/archive/html/classpath/ if you are not yet
> > subscribed. Maybe we could use something like OSGi bundles for
> > this. But the core libraries are pretty interwoven so there is a lot of
> > dicsussion what the right approach is.
>
> What other approaches have you been considering?
Basically what people do now is solve it for their own platform
separately. You can see examples of that for gcj which is of course
ported to losts of different (small) devices. Best is to follow the
discussion on the mailinglist, the last thread about this was stated by
Peter Kriens (Using OSG for Classpath):
http://lists.gnu.org/mailman/listinfo/classpath
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
[modularity] OSGi or ? (was Re: half-baked idea? j2me)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Nov 3, 2005, at 10:30 AM, Mark Wielaard wrote:
>
> This is one of the "hot topic" on the GNU Classpath mailinglist.
> How do
> we define "bundles" so people can more easily mix and match precisely
> those core library parts they want. See the discussions on
> http://lists.gnu.org/archive/html/classpath/ if you are not yet
> subscribed. Maybe we could use something like OSGi bundles for
> this. But
> the core libraries are pretty interwoven so there is a lot of
> dicsussion
> what the right approach is.
What other approaches have you been considering?
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: half-baked idea? j2me
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Mon, 2005-10-31 at 18:30 -0500, Geir Magnusson Jr. wrote:
> 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....
>
> I think that you'll be fairly satisfied with what we come up with.
Agreed. If you see what is possible now with for example jamvm and
different profiles/chunks of the core library from GNU Classpath you can
see that you can get as small or large as you want:
http://www.aqute.biz/2005/10/osgi-on-slug.html
http://planetmarrs.xs4all.nl/site/index.php?option=com_content&task=view&id=14&Itemid=1
This is one of the "hot topic" on the GNU Classpath mailinglist. How do
we define "bundles" so people can more easily mix and match precisely
those core library parts they want. See the discussions on
http://lists.gnu.org/archive/html/classpath/ if you are not yet
subscribed. Maybe we could use something like OSGi bundles for this. But
the core libraries are pretty interwoven so there is a lot of dicsussion
what the right approach is.
Cheers,
Mark
Re: half-baked idea? j2me
Posted by "David N. Welton" <da...@dedasys.com>.
Robert Lougher wrote:
> 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.
So you'd want to target MIDP2.0 for an implementation, and everything
for a development environment and emulator, as MIDP1.0 phones are still
on sale and will be used for years to come.
I found this paper on the virtual machine... looks like they are
doing/trying to do JIT:
http://java.sun.com/products/cldc/wp/CLDC_HI_WhitePaper.pdf
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
Re: half-baked idea? j2me
Posted by Robert Lougher <ro...@gmail.com>.
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 <da...@dedasys.com> 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
Posted by "David N. Welton" <da...@dedasys.com>.
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
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Do you really mean J2ME for a specific purpose?
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....
I think that you'll be fairly satisfied with what we come up with.
geir
On Oct 31, 2005, at 5:02 PM, David N. Welton wrote:
> Hello,
>
> I'm interested in having a freely available Java system, which
> seemed as
> good a reason as any to start lurking on this list lately.
>
> I've been mulling over what I've seen in the archives here, what I
> know
> of the free java world, free software, communities, marketing, and
> various and sundry other things and an idea popped into my head.
> Perhaps, like many others, it's a dumb one, but I thought I'd lob
> it out
> there just the same:
>
> Why not start out with j2me?
>
> *) It'd be breaking new ground - something no one has done before
> in the
> 'free' world (to my knowledge at least). That, to me at least, would
> increase the fun quotient.
>
> *) It's small, which would make it easier to get running - or at least
> easier to make it complete.
>
> *) It's simple. To my knowledge, in order to stay small, most
> implementations are interpreters (possibly assisted in hardware
> through
> things like Jazelle).
>
> *) Modulo space saving optimizations, it could then be used as a
> launch
> pad for "bigger and better things" should we so desire.
>
> *) Perhaps there are some financial incentives for corporations to get
> involved. J2SE is "free beer", so the impetus to work on a free
> version
> mostly comes from a desire to have an open source Java available,
> without the practical incentives of a free beer system that other open
> source projects have had working in their favor.
>
> Just a thought...
> --
> David N. Welton
> - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
> - http://www.dedasys.com/
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org