Le 11/01/2011 11:32, Christian Thalinger a écrit :
> On Jan 10, 2011, at 2:32 PM, Rémi Forax wrote:
>>> I just got back to this bug and now that InvokeDynamic is gone how can I
>>> rewrite that code to work again (without John's Indify magic)?
>>>
>>> -- Christian
>>>
>> Good question.
>>
>> Fir
On Jan 10, 2011, at 2:32 PM, Rémi Forax wrote:
>> I just got back to this bug and now that InvokeDynamic is gone how can I
>> rewrite that code to work again (without John's Indify magic)?
>>
>> -- Christian
>>
>
> Good question.
>
> First, I don't know if this bug is specific to invokedynamic
On 01/10/2011 02:02 PM, Christian Thalinger wrote:
> On Nov 9, 2010, at 4:25 PM, Rémi Forax wrote:
>> Here is an example.
>>If indy has no parameter, it tests void -> indy return type
>>If indy has one parameter, it test parameter type -> return type
>>If indy name is "spread", a spre
On Nov 9, 2010, at 4:25 PM, Rémi Forax wrote:
> Here is an example.
> If indy has no parameter, it tests void -> indy return type
> If indy has one parameter, it test parameter type -> return type
> If indy name is "spread", a spread/collect is done.
>
> Rémi
>
> PS: With the new API, all i
On Nov 11, 2010, at 4:34 PM, Rémi Forax wrote:
> BTW, in int2prim() all comments are wrong.
> Instead of
>
> assertEquals(false, (boolean) InvokeDynamic.foo(i)); //
> void -> boolean
>
>
> it should be
>
> assertEquals( false, (boolean) InvokeDynamic.foo(i)); // int ->
> boolean
That
Le 11/11/2010 16:11, Christian Thalinger a écrit :
> On Nov 9, 2010, at 4:25 PM, Rémi Forax wrote:
>
>> Here is an example.
>>If indy has no parameter, it tests void -> indy return type
>>If indy has one parameter, it test parameter type -> return type
>>If indy name is "spread",
Le 11/11/2010 16:11, Christian Thalinger a écrit :
> On Nov 9, 2010, at 4:25 PM, Rémi Forax wrote:
>
>> Here is an example.
>>If indy has no parameter, it tests void -> indy return type
>>If indy has one parameter, it test parameter type -> return type
>>If indy name is "spread",
On Nov 9, 2010, at 4:25 PM, Rémi Forax wrote:
> Here is an example.
> If indy has no parameter, it tests void -> indy return type
> If indy has one parameter, it test parameter type -> return type
> If indy name is "spread", a spread/collect is done.
>
> Rémi
>
> PS: With the new API, all ide
On Nov 9, 2010, at 6:08 PM, Rémi Forax wrote:
>> Thanks, that helps a lot! But the int -> float/double stuff does
>> not
>> work:
>>
>> Exception in thread "main" java.lang.ClassCastException:
>> java.lang.Integer cannot be cast to java.lang.Float
>> at
>> sun.dyn.util.ValueConversions
Le 09/11/2010 17:20, Christian Thalinger a écrit :
> On Nov 9, 2010, at 4:25 PM, Rémi Forax wrote:
>
>> Le 09/11/2010 14:57, Christian Thalinger a écrit :
>>
>>> On Nov 9, 2010, at 11:43 AM, Rémi Forax wrote:
>>>
>>>
So a workaround for that bug is to declare the return typ
On Nov 9, 2010, at 4:25 PM, Rémi Forax wrote:
> Le 09/11/2010 14:57, Christian Thalinger a écrit :
>> On Nov 9, 2010, at 11:43 AM, Rémi Forax wrote:
>>
>>> So a workaround for that bug is to declare the return type of
>>> invokedynamic
>>> to be not void but by example int.
>>>
>>
>> The fix is tr
Le 09/11/2010 14:57, Christian Thalinger a écrit :
> On Nov 9, 2010, at 11:43 AM, Rémi Forax wrote:
>
>> So a workaround for that bug is to declare the return type of
>> invokedynamic
>> to be not void but by example int.
>>
>
> The fix is trivial but I'd like to implemented to other mi
Remi, with your suggestion and the workaround the bug (by returning int),
here the updated "benchmark". Works, but still much slower than usual
reflection.
The new code is under doDynSyntaxSpread() and displayed as "invoke dynamic
syntax: spread".
Output is at the end.
= = = = = = = = = =
CODE
On Nov 9, 2010, at 11:43 AM, Rémi Forax wrote:
> So a workaround for that bug is to declare the return type of
> invokedynamic
> to be not void but by example int.
The fix is trivial but I'd like to implemented to other missing pieces
too, like int-to-float conversion and friends.
Remi, could
So a workaround for that bug is to declare the return type of
invokedynamic
to be not void but by example int.
thanks,
Rémi
Le 09/11/2010 10:54, Christian Thalinger a écrit :
> On Nov 9, 2010, at 9:33 AM, Rémi Forax wrote:
>> Le 09/11/2010 08:53, Christian Thalinger a écrit :
>>> On Nov 8, 2
On Nov 9, 2010, at 9:33 AM, Rémi Forax wrote:
> Le 09/11/2010 08:53, Christian Thalinger a écrit :
>> On Nov 8, 2010, at 11:46 PM, Rémi Forax wrote:
>>> But sadly, it crashes the VM.
>>> The test case below reproduces the bug.
>> I haven't tried yet but I guess it crashes in compiled code?
>>
>> -
Le 09/11/2010 08:53, Christian Thalinger a écrit :
> On Nov 8, 2010, at 11:46 PM, Rémi Forax wrote:
>> But sadly, it crashes the VM.
>> The test case below reproduces the bug.
> I haven't tried yet but I guess it crashes in compiled code?
>
> -- Christian
yes, no problem with the interpreter.
R
On Nov 8, 2010, at 11:46 PM, Rémi Forax wrote:
> But sadly, it crashes the VM.
> The test case below reproduces the bug.
I haven't tried yet but I guess it crashes in compiled code?
-- Christian
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http:/
Le 08/11/2010 20:52, assembling signals a écrit :
> Ok, I extended my "benchmark" to support a method handle with spread args,
> and this part slower than everything else :(
>
No chance.
> Note: I use Object[] for spread arguments, because in my real-world scenario,
> as mentioned before, I w
Ok, I extended my "benchmark" to support a method handle with spread args,
and this part slower than everything else :(
Note: I use Object[] for spread arguments, because in my real-world scenario,
as mentioned before, I would need any possible method signature to work.
Sadly, I still couldn't fi
John, Remi, thank you both for your replies!
Now, I sadly don't exactly understand what that means:
> "doing a Lookup.findVirtual on MethodHandle.invokeGeneric."
I first do something such as MethodHandles.lookup().find[Virtual|Static] and
the return is a method handle,
which I am using to do (let
Le 08/11/2010 07:43, John Rose a écrit :
> On Nov 7, 2010, at 1:17 AM, assembling signals wrote:
>
>> For the use case "calling a method whose signature is unknown prior to
>> runtime"
>> (such as some lib, loaded externally) :
> That's what MethodHandles.genericInvoker is for.
>
> You can also
On Nov 7, 2010, at 1:17 AM, assembling signals wrote:
> For the use case "calling a method whose signature is unknown prior to
> runtime"
> (such as some lib, loaded externally) :
That's what MethodHandles.genericInvoker is for.
You can also do this yourself by calling Lookup.findVirtual on
Me
On Nov 7, 2010, at 3:15 PM, Rémi Forax wrote:
> John, I wonder if invokeVarargs() with 0 argument should
> use invokeGeneric instead of the genericInvoker.
> Also it seems that there is no check in the VM that the default target
> of a switch can be not taken.
Probably. invokeWithArguments (whic
> John, I wonder if invokeVarargs() with 0 argument should
> use invokeGeneric instead of the genericInvoker.
> Also it seems that there is no check in the VM that the default target
> of a switch can be not taken.
>
In fact, it's not related to a switch. C2 generates code even
if the branch
Le 07/11/2010 18:48, assembling signals a écrit :
> 07.11.10, 14:58, "Rémi Forax":
>
>
>> Works with javac. Do you use it ?
>>
> Hm, strange, I thought Netbeans would use the usual javac, but now I guess it
> uses
> some API calls to compile files. Because using javac from command line
07.11.10, 14:58, "Rémi Forax" :
> Works with javac. Do you use it ?
Hm, strange, I thought Netbeans would use the usual javac, but now I guess it
uses
some API calls to compile files. Because using javac from command line works
indeed!
> Why do you want to call a method with a signature whic
Le 07/11/2010 10:17, assembling signals a écrit :
> Hello again!
>
>
> For that compiler error which you could reproduce, will you file a bug report,
> or is the API that much under change currently, that it's not relevant yet?
> Sorry, the proposed workaround produces same error for me.
>
Wor
Hello again!
For that compiler error which you could reproduce, will you file a bug report,
or is the API that much under change currently, that it's not relevant yet?
Sorry, the proposed workaround produces same error for me.
For the use case "calling a method whose signature is unknown prior t
Le 06/11/2010 17:36, assembling signals a écrit :
> Remi, thank you a lot for such a quick reply!
>
> I tried to do what you suggested, but it keeps failing.
>
> Note, that I don't use some customized build, but instead, as also mentionen
> in previous mail, JDK7 b116.
> Could you please try the c
Remi, thank you a lot for such a quick reply!
I tried to do what you suggested, but it keeps failing.
Note, that I don't use some customized build, but instead, as also mentionen in
previous mail, JDK7 b116.
Could you please try the code by yourself? It's a single class.
Thanks again!
= = =
Le 06/11/2010 11:31, assembling signals a écrit :
> Hello, everyone!
>
> I couldn't find information about several issues, so I'll ask here for help:
>
> I'm using JDK7 b116.
>
> When using MethodHandle.invokeExact(...), I can only invoke a method,
> which signature is "Object (Object[])", anything
Hello, everyone!
I couldn't find information about several issues, so I'll ask here for help:
I'm using JDK7 b116.
When using MethodHandle.invokeExact(...), I can only invoke a method,
which signature is "Object (Object[])", anything else fails with:
WrongMethodTypeException: ()V cannot be c
33 matches
Mail list logo
