8 ms·

Eclipse Vert.x goes Native

182 points by Samtaran 8y ago

simias 8y ago
This is impressive, although the cynic that I am can't help pointing out that we must have gone wrong somewhere when a "hello world" HTTP server application "only" taking 40MB of RES is seen as an improvement. That's more than 40 million bytes to open a socket, receive a few bytes, parse them and then write a few bytes back. The overhead of modern software development is insane. Of course I'm not not being entirely honest, a lot of this overhead is probably a constant and wouldn't grow linearly for more complex applications.
- Samtaran 8y ago
  Check out this article in which the author was able to run an app written in java with 4MB RAM only using GraalVM: https://sites.google.com/a/athaydes.com/renato-athaydes/posts/a7mbnative-imagejavaappthatrunsin30msandusesonly4mbofram https://sites.google.com/a/athaydes.com/renato-athaydes/post... That clearly shows whats possible.
- pavlov 8y ago
  Every application comes with an entire operating system's worth of code nowadays. Download a desktop chat client or a little menu bar utility — each app includes its own copy of Electron at 150MB. Make a "Hello world" web client app using React with the recommended "create-react-app" toolchain — your project will first download nearly 200MB of code via npm (and each project you start will have its own copy of this stuff). Make a web server with a framework like Rails, Vert.x or whatever — be prepared to spend hours downloading dependencies and setting up your local environment just so. I don't have any good ideas for how to break this cycle. By 2028, I expect every to-do app will include its own 4GB copy of Ubuntu because it's convenient.
  - koolba 8y ago
    > I don't have any good ideas for how to break this cycle. By 2028, I expect every to-do app will include its own 4GB copy of Ubuntu because it's convenient. 2028? More like 2015. It’s already like that for much of what runs in Docker containers.
    - gnur 8y ago
      Kind of, except that the base ubuntu image is more like 70MB.
      - pavlov 8y ago
        I was thinking of the Ubuntu desktop. Each desktop utility could be its own virtual machine, and it wouldn't be so far removed from what already happens with Electron.
        homarp 8y ago
        see https://www.qubes-os.org/ https://www.qubes-os.org/ and https://www.qubes-os.org/news/2018/01/22/qubes-air/ https://www.qubes-os.org/news/2018/01/22/qubes-air/
      - IanCal 8y ago
        And if things are using the same base, you don't have multiple copies but only one copy of the base image.
    - jrs95 8y ago
      Is it? Most people I’ve seen working with Docker have tried their best to use Alpine for everything. Even something with a lot of OS dependencies tends to end up at around 200MB on the high end.
      - spacemanmatt 8y ago
        my nginx image is around 16M until I add python (certbot)
  - bradleyjg 8y ago
    Every cell in your body includes gigabytes worth of source code for the entire organism. Maybe this kind of redundancy isn’t such a bad idea? The industry has tried shared library schemes many many times and it always turns out to be a mess.
    - pavlov 8y ago
      There's over 10^13 cells in the human body. If my computer had enough memory to fit 10 trillion copies of Electron, I wouldn't be complaining.
      - krylon 8y ago
        > If my computer had enough memory to fit 10 trillion copies of Electron, I wouldn't be complaining. You would, once you saw the power bill. ;-) SCNR
    - kbenson 8y ago
      I think there was a shift lost in the metaphor. Most people don't care if they have hundreds of copies of distros scattered around their humongous disks, but they might care if all those distros are running and actively using RAM and CPU cycles. In the same vein, I'm pretty sure that while all those cells contain a copy of DNA, they don't all execute the whole copy all the time.
      - theyinwhy 8y ago
        Deduping in ram anyone? https://theithollow.com/2012/12/17/memory-de-duplication-in-vmware/ https://theithollow.com/2012/12/17/memory-de-duplication-in-...
  - throwaway2048 8y ago
    you wish, more like each subcomponent of ubuntu will contain its own full operating system enviroment itself aswell.
  - specialist 8y ago
    I was an early critic (technorati objector) of the app server movement. Then I needed to have a UI to monitor & manage a bunch of independent loosely coupled processes. Think poor man's workflow engine. Imagine my chagrin when I knowingly, faithfully recreated the Windows Task Manager for my stack. I was very late to the Unix world. But I really think the Unix way is something akin to a golden law of the universe. Which each new cohort needs to rediscover for itself.
  - BenoitP 8y ago
    > and each project you start will have its own copy of this stuff I don't get why npm can't setup a content addressed shared repository, something à la m2/maven. This seems like such a waste of space. I'm not up to speed with filesystems, but IMHO content-addressing by default should be a standard feature as well.
  - acemarke 8y ago
    The set of dependencies that comes with CRA (and other similar tools) includes: - A compiler - A bundler/linker - An optimizing minifier - A linter - A development server with live reloading - A test runner All of those are isolated and scoped to that one project, and they are all build-time dependencies only. The build output you actually deploy is just static JS/HTML/CSS files, and developers are encouraged to keep those at a few hundred KB tops. It's also important to understand that Javascript packages are effectively distributed as source, which affects the number of files on disk. (Granted, many NPM packages do include unnecessary files in the published artifacts, but Javascript itself is a major factor there.) Meanwhile, XCode is supposedly something like 8GB installed, Visual Studio is multiple gigs, and if you were to look at the actual file size on disk of any C++ compiler toolchain, that would be a minimum of several dozen megs - those are just usually preinstalled on Linux or Mac systems. So, context is pretty important here. A couple hundred MB for a complete JS build toolchain is perfectly fine :)
  - fest 8y ago
    I've seen embedded device which runs on yocto/poky flavour of Linux, and the main app chroots into Ubuntu 14.04 for no apparent reason.
