Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > New JVM instruction invokedynamic

Reply
Thread Tools

New JVM instruction invokedynamic

 
 
M.O.B. i L.
Guest
Posts: n/a
 
      11-13-2010
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?
 
Reply With Quote
 
 
 
 
John B. Matthews
Guest
Posts: n/a
 
      11-13-2010
In article <ibm9k5$34u$(E-Mail Removed)-september.org>,
"M.O.B. i L." <(E-Mail Removed)> 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>
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      11-13-2010
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
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-13-2010
On 11/13/2010 10:38 AM, John B. Matthews wrote:
> In article<ibm9k5$34u$(E-Mail Removed)-september.org>,
> "M.O.B. i L."<(E-Mail Removed)> 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
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      11-13-2010
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
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      11-13-2010
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
 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      11-13-2010
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...

 
Reply With Quote
 
M.O.B. i L.
Guest
Posts: n/a
 
      11-13-2010
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.
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      11-14-2010
On Sat, 13 Nov 2010 16:07:49 +0100, "M.O.B. i L." <(E-Mail Removed)>
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.
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      11-14-2010
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/techni...s/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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
MS JVM and Sun JVM problem Young-Jin Lee Java 3 01-21-2004 04:25 AM
Different behavior for newStringUTF() for Sun JVM and IBM Jvm Lasse Java 1 01-05-2004 07:49 PM
vhdl for implementing pre-fetch and an instruction cache Eqbal Z VHDL 3 11-16-2003 06:07 AM
Private Instruction Sharon Microsoft Certification 1 09-25-2003 08:39 PM
Re: Handling both MS JVM and Sun JVM Kevin Hooke Java 2 09-02-2003 05:31 AM



Advertisments