Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v728)
In-Reply-To: <4281AAFF.3030805@apache.org>
References: <69f3b8db050510185671455bd7@mail.gmail.com>
	 <69f3b8db0505101900427c1bfe@mail.gmail.com>
 <4281998C.607@apache.org>	 <4281A302.9030105@apache.org>
 <69f3b8db0505102326223883a4@mail.gmail.com> <4281AAFF.3030805@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C04532A7-8F57-43D0-92C1-1956CB154D20@ieee.org>
Content-Transfer-Encoding: 7bit
From: Paul Gearon <gearon@ieee.org>
Subject: Re: I hope the JVM implements most using Java itself
Date: Wed, 11 May 2005 21:51:14 +1000
To: harmony-dev@incubator.apache.org


On 11/05/2005, at 4:49 PM, Torsten Curdt wrote:

>> maybe we can think the JIT Compiler as a simple box which input  
>> "bytecode"
>> and output "machine code".
>>
>
> ...native machine code I assume.
>
> All ok but ...now how do you
> want to execute that from java - easily?

Not saying you want to do it this way, but a question like this  
demands an answer.  :-)

Use System.getProperty()  with os.arch for the CPU type and os.name/ 
os.version for the OS.  These tell you what type of native code to  
generate.  It doesn't matter what language you write it in, you need  
different implementations for different OS/architectures.

Put the generated code into a byte array, or better yet, a  
MappedByteBuffer.  Then send the whole lot off to a native method  
that calls into the pointer it's given.  The native library needed to  
do that could be implemented in a trivially small dll, so, dylib,  
etc.  If you really want to avoid using other languages, even for  
this, then since you already have Java building native code, the  
startup code for the JIT could write out it's own binary library  
before loading it.

The hardest part about all of this, is the code that JITs bytecode  
into native instructions.  Not difficult, but very time consuming.

The alternatives are probably better, but this doesn't sound hard to  
me.  :-)

Regards,
Paul Gearon