New JVM instruction invokedynamic

M

M.O.B. i L.

I read this article:
<http://java.sun.com/developer/technicalArticles/DynTypeLang/index.html>.
It's about the new JVM instruction invokedynamic that should make
dynamic languages faster.

I like to think of the JVM as a CPU. I think it's an advantage if you
can write cycle exact code in Java and use profilers. Now, this new
JVM-instruction invocedynamic seems to be unpredictable when it comes to
time consumption. Wouldn't invokedynamic create problems for real time
programs?

Couldn't this problem with dynamic languages be solved with new classes
and methods (that would be native) in JDK instead?
 
J

John B. Matthews

"M.O.B. i L. said:
I read this article:
<http://java.sun.com/developer/technicalArticles/DynTypeLang/index.html>.
It's about the new JVM instruction invokedynamic that should make
dynamic languages faster.

I like to think of the JVM as a CPU. I think it's an advantage if you
can write cycle exact code in Java and use profilers. Now, this new
JVM-instruction invocedynamic seems to be unpredictable when it comes
to time consumption. Wouldn't invokedynamic create problems for real
time programs?

Couldn't this problem with dynamic languages be solved with new classes
and methods (that would be native) in JDK instead?

I don't know, but I found this related article to be informative:

<http://www.oracle.com/technetwork/issue-archive/2010/10-may/o30java-099612.html>
 
L

Lew

I read this article:
<http://java.sun.com/developer/technicalArticles/DynTypeLang/index.html>. It's
about the new JVM instruction invokedynamic that should make dynamic
languages faster.

I like to think of the JVM as a CPU. I think it's an advantage if you
can write cycle exact code in Java and use profilers. Now, this new
JVM-instruction invocedynamic seems to be unpredictable when it comes to
time consumption. Wouldn't invokedynamic create problems for real time
programs?

Couldn't this problem with dynamic languages be solved with new classes
and methods (that would be native) in JDK instead?

No.

Bear in mind that those languages already ran in the JVM, so the new bytecode
just makes it better.
 
T

Tom Anderson

I like to think of the JVM as a CPU. I think it's an advantage if you
can write cycle exact code in Java and use profilers.

You can't. In a JITted VM, there's a fairly vague relationship between the
bytecodes in the class file and what actually happens at runtime, and
practically all current VMs not on mobile devices are JITted.
Now, this new JVM-instruction invocedynamic seems to be unpredictable
when it comes to time consumption. Wouldn't invokedynamic create
problems for real time programs?

Yes. So don't use it in real-time programs.
Couldn't this problem with dynamic languages be solved with new classes
and methods (that would be native) in JDK instead?

Yes, but not cleanly or efficiently.

tom
 
J

Joshua Cranmer

I like to think of the JVM as a CPU. I think it's an advantage if you
can write cycle exact code in Java and use profilers. Now, this new
JVM-instruction invocedynamic seems to be unpredictable when it comes to
time consumption. Wouldn't invokedynamic create problems for real time
programs?

First off, I'm sure that dynamic JIT repatching is likely to cause just
as much uncertainty in terms of instructions.

Second, I don't think the Java compiler ever creates an invokedynamic
instruction call, but I haven't looked en enough detail about it.

Finally, this is going to be at least as fast as the non-invokedynamic
workaround for it anyways, so it's no worse off for realtime processes.
 
B

BGB

You can't. In a JITted VM, there's a fairly vague relationship between
the bytecodes in the class file and what actually happens at runtime,
and practically all current VMs not on mobile devices are JITted.

agreed...

a JIT is not "particularly" difficult to implement (vs many other things
likely found around in a VM, ...), and a JIT (even a very naive one)
usually offers a fairly drastic speedup vs an interpreter.

about the only real time then not to use a JIT is when one is operating
within a fairly confined memory footprint (since one needs memory for
both the bytecode, the produced machine code, and any temporary memory
needed for the JIT to "do its thing"...), or otherwise finds keeping
code size or complexity down is a bigger concern than raw performance.

Yes. So don't use it in real-time programs.

yep. if one really wants to be fussy, one can say not to use Java or C++
in real-time programs, and should instead stick purely to C and ASM.

in my experiences (mostly with soft-real-time), the bigger concern is
usually that operations don't take "too long", but the exact timing of
individual operations is usually not too important so long as they get
done "sufficiently quickly" (and any long and potentially obvious stalls
can be avoided).


but, anyways, the costs of a dynamic call need not be much different
than that associated with calling via an interface (depending on
implementation specifics).

