I've moved the patch to
[ https://github.com/forax/clojure/tree/indy-reflect |
https://github.com/forax/clojure/tree/indy-reflect ]
Rémi
>> De: "Ghadi Shayban"
>> À: "clojure"
>> Envoyé: Jeudi 23 Mai 2019 05:43:46
>> Objet: Re: Use invokedy
> De: "Ghadi Shayban"
> À: "clojure"
> Envoyé: Jeudi 23 Mai 2019 05:43:46
> Objet: Re: Use invokedynamic instead of the reflection API when possible
> Hi Rémi! What a pleasant surprise to see your name here. The whole community
> owes you a great deal of
> De: "Alex Miller"
> À: "Clojure"
> Envoyé: Jeudi 23 Mai 2019 03:47:53
> Objet: Re: Use invokedynamic instead of the reflection API when possible
> Hi Rémi! Thanks for all your work on ASM and other JVM stuff over the years by
> the way.
> We have of c
e we care a great deal about performance and those are places where I
> would place a lot higher priority. Ghadi, in particular, has investigated
> options for lazy-initing vars which could have a noticeable impact on
> startup performance while minimizing the effect on subsequent
e can probably chime in on
that more.
Alex
On Wednesday, May 22, 2019 at 6:16:58 PM UTC-5, Rémi Forax wrote:
>
> Hi all,
> now that Clojure is compatible with java 8, it can use invokedynamic where
> it makes sense, i.e. when the compiler has no information to generate
> d
Hi all,
now that Clojure is compatible with java 8, it can use invokedynamic where
it makes sense, i.e. when the compiler has no information to generate
directly the call in bytecode, instead of using the reflection API.
In fact, it's a little more complex than that,
- you can not fully re
I wonder if InvokeDynamic could be used to bring more consistency between
the 20-argument limit function signatures used for objects and the
4-argument limit function signatures for functions with primitive
arguments, by dynamically generating the appropriate method type (with
whatever
An interesting paper looking at the languages based on top of the JVM here:
http://www.dcs.gla.ac.uk/%7Ewingli/jvm_language_study/jvmlanguages.pdf
A presentation based on the above paper here:
http://www.dcs.gla.ac.uk/~wingli/jvm_language_study/JVM_Languages_Presentation.pdf
--
You received th
My understanding is that invokedynamic was very problematic in Java 7, but
is quite a different design and works much better in Java 8. I'd expect it
to be much more heavily optimised in Java 8 since it's used by a core Java
feature (lambdas). Unfortunately targeting Java 8 only is pr
I strongly recommend to talk with dynjs guys about invokedynamic.
Dynjs is a ECMAScript engine written in Java 7 that was intended to use all
the power of invokedynamic. Again, they can correct me if I'm saying
bananas, but it looks lie Java 7 has some issues in
invokedynamic implementatio
er, there are a few minor JDK-specific bits already
> in Clojure and it would be entirely possible to handle separate paths for 6
> and 7.
>
> The major concern is with the stability and *predictability* of
> invokedynamic. indy has undergone major revisions between Java 7 and 8
arate
paths for 6 and 7.
The major concern is with the stability and *predictability* of
invokedynamic. indy has undergone major revisions between Java 7 and 8 so
it may be that what needs to be done is substantially different between the
two. My impression from watching the work of people like Ch
hose were the blog posts I've read, but I can't see that this is
> actually being worked on for Clojure?
>
> 4. apr. 2014 kl. 11:43 skrev Plínio Balduino :
>
>> Hi, Hansen
>>
>> Fogus (from here) and Nutter (from JRuby) wrote nice posts about it.
>>
&g
ed on for Clojure?
>
> 4. apr. 2014 kl. 11:43 skrev Plínio Balduino
> >:
>
> Hi, Hansen
>
> Fogus (from here) and Nutter (from JRuby) wrote nice posts about it.
>
>
> http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/
>
&g
The guys from core team will correct me if I say any bs, but I think it's not
possible to keep Clojure compatible with Java 6, as Clojure 1.6 is, and use
InvokeDynamic bytecode in the same binary. DynJS, for example, is not
compatible with Java 6.
Anyway, it would be nice to se
me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/
>
> http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html?m=1
>
> Plinio Balduino
> 11 982 611 487
>
> On 04/04/2014, at 05:42, Robin Heggelund Hansen wrote:
>
>> Hi!
>&
Hi, Hansen
Fogus (from here) and Nutter (from JRuby) wrote nice posts about it.
http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/
http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html?m=1
Plinio Balduino
11 982 611 487
> On 04
Hi!
Did someone ever look at supporting InvokeDynamic for Clojure? I've read a
couple of blogs and it seemed interesting, would be cool to know if there
actually were any advantages in practice.
--
You received this message because you are subscribed to the Google
Groups "Clojure&
t;
> [1] https://github.com/szegedi/dynalink/wiki/User-Guide-0.5
>
> Ghadi
> @smashthepast
>
>
> On Tuesday, April 16, 2013 10:58:50 PM UTC-4, Brandon Bloom wrote:
>>
>> Do you have any measurements, results, or conclusions to report?
>>
>> On Tuesday, April 16,
, April 16, 2013 12:12:15 PM UTC-4, Ghadi Shayban wrote:
>>
>> I've added a very minimal usage of invokedynamic to the compiler.
>> Basically the smallest delta without having to change internals of ObjExpr
>> or break ABI compatibility. This is minimal and raw
Do you have any measurements, results, or conclusions to report?
On Tuesday, April 16, 2013 12:12:15 PM UTC-4, Ghadi Shayban wrote:
>
> I've added a very minimal usage of invokedynamic to the compiler.
> Basically the smallest delta without having to change internals of ObjExpr
I've added a very minimal usage of invokedynamic to the compiler.
Basically the smallest delta without having to change internals of ObjExpr
or break ABI compatibility. This is minimal and raw. There are many many
usages of indy that will really help the Clojure runtime, this ain
On 09/06/2011 08:42 AM, Paul Stadig wrote:
So far all I have done is update the bundled ASM and modify
Clojure to emit Java7 class files, but I'm getting VerifyErrors
(same as Tal). It's possible that this is a bug in the way that
ASM automatically calculates
I started on some work to use invokedynamic instructions (instead of
reflection) for calling Java interop. I based my work on 1.3beta2, and my
goal was just to see how much of a performance difference it could make (if
any).
So far all I have done is update the bundled ASM and modify Clojure to
2011/8/30 Tal Liron
> On 08/29/2011 06:01 PM, Aaron Bedra wrote:
>
> The version of ASM that is bundled in Clojure is very old. This will
> likely cause problems. You are correct in looking to ASM 4 since it has
> started supported the JSR-292 stuff and other Java 7 changes. I am
> planning o
On 08/29/2011 06:01 PM, Aaron Bedra wrote:
The version of ASM that is bundled in Clojure is very old. This will
likely cause problems. You are correct in looking to ASM 4 since it has
started supported the JSR-292 stuff and other Java 7 changes. I am
planning on doing an ex
he least I can do now is to
> point you at some of the serious challenges.
>
> Right now I have what I think is a nice semi-generic mechanism for
> invokedynamic. It's called the "Linker": it handles finding the target
> method handle, bootstrapping, and what I call &qu
Progress... is slow.
I encouraged other people to try, so the least I can do now is to point you
at some of the serious challenges.
Right now I have what I think is a nice semi-generic mechanism for
invokedynamic. It's called the "Linker": it handles finding the target
> Well, the statement you just made is true, but nonetheless you are the
> one who is mistaken. The emit() method is called, but if not enough
> information was present at compile time to resolve to a real method
> call (that is, if `method = null` was executed), then the emit() code
> emits
gt; hint). Otherwise the compiler just emits an invoke instruction to call the
> > Reflector at runtime. That invoke could be replaced with an invokedynamic
> > instruction.
>
> Yes, that's exactly where one of us is mistaken. :) My understanding is that
> this constructor
r just emits an invoke instruction to call the
> Reflector at runtime. That invoke could be replaced with an invokedynamic
> instruction.
>
Yes, that's exactly where one of us is mistaken. :) My understanding is that
this constructor is only called once during the analysis mode. The
On Sun, Aug 28, 2011 at 10:58 AM, Tal Liron wrote:
> I wonder if it would be that difficult to replace the reflector code with
>> an invokedynamic. There is a way to get from a java.lang.reflect.Method to a
>> java.lang.invoke.MethodHandle (see
>> java.lang.invoke.MethodHan
>
> Paul also points out areas where MethodHandles can replace the rather
>> sticky reflection work that Clojure does now to massage calls to non-Clojure
>> libraries. That's not entirely related to the invokedynamic stuff I'm
>> working on, so I think I'
On Sun, Aug 28, 2011 at 10:25 AM, Tal Liron wrote:
> Progress!
>
> I am staring right now at my JVM 7 build of Clojure that uses invokedynamic
> for Vars that contain functions. It essentially works, well enough for
> experimentation. A few of my simple apps seem to work fine wit
l and warns you that you're doing
> reflection...[snip]
> *
> You are right! This is perhaps the only place where invokedynamic can be
> useful for Clojure. *However*, to me this is not a big deal, because the
> workaround of allowing for type hinting solves the problem just as w
Progress!
I am staring right now at my JVM 7 build of Clojure that uses invokedynamic
for Vars that contain functions. It essentially works, well enough for
experimentation. A few of my simple apps seem to work fine with it.
There are still a lot of problems: the Clojure test suite fails, and
Another correction:
I stated that Clojure's maximum arity is 20. That's not exactly true: for
arity's beyond 20, IFn has a special invocation that accepts the arguments
as an array. But this means that the compiler has to account for this, and
arrange the arguments as a single array argument in
rsion 5 of the JVM, sure. However, there is lots of
invokedynamic goodness that Clojure could benefit from.*
I can think of a few ways in which it would be possible to distribute a
clojure.jar that supports JVM 7 features while still falling back to JVM 5
compatibility. So, I don't think
This is the best summary of how Clojure *could* benefit from invokedynamic.
Clojure doesn't dispatch as dynamically as JRuby, but there is a dynamic
component...specifically, you have to go get the fn. That repeated "get"
would disappear with invokedynamic,
In fact, anywhere you
On Thu, Aug 25, 2011 at 9:05 AM, Kevin Ilchmann Jørgensen wrote:
> This means I can read the rest of the logs
> http://clojure-log.n01se.net/date/2008-09-03.html
> and it stills hold up ? i.e we want tagged numbers ?
>
> /Kevin
1.3 went a different route. Fast path for 64bit arithmetic.
Davi
k.
>
> Cheers,
>
> Aaron Bedra
> --
> Clojure/core
> http://clojure.com
>
> On 08/25/2011 08:37 AM, Meikel Brandmeyer (kotarak) wrote:
>>
>> Hi,
>>
>> Disclaimer: I have no clue whatsoever about the low-level JVM stuff.
>>
>> I remember R
codebase, I have good news and
bad news. :)
(To quickly answer someone's question here -- I do know that it's a
low priority for the Clojure project, but thought the potential
benefit could be worth *my* personal time. A few people suggested that
invokedynamic would not be that useful f
On Thu, Aug 25, 2011 at 6:05 PM, Tal Liron wrote:
>
> Hmm... If you didn't have to worry about Java <7 compatibility, for one
>> thing with invokedynamic you could remove a lot of code from Clojure. No
>> more IFn or AFn. You simply have a method handle.
>>
>
aid in another post was that with invokedynamic (assuming you could
just go whole hog into Java 7) you don't need the IFn interface. You just
need a MethodHandle. So yes, I agree that given all the existing Clojure
code, and the desire to stay compatible with Java 5 or 6 or whatever,
invokedynamic is
benefit could be
> worth *my* personal time. A few people suggested that invokedynamic would not
> be that useful for Clojure, but I'm a skeptic and wanted to see for myself. I
> think other questions posed here are answered in the long report below...)
>
> The bad news is
> Hmm... If you didn't have to worry about Java <7 compatibility, for one
> thing with invokedynamic you could remove a lot of code from Clojure. No
> more IFn or AFn. You simply have a method handle.
>
Actually, Clojure's solution is almost identical to a method ha
> A significant speed improvement without resorting to type hints would be a
> pretty huge win from a programmer's standpoint.
True, but this is not a problem that invokedynamic can solve. :) It would
require, perhaps, better automation in the decision of how to coerce types
w
>
> Since Ruby isn't designed to run on the JVM, it doesn't have
> any syntax for type hints to avoid reflective calls. I believe method
> calls that use invokedynamic are much faster than reflective
> (non-hinted) method calls, but still a bit slower than type-hinted
&g
al benefit could be
worth *my* personal time. A few people suggested that invokedynamic would
not be that useful for Clojure, but I'm a skeptic and wanted to see for
myself. I think other questions posed here are answered in the long report
below...)
The bad news is that I don't think Cloj
lojure does not.
>
> @Tal Liron: You seem to differ in your opinion with Aaron (pretty sure
> you would not be investing your time otherwise). What exactlly are you
> attempting to speed up and how does invokedynamic help?
>
> --
> You received this message because you are s
Right invokedynamic doesn't just "mostly benefit object-oriented languages."
A MethodHandle can be used for anything that the JVM can do from a static
method call, to an instance method call, to a constructor, to a field
access.
And in fact the bootstrap method that links an inv
. What exactlly are you
> attempting to speed up and how does invokedynamic help?
I'm neither of them, nor I am a Clojure hacker, but still I think I
can contribute something to the discussion.
invokedynamic is basically a hook in the JVM's linking system; it
allows language implemen
On Thu, Aug 25, 2011 at 2:35 PM, Paul Stadig wrote:
> I think invokedynamic would be great for Clojure. Of course there are other
> concerns like the fact that it is only for Java 7, so maybe it won't be the
> best place to put resources at the moment. But that's no reason th
Hmm... If you didn't have to worry about Java <7 compatibility, for one
thing with invokedynamic you could remove a lot of code from Clojure. No
more IFn or AFn. You simply have a method handle.
Second, I think it would allow the JVM to have a better view into
optimization, and would a
invokedynamic help?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this g
On Thu, Aug 25, 2011 at 5:18 AM, Paulo Pinto wrote:
> invokedynamic reduces drastically the lookup times you require in
> dynamic languages. The JVM and JIT understand what you are trying
> to do and can optimize the invocation.
It's important to note that this only applies to met
in one of his talks/interviews, that
invokedynamic is not very interesting for Clojure and that Clojure
won't really benefit from it. I'm far from understanding these things.
So details on what's improved would be very interesting, I guess.
Sincerely
Meikel
--
You received thi
Hi,
Disclaimer: I have no clue whatsoever about the low-level JVM stuff.
I remember Rich saying in one of his talks/interviews, that invokedynamic is
not very interesting for Clojure and that Clojure won't really benefit from
it. I'm far from understanding these things. So details
This does not really answer Ken's question, does it ?
2011/8/25 Paulo Pinto
> invokedynamic reduces drastically the lookup times you require in
> dynamic languages. The JVM and JIT understand what you are trying
> to do and can optimize the invocation.
>
> Currently a
invokedynamic reduces drastically the lookup times you require in
dynamic languages. The JVM and JIT understand what you are trying
to do and can optimize the invocation.
Currently all dynamic languages targeting the JVM generate code
that cannot be easily optimized by the JVM before
On Thu, Aug 25, 2011 at 2:49 AM, Tal Liron wrote:
> Hey folks,
>
> I just want to reassure y'all that I am working on this. It took a while to
> create a test environment: one of the challenges of using invokedynamic is
> that the Java language does not support it; so the be
Hey folks,
I just want to reassure y'all that I am working on this. It took a while to
create a test environment: one of the challenges of using invokedynamic is
that the Java language does not support it; so the best way to test right
now is with ASM 4.0, which is still not offic
62 matches
Mail list logo
