De: "John Rose"
À: "Rémi Forax"
Cc: "Da Vinci Machine Project"
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:
it's less powerfu
On Aug 26, 2015, at 6:06 AM, Rémi Forax 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 main
test.
And
Hi John,
comment inlined
Le 26 août 2015 00:30:00 CEST, John Rose a écrit :
>On Feb 25, 2015, at 6:29 PM, John Rose 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; }
>>
On Feb 25, 2015, at 6:29 PM, John Rose 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 then you
> hav
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 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:
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 li
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
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/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
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
is a special 'bytecode'
for th
Spread arguments would have been nice to have.
Another related messy argument issue, which took me a while to deal with,
was handling
the receiver (this) object being on top of the stack. Since my GWT test
needs to act on
the receiver I ended up caching an airity specific drop MH. While is
wor
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 is
a special 'bytecode'
for the verifier and that the verifier will allow
(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 Mar 4, 2015, at 2:47 PM, Charles Oliver Nutter wrote:
>
> Busy week, finally circling back to this thread...
>
> On Wed, Feb 25, 2015 at 8:29 PM, John Rose 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 r
On Mar 6, 2015, at 5:30 AM, Vladimir Ivanov
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 that tree as wel
>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 pe
* 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 regards
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 h
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
wrote:
my biggest request: allow the call of a super constructor (like
super(foo,bar)) using MethodHandles an have it understood by the JVM
lik
Am 04.03.2015 23:50, schrieb Charles Oliver Nutter:
On Thu, Feb 26, 2015 at 4:27 AM, Jochen Theodorou 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
On Thu, Feb 26, 2015 at 4:27 AM, Jochen Theodorou 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 problem is that
Busy week, finally circling back to this thread...
On Wed, Feb 25, 2015 at 8:29 PM, John Rose 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. You can code y
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 always
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
rul
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
rules
AAARRGGHH! I hate these reply-to settings for this mailing list!
Sorry.
David
On 4/03/2015 9:13 PM, David Holmes wrote:
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
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
compi
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 so
John posed two questions on stating points for PICs in jsr292. The first
referenced Charleies method handle binder as an
example. While interesting this tool is aimed at making it easy to
generate MH chains not at improving performance.
And performance is really what I would like to see. For t
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 (polymorph
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 var
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 26/02/2015
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 requ
On Feb 25, 2015, at 5:09 PM, Mark Roos 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 like Charl
On Feb 25, 2015, at 4:02 PM, 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.
>
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 java
38 matches
Mail list logo