Yes, but not cleanly or efficiently.

yes. method calls are not free...

absent special-case trickery (hacking class/method specific logic into
the JIT, ...), there is no real way to work around the various costs of
performing a method call, whereas a special opcode may be much easier to
optimize (the JIT can emit machine-code or similar directly for the
opcode in question).

also shoving more special-case logic into a single instruction also
tends to make it more expensive to execute with or JIT.


granted, in my custom VM I have put in quite a few added instructions
(mostly escape-coded opcodes), but thus far none of them are really used
at present (errm, mostly because I am using the thing mostly for Java
and compiling said code with a standard-ish compiler, namely IBM's...).

I tried using the Sun/Oracle JDK's compiler, but it seemed to refuse to
accept a lot of my code, probably either because I am building my own
custom class libraries (for my VM), or because some of the internal
class-library classes have underscores in their classnames, I have not
really looked into it (if it is the underscores, I may need to get
around to changing them eventually).


or such...
 
M

M.O.B. i L.

Joshua said:
First off, I'm sure that dynamic JIT repatching is likely to cause just
as much uncertainty in terms of instructions.

Second, I don't think the Java compiler ever creates an invokedynamic
instruction call, but I haven't looked en enough detail about it.

I guess it should do that in JDK 7 -- perhaps not normally the Java
compiler but the compilers for the dynamic languages, e.g. JRuby and Jython.
Finally, this is going to be at least as fast as the non-invokedynamic
workaround for it anyways, so it's no worse off for realtime processes.

Well, I meant that the runtime could do thread synchronization between
byte code instructions, but perhaps a runtime wouldn't do it in the
middle of a byte code instruction or during native method calls (JNI).

Couldn't the non-invokedynamic workarounds that uses JNI be equally
fast? Then one could just choose one implementation and include that in
the new JDK rather than changing the JVM specification. This would be
more flexible if there are additional demands from the dynamic language
developers.

When one compares speed improvements for dynamic languages one should
compare the suggested invokedynamic approach with the JNI-approaches,
and not with a pure Java implementation using the existing JVM.
 
R

Roedy Green

Wouldn't invokedynamic create problems for real time
programs?

I think what you are worried about is interrupts being ignored for the
entire instruction execution. Complex instructions even in PicoJava
type CPUs are implemented as a series of simpler instructions in
firmware.
 
T

Tom Anderson

Remind me: what does invokedynamic do differently from invokevirtual?

Everything.

It's not just a slightly looser version of invokevirtual which lets you be
a bit more vague about types in the bytecode. It involves a completely
new, and frankly batshit insane, calling process, which involves finding
and using things called MethodHandles, which are objects, but which can
get involved with the call process.

Bear in mind that dynamic languages (here i will use a dynamic version of
java i have just made up) don't just need to be able to do:

var foo = 23;
foo.toString(); // foo has no static type here

They need to be able to do:

var foo = 23;
foo.toQuotedString = do String() {return "'" + this.toString() + "'"'}; // made-up lambda syntax
foo.toQuotedString(); // that method didn't even exist a minute ago

Supporting that inside the JVM requires some serious voodoo. invokedynamic
is it.

tom
 
A

Alessio Stalla

Funny. I don't think clojure uses invokedynamic if you do something like

(def my-thingie {:value 23})

invokedynamic (indy for brevity) is not primarily directed at dynamic
languages in the vein of Clojure: its main target are languages like
Python, Ruby or JavaScript - dynamic, single-inheritance OO languages.
Indy allows such languages to integrate their method linking process
with the JVM, with the potential of making it more efficient,
essentially avoiding an extra layer of indirection: foo.bar(args) can
be compiled to <invokedynamic foo bar args> instead of
foo.findMethod("bar", args).apply(args). Clojure and Lisps in general
are not object-based but function-based instead (though they are
object-oriented, in their own way), and as such indy has much less
impact for them. It may still be useful to handle function
redefinition - linking (foo args) to, say,
com.my.lisp.CompiledFunction_foo_1234.apply(args), and relinking it
when foo is redefined, instead of generating
com.my.lisp.Runtime.getFunction(theSymbolFoo).apply(args). Whether
that is really beneficial or not is an open question. I am working on
integrating invokedynamic in ABCL (Armed Bear Common Lisp), but I'm
having trouble - not from indy per se but from the necessity of
integrating the "new" Java SE 6+ code verifier, which is not supported
by our compiler and is required to emit Java 7 bytecode. And it's a
pain to code...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top