On Thu, Sep 30, 2010 at 4:03 PM, Helmut Eller <eller.hel...@gmail.com> wrote: > * Alessio Stalla [2010-09-30 13:28] writes: > >>> I guess you could avoid reflection if you generate a custom bootstrap >>> method for each callsite. Hmm.. probably just as clumsy as reflection. >> >> Yeah, clumsy and suffering from code bloat - I'm already disturbed to >> have one static block registering the bootstrap method > > I think with the new fancy constants you can put the bootstrap > method(handle) in the constant pool and the invokedynamic instruction > refers to the constant pool; no registering required.
Ok, interesting, I wasn't aware of that. >> for each class (i.e. per compiled function). I'd have much preferred >> if bootstrap method registration were inheritable. > > Can't you put many lisp functions in one class file? At least for > non-closure functions that seems possible. It is possible, and it's something we eventually want to support, but currently we have strictly one class file per function (though local non-closure functions are inlined when possible). Less than one class per top-level function is probably not worth the effort though, imho. >> But that aside, after all >> reflection will only be used the very first time the callsite is >> linked, so it shouldn't be much of a problem. > > Reflection is never cheap, at least according to folk wisdom. It's not cheap, especially the first time you reflectively access a given member like in my case, but consider that until some time ago all our functions were loaded from FASLs by using reflection, and that we use autoload a lot, so a little extra cost for every time a call site is first linked does not seem too bad. Of course part of the reason I'm doing this prototype is to find out whether invokedynamic is really beneficial or not for us. Alessio _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