- jug 8y ago
  Yes, but GraalVM is still a VM with all that implies. An emulation of a computer system to execute code in a platform independent environment, where another security-wise benefit is the walled garden nature. I think that all this done in 40 MB is pretty fascinating!! It depends on how you look at it? If you want the lowered resources, go ahead and code in C or why not Free Pascal, with an underestimated pretty mature and stable API on a multitude of platform targets. There are plenty of active projects with rich libraries. But there are also several disadvantages from not running on a VM. I think that these days, what you look for sometimes makes sense but in my opinion mostly just if you are into operating systems, embedded systems, hardware drivers, and so on. I don't think the added effort is worth it otherwise except for maybe personal pet projects. :)
  - tom_mellior 8y ago
    > Yes, but GraalVM is still a VM with all that implies. What does it imply? For one thing, the term "VM" itself is vague. GraalVM isn't an "emulation of a computer system" in the way a "VM" like VirtualBox is.
    - tootie 8y ago
      It sorta is. It was like a single Docker image called "Java" that gave you a complete runtime environment with all the OS internals available through a standard API so long as you wrote everything in one language.
      - tom_mellior 8y ago
        An API is not an emulation of a thing X. It's a way for you to access the actual X. Besides, as a sibling comment pointed out, even that loses all significance with native image compilation that throws out all the API methods that are not used, and inlines away the ones that are used.
  - viraptor 8y ago
    > GraalVM is still a VM with all that implies. An emulation of a computer system to execute code in a platform independent environment, Not with graalvm native image compilation. It does ahead of time compile and eliminates the bytecode as far as I understand. It still uses managed memory and other abstractions, but it's quite far from a typical java VM. (And definitely away from a system vm)
