harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Narendra Harnwal <narendra.harn...@gmail.com>
Subject Re: Sending native code to the processor at runtime
Date Sat, 14 May 2005 04:34:49 GMT
Can you please pass the info where did you get the wiki? any URL?.
Appreciate it.


On 5/13/05, acoliver@apache.org <acoliver@apache.org> wrote:
> 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.

Narendra S Harnwal
201-946-7735 (H)

View raw message