Hi John,
comment inlined
Le 26 août 2015 00:30:00 CEST, John Rose john.r.r...@oracle.com a écrit :
On Feb 25, 2015, at 6:29 PM, John Rose john.r.r...@oracle.com wrote:
Maybe this is general enough:
MHs.loop(init, predicate, body)(*a)
= { let i = init(*a); while (predicate(i, *a)) { i
On Aug 26, 2015, at 6:06 AM, Rémi Forax fo...@univ-mlv.fr wrote:
it's less powerful but it seems you can encode all your examples of loops too.
No, I don't think so. Multiple pred/fini pairs implement multiple loop exits.
Any loop with an if-return in it has an exit distinct from the loop's
-
De: John Rose john.r.r...@oracle.com
À: Rémi Forax fo...@univ-mlv.fr
Cc: Da Vinci Machine Project mlvm-dev@openjdk.java.net
Envoyé: Jeudi 27 Août 2015 01:28:20
Objet: Re: What can we improve in JSR292 for Java 9?
On Aug 26, 2015, at 6:06 AM, Rémi Forax fo...@univ-mlv.fr wrote
On Feb 25, 2015, at 6:29 PM, John Rose john.r.r...@oracle.com wrote:
Maybe this is general enough:
MHs.loop(init, predicate, body)(*a)
= { let i = init(*a); while (predicate(i, *a)) { i = body(i, *a); }
return i; }
...where the type of i depends on init, and if init returns void
Am 08.03.2015 18:39, schrieb Peter Levart:
On 03/08/2015 01:38 PM, Jochen Theodorou wrote:
Am 08.03.2015 12:16, schrieb Remi Forax:
[...]
You need to restrict the set of method handles that are allowed to be
installed inside a CallSite corresponding to such kind of invokedynamic.
Something
On 02/26/2015 01:02 AM, Charles Oliver Nutter wrote:
After talking with folks at the Jfokus VM Summit, it seems like
there's a number of nice-to-have and a few need-to-have features we'd
like to see get into java.lang.invoke. Vladimir suggested I start a
thread on these features.
A few from me:
Thanks Peter - I'd like that too.
Another benefit is that it would (presumably) force IDEs to support the
syntax so that you could this reference to, in your example, someMethod().
We had a problem in our large-ish codebase with methods that looked unused
to the IDE (and hence the casual reader),
On 03/08/2015 01:38 PM, Jochen Theodorou wrote:
Am 08.03.2015 12:16, schrieb Remi Forax:
[...]
You need to restrict the set of method handles that are allowed to be
installed inside a CallSite corresponding to such kind of invokedynamic.
Something like: you can do any transformations you want
On 03/08/2015 12:56 AM, Peter Levart wrote:
On 03/07/2015 02:53 PM, Remi Forax wrote:
On 03/07/2015 06:31 AM, John Rose wrote:
[...]
(I wish we had a similar candidate for invokespecial/super. That is
badly twisted around the verifier.)
One way to solve the problem is to consider that
Am 08.03.2015 12:16, schrieb Remi Forax:
[...]
You need to restrict the set of method handles that are allowed to be
installed inside a CallSite corresponding to such kind of invokedynamic.
Something like: you can do any transformations you want on the arguments
but not on the receiver (no drop,
On 03/07/2015 06:31 AM, John Rose wrote:
[...]
(I wish we had a similar candidate for invokespecial/super. That is badly
twisted around the verifier.)
One way to solve the problem is to consider that invokedynamic init is
a special 'bytecode'
for the verifier and that the verifier will
(Even here there are non-universalities; what if the cleanup
wants to see the return value and/or the thrown exception?
Should it take those as one or two leading arguments?)
Probably, it's too much. Result-agnostic cleanup logic looks like the cleanest
solution from API perspective.
There are
On 03/07/2015 02:53 PM, Remi Forax wrote:
On 03/07/2015 06:31 AM, John Rose wrote:
[...]
(I wish we had a similar candidate for invokespecial/super. That is
badly twisted around the verifier.)
One way to solve the problem is to consider that invokedynamic init
is a special 'bytecode'
* try/finally as a core atom of MethodHandles API.
Libraries like invokebinder provide a shortcut API To generating the
large tree of handles needed for try/finally, but the JVM may not be
able to optimize that tree as well as a purpose-built adapter.
I agree there. We should put this in.
In other words, what we discussed was how do we see lightweight bytecode
loading functionality in java.lang.invoke API.
We don't want to make Unsafe.defineAnonymousClass() part of public API,
but consider moving forward on that front providing lightweight code
loading machinery.
Best
From Valdimir
We don't want to make Unsafe.defineAnonymousClass() part of public API,
but consider moving forward on that front providing lightweight code
loading machinery.
While I used defineAnno for awhile currently I just use defineClass in my
own class loader.
My only concern is that
On Mar 6, 2015, at 5:30 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
* try/finally as a core atom of MethodHandles API.
Libraries like invokebinder provide a shortcut API To generating the
large tree of handles needed for try/finally, but the JVM may not be
able to optimize
On Mar 4, 2015, at 2:47 PM, Charles Oliver Nutter head...@headius.com wrote:
Busy week, finally circling back to this thread...
On Wed, Feb 25, 2015 at 8:29 PM, John Rose john.r.r...@oracle.com wrote:
* A loop handle :-)
Given a body and a test, run the body until the test is false. I'm
Am 05.03.2015 11:09, schrieb Peter Levart:
On 03/05/2015 04:09 AM, Jochen Theodorou wrote:
[...]
public class Foo {
public Foo(String s, Integer i){}
public Foo(Integer s, Object o){}
}
public class Bar extends Foo {
public Bar(def a, def b) {
super(a,b) // call with runtime types
On 03/05/2015 04:09 AM, Jochen Theodorou wrote:
Am 04.03.2015 23:50, schrieb Charles Oliver Nutter:
On Thu, Feb 26, 2015 at 4:27 AM, Jochen Theodorou blackd...@gmx.org
wrote:
my biggest request: allow the call of a super constructor (like
super(foo,bar)) using MethodHandles an have it
Julian wrote
An open question that I have is that of facilitating the support
of overloaded methods.
It's typically something dynamically-typed languages struggle
with, and doing it
correctly *and* efficiently is not that pretty.
Overloaded and multi methods have
Busy week, finally circling back to this thread...
On Wed, Feb 25, 2015 at 8:29 PM, John Rose john.r.r...@oracle.com wrote:
* A loop handle :-)
Given a body and a test, run the body until the test is false. I'm
guessing there's a good reason we don't have this already.
A few reasons: 1.
On Thu, Feb 26, 2015 at 4:27 AM, Jochen Theodorou blackd...@gmx.org wrote:
my biggest request: allow the call of a super constructor (like
super(foo,bar)) using MethodHandles an have it understood by the JVM like a
normal super constructor call... same for this(...)
Just so I understand...the
Am 04.03.2015 23:50, schrieb Charles Oliver Nutter:
On Thu, Feb 26, 2015 at 4:27 AM, Jochen Theodorou blackd...@gmx.org wrote:
my biggest request: allow the call of a super constructor (like
super(foo,bar)) using MethodHandles an have it understood by the JVM like a
normal super constructor
Hello,
I echo Jochen's griefs on constructors. There are cases of dynamic subclassing
or bytecode wizardry where one would like to make that call with invokedynamic,
and being forced into doing so with an invokespecial to not break the verifier
rules is a big problem.
Other than that having
Marcus,
On 3/03/2015 9:12 PM, Marcus Lagergren wrote:
At the VM language summit at JFokus 2015, we discussed having ways to get new
dynamic language functions into the JVM without having to resort to generating
a class wrapping their byte code. A class is currently the smallest possible
On 03/04/2015 12:00 PM, Julien Ponge wrote:
Hello,
I echo Jochen's griefs on constructors. There are cases of dynamic subclassing
or bytecode wizardry where one would like to make that call with invokedynamic,
and being forced into doing so with an invokespecial to not break the verifier
Am 04.03.2015 12:00, schrieb Julien Ponge:
Hello,
I echo Jochen's griefs on constructors. There are cases of dynamic subclassing
or bytecode wizardry where one would like to make that call with invokedynamic,
and being forced into doing so with an invokespecial to not break the verifier
At the VM language summit at JFokus 2015, we discussed having ways to get new
dynamic language functions into the JVM without having to resort to generating
a class wrapping their byte code. A class is currently the smallest possible
compilation unit for the JVM, and its installation carries
New could would mean adding a {MethodHandle, ConstantPoolData}
tuple to a particular callsite?s representation.
Now if we could add a item for the object reference used for the
comparison in the test part of a GWT we would have a structure which could
be used
in a PIC
MH.spreadArguments would certainly be useful from my point of view. We
have many cases where we need to take a trailing argument array and turn
it into some arguments, and array contain the remainder. This involves a
depressing amount of shuffling at the moment, and should be better.
On
Am 26.02.2015 01:02, schrieb Charles Oliver Nutter:
After talking with folks at the Jfokus VM Summit, it seems like
there's a number of nice-to-have and a few need-to-have features we'd
like to see get into java.lang.invoke. Vladimir suggested I start a
thread on these features.
my biggest
On Feb 25, 2015, at 4:02 PM, Charles Oliver Nutter head...@headius.com wrote:
After talking with folks at the Jfokus VM Summit, it seems like
there's a number of nice-to-have and a few need-to-have features we'd
like to see get into java.lang.invoke. Vladimir suggested I start a
thread on
On Feb 25, 2015, at 5:09 PM, Mark Roos mr...@roos.com wrote:
I would like to see some form of PIC (polymorphic inline cache ) support that
jits (inlines) well and transitions from mono to bi to multi(4,5) to mega
nicely.
What would be the starting points for such a thing?
It seems to be
After talking with folks at the Jfokus VM Summit, it seems like
there's a number of nice-to-have and a few need-to-have features we'd
like to see get into java.lang.invoke. Vladimir suggested I start a
thread on these features.
A few from me:
* A loop handle :-)
Given a body and a test, run the
I would like to see some form of PIC (polymorphic inline cache ) support
that
jits (inlines) well and transitions from mono to bi to multi(4,5) to mega
nicely.
The main thought would be to inline two or three with some way to reopt
as the types/counters change.
Of course my types are not
36 matches
Mail list logo