- pron 8y ago
  This is actually very, very sane. I've been a professional developer for 25 years, and in the old days we used to -- or, rather, had to -- make use of a lot of crazy hacks to get what we wanted, in terms of performance and RAM footprint, from slow, RAM-limited machines. This resulted both in brittle code (which wasn't so bad because the programs had to be small) and in increased development time. These days, you can increase the performance of your code by writing well-optimized code, using a better compiler (but there's a limit to that), getting more CPUs (but there's a limit to that, too, due terms of hardware support, programming style and Amdahl's law) and getting more RAM. By far the most expensive option is writing hand-optimized code, and the cheapest, least limited resource (except for special cases of constrained environments) is RAM. Every MB of RAM spent on making your code faster while still keeping development costs low is a MB well-spent. Of course, nothing here should be taken to the extreme.
  - specialist 8y ago
    I'm really struggling with this. Most of my professional career, I've optimized my time. My novel strategy has always been "do less work" (aka a month of coding can save a week of design). 80% of a project is maintenance, right? Mitigating that means clear code, good docs, safety net of tests, etc. Is that 80% still true? I've heard, but cannot yet validate, that code now only lives 3 years. I just can't believe how much code we're all creating. Over the weekend, I rewrote some incomprehensible goo which took months to create. A module all our services use. A real pain point. My rewrite is 1/6th the size. Was the rewrite worth it? I honestly can't say.
    - BenoitP 8y ago
      > I've heard, but cannot yet validate, that code now only lives 3 years. That would be the rate at which the Hello World's and the front-end pieces get replaced. Back-end or entreprise code is very different in my experience. Most enterprise internal apps actually live for much much longer that that. These are seen as cost centers and never get the necessary cash to be properly refactored. They are usually riddled with copious amounts of lava flow anti-patterns [1]; and outlive several times over the users, the developers, the management, and the founders/CEOs. If the hardware dies, they get put as-is on a VM that emulates the old hardware. Development is incremental and grinds slowly down, tending to the asymptotic ratio of changing business needs w.r.t. the amount of archeology required. [1] https://en.wikipedia.org/wiki/Lava_flow_(programming) https://en.wikipedia.org/wiki/Lava_flow_(programming)
- shellac 8y ago
  On my machine it's an order of magnitude larger than `true`. /usr/bin/time -f "\nmaxRSS\t%MkB" true maxRSS 1276kB I'm not sure what to make of that.
- dullgiulio 8y ago
  Not a lot of pruning. Incidentally, writing the same thing in Go (for example) yields more or less the same binary size. You should see how quickly the binary size grows as you add more of your code (answer: not much) and what the alternative is: a txt file containing "hello world" and a statically built nginx server.
  - eikenberry 8y ago
    They list the binary size as 27MB where a similar Go binary is just under 5MB. So I'm not sure where you got your numbers, but they're wrong. Also you were responding to a comment about the runtime resident memory (RSS) of the app being 40MB, not about the file size.
- dagenix 8y ago
  It's not overhead unless you are intent on only making a hello world app and stopping there. Assuming you are going to make something more involved, you are going to use those extra features. Optimizing the size of the executable for the hello world case (outside of a fun weekend project) is insane - optimization should be done for the types of apps that are doing real work. I'm not sure why I'm saying any of this since you seem to be aware of it - your second paragraph says the same thing and completely contradicts your first paragraph.
- jpalomaki 8y ago
  What is the most scarce resource for average developer. Is it CPU? Is it memory? Is it network bandwidth? Or is it his own time? I guess for most developers it is reasonable to trade-off to blow few megabytes here and some kilobits there in order to save even few hours of precious calendar time. When everybody contributing to the dependency graph does that, it adds up.
AndrewSChapman 8y ago
Excellent! I've started using Vert.x with Kotlin instead of PHP for making restful API's and it's wonderful. Event driven, strongly typed and performant. Looking forward to trying this out.
- nobleach 8y ago
  Did you find the documentation to be a bit painful? I gave it a shot for API endpoints too, and was very frustrated that Kotlin felt like a fourth class citizen... and the existing docs displayed one of my biggest pet peeves with most Java-esque docs; "we won't mention the imports, you'll probably have an IDE that figures those out magically". As a Vim user, that's a bit more difficult.
marktangotango 8y ago
Great but whats the gc story? Does substrate vm include a generational gc?
- tom_mellior 8y ago
  Yes, according to https://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate-vm.html https://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate...: "... the SVM has a new generational garbage collector (GC) that’s different from the JVM’s. The SVM ahead-of-time (AOT) compiler uses a 1 GB young generation size and a 3 GB old generation size by default."
- Reason077 8y ago
  Yes, SubstrateVM provides generational GC. Just not traditional Java dynamic classloading or JIT compilation.
djsumdog 8y ago
I hadn't heard of Vertx until my most recent job where we use it for our platform. We currently deploy in openjdk docker containers. This seems neat, but I'm wondering about dependencies. Does Graal rebuild all your dependent jars to be native? What if you have unsupported things like reflection in a dependency? I'm looking through their website and can't seem to find any answers. We've already run into dependencies for Vertx that puke on Java 9 (depreciated/removed API) and are currently still on Java 8. This seems nice, but I have a feeling that, for production, you'd end up writing a lot around GraalVM.
- nwatson 8y ago
  The "limitations" link in the posted page has a section on "Reflection", [1]. It says: "Support Status: Mostly supported ... Individual classes, methods, and fields that should be accessible via reflection must be specified during native image generation in a configuration file ..." I'd assume libraries your app depends on should be usable via Reflection as well, and that their own calls to reflection APIs should work as well, as long as the classes your code, or the library codes, want to reach are somehow included in the Java --> Native conversion configuration files. [1] https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md#reflection https://github.com/oracle/graal/blob/master/substratevm/LIMI...
- shellac 8y ago
  My understanding is that Graal is doing whole-application compilation, so the dependent jars will be compiled. Reflection is an issue that they have a work around for. There's a good article illustrating various issues [1] in the case of netty written by one of the graal team. (There you'll see an example of a reflection configuration file) [1] https://medium.com/graalvm/instant-netty-startup-using-graalvm-native-image-generation-ed6f14ff7692 https://medium.com/graalvm/instant-netty-startup-using-graal...
