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 em
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
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 P
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, bootstrap
> 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
On Aug 28, 12:41 pm, Tal Liron 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). Otherwise the co
> 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 in
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.MethodHandles.Lookup.unreflect).
>
> 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 s
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 with it.
>
> There a
On Sat, Aug 27, 2011 at 8:31 PM, Tal Liron 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
> unconvinced by m
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 m
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
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 the
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
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
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 wrote:
> That's correct. That is why Clojure/core hasn't prioritized this work.
>
> Cheers,
>
Thank you very much for the write up. I am going to paste this along
with some additional details on the wiki under Java 7 support.
Aaron
On 08/25/2011 05:41 PM, Tal Liron wrote:
So, after setting up a JVM 7 environment to play with Clojure, and
enthusiastically rummaging through the codebase
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.
>>
>
> Actually, Clojure's solution is alm
On Thu, Aug 25, 2011 at 5:41 PM, Tal Liron 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
> its entirety
Hey Tai,
this is a brilliant report - thanks very much. Even though you haven't done
anything but back up the assertions from Clojure/core, I find your report much
more reassuring (from a personal perspective) than just blindly believing
something.
I think the Clojure community would benefit
> 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
> 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
when calling J
>
> 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 t
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. :)
(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
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 wrote:
> @Aaron: Could you go into why this is the case? What does jruby do
> that it needs it so much and clojure does
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
On 25 Ago, 20:21, Nick Zbinden 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). What exactlly ar
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 that Tal
> can't work on
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
@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 invoke
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 method calls, not
f
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
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 imp
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 all dynamic languages targeti
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 invokedynamic
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 best way to test right
>
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 released
40 matches
Mail list logo
