Jvm.go: A JVM written in Go(github.com)
github.com
Jvm.go: A JVM written in Go
https://github.com/zxh0/jvm.go
15 comments
You do realise that Oracle's JVM isn't the only one and there are many open source JVM alternatives. Quite a few of which are designed for lightweight systems:
http://en.wikipedia.org/wiki/List_of_Java_virtual_machines
And I have no idea what you mean by baggage. I am assuming you mean "features" like JNI, JMX etc ?
If that is the case then the modularisation of the JVM is something that has been underway for a number of years now. It is targeted for Java 9 release:
http://openjdk.java.net/projects/jigsaw/
And there is no difference in the way Oracle or Sun has managed the JVM. Changes are still made through the JSR/JEP process.
And finally again no idea what you mean by countess Java developers wanting to reuse their knowledge but in a different environment.
Android is already an option as is Swing but honestly does anyone care about desktop apps these days ?
http://en.wikipedia.org/wiki/List_of_Java_virtual_machines
And I have no idea what you mean by baggage. I am assuming you mean "features" like JNI, JMX etc ?
If that is the case then the modularisation of the JVM is something that has been underway for a number of years now. It is targeted for Java 9 release:
http://openjdk.java.net/projects/jigsaw/
And there is no difference in the way Oracle or Sun has managed the JVM. Changes are still made through the JSR/JEP process.
And finally again no idea what you mean by countess Java developers wanting to reuse their knowledge but in a different environment.
Android is already an option as is Swing but honestly does anyone care about desktop apps these days ?
I mean we carry stuff around from the days when we (the Java community) felt 'more is good' - you know the days of spit Java Blueprints.
> And there is no difference in the way Oracle or Sun has managed the JVM
Yet coincidentally more positive changes have happened to the language in the last 3 years than the previous 10? I see a language that was dying on it's feet coming back to life - so hence my feelings about Oracle's stewardship (right or wrong!).
> And finally again no idea what you mean by countess Java developers wanting to reuse their knowledge but in a different environment.
Almost every Java programmer I know and/or meet has their 'other language'. That they use to solve problems that Java has failed in. But a common frustration is the need to relearn a similar but subtly different syntax. Concrete examples are NodeJS (and hence Nashorn, Vert.x et al) for lightweight format neutral APIs. Android for mobile :-) so hat's a win. Go for systems (Python in the past). Objective-C et al Desktop.
For me there is no concrete reason why we can't have these in Java (language). But in doing so we need to be willing to throw away components that don't fit. I.e. existing APIs, existing philosophies. Java is much more than the language, however so when tackling problems that aren't large scale serverside applications we need to adapt if we are to reuse. This is an area that I very much am interested in seeing develop. My specific case in hand is Android - which reuses Java skills but has a lot less to do with normal Java programming.
Hope that clarifies a bit.
> And there is no difference in the way Oracle or Sun has managed the JVM
Yet coincidentally more positive changes have happened to the language in the last 3 years than the previous 10? I see a language that was dying on it's feet coming back to life - so hence my feelings about Oracle's stewardship (right or wrong!).
> And finally again no idea what you mean by countess Java developers wanting to reuse their knowledge but in a different environment.
Almost every Java programmer I know and/or meet has their 'other language'. That they use to solve problems that Java has failed in. But a common frustration is the need to relearn a similar but subtly different syntax. Concrete examples are NodeJS (and hence Nashorn, Vert.x et al) for lightweight format neutral APIs. Android for mobile :-) so hat's a win. Go for systems (Python in the past). Objective-C et al Desktop.
For me there is no concrete reason why we can't have these in Java (language). But in doing so we need to be willing to throw away components that don't fit. I.e. existing APIs, existing philosophies. Java is much more than the language, however so when tackling problems that aren't large scale serverside applications we need to adapt if we are to reuse. This is an area that I very much am interested in seeing develop. My specific case in hand is Android - which reuses Java skills but has a lot less to do with normal Java programming.
Hope that clarifies a bit.
Baggage: http://stackoverflow.com/questions/313584/what-is-the-concep...
Yes there are many JVM:s but most of them aren't any good.
Yes there are many JVM:s but most of them aren't any good.
They're working on real generics for the JVM, but it's a lot of work, especially to preserve compatibility (which is why it wasn't done beforehand). If you throw out compatibility it's still a lot of work though, plus you no longer have any of the libraries.
I guess if you mean by "not any good" they're slower/less featureful than the original HotSpot JVM, then, well, yes..... you get what you pay for (in terms of resource usage).
I guess if you mean by "not any good" they're slower/less featureful than the original HotSpot JVM, then, well, yes..... you get what you pay for (in terms of resource usage).
Where have you heard that? Generics were implemented using type erasure long ago because it was deemed to hard and would break to much existing code to implement them correctly. What has change to make it feasible now? Not saying you're wrong but I haven't seen any mention of any work in that direction.
Look for project Valhalla. It's doing value types, which means you will be able to write List<int> amongst other things. Obviously that means the int type cannot be erased in that context.
Nothing in particular has changed, but full generics C++ style imply value types, and value types are now on the table whereas before they were not (other higher priorities, I guess).
Nothing in particular has changed, but full generics C++ style imply value types, and value types are now on the table whereas before they were not (other higher priorities, I guess).
Well, I'm fine with the link because it says it was just done for learning, but you'll never get anything practically useful out of this. The performance of the real JVM is decades ahead...
What is the "baggage" of Java? This is just a JVM and Java's JVM has no much more baggage than any other implementation. In order for this to be practical in terms of performance, reliability, and so on, years have to pass and meanwhile Oracle JDK and OpenJDK are not gonna stay still.
As a side note, I really wonder how an engineer can use ghetto talk like "crazy sh*t" and especially in this forum here.
As a side note, I really wonder how an engineer can use ghetto talk like "crazy sh*t" and especially in this forum here.
Yo bitches, I am not an engineer - you may have noticed that this is Hacker News - not Engineering Weekly. I ain't never built any machinery - or designed no bridges - I'm just mo programming wit deez wild fingers.
Take it easy - until you know the language well enough to know when someone is using a complement like 'crazy sh*t' - I wouldn't rush to judge them. Context is everything - as the first two words of this comment attest. Context is everything :-)
Take it easy - until you know the language well enough to know when someone is using a complement like 'crazy sh*t' - I wouldn't rush to judge them. Context is everything - as the first two words of this comment attest. Context is everything :-)
Impotent language, sorry.
> ghetto talk
Excuse me?
Excuse me?
I'm sorry you're offended, maybe that's part of your lingo, too, but "crazy sht" is ghetto talk. Indeed. A self-respected and honorable engineer pays attention to detail - not only in their work, but in their language as well and especially in the meticulous choice of words. English is not my native tongue, but I respect it very much, and the language I respect does not include phrases such as "crazy sht" - it's a rich and very expressive language and only the severely incapacitated include those in their written communication.
First of all, saying that profanity is "ghetto talk" is racist. Ghettos are places that (often poor and persecuted) minorities[1] are pressured to live. So what you said was far more offensive than saying "crazy shit"[2].
Second, wealthier people swear more[3]. So not only are you racist, you're also wrong.
Third, there's a great deal of research showing the usefulness of profanity. It conveys emotional content in a way that other words can't. If you refuse to accept and understand profanity, you're neutering the language.
1. http://www.merriam-webster.com/dictionary/ghetto
2. (On that note, "ghetto" is often used by racist Americans as a pejorative euphemism for "black".)
3. http://newsfeed.time.com/2013/04/10/nine-things-you-probably...
Second, wealthier people swear more[3]. So not only are you racist, you're also wrong.
Third, there's a great deal of research showing the usefulness of profanity. It conveys emotional content in a way that other words can't. If you refuse to accept and understand profanity, you're neutering the language.
1. http://www.merriam-webster.com/dictionary/ghetto
2. (On that note, "ghetto" is often used by racist Americans as a pejorative euphemism for "black".)
3. http://newsfeed.time.com/2013/04/10/nine-things-you-probably...
There's not one or two races in a ghetto - I've been in some myself, so, let's not abuse the "R" word. "Crazy sht" is not swearing, not even profanity; it's just weak speech and a cliche that needs to be eradicated - the whole "sht" thing stinks, literally.
A ghetto is, by definition, mostly populated by minority races. It might be several minorities, but it must be minorities. You say you love English, so you should be particularly sensitive to using a word as it's defined.
What you said was racist, whether you intended it to be or not. Look up the definition and use the word "ghetto" correctly in the future. Using a very loaded word incorrectly is far weaker than saying "crazy shit".
Speaking of crazy shit: if it's neither swearing nor profanity, why won't you spell it correctly in your quotes?
Anyway, your argument here isn't intellectual unless you have some functionally equivalent suggestion to replace "crazy shit" with. And, like I said, profanity has additional emotional content, so you can't replace it with anything that isn't profane without losing some meaning.
What you said was racist, whether you intended it to be or not. Look up the definition and use the word "ghetto" correctly in the future. Using a very loaded word incorrectly is far weaker than saying "crazy shit".
Speaking of crazy shit: if it's neither swearing nor profanity, why won't you spell it correctly in your quotes?
Anyway, your argument here isn't intellectual unless you have some functionally equivalent suggestion to replace "crazy shit" with. And, like I said, profanity has additional emotional content, so you can't replace it with anything that isn't profane without losing some meaning.
Bullshit (pun intended)! You confuse ethnicity with race. In California where I live, the ghettos are populated by the majority race [0]. Regarding the spelling, I used the OP's spelling to stress out.
[0] https://en.wikipedia.org/wiki/Demographics_of_California
[0] https://en.wikipedia.org/wiki/Demographics_of_California
Sorry, I wanted to use "sh*t", but a single asterisk actually acts as a special formatting character. Too late, I can't edit it.
This looks really neat, but there's no license or copyright notices as far as I can tell. Author, please add a license to your repository!
There's a " LICENSE.txt"[sic] file now. Looks like it's MIT licensed.
1600 commits by one dude? 700 commits in January? An average of 23 commits a day? 12,000 lines written and 7,000 removed just that month. An average of 640 commits per month.
I may be naive. Am I missing something or this guy is an incredible code machine?
I may be naive. Am I missing something or this guy is an incredible code machine?
Nah, that's a perfectly reasonable pace to work at when you have:
* Predefined explicit requirements (a tight spec).
* No distractions.
* No colleagues (i.e. you're working on a non-blocking single thread of execution).
* Enthusiasm.
* An unhealthy enjoyment of coding.
I have worked at this pace and I'm sure many others have, but you need to have those pre-requisites (and they are RARE!).
Bare in mind that if you're the only developer those commits probably haven't been tested and you're not worrying about damaging other people's code.
Of course, you can't scale that model :-)
Which btw is a fantastic real world analogy of why multi-threading can suck horrifically in some cases and why that parallel execution isn't always a good thing.
NOTE: None of that takes a way from a totally awesome and fearless project to take on and complete (which I believe it is?).
* Predefined explicit requirements (a tight spec).
* No distractions.
* No colleagues (i.e. you're working on a non-blocking single thread of execution).
* Enthusiasm.
* An unhealthy enjoyment of coding.
I have worked at this pace and I'm sure many others have, but you need to have those pre-requisites (and they are RARE!).
Bare in mind that if you're the only developer those commits probably haven't been tested and you're not worrying about damaging other people's code.
Of course, you can't scale that model :-)
Which btw is a fantastic real world analogy of why multi-threading can suck horrifically in some cases and why that parallel execution isn't always a good thing.
NOTE: None of that takes a way from a totally awesome and fearless project to take on and complete (which I believe it is?).
I don't know about you, but I could maybe keep that pace 3 days. Maybe 5. But 2.5 months?
When I fall in love with a personal project, it happens to me too. The important factor is that I don't have anyone else to explain myself to, no one blocking my changes, I own the whole project from the bottom all the way to the top - it's basically just a giant positive feedback loop.
I checked my stats and over the last six weeks I have dedicated my spare time (of which there has been more than usual, but I have a family and work 9-5) to my current project, and I've averaged 7 commits per day with 59308 lines added, 22903 deleted.
I am feeling a little burnt out now, but fortunately the code is essentially done and all that's left is a little mop up and writing a blog post.
I checked my stats and over the last six weeks I have dedicated my spare time (of which there has been more than usual, but I have a family and work 9-5) to my current project, and I've averaged 7 commits per day with 59308 lines added, 22903 deleted.
I am feeling a little burnt out now, but fortunately the code is essentially done and all that's left is a little mop up and writing a blog post.
If you have a list of hundreds of APIs to implement, you can easily skip the ones that are hard to (properly) implement in the first months. You also may choose to keep TODOs in your code that indicate 'minor' issues whose implementation is tricky, or that may already be correct, but 'just' need checking. For example, if a call that throws must not make any partial changes before throwing, you may whip out something that likely is correct, but postpone the actual verification of that fact.
Alternately, if you are going super-TDD on things and committing after every test, that pace is also reasonable under the conditions you list. I was at about that rate when I once tried to write a scheme interpreter in javascript in a weekend. I mostly succeeded, but ran out of time before getting done with some special forms.
Implementing vm opcodes is not what you'd call demanding. Look at the jvm spec, a lot of opcodes are really very similar. Pop, pop, binary op, push.
First off -- this is really impressive! Is the author present here? I wonder:
- How is the performance?
- Is a GC implemented separately or is the Go one directly used (awesome!)?
- How do calls to native JNI things operate (through CGO)? Does it work?
- How is the performance?
- Is a GC implemented separately or is the Go one directly used (awesome!)?
- How do calls to native JNI things operate (through CGO)? Does it work?
> - How is the performance?
I'm guessing not great. Looks like a simple bytecode interpreter using interface virtual dispatch on the instructions (!).
> - Is a GC implemented separately or is the Go one directly used (awesome!)?
As far as I can tell, it just uses the native Go GC, which is smart.
I'm guessing not great. Looks like a simple bytecode interpreter using interface virtual dispatch on the instructions (!).
> - Is a GC implemented separately or is the Go one directly used (awesome!)?
As far as I can tell, it just uses the native Go GC, which is smart.
Java supports exotic reference types like weak references. These require close integration with the GC, and Go doesn't support them, so Go's GC can't be used to implement them.
And JNI local and global refs and heap walking via JVMTI and …
Not to take away from the author's effort, a basic JVM is not hard to implement. It's easier than writing a JavaScript or a Ruby interpreter, as the Java bytecode was designed for simple execution.
What is a lot of work is writing a high-performance JVM (with a good optimizing JIT and a good GC), getting the details right (especially the Java memory model), and supporting "advanced" features such as JNI and JVMTI.
What is a lot of work is writing a high-performance JVM (with a good optimizing JIT and a good GC), getting the details right (especially the Java memory model), and supporting "advanced" features such as JNI and JVMTI.
I was going to say: "the hard part of a JVM is the JIT, GC and the cooperation between. As it stands now I am not sure it's possible to write a good JVM on anything but C/asm level language."... But I see it's already done.
> "I am not sure it's possible to write a good JVM on anything but C/asm level language"
Graal is one part of a JVM, the JIT compiler, written in Java [0]. It performs about as well as C2, and sometimes better [1].
[0] http://openjdk.java.net/projects/graal/
[1] http://lampwww.epfl.ch/~hmiller/scala2013/resources/pdfs/pap...
Graal is one part of a JVM, the JIT compiler, written in Java [0]. It performs about as well as C2, and sometimes better [1].
[0] http://openjdk.java.net/projects/graal/
[1] http://lampwww.epfl.ch/~hmiller/scala2013/resources/pdfs/pap...
Chris, although it's slightly off topic I just want to fanboy your work for a second. Your blog posts about how Graal/Truffle can inline C into Ruby and vice-versa and beat Ruby+C, all on the JVM, is the most mind blowing compiler tech I've ever seen.
Saying Graal performs about as well as C2 and sometimes better is modest. The Graal/Truffle combo does a lot more than C2 can ever do. It is only really comparable if you ignore the astonishing capabilities it has vs the competition.
For readers who are not aware of this work, and who have an interest in VM/compiler technology, I strong recommend checking out Chris' blog and the Graal/Truffle presentations that are floating around. Basically they've built a program that converts simple syntax tree interpreters into full blown JIT compilers. It means that basically any toy scripting language can have similar performance to, say, Javascript on V8, just by writing the base interpreter with their framework.
But where it gets really crazy is when you write an interpreter for C or (say) Objective-C, and start to get aggressive speculative just in time compilation with seamless cross language optimisation, to the extent that C code can actually be run on a compacting garbage collector.
Saying Graal performs about as well as C2 and sometimes better is modest. The Graal/Truffle combo does a lot more than C2 can ever do. It is only really comparable if you ignore the astonishing capabilities it has vs the competition.
For readers who are not aware of this work, and who have an interest in VM/compiler technology, I strong recommend checking out Chris' blog and the Graal/Truffle presentations that are floating around. Basically they've built a program that converts simple syntax tree interpreters into full blown JIT compilers. It means that basically any toy scripting language can have similar performance to, say, Javascript on V8, just by writing the base interpreter with their framework.
But where it gets really crazy is when you write an interpreter for C or (say) Objective-C, and start to get aggressive speculative just in time compilation with seamless cross language optimisation, to the extent that C code can actually be run on a compacting garbage collector.
Hah, I'm actually quite grateful that you didn't actually link to his blog (presumably[1]?) -- not because it's not interesting, but because if I hadn't tried to find "chris' blog" on truffle/graal, I wouldn't have come across:
http://cesquivias.github.io/blog/2014/10/13/writing-a-langua...
I've yet to read through [1], but the series above (so far up top 4 parts) gives a nice overview of truffle/graal -- and some ideas as to how it is different/similar to rpython/pypy. Be sure to also skim the comments, as they provide some input to why things are/starts out slow, and how to fix it (if it can be fixed).
Didn't realize there'd actually materialized any actual released code from the graal project -- glad it has (quite a while ago, apparently)!
[1] http://www.chrisseaton.com/rubytruffle/
http://cesquivias.github.io/blog/2014/10/13/writing-a-langua...
I've yet to read through [1], but the series above (so far up top 4 parts) gives a nice overview of truffle/graal -- and some ideas as to how it is different/similar to rpython/pypy. Be sure to also skim the comments, as they provide some input to why things are/starts out slow, and how to fix it (if it can be fixed).
Didn't realize there'd actually materialized any actual released code from the graal project -- glad it has (quite a while ago, apparently)!
[1] http://www.chrisseaton.com/rubytruffle/
> It means that basically any toy scripting language can have similar performance to, say, Javascript on V8, just by writing the base interpreter with their framework.
That actually sounds a lot like what RPython from PyPy enables.
That actually sounds a lot like what RPython from PyPy enables.
Yes. Some of the underlying theory is the same, but truffle appears to generalise to other languages a lot better (note: I am not an expert)
Are you aware of any comparisons that shows "truffle appears to generalise to other languages a lot better"? I'd be interested in reading them. :)
The performance of various RPython interpreters like PyPy and HippyVM are pretty impressive.
The performance of various RPython interpreters like PyPy and HippyVM are pretty impressive.
Not aware of any direct comparisons. Perhaps I am engaging in hyperbole :) The reason I said that is I thought RPython is mostly for speeding up Python, and wasn't aware of HippyVM. There are tutorials on how to use Truffle for other languages and some apparently useful implementations though.
RPython is definitely a Python-first thing. PyPy is the only VM written in it that's actually production-ready at the moment. I'm guessing that has more to do with effort invested than any real limitations on RPython's part though. I'll definitely read up more on Truffle. :)
I don't know if it could or couldn't be done well in RPython, but one application of Truffle that shows off how well it generalises to other languages is a C interpreter. We use it to interpret Ruby C extensions.
Thanks very much! Is there anything you'd like to see in a blog post or to get working in JRuby+Truffle?
I don't actually use Ruby so I have never tried JRuby+Truffle. Just general news and information about Graal/Truffle in general would be great though.
There are multiple JVMs written in Java.
Besides the sibling post, JikesRVM is one of the most well known ones.
Besides the sibling post, JikesRVM is one of the most well known ones.
While we're at it, wonder if it runs JGo? Go compiled to java bytecode running on a JVM built in Go.
https://code.google.com/p/jgo/
https://code.google.com/p/jgo/
A relevant post by the author (English translation): http://translate.google.com/translate?hl=en&sl=zh-CN&u=http:...
This is cool, but now there's a risk that tomorrow will bring us JVM.js with a kickstarter, trendy logo, and a subtle but distinct whiff of moral superiority.
Edit: so I really am a cynic, I count at least two on the first page and neither are at all as wanky as my imagination likes to think.
Edit: so I really am a cynic, I count at least two on the first page and neither are at all as wanky as my imagination likes to think.
That is the benefit of working on hard problems that are almost entirely technical. Especially if you are working alone, and usually not getting paid, it's easy to not get distracted by fad movements or popularization in simply writing software. But unfortunately, it usually ends up being a total waste of time.
There are already a few jvm's written in Javascript.
Now put a Lisp on there, quick! Clogure?
Shouldn't Clojure work out of the box if it implements the same API as the JVM?
If it's JLS compliant, absolutely.
Will this open the door to utilizing Java libraries from within go apps?
Coming soon: scala.go (!)
Coming soon: scala.go (!)
No - for that you'd need a Go implementation on the JVM.
Last time I checked there was a half finished student project that does this. But not a full implementation. That's a shame. I've encountered a Go shop that was really suffering from things as basic as "our best debugger is gdb which doesn't really work" and "how do we get a stack trace from our running program?".
The Go crowd like to talk about how Go programs are small and standalone, but obviously the HotSpot JVM is not just a big pile of NOPs. You can get very small implementations of Java too, but only by cutting lots of useful functionality.
I bet if a company produced a solid, compliant Go for the JVM, that'd be a license to print money. I feel like lots of startups are coding themselves into a corner by relying on the relatively new and simple Go runtime. If they could bring their code across to the JVM and get access to all the useful tools it has, that'd be worth some money.
Last time I checked there was a half finished student project that does this. But not a full implementation. That's a shame. I've encountered a Go shop that was really suffering from things as basic as "our best debugger is gdb which doesn't really work" and "how do we get a stack trace from our running program?".
The Go crowd like to talk about how Go programs are small and standalone, but obviously the HotSpot JVM is not just a big pile of NOPs. You can get very small implementations of Java too, but only by cutting lots of useful functionality.
I bet if a company produced a solid, compliant Go for the JVM, that'd be a license to print money. I feel like lots of startups are coding themselves into a corner by relying on the relatively new and simple Go runtime. If they could bring their code across to the JVM and get access to all the useful tools it has, that'd be worth some money.
Go on the JVM completely defeats one of the biggest Go selling points for me: compilation to native code.
Debuggers are definitely a weak spot, though, I agree. Luckily it's being worked on (https://github.com/derekparker/delve).
Debuggers are definitely a weak spot, though, I agree. Luckily it's being worked on (https://github.com/derekparker/delve).
What precise benefits do you look for?
Bear in mind "compile to native code" is a bit vague. JVMs compile bytecodes to native code too, they just do it on the fly instead of ahead of time. If you mean "single executable" then there are ways to do that with Java too, check out the downloadable demos on the Avian website. But many native apps are not single files and have lots of libraries they depend on, so the distinction there isn't obvious either.
Bear in mind "compile to native code" is a bit vague. JVMs compile bytecodes to native code too, they just do it on the fly instead of ahead of time. If you mean "single executable" then there are ways to do that with Java too, check out the downloadable demos on the Avian website. But many native apps are not single files and have lots of libraries they depend on, so the distinction there isn't obvious either.
One of the hats I wear is "DevOps"/"SRE" (among other things). To me the JVM is another big layer of complexity between the code and the hardware it runs on that makes debugging and performance analysis that much more complicated. Granted, it also brings tools to the table (JMX, etc). However given the choice I'll nearly always pick an application that compiles directly to a native machine code binary. It's ironic to me that the JVM was conceived as a portability panacea ("write once, run anywhere") yet outside of mobile virtually everything runs on x86(-64). So with the JVM we have this thick, unnecessary VM layer that penalizes (in terms of performance and complexity) all code running on it.
The fact that Go programs are all statically-linked (easy deployment, no weird dependency issues) and are reasonably safe given idiomatic coding patterns are nice bonuses.
The fact that Go programs are all statically-linked (easy deployment, no weird dependency issues) and are reasonably safe given idiomatic coding patterns are nice bonuses.
Very cool project, I like the focus on readability (even if at the cost of performance): that makes it a good example to show to people who want to learn about the implementation of languages and VMs.
Really cool. Thanks for sharing!
It is pretty impressive as a project, but I am not sure I get the point. JVM already exists, so we can run Java programs. Go exists so we can compile Go programs. What do I get from running a Java program in a Go-built JVM over a C-built JVM?
I've noticed from HN headlines that there's an odd focus on what programming language something is written in. Often they'll take the form of "A <thing that is already common> written in <recently popular language>", rather than a real USP. It's especially odd from a community that places so much emphasis on the importance of a good pitch.
> a community that places so much emphasis on the importance of a good pitch
A subset do, for sure. But some of us are just playing around.
A subset do, for sure. But some of us are just playing around.
I absolutely understand where you are coming from, but then again we are enthusiasts. It has some kind of relevance to us on the basis of being a novelty. Compare, "car engine runs on plant sap".
Think of it in terms of a typical 13 year old boy acting out, e.g. by climbing real high in a tree or doing tricks on his bike, to impress friends/girls. That's all this shit is, except it is targeted to a slightly different audience who will go out of their way to deny it. Not saying that applies to this particular project, just to your comment more generally.
Sometimes it is done just to learn, but it seems a bit silly to do it in public as it were.
Sometimes it is done just to learn, but it seems a bit silly to do it in public as it were.
I think it is closer to a 13 year old doing something that they have spent years practicing, such as a piano recital.
Sure, sometimes it is, undeniably. But given how immature in general this industry is--and that means both in terms of the span of its existence and in terms of the age of practitioners--it sure is suspicious how often X-that-has-been-around-forever-implented-in-Y comes up.
I mean how likely is it that "Hashtable/JS interpreter/JVM implemented in C" is going to be a big hit on HN? Not often. But since Go, JavaScript, and other insert new hotness language here are popular things somehow it's more interesting to retread old ideas with them. That's not the sign of a young master demonstrating his skill, it is the sign of an immature field that hasn't figured out how to distinguish what is new and important from what isn't.
It's unfortunate in particular for the people who do do these projects for fun or learning. These people have their work hijacked for a showoff culture's mutual backpatting.
I mean how likely is it that "Hashtable/JS interpreter/JVM implemented in C" is going to be a big hit on HN? Not often. But since Go, JavaScript, and other insert new hotness language here are popular things somehow it's more interesting to retread old ideas with them. That's not the sign of a young master demonstrating his skill, it is the sign of an immature field that hasn't figured out how to distinguish what is new and important from what isn't.
It's unfortunate in particular for the people who do do these projects for fun or learning. These people have their work hijacked for a showoff culture's mutual backpatting.
A similar thing happens with browser technology. "Look at this amazing WebGL demo!" The thing is, the only interesting thing is that OpenGL can be accessed from JavaScript in the browser. After that, it's just lots of people rehashing demos that were done years ago, but people continue to be impressed because it's in a browser.
So we're all wasting our time. Some people find more interesting ways to do it than others.
It's important for libraries. If you're writing in Go, a Java library doesn't help you much. Think of it as an easy way to qualify leads.
For apps, it matters less but you still have to think about how easy it is to modify. That's why we care about open source, right?
For apps, it matters less but you still have to think about how easy it is to modify. That's why we care about open source, right?
This is the wrong way around for that. It won't give you Java/Go interop.
> It's especially odd from a community that places so much emphasis on the importance of a good pitch.
A good pitch? Why does that even matter? 97% of these projects are for fun/as a learning exercise. If someone is interested those things, then they can check it out. If they aren't, then I guess the author misses out on a few GitHub stars. shrug
A good pitch? Why does that even matter? 97% of these projects are for fun/as a learning exercise. If someone is interested those things, then they can check it out. If they aren't, then I guess the author misses out on a few GitHub stars. shrug
There aren't always great reasons behind great hacks.
We can appreciate them for the ideas they present, the interesting implementation of features, and the what-if's that can come from expanding the hack further.
We can appreciate them for the ideas they present, the interesting implementation of features, and the what-if's that can come from expanding the hack further.
> JVM already exists
Actually there is no single "the JVM," even today. Various JVMs exist, commercial and free, that have their individual strengths.
Actually there is no single "the JVM," even today. Various JVMs exist, commercial and free, that have their individual strengths.
Sometimes we build things just for the experience, just to learn as we build.
Depending on how it is done, one benefit could be you'd be able to use java/clojure/scala to build command line tools, something few people do now because of the slow JVM startup time.
The JVM isn't too slow for command line tools. What is too slow is the size of the executables and the amount of upfront work that secondary runtimes are doing. I can't say anything for Scala, but the startup time of Clojure has nothing to do with the JVM.
Pure Java Hello World launches in 90ms on my machine. Jython Hello World takes 1.3 seconds.
EDIT: to address all the comments.
I am saying the JVM isn't _too_ slow for command line applications. Not ideal, but tolerable.
I just tested the startup time of a robovm'ed Hello World: 23ms FWIW. And the resulting executable isn't exactly light weight.
Pure Java Hello World launches in 90ms on my machine. Jython Hello World takes 1.3 seconds.
EDIT: to address all the comments.
I am saying the JVM isn't _too_ slow for command line applications. Not ideal, but tolerable.
I just tested the startup time of a robovm'ed Hello World: 23ms FWIW. And the resulting executable isn't exactly light weight.
$ otool -L Main
Main:
/usr/lib/libSystem.B.dylib
/usr/lib/libiconv.2.dylib
/usr/lib/libsqlite3.dylib
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
/usr/lib/libstdc++.6.dylib
$ du -sch Main
11M MainA pipeline of Java hello worlds then might take half a second just to spawn the multiple JVMs. It is also important to note that the work a JVM does scales in the number of classes you load: running "saxonb-xslt" with no arguments (so as to get the usage block) takes 215ms "hot" (1485ms "cold") on my relatively beefy server. In comparison, running "xsltproc" with no arguments takes 7ms "hot" (113ms "cold", though my cold numbers for this may be artificially low as maybe the JVM warmed up some C library xsltproc also happens to be using; the number doesn't feel wrong, though, given the hot times, which are perfectly reproducible, btw, as nothing else is happening on this computer). If I actually tried to use Saxon (so it had to load and link even more classes related to the transformations) the slowness would just become more and more painful.
Those numbers seem totally plausible. I am not advocating for `ls` to implemented on the JVM. But for most usages, there is not a huge problem implementing CLI programs on the JVM, but some things like loading a huge AoP framework is out of the question.
Right. The "JVM's slow startup" (or, rather, HotSpot's slow startup) is a result of two things: the tendency of JVM code to use a lot of dependencies and, more importantly, the time it takes the HotSpot to warm up enough until it does all the optimizing compilation to native code.
So, on my machine, Hello World takes about 80ms to launch (and terminate), but writing grep in Java isn't the best idea as it will take a while for the program to achieve "native" speed.
HotSpot shines when running long-running processes, where the JIT is able to perform optimizations few (if any) static compilers can. Java 9, however, is expected to include JIT caching/AOT compilation to help programs that need to start at full speed.
Of course, there are JVMs out there that do AOT compilation rather than JIT, and they don't have a "slow startup".
So, on my machine, Hello World takes about 80ms to launch (and terminate), but writing grep in Java isn't the best idea as it will take a while for the program to achieve "native" speed.
HotSpot shines when running long-running processes, where the JIT is able to perform optimizations few (if any) static compilers can. Java 9, however, is expected to include JIT caching/AOT compilation to help programs that need to start at full speed.
Of course, there are JVMs out there that do AOT compilation rather than JIT, and they don't have a "slow startup".
If the JVM is slow at loading dependencies, that fact is very relevant when talking about the startup time.
> startup time of Clojure has nothing to do with the JVM
Startup time has everything to do with the VM. Check out this post, comparing perf and startup time for Clojure on the CLR vs JVM:
http://stackoverflow.com/questions/10827093/clojure-performa...
> startup time of Clojure has nothing to do with the JVM
Startup time has everything to do with the VM. Check out this post, comparing perf and startup time for Clojure on the CLR vs JVM:
http://stackoverflow.com/questions/10827093/clojure-performa...
All C implementations of languages that exist on the JVM start fast. All JVM implementations are slow. How is this not a JVM problem?
We are working on the lightweightness. We currently throw away a bit of startup performance due to the way we load classes at runtime. That being said, 23ms is quite reasonable i guess.
I don't think the size is horrible, though for mobile, smaller executables do reduce breakage. I haven't tried converting a large app, but I assume even a big jar is a small incremental increase in exe size.
23ms is is pretty good. To compare, Hello World in Python, converted to a native executable has a launch time of 6ms (284k executable size). So there might be some room for improvement. RoboVM is still amazing.
23ms is is pretty good. To compare, Hello World in Python, converted to a native executable has a launch time of 6ms (284k executable size). So there might be some room for improvement. RoboVM is still amazing.
There have been many different VMs implemented on top of JavaScript VM, and it is to be able to run codes written in different languages on JavaScript VM without porting effort. It is useful since there are systems only running JavaScript programs, such as web browsers. I guess the purpose of this project may be justified similarly as Go started off from frustration with JavaScript and Go enthusiasts are dreaming that it would replace JavaScript (or get a spot in every browser) in the future.
Minor note: go is now self-hosted which means it is no longer wrapped in c.
This is a very cool project, I just hope Oracle's lawyers don't descend on this...they have a knack for ruining everything.
Yeah, I mean, just look what they did to the openjdk
Any specifics for the unoriented?
The Oracle JVM is virtually all open source under a different name (OpenJDK) and there are lots of other JVMs out there. Oracle won't care about this project.
It was sarcasm.
On what grounds.
Oh, yay, we can now get DOUBLE GC PAUSES!
I wish the README had more information about the reason this project exists. Is it just a fun toy jvm for learning? Is it meant to be eventually production-ready and performant?
Just knowing whether something is meant as a learning project or for production use vastly changes how people will approach it and I just can't tell with this one.
I wish the README had more information about the reason this project exists. Is it just a fun toy jvm for learning? Is it meant to be eventually production-ready and performant?
Just knowing whether something is meant as a learning project or for production use vastly changes how people will approach it and I just can't tell with this one.
tombenner posted a comment with a link to the author's blog: https://news.ycombinator.com/item?id=9203594
> A relevant post by the author (English translation): http://translate.google.com/translate?hl=en&sl=zh-CN&u=http:... .
Relevant (autotranslated) snip from the blog:
>> Go itself is garbage collected language, so there is no separate jvm.go achieve garbage collection mechanism.
> A relevant post by the author (English translation): http://translate.google.com/translate?hl=en&sl=zh-CN&u=http:... .
Relevant (autotranslated) snip from the blog:
>> Go itself is garbage collected language, so there is no separate jvm.go achieve garbage collection mechanism.
Awesome, I'm happy to be wrong there.
I saw the following code and noticed the commented out "gc" function and assumed it meant it was just "not yet implemented but will be" vs "unneeded". I wish the code was actually documented somewhat.
https://github.com/zxh0/jvm.go/blob/dd74e6227e9d78ad8ec191ec...
I saw the following code and noticed the commented out "gc" function and assumed it meant it was just "not yet implemented but will be" vs "unneeded". I wish the code was actually documented somewhat.
https://github.com/zxh0/jvm.go/blob/dd74e6227e9d78ad8ec191ec...
glancing through the source code I don't see any reason there would be double gc pauses. This appears to be a full jvm, not exec.Command("java", ...).Run().
The JVM handles the garbage collection for Java so if someone writes a JVM in a garbage collected language I would suspect two garbage collectors to be running (one for GO and one for the bytecode the JVM is running).
It would be an interesting concept to pass through Java objects for the GO garbage collector to deal with but that sounds incredibly difficult or impossible.
It would be an interesting concept to pass through Java objects for the GO garbage collector to deal with but that sounds incredibly difficult or impossible.
At least if you are interpreting the language just using the garbage collector of the host language will pretty surly simplify the design a lot. Actually a design where every Java object is simply represented by a Go object should give this for free.
It is actually very easy/simple. Imagine a piece of Java code that calls "new Object()". I don't program in Go, but essentially, the VM would create a temporary variable x := MakeObject(typename = "Object"). Then if that's assigned somewhere, the VM would store the record. When things go out of scope, the GC collects.
But that's exactly what he does if you read his (poorly translated) blog posts.
I think it's actually much simpler to do it this way. It keeps the mapping between Java and Go constructs much tighter.
I think it's actually much simpler to do it this way. It keeps the mapping between Java and Go constructs much tighter.
Ah I didn't see those so I'll have to take a look. The reason I thought it was very difficult and maybe even impossible was mostly because passing through to GO changes the behavior or Java to a point where it could cause some adverse affects in applications tuned or expecting it to work as the other JVMs work.
Still a cool project either way.
Still a cool project either way.
For many things that may be the case, but to my knowledge Java doesn't make any strict assumptions about garbage collection. You can get drastically different behavior just by passing different parameters to your JVM for instance.
As long as the Go garbage collection works, it shouldn't affect how the program runs. That's kind of the whole point of GC. Hell, you could write a toy VM with no garbage collection, and it would work fine until you blew your memory.
As long as the Go garbage collection works, it shouldn't affect how the program runs. That's kind of the whole point of GC. Hell, you could write a toy VM with no garbage collection, and it would work fine until you blew your memory.
Such schemes are not impossible, as Servo does something similar: https://blog.mozilla.org/research/2014/08/26/javascript-serv...
It's actually much easier to just use the host language's memory model. Writing a GC is much harder.
[deleted]
I think what he means is that Go's built-in GC cannot be used to handle GC for the JVM. So the developer probably has to develop a GC for JVM data in Go. But since Go is a GCed language, the implementation of the JVM GC itself will be GCed at times. So you have two nested garbage collectors.
> I think what he means is that Go's built-in GC cannot be used to handle GC for the JVM.
Sure it can, and that appears to be what this JVM does. There's nothing in the JVM spec that says you have to implement your own GC any more than you have to implement IEEE floating point numbers yourself. In fact, I don't think the JVM mentions GC at all. It just assumes infinite memory.
If your implementation platform (in this case Go and the Go runtime) gives you something, by all means use it.
Sure it can, and that appears to be what this JVM does. There's nothing in the JVM spec that says you have to implement your own GC any more than you have to implement IEEE floating point numbers yourself. In fact, I don't think the JVM mentions GC at all. It just assumes infinite memory.
If your implementation platform (in this case Go and the Go runtime) gives you something, by all means use it.
> I don't think the JVM mentions GC at all. It just assumes infinite memory.
It seems like it must mention something about finalizers.
It seems like it must mention something about finalizers.
Actually, strangely enough, I can't find any mention of finalizers at all in the JVM spec. The Java spec does, of course, but I can't find it in the JVM spec.
Oh, yay, we can now get DOUBLE GC PAUSES!
I've also been in a position where I've exclaimed something "clever," only to find out later that it actually revealed a point of ignorance.
I've also been in a position where I've exclaimed something "clever," only to find out later that it actually revealed a point of ignorance.
Virtual machine implemented in GCd language -> Get ready, On your marks, FUD.
We need more people doing crazy sh*t like this. Java is a fantastic runtime - and a great language. But it has a huge amount of baggage. I'd love to see experiments int the open source arena playing around with alternatives to the standard Oracle JVM.
I'd love to see Android like alternatives for the desktop that re-use java's syntax but have less baggage and are not tied to Sun's view of what Java should be (Oracle's view of the language is actually a lot better than Sun's thank god).
There are countless Java developers who would like to reuse their knowledge but in a different set up. E.g. desktop not server, lightweight not heavyweight, systems level (like go/python) etc.
I keep hoping that one of these JVMs will end up going in their own direction one day not trying to achieve official Java compatibility.
Anyway kudos to the author.