randomsearch 8y ago
Does native code execution outweigh the loss of JIT optimisation?
- gabcoh 8y ago
  If I understand it correctly JIT compiles down Hotspots to native code, so if the entire executable is already native it must be just as fast or faster.
  - guipsp 8y ago
    There are some optimizations hotspot can do that substrate cannot
  - jhomedall 8y ago
    JIT compilation makes decisions on how to optimize the generated code based on run-time analysis the program. AOT compilation doesn't have access to that information, which can lead to slower code. However, because AOT compilation isn't delaying the execution of the program, it is allowed to take much more time to optimize the output.
    - pjmlp 8y ago
      You can AOT compile with PGO (Profile Guided Optimization) though.
      - Bjartr 8y ago
        And if you can record profiling data from every machine the code will run on you might be able to be confident no JIT could do better, until a new processor (that is a compatible architecture to the executable) that wasn't available at the time of compilation comes around and JIT can still tune for things like cache sizes or processor features and the AOT executable is stuck not being able to take advantage of them.
        pjmlp 8y ago
specialist 8y ago
My bro and my bestie worked on a Vert.x project. So I got to hear all about it. I can only comment thru comparison. Due to multiple poor life choices, I'm currently stuck maintaining multiple large nodejs code bases. I'm "maturing" our code base from callbacks to promises (futures) to async/await as able. It's terrible. Whatever the future of async I/O programming is, it's not events, promises, callback. I've been reading about and playing with actors, CSP, Erlang/Elixir/Phoenix. If I was doing greenfield, that's where I'd place my bets.
- BenoitP 8y ago
  There is a great approach in Quasar [1] where you program simple blocking code, and the runtime (bytecode manipulation with a Java agent) unmounts and remounts thin contexts in the fat thread you are in. A light thread, if you will. No events/promises/callbacks. It does require unmounting-aware APIs, though; making you incur the usual fat thread mounting/unmounting cost if they are not available. The author of this project is currently implementing the base element of this approach (continuations) in the JVM [2]; probably along the required rewrite of the Java standard library. I'm very excited about this! You could start writing code in Quasar, IIRC they said it will use these continuations when they are made available. I would not be surprised if it is one of the first frameworks to make use of it. [1] http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ [2] http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.htm...
  - ofrzeta 8y ago
    Latest news on the website from 2016. Latest commit on Github from January; build broken. Wouldn't be my first choice for starting a new project, I guess.
  - bpicolo 8y ago
    > unmounting-aware APIs Does that mean libraries need to be rewritten to support it? In my experience, important IO-driven libraries like database access/ORMs tend to be extremely poorly supported for non-language-native concurrency strategies, or even concurrency strategies added late in a language's lifecycle.
tannhaeuser 8y ago
AOT compilation for Java alone is just a technique to improve startup time for command line apps vs actually native apps; AOT shared libs still need JVM infrastructure for GC. Also, going all-in on async doesn't seem that helpful on the JVM where the vast majority of existing code (= what makes the JVM valuable) uses synchronous I/O. So what's the point of this? To start a webserver really fast? I always thought the value of vert.x is to become part of a node.js/CommonJS runtime for the JVM (like what Oracle and RedHat were trying a couple years ago).
- kuschku 8y ago
  > AOT compilation for Java alone is just a technique to improve startup time for command line apps vs actually native apps; AOT shared libs still need JVM infrastructure for GC. That’s true with the JVM’s AOT project, but SubstrateVM is entirely separate – you get a single binary that runs standalone.
- thermodynthrway 8y ago
  I've messed with async on JVM. In my experience, it doubles speed at most for CRUD apps with heavy DB access. Async is only useful if you're thread starved, and most DB calls are fast enough that it never happens. The one place it makes a huge difference is when you're waiting on other, possibly slow, services like third party REST calls. If you have 100 threads and each call takes 1000ms you will run out of threads at 100 req/sec which is quite low for the JVM. Using async in these situations allows thousands of threads to be paused while your 100 still do work, allowing you to handle maybe 10k req/sec even with a slow partner service. A lot of JS programmers don't understand the relation between thread starvation and async, they act like async is magic. If you're not thread starved (everything you do is pretty quick) then async is useless
  - apta 8y ago
    > I've messed with async on JVM. What library or framework did you use? Using ExecutorService or similar would still have those 100 threads blocked even if they run in their own future, correct? The only thing it would allow is queuing the other incoming requests, but it does not time slice or switch to another request upon hitting an IO request.
