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 tal.li...@gmail.com
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
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
method handle,
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 extraction, update, and re-packaging of ASM in
Clojure as soon as
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
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
On Sat, Aug 27, 2011 at 8:31 PM, Tal Liron tal.li...@gmail.com wrote:
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 was ever a barrier. But you obviously
On Sun, Aug 28, 2011 at 10:25 AM, Tal Liron tal.li...@gmail.com 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 with
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'll leave it to somebody else to take a stab at
On Sun, Aug 28, 2011 at 10:58 AM, Tal Liron tal.li...@gmail.com 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
If you look at the links in my previous e-mail (specifically this one
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L1364).
The reflection is done in the compiler only when there is a tag (i.e. a type
hint). Otherwise the compiler just emits an invoke
On Aug 28, 12:41 pm, Tal Liron tal.li...@gmail.com wrote:
If you look at the links in my previous e-mail (specifically this one
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/C...).
The reflection is done in the compiler only when there is a tag (i.e. a type
hint).
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 a
Paul, I'm going to combine two posts of yours in to one, if I may, and
answer some of your points.
(Aaron, can we add some of this to the wiki, too? I'm including at least one
correction)
*-- For version 5 of the JVM, I agree, and if your goal is to maintain
compatibility with version 5 of
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
On Thu, Aug 25, 2011 at 5:41 PM, Tal Liron tal.li...@gmail.com wrote:
So, after setting up a JVM 7 environment to play with Clojure, and
enthusiastically rummaging through the codebase, I have good news and bad
news. :)
So, when Clojure calls a function, it either already has the instance in
On Thu, Aug 25, 2011 at 6:05 PM, Tal Liron tal.li...@gmail.com 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.
Actually, Clojure's
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
On Thu, Aug 25, 2011 at 2:51 PM, Aaron Bedra aaron.be...@gmail.com wrote:
That's correct. That is why Clojure/core hasn't prioritized this
On Thu, Aug 25, 2011 at 9:05 AM, Kevin Ilchmann Jørgensen kijm...@gmail.com
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
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're going after
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 officially
On Thu, Aug 25, 2011 at 2:49 AM, Tal Liron tal.li...@gmail.com 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 best way
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
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 on what's
That's correct. That is why Clojure/core hasn't prioritized this work.
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 Rich saying in one of
On Thu, Aug 25, 2011 at 5:18 AM, Paulo Pinto paulo.jpi...@gmail.com 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
@Aaron: Could you go into why this is the case? What does jruby do
that it needs it so much and clojure 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
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 allow the
On Thu, Aug 25, 2011 at 2:35 PM, Paul Stadig p...@stadig.name 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 that Tal
On 25 Ago, 20:21, Nick Zbinden nick...@gmail.com wrote:
@Aaron: Could you go into why this is the case? What does jruby do
that it needs it so much and clojure does not.
@Tal Liron: You seem to differ in your opinion with Aaron (pretty sure
you would not be investing your time otherwise).
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 invokedynamic call
A significant speed improvement without resorting to type hints would be a
pretty huge win from a programmer's standpoint.
Kenny
On Thu, Aug 25, 2011 at 1:21 PM, Nick Zbinden nick...@gmail.com wrote:
@Aaron: Could you go into why this is the case? What does jruby do
that it needs it so much
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
calls. So if you are in a tight
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 handle. An
instance of AFn is not
34 matches
Mail list logo
