Attila Szegedi wrote:
> On Sep 3, 2008, at 11:56 PM, John Rose wrote:
>> Yes, that's the easier way to get customization, via inlining. We
>> probably need an @Inline annotation (use this Power only for Good).
>
> Why would we need an explicit inline annotation? I was under
> impression that use of invokedynamic would open the opportunity for
> HotSpot to inline the code with certain types of MethodHandles.
The Inline annotation would be a hint to hotspot that a given method
should at all costs be inlined into its callers (if I remember
discussions with John correctly). Potentially this could also be an
explicit way to break the N-bytecode size limit for inlined methods.
Basically I see it as a way to hint to hotspot that it shouldn't use a
given method as an inlining root, and should always try to force it into
its callers. I have many such cases in JRuby where I'd love to be able
to poke hotspot a bit.
>>> It seems to me that type specialization is a more broadly
>>> applicable, more generic, and thus more powerful concept that allows
>>> for finer-grained (method level) specializations/optimizations than
>>> doing it on a level of whole classes.
>> The V8 technique sounds like a successor to Self's internal classing
>> mechanism; it sounds more retroactive. A key advantage of such
>> things is removal of indirections and search. If you want the "foo"
>> slot of an object in a prototype based language, it's better if the
>> actual data structures have fewer degrees of freedom and less
>> indirections; ideally you use some sort of method caching to link
>> quickly to a "foo" method which performs a single indirection to a
>> fixed offset. If the data structure has many degrees of freedom
>> (because there is no normalization of reps.) then you have to treat
>> the object as a dictionary and search for the foo more often. You
>> might be able to lookup and cache a getter method for obj.foo, but it
>> would be even better to have a fixed class for obj, which you test
>> once, and use optimized getters and setters (of one or two
>> instructions) for all known slots in the fixed class.
>
>
> Yeah, my wet dream of combining this with the type specialization of
> methods above, is that you could have this JS code:
...
> and then HotSpot further JITs it to efficient native code.
Yeah, me too. And the primary thing that has kept me from trying to
implement such in JRuby is the risk of running on a JVM version that
holds onto loaded bytecode with a kung-fu death grip, eventually blowing
permgen. Bytecode Freedom! Bytecode Freedom!
> The only difference is that the class name as generated would probably
> be $$autogenerated$$0fc45e9a or something of similar beauty, and not
> "Complex" :-)
Perhaps it's time for an analog to JSR-42 that provides a mapping from
mangled class and method names to actual names. I've got a "hybrid"
stack trace generator in JRuby right now that mines StackTraceElement[]
for known interpreter calls and replaces them with information from
interpreter frames:
~/NetBeansProjects/jruby ➔ jruby -rjava
-J-Djruby.backtrace.style=RUBY_HYBRID -d -e "def foo; raise; end; foo"
java.lang.Thread:1426:in `getStackTrace': unhandled exception
from org.jruby.RubyException:141:in `setBacktraceFrames'
from org.jruby.exceptions.RaiseException:146:in `setException'
from org.jruby.exceptions.RaiseException:69:in `<init>'
from org.jruby.RubyKernel:756:in `raise'
from org.jruby.java.addons.KernelJavaAddons:26:in `rbRaise'
from :1:in `foo'
from org.jruby.internal.runtime.methods.DynamicMethod:225:in `call'
from org.jruby.internal.runtime.methods.DynamicMethod:202:in `call'
from org.jruby.runtime.CallSite$InlineCachingCallSite:592:in
`cacheAndCall'
from org.jruby.runtime.CallSite$InlineCachingCallSite:169:in `call'
from -e:1:in `foo'
from ruby.__dash_e__Invokermethod__0$RUBY$fooFixed0:-1:in `call'
from org.jruby.internal.runtime.methods.CompiledMethod:216:in `call'
from org.jruby.runtime.CallSite$InlineCachingCallSite:592:in
`cacheAndCall'
from org.jruby.runtime.CallSite$InlineCachingCallSite:169:in `call'
from -e:1: `<toplevel>'
from -e:-1: `<toplevel>'
from ruby.__dash_e__:-1:in `load'
from org.jruby.Ruby:547:in `runScript'
from org.jruby.Ruby:460:in `runNormally'
from org.jruby.Ruby:333:in `runFromMain'
from org.jruby.Main:214:in `run'
from org.jruby.Main:100:in `run'
from org.jruby.Main:84:in `main'
Note the `foo' and `<toplevel>' lines here interspersed with the normal
Java lines.
- Charlie
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
