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.
First, I don't know if
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 identity
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 identity
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, a
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, a
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
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émi
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?
-- Christian
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, 2010,
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
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 type of
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
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 do this
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's
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
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
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.
Works
07.11.10, 14:58, Rémi Forax fo...@univ-mlv.fr:
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
Le 07/11/2010 18:48, assembling signals a écrit :
07.11.10, 14:58, Rémi Foraxfo...@univ-mlv.fr:
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
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 was
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 (which
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
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
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 else
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 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 code by
26 matches
Mail list logo
