slot consumption
for generated signatures.
Best regards,
Vladimir Ivanov
On 5/18/15 8:58 PM, Vladimir Ivanov wrote:
Igor,
Looks good.
You don't need to bother computing slot size for a signature since you
use only 1-slot types, do you?
test/java/lang/invoke/MethodHandles/CatchExceptio
58 PM, Vladimir Ivanov wrote:
Igor,
Looks good.
You don't need to bother computing slot size for a signature since you
use only 1-slot types, do you?
test/java/lang/invoke/MethodHandles/CatchExceptionTest.java:
Class classes[] = {
Object.class,
Igor,
Looks good.
You don't need to bother computing slot size for a signature since you
use only 1-slot types, do you?
test/java/lang/invoke/MethodHandles/CatchExceptionTest.java:
Class classes[] = {
Object.class,
long.class,
Igor,
Looks good.
You don't need to bother computing slot size for a signature since you
use only 1-slot types, do you?
test/java/lang/invoke/MethodHandles/CatchExceptionTest.java:
Class classes[] = {
Object.class,
long.class,
int.
http://cr.openjdk.java.net/~iignatyev/8055269/webrev.00/
23 lines changed: 8 ins; 9 del; 6 mod
Hi all,
please review the tiny fix for CatchExceptionTest test.
problem: the tests generates a target w/ 255 parameters, so a
corresponding handler should have 256 parameters. that violates
restrict
Good.
thanks,
Vladimir K
On 3/16/15 12:05 PM, John Rose wrote:
Reviewed. — John
On Mar 16, 2015, at 11:47 AM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot
http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/jdk
https://bugs.openjdk.java.net/brow
Thanks, John!
Best regards,
Vladimir Ivanov
On 3/16/15 10:05 PM, John Rose wrote:
Reviewed. — John
On Mar 16, 2015, at 11:47 AM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot
http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/jdk
https://bugs.op
Reviewed. — John
On Mar 16, 2015, at 11:47 AM, Vladimir Ivanov
wrote:
>
> http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot
> http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/jdk
> https://bugs.openjdk.java.net/browse/JDK-8075263
___
http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot
http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/jdk
https://bugs.openjdk.java.net/browse/JDK-8075263
When MethodHandle is a compile-time constant and it is inlined in
MethodHandle.invoke/invokeExact there's no need in MHI::che
ote:
http://cr.openjdk.java.net/~iignatyev/8039953/webrev.00
98 lines changed: 93 ins; 3 del; 2 mod;
Hi all,
Please review the patch:
Problem:
on some configurations,
java/lang/invoke/MethodHandles/CatchExceptionTest.java can timeout
before all test cases are run
Fix:
interrup
del; 2 mod;
Hi all,
Please review the patch:
Problem:
on some configurations,
java/lang/invoke/MethodHandles/CatchExceptionTest.java can timeout
before all test cases are run
Fix:
interrupt test execution if it's not enough time to continue
bug : https://bugs.openjdk.java.net/browse/JDK
e:
http://cr.openjdk.java.net/~iignatyev/8039953/webrev.00
98 lines changed: 93 ins; 3 del; 2 mod;
Hi all,
Please review the patch:
Problem:
on some configurations,
java/lang/invoke/MethodHandles/CatchExceptionTest.java can timeout
before all test cases are run
Fix:
interrupt test executio
3 del; 2 mod;
Hi all,
Please review the patch:
Problem:
on some configurations, java/lang/invoke/MethodHandles/CatchExceptionTest.java
can timeout before all test cases are run
Fix:
interrupt test execution if it's not enough time to continue
bug : https://bugs.openjdk.java.net/browse/JDK-803
On Nov 29, 2014, at 5:36 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8039953/webrev.00
> 98 lines changed: 93 ins; 3 del; 2 mod;
>
> Hi all,
>
> Please review the patch:
>
> Problem:
> on some configurations,
> java/lang/invoke/MethodHandles/Ca
http://cr.openjdk.java.net/~iignatyev/8039953/webrev.00
98 lines changed: 93 ins; 3 del; 2 mod;
Hi all,
Please review the patch:
Problem:
on some configurations,
java/lang/invoke/MethodHandles/CatchExceptionTest.java can timeout
before all test cases are run
Fix:
interrupt test execution
Hi again,
I have a Groovy-indy program looking like this
https://gist.github.com/abargnesi/6628656
This did work in 7u25 and does not work in 7u40 or the developer preview
of jdk8. What I found out is, if you remove an argument the
IllegalArgumentException is not thrown
What I have (using 7u4
On 03/23/2013 04:30 PM, Peter Levart wrote:
>
> On 03/22/2013 11:50 AM, Remi Forax wrote:
>> On 03/22/2013 11:12 AM, Jochen Theodorou wrote:
>>> Am 22.03.2013 10:35, schrieb Remi Forax:
On 03/22/2013 10:24 AM, Jochen Theodorou wrote:
> Am 22.03.2013 10:11, schrieb Remi Forax:
> [...]
>
On 03/22/2013 11:50 AM, Remi Forax wrote:
On 03/22/2013 11:12 AM, Jochen Theodorou wrote:
Am 22.03.2013 10:35, schrieb Remi Forax:
On 03/22/2013 10:24 AM, Jochen Theodorou wrote:
Am 22.03.2013 10:11, schrieb Remi Forax:
[...]
I don't think it's a good idea to expose directly method handles t
On 03/22/2013 11:12 AM, Jochen Theodorou wrote:
> Am 22.03.2013 10:35, schrieb Remi Forax:
>> On 03/22/2013 10:24 AM, Jochen Theodorou wrote:
>>> Am 22.03.2013 10:11, schrieb Remi Forax:
>>> [...]
I don't think it's a good idea to expose directly method handles to users,
it's better to en
Am 22.03.2013 10:35, schrieb Remi Forax:
> On 03/22/2013 10:24 AM, Jochen Theodorou wrote:
>> Am 22.03.2013 10:11, schrieb Remi Forax:
>> [...]
>>> I don't think it's a good idea to expose directly method handles to users,
>>> it's better to encapsulate it into a Groovy object corresponding to a
>>
On 03/22/2013 10:24 AM, Jochen Theodorou wrote:
> Am 22.03.2013 10:11, schrieb Remi Forax:
> [...]
>> I don't think it's a good idea to expose directly method handles to users,
>> it's better to encapsulate it into a Groovy object corresponding to a
>> function or a closure so you can add a bunch o
Am 22.03.2013 10:11, schrieb Remi Forax:
[...]
> I don't think it's a good idea to expose directly method handles to users,
> it's better to encapsulate it into a Groovy object corresponding to a
> function or a closure so you can add a bunch of invoke overloads.
what invoke overloads are you thin
On 03/22/2013 10:06 AM, Remi Forax wrote:
> On 03/22/2013 07:52 AM, Jochen Theodorou wrote:
>> Am 21.03.2013 20:49, schrieb Remi Forax:
>> [...]
>>> I suppose you take a look to the instances.
>>> You can do something similar actually by using invokedynamic +
>>> a guardWithTest that checks already
thodHandle.invoke/invokeExact (which invokeWithArguments() will call),
>> and it looks at what MethodHandles get passed in.
>> When that work lands in HotSpot, your example will be a source of
>> profile pollution just like the well-known megamorphic callsites in the
>> ol
On 03/22/2013 07:52 AM, Jochen Theodorou wrote:
> Am 21.03.2013 20:49, schrieb Remi Forax:
> [...]
>> I suppose you take a look to the instances.
>> You can do something similar actually by using invokedynamic +
>> a guardWithTest that checks already seen instances instead of doing a
>> plain mh.in
s a (JIT-)compiled-time constant to be able to do
> inlining across the MethodHandle.invoke/invokeExact boundary.
ah yes, I forgot that.
> I'm working on adding profiling support for
> MethodHandle.invoke/invokeExact (which invokeWithArguments() will call),
> and it looks at what
Am 21.03.2013 20:49, schrieb Remi Forax:
[...]
> I suppose you take a look to the instances.
> You can do something similar actually by using invokedynamic +
> a guardWithTest that checks already seen instances instead of doing a
> plain mh.invoke*
> I think Duncan and Georges do something like tha
odHandle is a (JIT-)compiled-time constant to be able to do
> inlining across the MethodHandle.invoke/invokeExact boundary.
>
> I'm working on adding profiling support for
> MethodHandle.invoke/invokeExact (which invokeWithArguments() will call),
> and it looks at what MethodHandles ge
the MethodHandle.invoke/invokeExact boundary.
I'm working on adding profiling support for
MethodHandle.invoke/invokeExact (which invokeWithArguments() will call),
and it looks at what MethodHandles get passed in.
When that work lands in HotSpot, your example will be a source of
profile poll
Maybe I'm misunderstanding your question, but whether
mh.invokeWithArguments(args) internally generates a mono, poly, or
megamorphic call site internally in the JVM is going to depend on the
implementation and just how many subclasses of MethodHandle there are.
If you're concerned about the implem
Hi all,
assuming I have in Java a method:
public static Object invoke(MethodHandle mh, Object[] args) {
try {
return mv.invokeWithArguments(args);
} catch (Throwable th) {
ExceptionUtils.sneakyThrow(th);
}
}
(sneakyThrow is to work around checked exceptions and does basically
On Nov 18, 2012, at 5:50 PM, Douglas Campos wrote:
> When doing MH.toString(), the LambdaForm output (as enabled by
> java.lang.invoke.MethodHandle.DEBUG_NAMES) is WAY more readable. Any reasons
> for not using it as the default beyond perf cost?
Hi Douglas!
The debugging output reveals lots o
Howdy!
When doing MH.toString(), the LambdaForm output (as enabled by
java.lang.invoke.MethodHandle.DEBUG_NAMES) is WAY more readable. Any reasons
for not using it as the default beyond perf cost?
-- qmx
___
mlvm-dev mailing list
[email protected]
Am 16.11.2012 00:32, schrieb John Rose:
[...]
> What you are seeing is a bug. I can reproduce this in JDK 7 but not in
> JDK 8. The upcoming JDK 7 update will fix this, since it is a backport
> from 8.
ah, finally the backport of jdk8 ;) I hope it does not break other
things;) Btw, I noticed th
Hi John,
Am 16.11.2012 04:09, schrieb John Rose:
> On Nov 15, 2012, at 3:32 PM, John Rose wrote:
>
>> It can be right, but only if the actual argument is a null reference.
>> If it is a non-null Byte, it must unbox to a byte and then widen to a
>> float.
>
> Well, actually, in this case, the NPE
On Nov 15, 2012, at 3:32 PM, John Rose wrote:
> It can be right, but only if the actual argument is a null reference. If it
> is a non-null Byte, it must unbox to a byte and then widen to a float.
Well, actually, in this case, the NPE should not happen either.
Nulls are explicitly cast (though
[Repost, moving from jvm-l list.]
On Nov 14, 2012, at 6:16 AM, Jochen Theodorou wrote:
> I have a call to MethodHandles#explicitCastArgument with first argument being
> my MethodHandle(Groovy3135Bug,String,float,float,float,float,float)Object and
> the type I cast to being
> (G
Hi,
I have a call to MethodHandles#explicitCastArgument with first argument
being my
MethodHandle(Groovy3135Bug,String,float,float,float,float,float)Object
and the type I cast to being
(Groovy3135Bug,String,Byte,Short,Integer,Long,Float)Object
Ignoring the first two I should have some kind
On Jul 19, 2012, at 7:04 PM, Dain Sundstrom wrote:
> I have some code that tries to get the value of a static final field using a
> MethodHandle, and I find that the field is null because the class isn't
> initialized. Is calling a method handle supposed to cause a class to
> initialize (run th
I have some code that tries to get the value of a static final field using a
MethodHandle, and I find that the field is null because the class isn't
initialized. Is calling a method handle supposed to cause a class to initialize
(run the method)?
In a related question, what is the best way t
s them).
> >
> >
> > Now my question, is there something I can do to make it completely tail
> call
> > optimized? I've tried to 'rotate' the call graph/tree but that obviously
> > wouldn't work (it's still a direct recursion, no matter if you
d? I've tried to 'rotate' the call graph/tree but that obviously
> wouldn't work (it's still a direct recursion, no matter if you do it
> directly or in the combiner of a foldArguments). It seems that it is almost
> completely TCO already, but I haven't
ack. It's definitely leaking less stack than a simple recursion.
Or will we need a special looping combinator here? I initially tried to
create a while combinator, however it seems that guardWithTest does not
accept MethodHandles returning void (for the target and fallback).
If this can be ma
I think I got it!
MethodHandle result = MethodHandles.catchException(foo,
postException); # handles exceptional path of finally and throws
result = MethodHandles.foldArgments(postCall, result); # handles
non-exceptional path of finally.
Am I right?!
On Fri, Jun 10, 2011 at 7:12 PM, Charles Olive
I just posted your trick (a "duh" moment for me) to JVM-L, along with
an explanation of why it doesn't solve the try/finally problem. The
exceptional and non-exceptional paths need to be exclusive to match
what try/finally does.
- Charlie
On Fri, Jun 10, 2011 at 7:05 PM, Charles Oliver Nutter
wr
On Fri, Jun 10, 2011 at 6:55 PM, John Rose wrote:
> On Jun 10, 2011, at 4:39 PM, Charles Oliver Nutter wrote:
>
>> Please tell me I'm wrong, or tell me that we can modify catchException
>> in some way to also allow post-processing of non-exceptional results
>> (with return value inserted where the
On Jun 10, 2011, at 4:39 PM, Charles Oliver Nutter wrote:
> Please tell me I'm wrong, or tell me that we can modify catchException
> in some way to also allow post-processing of non-exceptional results
> (with return value inserted where the Throwable would go)!
I think this does what you want:
Please, please have a look at my recent threads on JVM-L. I am worried
I've found a major hole in what MethodHandles can do. Specifically,
there's no way to post-process a given handle, receiving both its
arguments and its return value and deciding what to do, for something
like this t
On 05/18/2011 09:03 PM, John Rose wrote:
> On May 18, 2011, at 11:59 AM, Rémi Forax wrote:
>
>> All others are hard because the value of the method handle is not
>> statically known
>> i.e the method handle cannot be considered as constant.
> It can be optimistically inlined, which is what we do fo
On May 18, 2011, at 11:59 AM, Rémi Forax wrote:
> All others are hard because the value of the method handle is not
> statically known
> i.e the method handle cannot be considered as constant.
It can be optimistically inlined, which is what we do for invokedynamic
instructions.
-- John
___
On 05/18/2011 06:44 PM, Charles Oliver Nutter wrote:
> On Wed, May 18, 2011 at 5:34 AM, Szymon Jachim wrote:
>> I have to questions to you guys about possible (and planned) JIT
>> optimizations for MethodHandles.
>> 1. Assuming that there will be a chain of MH's:
>
On Wed, May 18, 2011 at 5:34 AM, Szymon Jachim wrote:
> I have to questions to you guys about possible (and planned) JIT
> optimizations for MethodHandles.
> 1. Assuming that there will be a chain of MH's:
> mh1(invoker) -> mh2 -> aMethod()
> and there will be
I have to questions to you guys about possible (and planned) JIT
optimizations for MethodHandles.
1. Assuming that there will be a chain of MH's:
mh1(invoker) -> mh2 -> aMethod()
and there will be no other references to mh2. Will JIT/GC be able to
optimize unneeded mh2 a
would a language like Kawa
> benefit from using invokedynamic - or MethodHandles in some
> other way.\? Some potential benefits:
>
> * Reduce boxing - e.g passing an int to an unknown function
> which in turns expects an int.
> * A better implementation of "multi-methods" - whi
* Per Bothner [2010-10-10 23:38] writes:
> An example I was considering was:
>
> (define (twice f x)
>(f (f x)))
>
> My initial thought was to compile this as:
>
> public static Object (Procedure f, Object x) {
>MethodHandle f$mh = f.asMethodHandle();
>return f$mh.invoke(f$mh.invoke(x)
why do you want to use invokedynamic here ?
That is the question - how much would a language like Kawa
benefit from using invokedynamic - or MethodHandles in some
other way.\? Some potential benefits:
* Reduce boxing - e.g passing an int to an unknown function
which in turns expects an
On 10/10/2010 02:20 PM, Rémi Forax wrote:
> Le 10/10/2010 20:08, Per Bothner a écrit :
>> So we've determined that to make use of 292 Kawa should keep its
>> abstract gnu.mapping.Procedure class, but add a new method:
>> MethodHandle asMethodHandle()
>>
>> I mis-concluded that the compiler sho
Le 10/10/2010 20:08, Per Bothner a écrit :
> So we've determined that to make use of 292 Kawa should keep its
> abstract gnu.mapping.Procedure class, but add a new method:
> MethodHandle asMethodHandle()
>
> I mis-concluded that the compiler should therefore generate code
> to call asMethodHand
So we've determined that to make use of 292 Kawa should keep its
abstract gnu.mapping.Procedure class, but add a new method:
MethodHandle asMethodHandle()
I mis-concluded that the compiler should therefore generate code
to call asMethodHandle() and then the MethdHandle#invoke method.
However, t
On Thu, Sep 30, 2010 at 4:03 PM, Helmut Eller wrote:
> * Alessio Stalla [2010-09-30 13:28] writes:
>
>>> I guess you could avoid reflection if you generate a custom bootstrap
>>> method for each callsite. Hmm.. probably just as clumsy as reflection.
>>
>> Yeah, clumsy and suffering from code bloa
* Alessio Stalla [2010-09-30 13:28] writes:
>> I guess you could avoid reflection if you generate a custom bootstrap
>> method for each callsite. Hmm.. probably just as clumsy as reflection.
>
> Yeah, clumsy and suffering from code bloat - I'm already disturbed to
> have one static block register
On Thu, Sep 30, 2010 at 3:11 PM, Helmut Eller wrote:
> * Alessio Stalla [2010-09-30 11:52] writes:
>
>> On Thu, Sep 30, 2010 at 12:48 PM, Helmut Eller wrote:
>>>
>>> Just out of curiosity: what do you do if the package was renamed (say
>>> from SOME-LISP-PACKAGE to ANOTHER-LISP-PACKAGE) before th
* Alessio Stalla [2010-09-30 11:52] writes:
> On Thu, Sep 30, 2010 at 12:48 PM, Helmut Eller wrote:
>>
>> Just out of curiosity: what do you do if the package was renamed (say
>> from SOME-LISP-PACKAGE to ANOTHER-LISP-PACKAGE) before the bootstrap
>> method gets executed?
>
> It'll fail miserably
On Thu, Sep 30, 2010 at 12:48 PM, Helmut Eller wrote:
> * Alessio Stalla [2010-09-30 07:44] writes:
>
>> InvokeDynamic.#"SOME-LISP-PACKAGE:FOO"(...)
>>
>> and in the bootstrap method, roughly,
>>
>> ...
>> Symbol sym = readFromString(methodName);
>> MethodHandle mh = sym.getSymbolFunctionOrDie().a
* Alessio Stalla [2010-09-30 07:44] writes:
> InvokeDynamic.#"SOME-LISP-PACKAGE:FOO"(...)
>
> and in the bootstrap method, roughly,
>
> ...
> Symbol sym = readFromString(methodName);
> MethodHandle mh = sym.getSymbolFunctionOrDie().asMethodHandle();
> ...
Just out of curiosity: what do you do if
thodHandle? A Procedure? Something else?
>> There seem to be different kind of MethodHandles, so perhaps something
>> is appropriate. Is there some blog article or cookbook discussing this?
>
> Quick answer to your next-to-last question: The language-specific APIs
> s
rent kind of MethodHandles, so perhaps something
> is appropriate. Is there some blog article or cookbook discussing this?
Quick answer to your next-to-last question: The language-specific APIs should
use their own interfaces or classes, so continue to use Procedure. But if and
when you go t
I'm interested into (at least) evaluating MethodHandles for
Kawa (and similar languages with first-class functions).
But I'm not quite sure where to start, or what is the right
abstraction.
Kawa's function implementation is fairly efficient. Calls
to known functions compile t
ce an
> interface with lots of special magic treatment.
>
> Or maybe {int => String}.class would be a MethodType. As I said, some
> distortion is likely.
>
Yes, some distortion is likely. But MethodHandles are so close to
closures (no pun intended) that it would be a waste, no
While hacking the backport, I found some hitches in MethodHandles doc,
here is my notes:
- The documentation of spread/collectArgument talk about an array type T[]
but T is not defined. The question here is: Can T be a primitive type
or not ?
- Mismatch between spread/collectArguments
On May 27, 2009, at 9:16 PM, Charles Oliver Nutter wrote:
> we *must* give the keys to the castle to language
> developers, by opening up the very guts of the JVM's optimizing
> pipeline
I agree that static type checking for method handles would be very
useful, but the language design work is d
ing!
Having spent a lot more time playing with MethodHandles and imagining
the potential, I must say I strongly agree with Fredrik. In the face of
compiler systems like LLVM and to a lesser extent the CLR/DLR's
expression tree support, I believe in order for the JVM to survive as a
dominant
There was some discussion on a proposal like this for Project Coin
(small language changes for Java 7); see this mail thread:
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000388.html
I don't believe this is currently under consideration for Java 7.
> All the runtime access methods l
Rémi Forax skrev:
> On javac support: your javac support is close to a closure proposal :)
> I think we can output a spec without a complete (typecked) support
> of MethodHandles in Java to avoid the closure trap :)
>
All the runtime access methods like findVirtual, findSpecial an
://groups.google.com/group/jvm-languages/browse_thread/thread/47b4423aa99be008
Particularly, the inner class Guard.
I agree with you that it could avoid to implement lot of static methods in
MethodHandles. Anyway, some of them like convert, spread/collect, bind
are very common and I think it's a good ide
where adapter code is generated by calling for example
MethodHandles.appendArgument(). I am not entirely comfortable with this
construction. Mostly because JRockit does not have an interpreter.
So, following a recommendation from John, that I should blog about
jsr292. :-)
Here is the link:
http://
I've continue to implement the backport last evening
and I hope to be able to publish it in 2 weeks (more or less).
Some remarks:
- there is a bug in the doc comments of MethodHandles.insertArgument(),
"The pos may range between zero and N (inclusively)"
Hum, you forget to take a look int
77 matches
Mail list logo