kodablah 8y ago
Missing under limitations is lack of Windows support (though it's coming they say). Also, I would caution anyone from putting their eggs in this Oracle basket. This is not a community project and we know who the owner is and they do have a premium version. Sure, if you have existing JVM stuff and want a native app, go ahead, just don't build a reliance on it. Otherwise, even if you believe Oracle will be good stewards of the project (which I do believe), it's still ok to avoid it on principles around the owner's other activities. Of course stances like these can't be 100% consistent across everything (especially legacy or defacto standards) but just something to keep in mind.

182 points by Samtaran 8y ago

This is impressive, although the cynic that I am can't help pointing out that we must have gone wrong somewhere when a "hello world" HTTP server application "only" taking 40MB of RES is seen as an improvement. That's more than 40 million bytes to open a socket, receive a few bytes, parse them and then write a few bytes back. The overhead of modern software development is insane. Of course I'm not not being entirely honest, a lot of this overhead is probably a constant and wouldn't grow linearly for more complex applications.

Samtaran 8y ago
Check out this article in which the author was able to run an app written in java with 4MB RAM only using GraalVM: https://sites.google.com/a/athaydes.com/renato-athaydes/posts/a7mbnative-imagejavaappthatrunsin30msandusesonly4mbofram https://sites.google.com/a/athaydes.com/renato-athaydes/post... That clearly shows whats possible.
pavlov 8y ago
Every application comes with an entire operating system's worth of code nowadays. Download a desktop chat client or a little menu bar utility — each app includes its own copy of Electron at 150MB. Make a "Hello world" web client app using React with the recommended "create-react-app" toolchain — your project will first download nearly 200MB of code via npm (and each project you start will have its own copy of this stuff). Make a web server with a framework like Rails, Vert.x or whatever — be prepared to spend hours downloading dependencies and setting up your local environment just so. I don't have any good ideas for how to break this cycle. By 2028, I expect every to-do app will include its own 4GB copy of Ubuntu because it's convenient.
- koolba 8y ago
  > I don't have any good ideas for how to break this cycle. By 2028, I expect every to-do app will include its own 4GB copy of Ubuntu because it's convenient. 2028? More like 2015. It’s already like that for much of what runs in Docker containers.
  - gnur 8y ago
    Kind of, except that the base ubuntu image is more like 70MB.
    - pavlov 8y ago
      I was thinking of the Ubuntu desktop. Each desktop utility could be its own virtual machine, and it wouldn't be so far removed from what already happens with Electron.
      - homarp 8y ago
        see https://www.qubes-os.org/ https://www.qubes-os.org/ and https://www.qubes-os.org/news/2018/01/22/qubes-air/ https://www.qubes-os.org/news/2018/01/22/qubes-air/
    - IanCal 8y ago
      And if things are using the same base, you don't have multiple copies but only one copy of the base image.
  - jrs95 8y ago
    Is it? Most people I’ve seen working with Docker have tried their best to use Alpine for everything. Even something with a lot of OS dependencies tends to end up at around 200MB on the high end.
    - spacemanmatt 8y ago
      my nginx image is around 16M until I add python (certbot)
- bradleyjg 8y ago
  Every cell in your body includes gigabytes worth of source code for the entire organism. Maybe this kind of redundancy isn’t such a bad idea? The industry has tried shared library schemes many many times and it always turns out to be a mess.
  - pavlov 8y ago
    There's over 10^13 cells in the human body. If my computer had enough memory to fit 10 trillion copies of Electron, I wouldn't be complaining.
    - krylon 8y ago
      > If my computer had enough memory to fit 10 trillion copies of Electron, I wouldn't be complaining. You would, once you saw the power bill. ;-) SCNR
  - kbenson 8y ago
    I think there was a shift lost in the metaphor. Most people don't care if they have hundreds of copies of distros scattered around their humongous disks, but they might care if all those distros are running and actively using RAM and CPU cycles. In the same vein, I'm pretty sure that while all those cells contain a copy of DNA, they don't all execute the whole copy all the time.
    - theyinwhy 8y ago
      Deduping in ram anyone? https://theithollow.com/2012/12/17/memory-de-duplication-in-vmware/ https://theithollow.com/2012/12/17/memory-de-duplication-in-...
- throwaway2048 8y ago
  you wish, more like each subcomponent of ubuntu will contain its own full operating system enviroment itself aswell.
- specialist 8y ago
  I was an early critic (technorati objector) of the app server movement. Then I needed to have a UI to monitor & manage a bunch of independent loosely coupled processes. Think poor man's workflow engine. Imagine my chagrin when I knowingly, faithfully recreated the Windows Task Manager for my stack. I was very late to the Unix world. But I really think the Unix way is something akin to a golden law of the universe. Which each new cohort needs to rediscover for itself.
- BenoitP 8y ago
  > and each project you start will have its own copy of this stuff I don't get why npm can't setup a content addressed shared repository, something à la m2/maven. This seems like such a waste of space. I'm not up to speed with filesystems, but IMHO content-addressing by default should be a standard feature as well.
- acemarke 8y ago
  The set of dependencies that comes with CRA (and other similar tools) includes: - A compiler - A bundler/linker - An optimizing minifier - A linter - A development server with live reloading - A test runner All of those are isolated and scoped to that one project, and they are all build-time dependencies only. The build output you actually deploy is just static JS/HTML/CSS files, and developers are encouraged to keep those at a few hundred KB tops. It's also important to understand that Javascript packages are effectively distributed as source, which affects the number of files on disk. (Granted, many NPM packages do include unnecessary files in the published artifacts, but Javascript itself is a major factor there.) Meanwhile, XCode is supposedly something like 8GB installed, Visual Studio is multiple gigs, and if you were to look at the actual file size on disk of any C++ compiler toolchain, that would be a minimum of several dozen megs - those are just usually preinstalled on Linux or Mac systems. So, context is pretty important here. A couple hundred MB for a complete JS build toolchain is perfectly fine :)
- fest 8y ago
  I've seen embedded device which runs on yocto/poky flavour of Linux, and the main app chroots into Ubuntu 14.04 for no apparent reason.
jug 8y ago
Yes, but GraalVM is still a VM with all that implies. An emulation of a computer system to execute code in a platform independent environment, where another security-wise benefit is the walled garden nature. I think that all this done in 40 MB is pretty fascinating!! It depends on how you look at it? If you want the lowered resources, go ahead and code in C or why not Free Pascal, with an underestimated pretty mature and stable API on a multitude of platform targets. There are plenty of active projects with rich libraries. But there are also several disadvantages from not running on a VM. I think that these days, what you look for sometimes makes sense but in my opinion mostly just if you are into operating systems, embedded systems, hardware drivers, and so on. I don't think the added effort is worth it otherwise except for maybe personal pet projects. :)
- tom_mellior 8y ago
  > Yes, but GraalVM is still a VM with all that implies. What does it imply? For one thing, the term "VM" itself is vague. GraalVM isn't an "emulation of a computer system" in the way a "VM" like VirtualBox is.
  - tootie 8y ago
    It sorta is. It was like a single Docker image called "Java" that gave you a complete runtime environment with all the OS internals available through a standard API so long as you wrote everything in one language.
    - tom_mellior 8y ago
      An API is not an emulation of a thing X. It's a way for you to access the actual X. Besides, as a sibling comment pointed out, even that loses all significance with native image compilation that throws out all the API methods that are not used, and inlines away the ones that are used.
- viraptor 8y ago
  > GraalVM is still a VM with all that implies. An emulation of a computer system to execute code in a platform independent environment, Not with graalvm native image compilation. It does ahead of time compile and eliminates the bytecode as far as I understand. It still uses managed memory and other abstractions, but it's quite far from a typical java VM. (And definitely away from a system vm)
pron 8y ago
This is actually very, very sane. I've been a professional developer for 25 years, and in the old days we used to -- or, rather, had to -- make use of a lot of crazy hacks to get what we wanted, in terms of performance and RAM footprint, from slow, RAM-limited machines. This resulted both in brittle code (which wasn't so bad because the programs had to be small) and in increased development time. These days, you can increase the performance of your code by writing well-optimized code, using a better compiler (but there's a limit to that), getting more CPUs (but there's a limit to that, too, due terms of hardware support, programming style and Amdahl's law) and getting more RAM. By far the most expensive option is writing hand-optimized code, and the cheapest, least limited resource (except for special cases of constrained environments) is RAM. Every MB of RAM spent on making your code faster while still keeping development costs low is a MB well-spent. Of course, nothing here should be taken to the extreme.
- specialist 8y ago
  I'm really struggling with this. Most of my professional career, I've optimized my time. My novel strategy has always been "do less work" (aka a month of coding can save a week of design). 80% of a project is maintenance, right? Mitigating that means clear code, good docs, safety net of tests, etc. Is that 80% still true? I've heard, but cannot yet validate, that code now only lives 3 years. I just can't believe how much code we're all creating. Over the weekend, I rewrote some incomprehensible goo which took months to create. A module all our services use. A real pain point. My rewrite is 1/6th the size. Was the rewrite worth it? I honestly can't say.
  - BenoitP 8y ago
    > I've heard, but cannot yet validate, that code now only lives 3 years. That would be the rate at which the Hello World's and the front-end pieces get replaced. Back-end or entreprise code is very different in my experience. Most enterprise internal apps actually live for much much longer that that. These are seen as cost centers and never get the necessary cash to be properly refactored. They are usually riddled with copious amounts of lava flow anti-patterns [1]; and outlive several times over the users, the developers, the management, and the founders/CEOs. If the hardware dies, they get put as-is on a VM that emulates the old hardware. Development is incremental and grinds slowly down, tending to the asymptotic ratio of changing business needs w.r.t. the amount of archeology required. [1] https://en.wikipedia.org/wiki/Lava_flow_(programming) https://en.wikipedia.org/wiki/Lava_flow_(programming)
shellac 8y ago
On my machine it's an order of magnitude larger than `true`. /usr/bin/time -f "\nmaxRSS\t%MkB" true maxRSS 1276kB I'm not sure what to make of that.
dullgiulio 8y ago
Not a lot of pruning. Incidentally, writing the same thing in Go (for example) yields more or less the same binary size. You should see how quickly the binary size grows as you add more of your code (answer: not much) and what the alternative is: a txt file containing "hello world" and a statically built nginx server.
- eikenberry 8y ago
  They list the binary size as 27MB where a similar Go binary is just under 5MB. So I'm not sure where you got your numbers, but they're wrong. Also you were responding to a comment about the runtime resident memory (RSS) of the app being 40MB, not about the file size.
dagenix 8y ago
It's not overhead unless you are intent on only making a hello world app and stopping there. Assuming you are going to make something more involved, you are going to use those extra features. Optimizing the size of the executable for the hello world case (outside of a fun weekend project) is insane - optimization should be done for the types of apps that are doing real work. I'm not sure why I'm saying any of this since you seem to be aware of it - your second paragraph says the same thing and completely contradicts your first paragraph.
jpalomaki 8y ago
What is the most scarce resource for average developer. Is it CPU? Is it memory? Is it network bandwidth? Or is it his own time? I guess for most developers it is reasonable to trade-off to blow few megabytes here and some kilobits there in order to save even few hours of precious calendar time. When everybody contributing to the dependency graph does that, it adds up.

AndrewSChapman 8y ago

Excellent! I've started using Vert.x with Kotlin instead of PHP for making restful API's and it's wonderful. Event driven, strongly typed and performant. Looking forward to trying this out.

nobleach 8y ago
Did you find the documentation to be a bit painful? I gave it a shot for API endpoints too, and was very frustrated that Kotlin felt like a fourth class citizen... and the existing docs displayed one of my biggest pet peeves with most Java-esque docs; "we won't mention the imports, you'll probably have an IDE that figures those out magically". As a Vim user, that's a bit more difficult.

marktangotango 8y ago

Great but whats the gc story? Does substrate vm include a generational gc?

tom_mellior 8y ago
Yes, according to https://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate-vm.html https://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate...: "... the SVM has a new generational garbage collector (GC) that’s different from the JVM’s. The SVM ahead-of-time (AOT) compiler uses a 1 GB young generation size and a 3 GB old generation size by default."
Reason077 8y ago
Yes, SubstrateVM provides generational GC. Just not traditional Java dynamic classloading or JIT compilation.

djsumdog 8y ago

I hadn't heard of Vertx until my most recent job where we use it for our platform. We currently deploy in openjdk docker containers. This seems neat, but I'm wondering about dependencies. Does Graal rebuild all your dependent jars to be native? What if you have unsupported things like reflection in a dependency? I'm looking through their website and can't seem to find any answers. We've already run into dependencies for Vertx that puke on Java 9 (depreciated/removed API) and are currently still on Java 8. This seems nice, but I have a feeling that, for production, you'd end up writing a lot around GraalVM.

nwatson 8y ago
The "limitations" link in the posted page has a section on "Reflection", [1]. It says: "Support Status: Mostly supported ... Individual classes, methods, and fields that should be accessible via reflection must be specified during native image generation in a configuration file ..." I'd assume libraries your app depends on should be usable via Reflection as well, and that their own calls to reflection APIs should work as well, as long as the classes your code, or the library codes, want to reach are somehow included in the Java --> Native conversion configuration files. [1] https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md#reflection https://github.com/oracle/graal/blob/master/substratevm/LIMI...
shellac 8y ago
My understanding is that Graal is doing whole-application compilation, so the dependent jars will be compiled. Reflection is an issue that they have a work around for. There's a good article illustrating various issues [1] in the case of netty written by one of the graal team. (There you'll see an example of a reflection configuration file) [1] https://medium.com/graalvm/instant-netty-startup-using-graalvm-native-image-generation-ed6f14ff7692 https://medium.com/graalvm/instant-netty-startup-using-graal...

