On Thu, Nov 18, 2010 at 6:14 PM, Alex Osborne <a...@meshy.org> wrote: > Alyssa Kwan <alyssa.c.k...@gmail.com> writes: > >> Perfect! That makes things so much easier! I assume that interning >> vars is synchronized then? This is the second big source code read >> FAIL in two days. Obviously I can't read. :) > > They're stored in an AtomicReference (basically an atom).
Eww. Wouldn't a java.util.concurrent.ConcurrentHashMap give better performance in highly parallel situations? Then again, var interning isn't exactly the commonest of run-time operations, except when the program running is a development REPL, and that tends to be I/O bound, spending most of its time waiting for a response from the 30- to 40-baud Homo sapiens at the other end of the connection. Still, it probably wouldn't *hurt*. Who knows what future applications might need to intern vars in a tight loop for some purpose? One day we might have a fairly fast AI on the other end of that REPL instead of a human. Or something. >> Because it's not at compile time, I don't have access to the expr that >> generates the function. Stuart Halloway mentioned an invoke-time >> check for recompilation, which I assume requires the function to hang >> onto the expr and lexical environment which generates it. AFAICT, >> there is no such reference, and invoke-time lookups through vars are >> still being used; I'm probably not looking in the right place. > > I can't find something like that either and I can't see why it would > exist. Perhaps he was talking about JIT recompilation, not source > recompilation? If so, Alyssa's concern is moot; JIT recompilation would just translate the pre-existing bytecodes in a deterministic manner. If the bytecodes work properly when invoked and the JIT compiler lacks bugs, the JIT-compiled code will also work properly, lexical environment be damned. If the recompilation at issue involves regenerating bytecode from s-expressions, on the other hand, it's a whole 'nother kettle of fish. -- 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
