I want to make a comment on OptimizeMethodHandles here, for those users
(extremely important users!) who build and/or use the JSR 292 features while
they are incubating in the mlvm repository.
As we complete the JDK7 cycle, I'm working on a long-standing problem with the
current implementation
These java/lang/invoke tests are failing on my MLVM build today:
InvokeDynamicPrintArgs.java
InvokeGenericTest.java
JavaDocExamplesTest.java
MethodHandlesTest.java
$ jtreg -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions
-XX:+EnableInvokeDynamic
-jdk:build/bsd-amd
On Apr 10, 2011, at 12:39 AM, John Rose wrote:
> P.S. A general note on scheduling: The official Public Review of the JSR 292
> API specification ends on 4/18. Comments are always welcome, but the door
> will close for changes soon after that. As you might guess from looking at
> the JDK7 s
Today I played a bit more with expanding our use of invokedynamic in
JRuby. The experiment today was to replace direct guarded calls with
indy calls.
Specifically, when calling an operator (+, -, <, etc) with a literal
integer, we use a different call site that checks instanceof
RubyFixnum and cal
Hi Charles !
On 04/11/2011 12:18 AM, Charles Oliver Nutter wrote:
> Today I played a bit more with expanding our use of invokedynamic in
> JRuby. The experiment today was to replace direct guarded calls with
> indy calls.
>
> Specifically, when calling an operator (+, -,<, etc) with a literal
> in
On Sun, Apr 10, 2011 at 6:15 PM, Rémi Forax wrote:
> I think you can fix a little bit your implementation:
> First instead of sending the name of the operation at each call
> you should use the indy name to encode that name
> instead of pushing it on the stack.
> So fixnumFallback should bind the
