New JVM instruction invokedynamic

Discussion in 'Java' started by M.O.B. i L., Nov 13, 2010.

  1. M.O.B. i L.

    M.O.B. i L. Guest

    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?
    M.O.B. i L., Nov 13, 2010
    #1
    1. Advertising

  2. In article <ibm9k5$34u$-september.org>,
    "M.O.B. i L." <> wrote:

    > 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>

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
    John B. Matthews, Nov 13, 2010
    #2
    1. Advertising

  3. M.O.B. i L.

    Lew Guest

    On 11/13/2010 10:07 AM, M.O.B. i L. wrote:
    > 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.

    --
    Lew
    Lew, Nov 13, 2010
    #3
  4. M.O.B. i L.

    Lew Guest

    On 11/13/2010 10:38 AM, John B. Matthews wrote:
    > In article<ibm9k5$34u$-september.org>,
    > "M.O.B. i L."<> wrote:
    >
    >> 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>


    It's a rework of the same article by the same writer. That's related, all right.

    --
    Lew
    Lew, Nov 13, 2010
    #4
  5. M.O.B. i L.

    Tom Anderson Guest

    On Sat, 13 Nov 2010, M.O.B. i L. wrote:

    > 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

    --
    uk.local groups TO BE RENAMED uk.lunatic.fringe groups
    Tom Anderson, Nov 13, 2010
    #5
  6. On 11/13/2010 10:07 AM, M.O.B. i L. wrote:
    > 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.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
    Joshua Cranmer, Nov 13, 2010
    #6
  7. M.O.B. i L.

    BGB Guest

    On 11/13/2010 11:22 AM, Tom Anderson wrote:
    > On Sat, 13 Nov 2010, M.O.B. i L. wrote:
    >
    >> 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.
    >


    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.


    >> 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.
    >


    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).


    >> 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.
    >


    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...
    BGB, Nov 13, 2010
    #7
  8. M.O.B. i L.

    M.O.B. i L. Guest

    Joshua Cranmer wrote:
    > On 11/13/2010 10:07 AM, M.O.B. i L. wrote:
    >> 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 invokedynamic 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.


    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.
    M.O.B. i L., Nov 13, 2010
    #8
  9. M.O.B. i L.

    Roedy Green Guest

    On Sat, 13 Nov 2010 16:07:49 +0100, "M.O.B. i L." <>
    wrote, quoted or indirectly quoted someone who said :

    >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.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    Finding a bug is a sign you were asleep a the switch when coding. Stop debugging, and go back over your code line by line.
    Roedy Green, Nov 14, 2010
    #9
  10. M.O.B. i L.

    Tom Anderson Guest

    On Sun, 14 Nov 2010, Ken Wesson wrote:

    > On Sat, 13 Nov 2010 16:07:49 +0100, M.O.B. i L. wrote:
    >
    >> 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.

    >
    > 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

    --
    Passersby were amazed by the unusually large amounts of blood.
    Tom Anderson, Nov 14, 2010
    #10
  11. On Nov 15, 7:45 am, Ken Wesson <> wrote:
    > On Sun, 14 Nov 2010 14:07:12 +0000, Tom Anderson wrote:
    > > On Sun, 14 Nov 2010, Ken Wesson wrote:

    >
    > >> On Sat, 13 Nov 2010 16:07:49 +0100, M.O.B. i L. wrote:

    >
    > >>> 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.

    >
    > >> 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.

    >
    > 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...
    Alessio Stalla, Nov 15, 2010
    #11
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eqbal Z
    Replies:
    3
    Views:
    5,055
    Eqbal
    Nov 16, 2003
  2. Kirby Turner

    Re: Proper Instruction Format

    Kirby Turner, Aug 30, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    387
    Kirby Turner
    Aug 30, 2004
  3. Kevin Hooke

    Re: Handling both MS JVM and Sun JVM

    Kevin Hooke, Aug 26, 2003, in forum: Java
    Replies:
    2
    Views:
    861
  4. Lasse
    Replies:
    1
    Views:
    680
    Jon A. Cruz
    Jan 5, 2004
  5. Young-Jin Lee

    MS JVM and Sun JVM problem

    Young-Jin Lee, Jan 20, 2004, in forum: Java
    Replies:
    3
    Views:
    560
    Mickey Segal
    Jan 21, 2004
Loading...

Share This Page