harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: half-baked idea? j2me
Date Thu, 03 Nov 2005 15:55:10 GMT
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 <robin.garner@anu.edu.au> wrote:
>>>
>>>
>>>>> On 11/1/05, Robin Garner <Robin.Garner@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



Mime
View raw message