CallSite constructor first argument not a class?

Rémi Forax forax at univ-mlv.fr
Sat Dec 12 15:24:03 PST 2009


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





More information about the mlvm-dev mailing list