randomsearch 8y ago

Does native code execution outweigh the loss of JIT optimisation?

gabcoh 8y ago
If I understand it correctly JIT compiles down Hotspots to native code, so if the entire executable is already native it must be just as fast or faster.
- guipsp 8y ago
  There are some optimizations hotspot can do that substrate cannot
- jhomedall 8y ago
  JIT compilation makes decisions on how to optimize the generated code based on run-time analysis the program. AOT compilation doesn't have access to that information, which can lead to slower code. However, because AOT compilation isn't delaying the execution of the program, it is allowed to take much more time to optimize the output.
  - pjmlp 8y ago
    You can AOT compile with PGO (Profile Guided Optimization) though.
    - Bjartr 8y ago
      And if you can record profiling data from every machine the code will run on you might be able to be confident no JIT could do better, until a new processor (that is a compatible architecture to the executable) that wasn't available at the time of compilation comes around and JIT can still tune for things like cache sizes or processor features and the AOT executable is stuck not being able to take advantage of them.
      - pjmlp 8y ago

specialist 8y ago

My bro and my bestie worked on a Vert.x project. So I got to hear all about it. I can only comment thru comparison. Due to multiple poor life choices, I'm currently stuck maintaining multiple large nodejs code bases. I'm "maturing" our code base from callbacks to promises (futures) to async/await as able. It's terrible. Whatever the future of async I/O programming is, it's not events, promises, callback. I've been reading about and playing with actors, CSP, Erlang/Elixir/Phoenix. If I was doing greenfield, that's where I'd place my bets.

