Jax keynote
•
3 recomendaciones•2,957 vistas
Keynote I did at JAX2013 with the topic basically being "the JVM is over - enter the Polyglot Runtime". It is about the work that Oracle and the community is doing to facilitate multiple languages (non Java) on the Java Virtual Machine. This is both relevant for dynamic languages as well as "non dynamic" ones.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Jax keynote
Similar a Jax keynote (20)
Más de Marcus Lagergren
Último
Último (20)
Jax keynote
- 1. Marcus Lagergren | Oracle Why dynamic languages on the JVM matter
- 2. Marcus Lagergren | Oracle Why dynamic languages on the JVM matter
- 3. Marcus Lagergren | Oracle Why dynamic languages on the JVM matter
- 4. Marcus Lagergren | Oracle Why dynamic languages on the JVM matter [and project Nashorn]
- 5. The Legal Slide "THE FOLLOWING IS INTENDED TO OUTLINE OUR GENERAL PRODUCT DIRECTION. IT IS INTENDED FOR INFORMATION PURPOSES ONLY, AND MAY NOT BE INCORPORATED INTO ANY CONTRACT. IT IS NOT A COMMITMENT TO DELIVER ANY MATERIAL, CODE, OR FUNCTIONALITY, AND SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISION. THE DEVELOPMENT, RELEASE, AND TIMING OF ANY FEATURES OR FUNCTIONALITY DESCRIBED FOR ORACLE'S PRODUCTS REMAINS AT THE SOLE DISCRETION OF ORACLE."
- 7. I am here to talk about… The Java Runtime: The JVM
- 8. I am here to talk about… The Universal Meta- execution environment
- 9. I am here to talk about… The Universal Meta- execution environment
- 10. I am here to talk about… The JVM as a multi- language runtime
- 11. I am here to talk about… The JVM as a multi- language runtime (especially in the context of dynamic languages)
- 12. History (what is a runtime, anyway?)
- 13. LISP
- 14. LISP 1950s – First compiler in 1962
- 17. LISP Also – Garbage Collection!
- 18. LISP Also – Garbage Collection!
- 19. Smalltalk
- 21. Smalltalk First class library. First visual GUI driven IDE.
- 22. Smalltalk First class library. First visual GUI driven IDE. Bytecode.
- 23. Smalltalk First class library. First visual GUI driven IDE. Bytecode.
- 25. Dynamic languages ActionScript Adenine APL BASIC BeanShell Clojure ColdFusion Dart Dylan Groovy E Fancy JavaScript Julia Lua MATLAB Objective-C Perl PHP Powershell Python Qore R REBOL REXX Ruby Scheme Smalltalk Snit Tcl VBScript Yoix etc etc etc etc…
- 26. Dynamic languages ActionScript Adenine APL BASIC BeanShell Clojure ColdFusion Dart Dylan Groovy E Fancy JavaScript Julia Lua MATLAB Objective-C Perl PHP Powershell Python Qore R REBOL REXX Ruby Scheme Smalltalk Snit Tcl VBScript Yoix etc etc etc etc…
- 27. Dynamic languages • Dynamic languages are hot today because – They are easy to use – Have no explicit compile stage – Have good code readability – Allow short development time for small projects – Performance is good enough
- 32. Trendy Dynamic Languages Already on top of the JVM
- 33. …and of course V8, Futhark, Carakan, SpiderMonkey, JägerMonkey, *Monkey, Nitro, Rhino, Nashorn, etc etc
- 38. Putting your language on top of the JVM
- 39. Why? • You get so much for free! – Automatic memory management – State of the art JIT optimizations – Native threading capability – Hybridization (javax.scripting, JSR-223) – Extending Java – Man decades of high tech
- 41. Why? 0 100000 200000 300000 400000 500000 Code bases Lines If it were all about code complexity – TOTALLY WORTH IT!
- 42. “All problems in computer science can be solved by another level of indirection” - David Wheeler
- 43. Sounds good – implement it! • Just serve up some bytecode • People have been doing it since 1996
- 44. They have been doing it a lot, actually… Fantom Fortress BeanShell Jaskell ANTLR JudoScript ABCL Erjang X10 jdart jgo Nice Gosu Jacl
- 45. “All problems in computer science can be solved by another level of indirection” - David Wheeler
- 46. “All problems in computer science can be solved by another level of indirection” - David Wheeler “Except for the problem of too many layers of indirection” - Kevlin Henney
- 47. So why is it hard?
- 48. So why is it hard? • “Java bytecode” – Notice the “Java” • There are “classes”, “methods”, size limitations, strong types • Languages can be much more dynamic than Java – Different linkage – Loose types
- 49. So why is it hard? • Different levels of “hard” • Square peg, round hole or round peg, oval hole • Scala is a fairly good fit • Ruby or JavaScript are (at least at first glance) pretty lousy ones
- 50. Not every language has exactly 5 strong types int, float, long, double, Object
- 51. Not every language has exactly 5 strong types int sum(int a, int b) { return a + b; } int, float, long, double, Object
- 52. Not every language has exactly 5 strong types int, float, long, double, Object iload_1 iload_2 iadd ireturn
- 53. Not every language has exactly 5 strong types int, float, long, double, Object function sum(a, b) { return a + b; }
- 54. Not every language has exactly 5 strong types int, float, long, double, Object ??? ??? ??? ???
- 55. Not every language has exactly 5 strong types int, float, long, double, Object ??? ??? ??? ???
- 56. Also: It is hard to swap out code with other code
- 57. Also: It is hard to swap out code with other code
- 58. Applicability and Performance • The extra layer also costs us performance • How can we work around it?
- 59. Applicability and Performance • The extra layer also costs us performance • How can we work around it? • Passive – Just wait – JIT is getting better all the time, GC is getting better all the time
- 60. Applicability and Performance • The extra layer also costs us performance • How can we work around it? • Passive – Just wait – JIT is getting better all the time, GC is getting better all the time • Active – Punch through the indirection layer – There are tools these days
- 61. Punch through the indirection layer invokedynamic is my ice pick
- 62. Invokedynamic • Breaks the constraints of Java calls and linkage • Can implement calls that act like function pointers • More general: can implement custom data access • Makes it possible to efficiently swap out code
- 63. The whole point: The JVM can optimize this!
- 64. The Nashorn Project (a Rhino for 2013)
- 67. Rationale • Proof of concept: invokedynamic • Does it provide all required functionality? • Does it perform? • Back in late 2010: – We must become the ultimate invokedynamic consumer and find out – Cross communication with other teams
- 68. Rationale – JavaScript? • Extremely dynamic – All (well, most) getters, setters, calls have to be invokedynamics • Rhino is slow and old • JSR-223 – Should make it easy to provide POC apps for Nashorn
- 73. Further POC: node.jar • A node.js implmentation in only Java and JavaScript – Forked the original node.js – threw out all native code – Async I/O implemented with Grizzly • Deploys fine on the ARM JVM on Raspberry PI • Might just as easy be a Java EE cloud offering
- 74. Nashorn already in OpenJDK 8 Now: more Nashorn & JVM performance enhancements Now: more powerful hybrid proof of concepts, e.g. node.jar, JavaFX
- 75. Contribute! 1. Ask the community to contribute functionality, testing, performance [analysis], bug fixes, library optimizations, browser simulation frameworks, kick-ass hybrid Java solutions. JVM optimizations 2. … 3. PROFIT! blogs.oracle.com/nashorn nashorn-dev@openjdk.java.net
- 76. The Da Vinci Machine (MLVM)
- 77. Can we do better than the ice pick? Reshape the hole!
- 78. Let’s continue building our “future VM” • An open source incubator for JVM futures • Contains code fragments (patches) • Migration to OpenJDK requires – A standard – A feature release plan mlvm-dev@openjdk.java.net
- 79. It’s more than just invokedynamic • Unified type systems • Pluggable frontends, “bytecode 2.0” • Tail calls • (delimited) Continuations / Coroutines • Tuple types or C-style structs • Tagged values • Arrays 2.0 • …
- 80. Da Vinci Machine Patches
- 81. It’s not just invokedynamic The JVM is evolving to become the multi-language runtime
- 82. Danke! [Hopefully, I’ll see you again at the Nashorn / invokedynamic deep dive 16.45 this afternoon] @lagergren