Le 12/12/2009 22:57, John Rose a écrit : > On Dec 12, 2009, at 1:16 AM, Emmanuel Castro wrote: > > >> I realize that the first argument of the CallSite constructor >> >> public CallSite(Object caller, String name, MethodType type) >> >> is not typed as a Class. However, when one uses it it a bootstrap >> method, it must be a Class (it is checked in >> sun.dyn.CallSiteImpl.makeSite()). >> >> What is the ideas behind that. When would it be safe (and usefull) to use >> some >> of argument type? >> > Good question. It was put that way in early design before we had much coding > experience with the APU. I think it can the narrowed to Class. > > The idea is that in some systems, call sites might be created in a way > decoupled from bytecode, during an interpretive phase, and later (perhaps) > associated with generated bytecode. In that case, there might not always be > a bytecoded Class that goes with the site. Instead, there might be an > "InterpreterClass" (hypothetical) which is not yet coded (and may never be) > > But, since CallSite it not final, if you want to make such a site, you can > just add a field to point to an "InterpreterClass". So there's no harm in > strongly typing the class. (For the case of an "InterpreterClass", the Class > value might be some placeholder class like MyInterpreter.class.) > > Thanks for the comment, Emmanuel. >
Hi John, about CallSite, I've asked several times to be able to create a CallSite only with a MethodType, other data seems inessential and because CallSite is not final Knowing that we have at least one object CallSite by call site, lightweight CallSite is appealing. > -- John > > P.S. I've been busy experimenting with using the API for several weeks. > It's been fun. I'll share results soon. > great. Rémi _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