BenoitP 8y ago
There is a great approach in Quasar [1] where you program simple blocking code, and the runtime (bytecode manipulation with a Java agent) unmounts and remounts thin contexts in the fat thread you are in. A light thread, if you will. No events/promises/callbacks. It does require unmounting-aware APIs, though; making you incur the usual fat thread mounting/unmounting cost if they are not available. The author of this project is currently implementing the base element of this approach (continuations) in the JVM [2]; probably along the required rewrite of the Java standard library. I'm very excited about this! You could start writing code in Quasar, IIRC they said it will use these continuations when they are made available. I would not be surprised if it is one of the first frameworks to make use of it. [1] http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ [2] http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.htm...
- ofrzeta 8y ago
  Latest news on the website from 2016. Latest commit on Github from January; build broken. Wouldn't be my first choice for starting a new project, I guess.
- bpicolo 8y ago
  > unmounting-aware APIs Does that mean libraries need to be rewritten to support it? In my experience, important IO-driven libraries like database access/ORMs tend to be extremely poorly supported for non-language-native concurrency strategies, or even concurrency strategies added late in a language's lifecycle.

tannhaeuser 8y ago

AOT compilation for Java alone is just a technique to improve startup time for command line apps vs actually native apps; AOT shared libs still need JVM infrastructure for GC. Also, going all-in on async doesn't seem that helpful on the JVM where the vast majority of existing code (= what makes the JVM valuable) uses synchronous I/O. So what's the point of this? To start a webserver really fast? I always thought the value of vert.x is to become part of a node.js/CommonJS runtime for the JVM (like what Oracle and RedHat were trying a couple years ago).

