On Jan 16, 6:18 pm, Sean Corfield <seancorfi...@gmail.com> wrote: > On Sun, Jan 16, 2011 at 3:50 PM, Jason Wolfe <ja...@w01fe.com> wrote: > > Moreover, we do not need to redefine the class at run-time. A simple > > way to do this: when you compile a function with arithmetic > > operations, concatenate bytecode for two versions: essentially, one > > with the unprimed (exception-throwing) ops and one with the primed > > (overflowing) ones. Now, replace the exceptions in the first path > > with local jumps into the second path. There are probably ways to get > > around generating two copies of the bytecode in advance, and making > > such a unilateral shift to inefficient semantics, but I don't know > > enough about JVM internals to say for sure. > > The problem is that if you have an arbitrary form that can operate > entirely in primitives (some loop/recur perhaps) and you allow > primitives to magically convert to Objects in that code, then the > entire piece of code has to handle both primitives AND Objects and > every single sub-form must be capable of handling primitives as input > AND Objects as input and returning primitives if possible... > > You can't have automatic promotion to Object from primitive and expect > any reasonable code to be generated that can maintain primitive > performance across arbitrary expressions. Either everything can work > with Objects - and you lose performance - or everything must be able > to work within primitives (and at most throw exceptions) and remain > performant.
I think you can. Let me elaborate on my simplistic example. Compile the code for a function twice -- once where everything works within primitives, and once where everything works with Objects -- and concatenate the bytecode together. Start by running the primitive version. On overflow, jump into the corresponding spot in the object version (after some patching up / boxing) -- rather than throwing an exception. If no overflow happens, you run *exactly* the same bytecode as the current unprimed ops. (I'm not sure how this would interact with JIT compared to exceptions, though). As soon as overflow happens, you run code as if all of the operations were primed, until function call exit. I believe this is related to the approach used by TraceMonkey, Firefox's Javascript compiler: http://hacks.mozilla.org/2009/07/tracemonkey-overview/ Anyway, I'll leave this be now; I just wanted to mention the idea since I hadn't seen it discussed. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
