harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acoli...@apache.org
Subject Re: Sending native code to the processor at runtime
Date Sat, 14 May 2005 01:23:51 GMT
Ah, thank you very kindly Davanum.  It took me a bit to find the wiki, 
but once I did.  I've read about half way through the first paper and I'm
already intrigued.  The whole "threaded inlining" thing is something 
I've never thought about or done before but is really an elegant way to 
hijack
the compiler to do your work for you. 

Basically the compiler writes your machine code for you anyhow.  I'm 
quite curious about the claims that it achieves 70% of native 
performance (which
is really quite good) in microbenchmarks.  It also seems to me like this 
threaded inlining might be a way in which you could swap in your own 
native code if
you wanted to do optimization.  I had been thinking in assembler when 
thinking about how this could be done and for some reason it didn't 
occur to me to do
some of those tricks with C and let it worry about the rest.

I'm not sure what this inlining and the such means for garbage 
collection, error reporting and stack allocation but it is really 
nifty.  I had been thinking for some
time that interpreted code was kind of dumb.  That maybe just ditching 
the entire concept of non-JITing was the best thing.  Sure you pay a 
penalty for startup time.
however, the more I think about it, since JITing is tied to classes and 
classes are tied to classloaders then any kind of serialization, 
scoping/etc would be a problem. 
One could walk around this by not obeying CL x FQN semantics for JIT 
purposes, but then you have to do some kind of binary analysis which 
could frankly be worse,
especially with the possibility of custom classloaders (don't you hate 
those ha ha ha -- those who will know -- know).

So I think there will be intepreted code and some kind of "patch in" for 
hot methods similar to hotspot.  I have to say though that I rather like 
the idea of eager JIT-compiling all
base libraries at startup (toggleable of course).  One of the things I 
like about this inlining is that it practically means that Harmony could 
achieve a near-decent degree of performance on nearly every platform 
that GCC supports.  That seems like a rather cool thing.

I'm still wrapping my mind around the issue with GETSTATIC and function 
calls.  I see what they mean about the performance issue of checking to 
see if the class is loaded and having to make a function call, but isn't 
that still a problem with native code too?  How is this specific to the 
method of inlining?

-Andy

Davanum Srinivas wrote:

>Andy,
>
>check the wiki. there are some papers of interest.
>
>-- dims
>
>On 5/13/05, acoliver@apache.org <acoliver@apache.org> wrote:
>  
>
>>It has been a considerable time since I did programming at that level
>>but can someone tell me how:
>>
>>If you are running code, generate some binary code, how do you schedule
>>it to run on the processor (and preferably in an unbounded way).  I
>>believe IIRC you can copy it into the code segment.   Can someone point
>>me to a good reference or better yet some reasonably well written source
>>which does this?
>>
>>Thank you very much.
>>
>>-andy
>>--
>>Andrew C. Oliver
>>SuperLink Software, Inc.
>>
>>Java to Excel using POI
>>http://www.superlinksoftware.com/services/poi
>>Commercial support including features added/implemented, bugs fixed.
>>
>>    
>>
>
>
>  
>


-- 
Andrew C. Oliver
SuperLink Software, Inc.

Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.


Mime
View raw message