Andy, Can you please pass the info where did you get the wiki? any URL?. Appreciate it.
Thanks! naren On 5/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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)
