John Rose a écrit :
> On May 21, 2008, at 1:47 PM, Rémi Forax wrote:
>
>
>>> Open question: Does BCI need to be exposed in the StaticContext?
>>> Default answer: No, not useful enough, and there are workarounds if
>>> such information is needed.
>>>
>>>
>> I can see a use case that require BCIs to be exposed. The compiler can
>> encode
>> information (by example reified generics :) in one annotation (runtime
>> invisible)
>> in a table BCI -> runtime type and use the BCI provided at callsite
>> to extract runtime type from the annotation.
>>
>> In the same time, i wonder if it can prevent optimisation like
>> inlining.
>>
>
> It is also fragile. There are some JVM features (e.g., debugging and
> AOP) which edit bytecodes after a bytecode backend creates them and
> before the JVM runs them. These features can shift BCIs, so they are
> an unstable (buggy) key to use for distinguishing call sites.
>
ok.
> Here's what I'm thinking of adding to the spec.:
>
>>> (<em>Note:</em> There is no need to specify a bytecode index in a
>>> call site’s static context. Such a number would not be very
>>> useful, even if the dynamic language backend built some sort of
>>> BCI-based table, because low-level bytecode editing could change
>>> bytecode indexes independently of the backend. If individual call
>>> sites must be distinguished, and if the call site objects
>>> themselves are unsuitable as map keys, the language backend can
>>> create extra back-channels by embedding data in the method name
>>> string, or in hidden arguments.)
>>>
hidden argument -> extra space used before by quick invokeinterface opcode ?
There is currently no way to access to that info.
>
>> I wonder if the separation of static/dynamic states is not a premature
>> optimization.
>> The spec could be relaxed and only require one class CallSite and let
>> the VM implementors
>> choose if they want to create only one class or more in order to share
>> states between
>> call sites.
>>
>
> It is easier (IMO) to define, document, and implement an immutable
> object which is then an immutable property of a mutable object, than
> to document a merged object with some properties mutable and others
> not. Also, the two kinds of data have inherently different object
> identity behaviors. One is a value object and the other a non-
> forgeable capability reference. To me it looks confusing to merge them.
>
Ok, it's more easy to explain but I clearly understand the meaning of
ClassSite
and its semantics. It's not that obvious for StaticContext
> I'm considering this language to explain the distinct roles:
>
>>> The interface <code>StaticContext</code> provides a channel for
>>> the JVM to inform bootstrap code of which call sites are being
>>> linked.
Bootstrap code uses CallSite not StaticContext.
Object bootstrapInvokeDynamic(CallSite site, Object receiver, Object...
arguments)
So i don't understand why you need this object.
Is it because you need it to simplify VM internals ?
In that case, isn't it too hotspot specific ?
>>> A static context is immutable linkage information
>>> permanently associated with each call site. It is pure structure;
>>> its identity (as detected by reference equality) is insignificant.
>>>
>>> The interface <code>CallSite</code> provides the necessary
>>> ‘hook’ for bootstrap methods (or failing methods) to
>>> update the state of an <code>invokedynamic</code>
>>> instruction’s linkage state. A call site has a single
>>> mutable variable, the target method, plus an immutable static
>>> context. The identity of a call site object (as detected by
>>> reference equality) is significant
[...]
>> This allows by example to only create one CallSite by thread and
>> populate it
>> with the information as needed.
>>
>
> No, CallSite objects are durable references, even across threads.
>
ok. so a CallSite can be stored and setTarget() can be called at any time.
[...}
>
>> Someting like:
>> CallSiteQuery query=CallSiteQueris.and(CallSiteQueries.name("hello") ,
>> CallSiteQueries.callerClass(Dummy.class));
>> Linkage.invalidate(query); // invalidate at least all call sites with
>> name "hello" and caller class Dummy
>> // it can invalidate more
>> call
>> sites (perhaps all).||
>>
>
> That looks nice. Hmm. Is there a way to do something like this
> without pushing all that implementation down into the JVM?
>
yes, that the idea. This is just the external Java API.
The internal one depends on how the VM is able to invalidate call sites.
> -- John
>
> P.S. I will be collecting possible EDR diffs on my weblog, at:
> http://blogs.sun.com/jrose/resource/InvokeDynamic-EDR-diffs.html
>
>
cheers,
Rémi
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