kuschku 8y ago
> AOT compilation for Java alone is just a technique to improve startup time for command line apps vs actually native apps; AOT shared libs still need JVM infrastructure for GC. That’s true with the JVM’s AOT project, but SubstrateVM is entirely separate – you get a single binary that runs standalone.
thermodynthrway 8y ago
I've messed with async on JVM. In my experience, it doubles speed at most for CRUD apps with heavy DB access. Async is only useful if you're thread starved, and most DB calls are fast enough that it never happens. The one place it makes a huge difference is when you're waiting on other, possibly slow, services like third party REST calls. If you have 100 threads and each call takes 1000ms you will run out of threads at 100 req/sec which is quite low for the JVM. Using async in these situations allows thousands of threads to be paused while your 100 still do work, allowing you to handle maybe 10k req/sec even with a slow partner service. A lot of JS programmers don't understand the relation between thread starvation and async, they act like async is magic. If you're not thread starved (everything you do is pretty quick) then async is useless
- apta 8y ago
  > I've messed with async on JVM. What library or framework did you use? Using ExecutorService or similar would still have those 100 threads blocked even if they run in their own future, correct? The only thing it would allow is queuing the other incoming requests, but it does not time slice or switch to another request upon hitting an IO request.

kodablah 8y ago

Missing under limitations is lack of Windows support (though it's coming they say). Also, I would caution anyone from putting their eggs in this Oracle basket. This is not a community project and we know who the owner is and they do have a premium version. Sure, if you have existing JVM stuff and want a native app, go ahead, just don't build a reliance on it. Otherwise, even if you believe Oracle will be good stewards of the project (which I do believe), it's still ok to avoid it on principles around the owner's other activities. Of course stances like these can't be 100% consistent across everything (especially legacy or defacto standards) but just something to keep in mind.