Trying to work newer indy into JRuby
forax at univ-mlv.fr
Tue May 19 01:00:30 PDT 2009
Fredrik Öhrström a écrit :
> Charles Oliver Nutter skrev:
>> I must also remark how similar this feels to LLVM's method invocation
>> APIs, where they toss "function" objects into the IR and it just
>> optimizes the calling logic. It seems to me that the new indy stuff
>> could be the underpinnings of a "JVM-LLVM" API that represents basic
>> blocks as concrete code bodies and transitions as method handle
> I couldn't agree more! In fact, as long as we can
> limit the combinatorial explosion of method descriptors
> we will not even need a specific API.
> Generating new code from plain Java code (with no bytecode gen)
> would simply be done by stringing together methods with
> final and bound method handles. This makes it really easy
> for the optimizer to inline the code. I tried to make this
> point in my blog earlier.
> Because of this, the factory methods for adapters/transforms
> like GuardWithTest et.al. should not be needed. (Even though
> there might be a utility factory for commonly used transforms
> somewhere.) I strongly believe that the dynamic language
> runtime developers and the JVM developers should stand on
> equal footing when it comes to creating new transforms.
If you take a close look to the current API:
there are not lot of primitive adapters, i.e adapters that can not be
The purpose of primitive adapters is to hep the language developer to fight
the inherent complexity of dealing with polymorphic signature.
In case of Jython or JRuby (correct me if I'm wrong) but current
massively use method with object as parameter type.
In that case, guards etc can be implemented using only convert, spread
and the JavaMethodHandle.
But, for my pet project, for Groovy or for Neal's closure, you have to
signatures including primitive types.
In that case, insert/drop, permute and combine/guardWithTest are very
More information about the mlvm-dev