GraalVM at Facebook(medium.com)
medium.com
GraalVM at Facebook
https://medium.com/graalvm/graalvm-at-facebook-af09338ac519
170 comments
You’re not sure why there’s negativity towards Oracle? That’s an easy one word answer: audits.
I don’t work at Oracle but have lots of customers who use their/your products and they all feel your sales staff and motion are best described as predatory.
I don’t work at Oracle but have lots of customers who use their/your products and they all feel your sales staff and motion are best described as predatory.
I used to work at Oracle, and the penny pinching isn't any better on the inside.
It's a bit ridiculous when, being an Oracle employee and using Oracle products, there's only one member on our team with access to a product's support pages and you have to message him and ask for a PDF printout whenever you run into an obscure issue.
It's a bit ridiculous when, being an Oracle employee and using Oracle products, there's only one member on our team with access to a product's support pages and you have to message him and ask for a PDF printout whenever you run into an obscure issue.
> The pricing model is admittedly a bit complex, but from what I've been told it is a fairly common pricing model in this industry
Yes, but that's one of the reasons Public Clouds are thriving.
Yes, but that's one of the reasons Public Clouds are thriving.
+1 for paying for value. At the scale that companies like Facebook operate, 40% improvement on compute efficiency represents millions. I’m not really an Oracle fanboy, but definitely feel that value should be captured where it’s created, especially for enterprise use cases.
> The pricing model is admittedly a bit complex,
Maybe you can answer this question I had below: https://news.ycombinator.com/item?id=27786051
If at any given second of the course of a month I have somewhere between 500 and 2000 vcore’s worth of AWS vms running with Java SE, how do I figure out how much I owe Oracle?
Amazon, a competitor to Oracle, publicly provides enough information to figure this out.
Maybe you can answer this question I had below: https://news.ycombinator.com/item?id=27786051
If at any given second of the course of a month I have somewhere between 500 and 2000 vcore’s worth of AWS vms running with Java SE, how do I figure out how much I owe Oracle?
Amazon, a competitor to Oracle, publicly provides enough information to figure this out.
It's very hard to justify touching Oracle technology when they are so keen on suing their own customers.
Maybe because some of us old Lions have no illusions
and we do not "...anthropomorphize the lawnmower..."
https://www.youtube.com/watch?v=-zRN7XLCRhc&t=2047s
https://www.youtube.com/watch?v=-zRN7XLCRhc&t=2047s
It just doesn’t sit well with me that they’re charging for things like G1GC which are free in HotSpot.
A lot of people in this thread are coming in here to shit on Oracle.
I don't know anything about Oracle. Maybe they're awful. But I've interacted with the folks on the GraalVM team on a semi-regular basis and they're all genuinely friendly, helpful people.
I can understand bringing up "Hey the parent company is no bueno in my book"
But I don't think it's necessarily fair to the humans behind the product, who don't embody the company itself and are (for the most part) just genuinely interested in working on this problem and building a product -- to bring that kind of criticism.
Imagine you got your dream job working on something you were passionate about, and you're just doing your honest-to-god best, but every time someone brings up your work the only thing you hear is "Hey, fuck your company."
=(
Just my $0.02 though
I don't know anything about Oracle. Maybe they're awful. But I've interacted with the folks on the GraalVM team on a semi-regular basis and they're all genuinely friendly, helpful people.
I can understand bringing up "Hey the parent company is no bueno in my book"
But I don't think it's necessarily fair to the humans behind the product, who don't embody the company itself and are (for the most part) just genuinely interested in working on this problem and building a product -- to bring that kind of criticism.
Imagine you got your dream job working on something you were passionate about, and you're just doing your honest-to-god best, but every time someone brings up your work the only thing you hear is "Hey, fuck your company."
=(
Just my $0.02 though
Then perhaps Graal should forked and managed by a foundation? I'm serious. The tech is pretty cool indeed, and it's open source.
You're right. It's not fair to the creators. They have done an awesome job at creating a very useful thing...but they did it for the wrong company.
This should be a massive warning to anybody who cares about what they create: don't do it for an unethical company that will use your work to fuck over their customers.
This should be a massive warning to anybody who cares about what they create: don't do it for an unethical company that will use your work to fuck over their customers.
I don't have anything against open core business models, but of all the companies to do it, I trust Oracle the least. You just know they've built every trap door that they can into it. Graal is a pretty awesome piece of technology, but I wouldn't touch it with a ten foot pole.
Agree. Its amazing technology in the hands of the worst possible company. It can run anything, JavaScript,
Java, Rust.
Every time I get to the download page, and despite all the claims around the Community edition OS licenses, it just reminds me who is behind it.
I think the trick is that they might just drop their efforts behind the Community Edition anytime. The Open Source license its not a guarantee. Any Open Source team that would decide to pick up the engineering effort would have them coming around and claiming some kind of license infringement.
Really a shame, actually.
Every time I get to the download page, and despite all the claims around the Community edition OS licenses, it just reminds me who is behind it.
I think the trick is that they might just drop their efforts behind the Community Edition anytime. The Open Source license its not a guarantee. Any Open Source team that would decide to pick up the engineering effort would have them coming around and claiming some kind of license infringement.
Really a shame, actually.
The licenses provide good protection. It's GPL2+Classpath Exception, or UPL, where UPL is basically an Apache like license but with a patent grant IIRC. So very liberal. They just got beaten in court by Google where Google literally cloned their entire product before it was open source, so it seems very unlikely they could play funny games with claiming license infringement on something they explicitly put under very liberal licenses, unless you actually do violate the GPL.
The second thing there doesn't seem like a fair criticism of Oracle or any company really. Firstly any company can abandon stuff. There is no expectation that open sourcing something means funding it in perpetuity forever. Look at Google and Facebook, they abandon open source projects at a way higher rate than Oracle has ever done.
And secondly Oracle have actually been very steady hands on the tiller of Java. GraalVM is a very long term project. More than a decade old now. They have been funding long term research programmes like Valhalla. They're still maintaining JavaFX and other large libraries, even when they didn't become super popular. Their attention span is way longer and more stable than the average tech company.
The second thing there doesn't seem like a fair criticism of Oracle or any company really. Firstly any company can abandon stuff. There is no expectation that open sourcing something means funding it in perpetuity forever. Look at Google and Facebook, they abandon open source projects at a way higher rate than Oracle has ever done.
And secondly Oracle have actually been very steady hands on the tiller of Java. GraalVM is a very long term project. More than a decade old now. They have been funding long term research programmes like Valhalla. They're still maintaining JavaFX and other large libraries, even when they didn't become super popular. Their attention span is way longer and more stable than the average tech company.
> UPL is basically an Apache like license but with a patent grant
Apache contains a patent grant.
> still maintaining JavaFX and other large libraries, even when they didn't become super popular
They kept JavaFX proprietary for years before opening it up, and they only did so reluctantly—after it was obvious that it was a failure.
Apache contains a patent grant.
> still maintaining JavaFX and other large libraries, even when they didn't become super popular
They kept JavaFX proprietary for years before opening it up, and they only did so reluctantly—after it was obvious that it was a failure.
Graal without enterprise features offers a 10% improvement with all the will-i-get-sued that comes with any product from Oracle; I would rather simmer in a vat of acid
Huge numbers of companies use Oracle software and are never sued. Moreover Google wasn't using it, that was kind of the point - they were reimplementing it. There's a lot of over-generalization from a single case here.
Funnily enough, Oracle have been a very great steward of Java - they open sourced the whole thing completely for the first time, and it is under very heavy development once again.
To be honest, I would be much more afraid of google touching an open source project for that matter - they have a much worse track record.
To be honest, I would be much more afraid of google touching an open source project for that matter - they have a much worse track record.
> To be honest, I would be much more afraid of google touching an open source project for that matter
Google has thousands of open source projects, including the Chromium web browser, the Chromium operating system, the V8 Javascript engine that Node.js depends on, Kubernetes, Golang, the Android OSP, gRPC, Tensorflow, Authenticator (2FA), etc.
The track record you're apparently referring to, of commercial products being discontinued, is not really that relevant to this. The issue in that case is that they are services that users come to depend on, and then are forced to switch away from. There's not really a comparable scenario in open source. The worst case is that the original sponsor stops paying for new development. If the project is viable enough, forks and other sponsors are likely to arise.
Google has thousands of open source projects, including the Chromium web browser, the Chromium operating system, the V8 Javascript engine that Node.js depends on, Kubernetes, Golang, the Android OSP, gRPC, Tensorflow, Authenticator (2FA), etc.
The track record you're apparently referring to, of commercial products being discontinued, is not really that relevant to this. The issue in that case is that they are services that users come to depend on, and then are forced to switch away from. There's not really a comparable scenario in open source. The worst case is that the original sponsor stops paying for new development. If the project is viable enough, forks and other sponsors are likely to arise.
> Oracle have been a very great steward of Java - they open sourced the whole thing completely
And sued a company for doing their own implementation of Java...
And sued a company for doing their own implementation of Java...
As I understand it, they only open-sourced because almost everyone saw the handwriting on the wall and immediately forked.
It was simply open up or die.
It was simply open up or die.
Your loss, it’s a pretty amazing technology and also totally available under friendly open source license.
Evaluating the long term-maintainability of a tool is maybe more important than evaluating if said tool solves a problem. And when dealing with Oracle, your chance of getting royally screwed on licensing as time goes on approaches 100%. So it all depends what kind of time frame you're working on.
In practice, what would be the risk here?
The whole marketing angle behind GraalVM is that it's a drop-in replacement of your JVM. If things go wrong down the road, what stops you from switching back to an OpenJDK distribution from a 3rd party vendor? Nowadays there are enough companies involved in maintaining OpenJDK and Hotspot... including some that aren't exactly friends with Oracle.
The whole marketing angle behind GraalVM is that it's a drop-in replacement of your JVM. If things go wrong down the road, what stops you from switching back to an OpenJDK distribution from a 3rd party vendor? Nowadays there are enough companies involved in maintaining OpenJDK and Hotspot... including some that aren't exactly friends with Oracle.
I've been burned by far too many subtle bugs caused by real differences in "drop-in" replacements to take that risk again. I've also been burned by too many vendors I thought trustworthy having their priorities change and causing me unnecessary work at bad times.
I work in a very slow moving domain where once we get customers, they tend to stick with a product unless you seriously screw them over. This has moved me to evaluating everything I do on at least a 10-year time horizon.
So in the case of GraalVM, what do I think the risk of Oracle wanting to charge me for every CPU in Amazon's data center is in the next 10 years at the worst possible time to have to drop real work and move everything to OpenJDK? I think it's unacceptably high. YMMV.
I work in a very slow moving domain where once we get customers, they tend to stick with a product unless you seriously screw them over. This has moved me to evaluating everything I do on at least a 10-year time horizon.
So in the case of GraalVM, what do I think the risk of Oracle wanting to charge me for every CPU in Amazon's data center is in the next 10 years at the worst possible time to have to drop real work and move everything to OpenJDK? I think it's unacceptably high. YMMV.
Since the faster release cycle that came with Java 9, you really should not architecture anything running on the JVM if you cannot swap the distribution easily. Even if you're on an LTS version from a good vendor (like RHEL), non-trivial patches get backported and can sometimes introduce weird performance regressions.
Isn't that what long term contracts are for? Oracle sign those, they have a whole section of their website related to contracts.
For GraalVM in particular there's no risk because the EE is basically just the open source CE version + more compiler optimizations. So it truly is a drop in replacement.
For GraalVM in particular there's no risk because the EE is basically just the open source CE version + more compiler optimizations. So it truly is a drop in replacement.
It's not a drop-in replacement if you want to do native image builds. That can require significant changes to a codebase. That would be wasted effort, at least some of which you'd probably want to reverse, if you later find that GraalVM is not a good option.
Nobody is talking about native images. The article is about big data workloads, specifically Spark.
The discussion has certainly moved on from the original premise of the article.
It extends Java, building in fairly comprehensive language interoperability. Honestly, it's an amazing feature...and also the perfect trap. If you build your code taking advantage of it, you lose compatibility with standard JVMs and you give Oracle leverage over you. And the moment they think they have you, they'll do an about face on their licensing and start charging you for it.
The problem with Java is that there's more to it than just the source code, and Oracle has demonstrated no qualms whatsoever about using essential but non-open-source parts of the Java ecosystem to push people around.
Which parts are "non-open-source" and "essential"?
The TCK is the really big one. It is not Free Software, and it more-or-less necessary to get a license for it in order to successfully maintain your own JVM. Look at what happened with Apache Harmony, for example.
There are also some potential patent encumbrances? I know less about that.
I also don't know for sure if IcedTea is still necessary to get a 100% open build of newer versions of Java (I'm still one of those incorrigible elements who's still on Java 8), but, at least historically, there was an appreciable chunk of the official OpenJDK distribution that was not, in actual fact, open.
There are also some potential patent encumbrances? I know less about that.
I also don't know for sure if IcedTea is still necessary to get a 100% open build of newer versions of Java (I'm still one of those incorrigible elements who's still on Java 8), but, at least historically, there was an appreciable chunk of the official OpenJDK distribution that was not, in actual fact, open.
> Look at what happened with Apache Harmony, for example.
It died the moment the OpenJDK was released 14 years ago? The issue wasn't the TCK itself, as far as I understand Sun just didn't want to license any Java implementation that could cut into its embedded market and dragged its feet when the community requested an out for the Apache licensed Harmony project. The TCK now seems to be available for any OpenJDK derived implementation[1] in case you want to use official Java trademarks for your implementation.
> I also don't know for sure if IcedTea is still necessary to get a 100% open build of newer versions of Java
I can't actually find anything about IcedTea for any recent OpenJDK, but its wiki page[2] seems to hint at the IcedTea patches were merged back into OpenJDK. Debian and other free software distros also seem fine with distributing current OpenJDK versions instead of reviving gcj to torment their users.
[1]https://en.wikipedia.org/wiki/Technology_Compatibility_Kit#T...
[2] https://en.wikipedia.org/wiki/IcedTea
It died the moment the OpenJDK was released 14 years ago? The issue wasn't the TCK itself, as far as I understand Sun just didn't want to license any Java implementation that could cut into its embedded market and dragged its feet when the community requested an out for the Apache licensed Harmony project. The TCK now seems to be available for any OpenJDK derived implementation[1] in case you want to use official Java trademarks for your implementation.
> I also don't know for sure if IcedTea is still necessary to get a 100% open build of newer versions of Java
I can't actually find anything about IcedTea for any recent OpenJDK, but its wiki page[2] seems to hint at the IcedTea patches were merged back into OpenJDK. Debian and other free software distros also seem fine with distributing current OpenJDK versions instead of reviving gcj to torment their users.
[1]https://en.wikipedia.org/wiki/Technology_Compatibility_Kit#T...
[2] https://en.wikipedia.org/wiki/IcedTea
[deleted]
The testing suite for the JDK, which allows you to tell if something is compatible to Oracle Java.
Which is frankly a good thing. You wouldn’t want to share the exact questions for a driving license before the test either, would you?
This is a terrible analogy. We're talking about an automated test suite for verifying that a piece of software conforms to an established specification, not a skills assessment for humans.
Compare it more, perhaps, to housing codes. . . and imagine if the specification of the housing codes were covered by an (at least ostensibly) democratic process, but the actual housing inspectors all worked for one company, and that company also happened to be the biggest player in the construction business. So the inspector therefore had a clear incentive treat outside construction firms with less than complete fairness.
Compare it more, perhaps, to housing codes. . . and imagine if the specification of the housing codes were covered by an (at least ostensibly) democratic process, but the actual housing inspectors all worked for one company, and that company also happened to be the biggest player in the construction business. So the inspector therefore had a clear incentive treat outside construction firms with less than complete fairness.
Oracle sells the test kit.
Sure, you wouldn't want to share the answers to the drivers license exam...are you saying that they should sell the answers instead? What the actual fuck?
Sure, you wouldn't want to share the answers to the drivers license exam...are you saying that they should sell the answers instead? What the actual fuck?
> 1998: Many major companies such as IBM, Compaq and Oracle announce their support for Linux.
-- https://en.wikipedia.org/wiki/History_of_Linux
Also if the same morals apply to the remaining contributors of the Linux kernel, better not use it. There are a few other ones that seat at Oracle table, so to speak.
https://lwn.net/Articles/839772/
-- https://en.wikipedia.org/wiki/History_of_Linux
Also if the same morals apply to the remaining contributors of the Linux kernel, better not use it. There are a few other ones that seat at Oracle table, so to speak.
https://lwn.net/Articles/839772/
> Also if the same morals apply to the remaining contributors of the Linux kernel, better not use it.
Your parent said: "[Oracle has] built every trap door that they can into it". Oracle doesn't control what goes into Linux; they can only propose, it's Linus who controls what goes in. So your claim that Linux suffers from a similar risk because Oracle et. al. contribute to it is invalid. Contribution != Control
Your parent said: "[Oracle has] built every trap door that they can into it". Oracle doesn't control what goes into Linux; they can only propose, it's Linus who controls what goes in. So your claim that Linux suffers from a similar risk because Oracle et. al. contribute to it is invalid. Contribution != Control
What a completely disingenuous argument. Oracle never held the sole copyright on Linux, never controlled Linux, nor was it ever a significant contributor to Linux. There was never any threat that Oracle would take Linux closed source and start charging you for it after you've built significant infrastructure on it.
There's a reason you have to give Oracle joint copyright ownership if you contribute to GraalVM. They want to be able to close the source and sell it.
There's a reason you have to give Oracle joint copyright ownership if you contribute to GraalVM. They want to be able to close the source and sell it.
> They want to be able to close the source and sell it.
What a completely disingenuous argument without any concrete facts. Also, you can’t close source something with a permissive dual license.
What a completely disingenuous argument without any concrete facts. Also, you can’t close source something with a permissive dual license.
Yes, you can. The copyright owner always has that right...which is why Oracle now requires all contributors to assign joint copyright ownership of their code to Oracle. In fact, the only reason you would need copyright ownership of contributor code is to reserve the right to change the licensing.
Oracle wanted to do it with MySQL, but their lack of copyright ownership for some parts of a GPL-ed MySQL codebase made it impossible. They fixed that mistake with their new contributor agreement, ensuring that they always have control over your code if you contribute.
Oracle wanted to do it with MySQL, but their lack of copyright ownership for some parts of a GPL-ed MySQL codebase made it impossible. They fixed that mistake with their new contributor agreement, ensuring that they always have control over your code if you contribute.
I think the robustness of the JVM ecosystem makes this less of a concern. It should be of relativity little cost to switch back to HotSpot if Oracle acts up.
My first question was licensing cost. Here's the rate :
$18 per processor per month to use GraalVM Enterprise.
$18 per processor per month to use GraalVM Enterprise.
The trouble you'll run into with Oracle licensing is that, in many cases, when they say "core" they mean cores for the underlying hardware. If you are running this on a virtual machine, Oracle will traditionally want you to license every core on the box underneath, even if you're only carving out 2 or 4 or whatever for the VM itself.
Worse, if your VM platform supports migration (vMotion et al), they will then insist that you buy licenses for every core the workload could theoretically run on. For modern hypervisors, this often times means licensing every core in your virtualization estate. I've had Oracle licensing tell me this exact thing with a straight face.
There are more than one law firms in the US which do nothing but sue Oracle on their client's behalf. When your licensing terms are so odious that multiple law firms can make a living fighting your terms.... something isn't right.
"One Rich Asshole Called Larry Ellison"
Worse, if your VM platform supports migration (vMotion et al), they will then insist that you buy licenses for every core the workload could theoretically run on. For modern hypervisors, this often times means licensing every core in your virtualization estate. I've had Oracle licensing tell me this exact thing with a straight face.
There are more than one law firms in the US which do nothing but sue Oracle on their client's behalf. When your licensing terms are so odious that multiple law firms can make a living fighting your terms.... something isn't right.
"One Rich Asshole Called Larry Ellison"
It's super confusing. There are several ways to get it. I think it's free if you run stuff in the Oracle Cloud. And the pricing on Oracle Cloud is actually quite good.
But the price list is here, it seems:
https://www.oracle.com/us/corporate/pricing/price-lists/java...
So price can vary between $25/processor/month and $12.50/month with further discounts available if you negotiate, probably. But ... this has to be rounded up to whatever the physical processor has, then multiplied by some "core factor" which can actually reduce the number of cores you need to buy from the physical number. Which can be found here:
https://www.oracle.com/us/corporate/contracts/processor-core...
For Intel and AMD chips, the factor is 0.5 - so the actual prices are just half of those numbers!
The rules about virtualization are kinda weird especially because Oracle Cloud presumably is virtualized itself. Presumably it's because if your jobs can "flex" at will then it becomes impossible to say how many cores you're actually using. Like, what do you do, integrate the area under the curve of second-by-second CPU usage or something? That would be very complicated. If they say, OK, your workload can use up to 100 cores then you pay for 100 cores, it's very simple. All you have to agree on with them is how many cores the maximum amount is. I can't imagine it would matter if the physical underlying hardware changes as long as the workload can only run on one machine at once. Otherwise it'd be impossible to run any Oracle product in any cloud at all, but people do it!
But the price list is here, it seems:
https://www.oracle.com/us/corporate/pricing/price-lists/java...
So price can vary between $25/processor/month and $12.50/month with further discounts available if you negotiate, probably. But ... this has to be rounded up to whatever the physical processor has, then multiplied by some "core factor" which can actually reduce the number of cores you need to buy from the physical number. Which can be found here:
https://www.oracle.com/us/corporate/contracts/processor-core...
For Intel and AMD chips, the factor is 0.5 - so the actual prices are just half of those numbers!
The rules about virtualization are kinda weird especially because Oracle Cloud presumably is virtualized itself. Presumably it's because if your jobs can "flex" at will then it becomes impossible to say how many cores you're actually using. Like, what do you do, integrate the area under the curve of second-by-second CPU usage or something? That would be very complicated. If they say, OK, your workload can use up to 100 cores then you pay for 100 cores, it's very simple. All you have to agree on with them is how many cores the maximum amount is. I can't imagine it would matter if the physical underlying hardware changes as long as the workload can only run on one machine at once. Otherwise it'd be impossible to run any Oracle product in any cloud at all, but people do it!
Above is old info. It’s no longer billed that way.
See https://www.oracle.com/assets/cloud-licensing-070579.pdf
—-
> “ Amazon EC2 and RDS - count two vCPUs as equivalent to one Oracle Processor license if hyper-threading is enabled, and one vCPU as equivalent to one Oracle Processor license if hyper-threading is not enabled. Microsoft Azure – count two vCPUs as equivalent to one Oracle Processor license if hyper- threading is enabled, and one vCPU as equivalent to one Oracle Processor license if hyper- threading is not enabled. When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable.”
The key is that last sentence.
See https://www.oracle.com/assets/cloud-licensing-070579.pdf
—-
> “ Amazon EC2 and RDS - count two vCPUs as equivalent to one Oracle Processor license if hyper-threading is enabled, and one vCPU as equivalent to one Oracle Processor license if hyper-threading is not enabled. Microsoft Azure – count two vCPUs as equivalent to one Oracle Processor license if hyper- threading is enabled, and one vCPU as equivalent to one Oracle Processor license if hyper- threading is not enabled. When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable.”
The key is that last sentence.
It doesn't matter - Oracle is a company that will send lawyers and salesmen your way to threaten and try to squeeze the money out of you.
We've had the case where they threathened to double per-core licensing cost of their products just because our developers wanted to use PostgreSQL in their new project. Once they get into your system they'll bleed your time and money with their licensing bullshit. You have better things to do with your company time.
We've had the case where they threathened to double per-core licensing cost of their products just because our developers wanted to use PostgreSQL in their new project. Once they get into your system they'll bleed your time and money with their licensing bullshit. You have better things to do with your company time.
The key is "Authorized Cloud Environments", which is defined in the first paragraph:
> This policy applies to cloud computing environments from the following vendors: Amazon Web Services –Amazon Elastic Compute Cloud (EC2), Amazon Relational Database Service (RDS) and Microsoft Azure Platform (collectively, the ‘Authorized Cloud Environments’).This policy applies to these Oracle programs.
So, only for AWS and Azure.
> This policy applies to cloud computing environments from the following vendors: Amazon Web Services –Amazon Elastic Compute Cloud (EC2), Amazon Relational Database Service (RDS) and Microsoft Azure Platform (collectively, the ‘Authorized Cloud Environments’).This policy applies to these Oracle programs.
So, only for AWS and Azure.
The document is about cloud licensing. You're replying to a comment about vmotion which most likely means on-premise setup.
Speaking from experience listening to corporate sales deals, those listed prices are just like at the street bazaar.
You only get them when lacking negotiation skills, or failing to understand the whole political process from enterprise sales.
You only get them when lacking negotiation skills, or failing to understand the whole political process from enterprise sales.
I wouldn't be surprised if FB only started paying 2+ years after starting the contract.
As a lighthouse client, FB is pretty amazing in this space.
As a lighthouse client, FB is pretty amazing in this space.
Yeah something like that would be quite possible.
I replace Rich with Raging - but both work.
If your "enterprise" software doesn't generate $18/month, then you probably don't have a viable business model and should use the community edition. I don't take the Oracle hate seriously when it's all the latest fashion to pay much, much more for your CPU because it's hosted by Amazon. The alternative of "free" services in the Google-sense (ie data-mining users to sell to third parties or develop other products) seems worse, personally.
Did you even read the parent comment? It's not $18/mo; it's $18/mo/theoretically-schedulable-substrate-CPU. For people considering running this on an IaaS, that'd literally be "$18 * [number of CPUs in the entire datacenter emcompassing your AWS/GCP/Azure zone] per month". That's a higher OpEx than pretty much any single service is worth.
Yes, and that's trivial for useful business cases. Let's look at a service beyond reproach:
https://aws.amazon.com/ec2/dedicated-hosts/pricing/
Wow! An M5 costs $2300 a month, which is almost three times as much as Graal licensing would cost, assuming you paid for all 48 cores ($864). Frankly, if a minimum wage job is a larger revenue stream than your "app", then you should probably do the minimum wage job instead. There's also a community edition. It's free. I think the moral outrage about anything Oracle-related is a hollow fashion statement, like a Che Guevara t-shirt.
https://aws.amazon.com/ec2/dedicated-hosts/pricing/
Wow! An M5 costs $2300 a month, which is almost three times as much as Graal licensing would cost, assuming you paid for all 48 cores ($864). Frankly, if a minimum wage job is a larger revenue stream than your "app", then you should probably do the minimum wage job instead. There's also a community edition. It's free. I think the moral outrage about anything Oracle-related is a hollow fashion statement, like a Che Guevara t-shirt.
> assuming you paid for all 48 cores ($864)
...no, you're still reading it wrong. It's not the number of substrate CPUs on the compute node your workload is running on. It's the number of substrate CPUs on all the compute nodes your workload could potentially ever be re-scheduled or migrated onto. I.e., all the CPUs of every single (non-reserved) compute node in the datacenter. (Or, presuming certain service-transitioning technologies, multiple datacenters!) We're talking about e.g. "the entirety of AWS EC2 us-west-2." Hundreds of thousands of machines. Millions of CPUs.
By analogy: imagine there's a car-sharing service, that rents out its fleet of cars to people — but because, when you rent a car, you could theoretically end up driving any car in the rental company's fleet — they set their premium to be $18/mo * [the size of the rental company's entire rental-car fleet.] Because in theory, if you set things up just right, you could manage to drive all their cars, in one day. And so they want to charge you, at all times, for that basically-impossible worst-case upper-bound price.
Do you see how insane that sounds?
...no, you're still reading it wrong. It's not the number of substrate CPUs on the compute node your workload is running on. It's the number of substrate CPUs on all the compute nodes your workload could potentially ever be re-scheduled or migrated onto. I.e., all the CPUs of every single (non-reserved) compute node in the datacenter. (Or, presuming certain service-transitioning technologies, multiple datacenters!) We're talking about e.g. "the entirety of AWS EC2 us-west-2." Hundreds of thousands of machines. Millions of CPUs.
By analogy: imagine there's a car-sharing service, that rents out its fleet of cars to people — but because, when you rent a car, you could theoretically end up driving any car in the rental company's fleet — they set their premium to be $18/mo * [the size of the rental company's entire rental-car fleet.] Because in theory, if you set things up just right, you could manage to drive all their cars, in one day. And so they want to charge you, at all times, for that basically-impossible worst-case upper-bound price.
Do you see how insane that sounds?
That sounds insane because you made it up. You don’t get a bill for every core that Amazon owns because you hosted an enterprise edition of GraalVM on one. Even if that were the case, use the CE or collocate or self host.
You don't, because there is a special case for AWS and Azure, this is mentioned earlier in this thread.
If you set up your own virtualisation environment, then you're subject to those rules. However, you can work around it by separating out the machines that runs Oracle into its own groups of physical machines.
It does mean that deployment of Oracle software is much more complicated, since you can't use the regular environment. You also need it to be as separate as possible unless you want to have a long discussion with Oracle's lawyers about how to interpret those clauses.
If you set up your own virtualisation environment, then you're subject to those rules. However, you can work around it by separating out the machines that runs Oracle into its own groups of physical machines.
It does mean that deployment of Oracle software is much more complicated, since you can't use the regular environment. You also need it to be as separate as possible unless you want to have a long discussion with Oracle's lawyers about how to interpret those clauses.
> Even if that were the case, use the CE or collocate or self host.
Or, as the op suggested, their pricing is just straight up insane
Or, as the op suggested, their pricing is just straight up insane
That’s basically libel at this point. How about actually adding some facts to your bullshit here and there?
I’m just going off what the GGGP commentor (who is not me, please note) stated as the facts of the situation.
If you want to rebut those facts, go ahead, but don’t axiomatically accept the facts (by not arguing with the GGGP commentor directly, now that you understand the point that they were making) and then try to deny their implications.
If you want to rebut those facts, go ahead, but don’t axiomatically accept the facts (by not arguing with the GGGP commentor directly, now that you understand the point that they were making) and then try to deny their implications.
Or maybe they are just historically a terrible company to work with who makes mostly shitty software and everyone knows it.
There's no moral outrage over here either, just "I dont want to do business with assholes who keep fucking everyone over."
There's no moral outrage over here either, just "I dont want to do business with assholes who keep fucking everyone over."
> “Processor: shall be defined as all processors where the Oracle programs are installed and/or running. Programs licensed on a processor basis may be accessed by your internal users (including agents and contractors) and by your third party users. The number of required licenses shall be determined by multiplying the total number of cores of the processor by a core processor licensing factor specified on the Oracle Processor Core Factor Table which can be accessed at http://oracle.com/contracts. All cores on all multicore chips for each licensed program are to be aggregated before multiplying by the appropriate core processor licensing factor and all fractions of a number are to be rounded up to the next whole number.”
--
x86 has a 0.5 core multiplier. So if you have a 16-core server, you need to purchase “8 processors”.
And before people start spewing Oracle hate, this is standard enterprise on-premise licensing practices used by Microsoft, IBM, SAP etc.
https://www.oracle.com/ae/a/ocom/docs/graalvm-price-list.pdf
https://www.oracle.com/us/corporate/contracts/processor-core...
--
x86 has a 0.5 core multiplier. So if you have a 16-core server, you need to purchase “8 processors”.
And before people start spewing Oracle hate, this is standard enterprise on-premise licensing practices used by Microsoft, IBM, SAP etc.
https://www.oracle.com/ae/a/ocom/docs/graalvm-price-list.pdf
https://www.oracle.com/us/corporate/contracts/processor-core...
> And before people start spewing Oracle hate, this is standard enterprise on-premise licensing practices used by Microsoft, IBM, SAP etc.
I don't see why we can't be annoyed at all the large enterprises with their "negotiate your own per-core price and commitment" sales.
I don't see why we can't be annoyed at all the large enterprises with their "negotiate your own per-core price and commitment" sales.
OpenJDK > 11 has GraalVM inside, you can activate it with a switch.
https://openjdk.java.net/projects/graal/
https://openjdk.java.net/projects/graal/
This is partially incorrect. JEP 410 [0] will be removing them from HotSpot in the next release (17). Project Metropolis has also been put on hold, so for the foreseeable future if you want Graal features, you'll have to use GraalVM [1]
[0] https://openjdk.java.net/jeps/410 [1] https://mail.openjdk.java.net/pipermail/metropolis-dev/2021-...
[0] https://openjdk.java.net/jeps/410 [1] https://mail.openjdk.java.net/pipermail/metropolis-dev/2021-...
That is incorrect. JVMCI is still in OpenJDK and is the only thing required to run Graal. You need to put Graal as jar from Maven on the upgrade-module-path since JEP 410 since it's no longer there by default but this is the only thing that changed.
So you can continue to use Graal as your last tier compiler or to compile Truffle languages on OpenJDK.
So you can continue to use Graal as your last tier compiler or to compile Truffle languages on OpenJDK.
I see! I must have misinterpreted the mailing list.
> so for the foreseeable future if you want Graal features, you'll have to use GraalVM
This isn't true - you can use Graal from a JAR just fine.
This isn't true - you can use Graal from a JAR just fine.
There is no chance Facebook is paying anywhere close to the published price.
How does this work with dynamic cloud workloads. If I can effectively tack this on to my AWS cost with the same granularity then I could use it only where I come out ahead. But if the whole monthly core licensing thing means that I effectively have to make an all or nothing decision on my entire cloud fleet on a month by month basis that’s far less likely to be worth it.
$216/year pr CPU not pr core? That's... Incredibly cheap? Less than $2/core/year on the right CPUs?
Ed: ah, no. See sibling comment
Ed: ah, no. See sibling comment
Per socket or per core? Whats the business case where this makes sense, it seems a pretty steep price?
Since there’s a free version either the extra performance of the paid version pays for itself or it doesn’t.
Probably cases where hw is expensive or where your workload doesn't scale horizontally all that well, or where latency is a big deal (better perf = lower latency = less hw needed).
In true Oracle style, they will bleed you dry.
I guess they made a deal for a discount on GraalVM if they promote it?
The article is written by GraalVM Developer Advocate , it's not even written by Facebook technically.
I remember a contrat with Kong API Gateway , they offered generous deal if we agreed to sign an agreement to attend their conference to promote their product.
Very common in the industry to have those terms "legally binded".
I remember a contrat with Kong API Gateway , they offered generous deal if we agreed to sign an agreement to attend their conference to promote their product.
Very common in the industry to have those terms "legally binded".
Here's a video of a session by Chen Li (mentioned in the post as a collaborator) from the Graal workshop with more details and some background: https://www.youtube.com/watch?v=Hepjf00LJrM
Is anybody here using Graal Native Images in production? I'm interested in it, but it seems like it's too "alpha" to be used for anything real yet.
I've used native-image both directly and indirectly. Directly to implement a Clojure-language authentication server which needed a small memory footprint. Indirectly through @borkdude's https://github.com/babashka/babashka which provides a native-image binary that can run much of the Clojure language.
We open-sourced some babashka code at https://github.com/staticweb-io/staticweb-open-wp/tree/maste... One major caveat: when I wrote that code, babashka didn't have any MySQL support, so I shelled out to the MySQL CLI. Later, I figured out how to compile the MySQL JDBC drivers with native-image and it's now available at https://github.com/babashka/babashka-sql-pods along with HSQLDB, SQL Server, Oracle, and Postgres drivers.
We open-sourced some babashka code at https://github.com/staticweb-io/staticweb-open-wp/tree/maste... One major caveat: when I wrote that code, babashka didn't have any MySQL support, so I shelled out to the MySQL CLI. Later, I figured out how to compile the MySQL JDBC drivers with native-image and it's now available at https://github.com/babashka/babashka-sql-pods along with HSQLDB, SQL Server, Oracle, and Postgres drivers.
[deleted]
Twitter was already using it in 2019.
https://jeeconf.com/program/performance-tuning-twitter-servi...
https://jeeconf.com/program/performance-tuning-twitter-servi...
The parent poster is specifically asking about native images, which Twitter doesn't use.
In that case, from Red-Hat,
https://www.redhat.com/en/topics/cloud-native-apps/what-is-q...
https://quarkus.io/guides/building-native-image
https://www.redhat.com/en/topics/cloud-native-apps/what-is-q...
https://quarkus.io/guides/building-native-image
Or use Spring Native (in beta)
https://docs.spring.io/spring-native/docs/current/reference/...
https://docs.spring.io/spring-native/docs/current/reference/...
> “ Apache Spark benchmarks show an average speedup 1.1x for [GraalVM] Community and of 1.42x for [GraalVM] Enterprise, with some benchmarks running up to 4.84x faster”
I wonder if FB bought the Oracle enterprise license or is using the community edition version.
I wonder if FB bought the Oracle enterprise license or is using the community edition version.
What are the differences between versions that contribute most to the performance difference ?
Oracle advertises the enterprise edition has having a more advanced compiler that does more and better optimizations.
I'm a little surprised by the contortions companies go into to make languages faster.
What happened to writing C/C++ in the first place if speed matters? Would you write Stockfish in Java or Python and hope for a sophisticated, bug free VM?
What happened to writing C/C++ in the first place if speed matters? Would you write Stockfish in Java or Python and hope for a sophisticated, bug free VM?
Java is actually incredibly well written for large scale multicore systems.
Java's garbage collector, although the source of many performance headaches, is in fact very sophisticated and "does the right thing" for most OOP-style code. Yes, it takes some understanding and tuning (and yes, there are multiple garbage collectors you're supposed to test out as you tune your software...) but that's the sort of thing that's available.
In C/C++ world: you can't just swap out versions of "malloc" or "new" as easily (ie: without recompiling everything, to tune / test your code on different systems). Restarting your JVM with slightly different garbage collector settings over-and-over again is absolutely a thing in the Java world to help tune your applications to the machines they run on.
---------
Java's high performance concurrency libraries are very well written as well. And there are some real speed demons (Azul) out there.
Its really a different world and model than the C/C++ world.
Java's garbage collector, although the source of many performance headaches, is in fact very sophisticated and "does the right thing" for most OOP-style code. Yes, it takes some understanding and tuning (and yes, there are multiple garbage collectors you're supposed to test out as you tune your software...) but that's the sort of thing that's available.
In C/C++ world: you can't just swap out versions of "malloc" or "new" as easily (ie: without recompiling everything, to tune / test your code on different systems). Restarting your JVM with slightly different garbage collector settings over-and-over again is absolutely a thing in the Java world to help tune your applications to the machines they run on.
---------
Java's high performance concurrency libraries are very well written as well. And there are some real speed demons (Azul) out there.
Its really a different world and model than the C/C++ world.
There are actually plenty of runtime tuning parameters for malloc and friends (using environment variables), and you can swap out allocators using LD_PRELOAD without recompiling anything.
You can do the same in C - for example:
LD_PRELOAD=libjemalloc.so MALLOC_CONF=narenas:1 /your/unmodified/appBecause it's difficult to write large amounts of reliable code with c++.
Yes, it's easier with modern c++, but it's still significantly harder than with, say, rust or ada (or java for that matter, which is not slow, contrary to popular belief).
Furthermore, in the Facebook case, it's about cost : you save money by being faster, but you don't want to lose money because you're tracking overflow bugs in c++. If you can have both execution speed and development/maintenance speed , it's much better.
Yes, it's easier with modern c++, but it's still significantly harder than with, say, rust or ada (or java for that matter, which is not slow, contrary to popular belief).
Furthermore, in the Facebook case, it's about cost : you save money by being faster, but you don't want to lose money because you're tracking overflow bugs in c++. If you can have both execution speed and development/maintenance speed , it's much better.
And to be fair, it's not like FB use Java for (much) performance critical code (AFAIK, obviously).
I'd be willing to bet that lots of the core ranking/ads stuff at most of the major tech companies is written in C++.
I'd be willing to bet that lots of the core ranking/ads stuff at most of the major tech companies is written in C++.
Just checked and Spark has over a million lines of Scala code, as well as 100k+ loc of Java and Python. Which would you prefer, rewriting a million lines of Scala, or having a small team work on improving compiler/runtime efficiency?
Spark is also heavily dependent on a bajillion other OSS libraries, many of which don't directly translate to C++ libs -- Apache, Guava, etc. It's probably at least 10x this line count if you include all the utilities they pull in.
Let alone lines of code would be even more when it's written in C++.
A lot more. Scala, the Akka ecosystem, and the Hadoop ecosystem is uniquely suited to Spark's problem domain.
And Scala is, for both better and worse, an extremely compact language too. I would expect about 5x more lines of code just from that.
And Scala is, for both better and worse, an extremely compact language too. I would expect about 5x more lines of code just from that.
One interesting thing here is that there are people who know some real numbers, and not just hypotheticals, but they probably can't talk about it publicly. Google has their own distributed compute engine, written in C++. Everyone I know who's worked with it says it's much nicer than Spark, and much more performant.
I wouldn't necessarily just assume that it's 5x more code. I've spent a fair bit of time digging around in the Spark code, and it's not clear to me that it's as efficiently designed or cleanly implemented as one might like. And, while I can't speak to the influence of Google's style guide, I don't personally feel like modern C++ is 5x as verbose as modern Scala. A bit more, maybe? But it's not like Scala (2, at least) doesn't have its own bizarre sources of unnecessary verbosity. It mostly looks great by comparison to Java.
I wouldn't necessarily just assume that it's 5x more code. I've spent a fair bit of time digging around in the Spark code, and it's not clear to me that it's as efficiently designed or cleanly implemented as one might like. And, while I can't speak to the influence of Google's style guide, I don't personally feel like modern C++ is 5x as verbose as modern Scala. A bit more, maybe? But it's not like Scala (2, at least) doesn't have its own bizarre sources of unnecessary verbosity. It mostly looks great by comparison to Java.
Java can actually compete with C/C++ if written in a specific, limited way. Some high-frequency trading shops use Java, and their entire business is speed.
The problem is, Java written in that specific limited way is way less expressive, less safe and less productive than modern C++, not even mentioning Rust.
Since it fails to achieve 70% of the memory corruption issues that modern C++ is capable of, definitely less safe.
As much as we would like the modern C++ from books and conference talks to exist in real life, that is not how the large majority of the world actually writes C++.
Heck, just check the AOSP source code to see how much modern C++ it has, from one of the companies that contributes to ISO C++.
Or if that fails to impress, see how much modern C++ exists in Microsoft Github sample projects.
As much as we would like the modern C++ from books and conference talks to exist in real life, that is not how the large majority of the world actually writes C++.
Heck, just check the AOSP source code to see how much modern C++ it has, from one of the companies that contributes to ISO C++.
Or if that fails to impress, see how much modern C++ exists in Microsoft Github sample projects.
Memory corruption / safety issues related to memory are not only typical C problems like use after free but also type errors. Optimizing Java for performance means using only primitive types which is significantly less type-safe than C++ classes / structs.
C++ isn't Coq, so don't get what type safety you are selling.
Naturally it is possible to write static classes that hide the internals of a data structure, and ensure they are properly used.
And if that isn't enough, Valhalla is eventually here, Java 17 already includes the preview for new native memory primitives, and polyglot developers can always write a bunch of native methods, no need to throw safety and productivity away for 100% of the code.
Naturally it is possible to write static classes that hide the internals of a data structure, and ensure they are properly used.
And if that isn't enough, Valhalla is eventually here, Java 17 already includes the preview for new native memory primitives, and polyglot developers can always write a bunch of native methods, no need to throw safety and productivity away for 100% of the code.
C++ is not Coq, but it is still a lot closer to Coq than C-like Java written for performance.
> Naturally it is possible to write static classes that hide the internals of a data structure
Which limits you to reusing a single instance which is not only very limited in what you can do with, but also inherently error-prone compared to passing structs.
Valhalla does not exist yet, had been in development for a decade, and even once they release it, it won't be equivalent to C++ structs - it is by design much more limited.
Finally, productivity of Java is overrated, I've been writing in many languages and I'm not more productive in Java than in C++. Productivity is mostly a trait of a developer and libraries, not a language.
> Naturally it is possible to write static classes that hide the internals of a data structure
Which limits you to reusing a single instance which is not only very limited in what you can do with, but also inherently error-prone compared to passing structs.
Valhalla does not exist yet, had been in development for a decade, and even once they release it, it won't be equivalent to C++ structs - it is by design much more limited.
Finally, productivity of Java is overrated, I've been writing in many languages and I'm not more productive in Java than in C++. Productivity is mostly a trait of a developer and libraries, not a language.
No it doesn't limit it, because that single instance class can also do JNI and manual memory management without exposing it on the public interface.
I know C++ since 1993, have delivered C++ into production at CERN and Nokia Networks, and also taught it at the university to first year students.
So what do I know a bit about C++ productivity versus other languages.
Now if we start talking about GPGPU programming, HPC or writing device drivers then it is another matter, there is where C++ shines and will keep doing so for the foreseeable future.
CERN is definitely not going to rewrite HLT in Java, in fact for some units not even C++ was good enough, and the code is actually implemented in FPGAs.
I know C++ since 1993, have delivered C++ into production at CERN and Nokia Networks, and also taught it at the university to first year students.
So what do I know a bit about C++ productivity versus other languages.
Now if we start talking about GPGPU programming, HPC or writing device drivers then it is another matter, there is where C++ shines and will keep doing so for the foreseeable future.
CERN is definitely not going to rewrite HLT in Java, in fact for some units not even C++ was good enough, and the code is actually implemented in FPGAs.
Because they want a higher level of abstraction for 'all the other benefits' - and then just to get it work a little faster.
When we think C++ performance, we're thinking of something like a video or audio compression i.e. discrete functionality. Note a massive, enterprise level solution with myriads of kinds of business functions.
It would never get complete in C++ as that language has complexity issues which overwhelm everything else at some scale, more often than not.
When we think C++ performance, we're thinking of something like a video or audio compression i.e. discrete functionality. Note a massive, enterprise level solution with myriads of kinds of business functions.
It would never get complete in C++ as that language has complexity issues which overwhelm everything else at some scale, more often than not.
Even then, many devs focus too much on the performance tree and miss the forest of polyglot programming.
If there are performance issues with a Java application, where after all attempts, there is still some room left, there is no need to throw everything way.
Those areas can be ported to C, C++, Rust, whatever, and then called via native methods.
If there are performance issues with a Java application, where after all attempts, there is still some room left, there is no need to throw everything way.
Those areas can be ported to C, C++, Rust, whatever, and then called via native methods.
Java designed for performance, when the VM settles down after n iterations pushes 'on par' with C++.
There's also no reason to believe that C or C++ will be faster, because you have to 1) know how to write performant C++ code (not obvious) and 2) content with the Java-JNI-C barrier which is non-negligible.
I don't see too many scenarios where taking a module and porting to C++ is really ever a thing frankly.
Usually, it'd be for integrating already existing systems - or - for integrating things which might naturally be written in C/C++ in the first place.
For something like Graal, it's one of those broad improvements wherein everyone gains, hopefully magically without having to do anything like a big improvement in V8 that just 'happens'.
There's also no reason to believe that C or C++ will be faster, because you have to 1) know how to write performant C++ code (not obvious) and 2) content with the Java-JNI-C barrier which is non-negligible.
I don't see too many scenarios where taking a module and porting to C++ is really ever a thing frankly.
Usually, it'd be for integrating already existing systems - or - for integrating things which might naturally be written in C/C++ in the first place.
For something like Graal, it's one of those broad improvements wherein everyone gains, hopefully magically without having to do anything like a big improvement in V8 that just 'happens'.
Since 2006 I already replaced a couple of C++ platforms with either Java or .NET, then there is Android as well, or embedded platforms like microEJ.
On managed languages FFI should never be done 1:1, as you very well point out it isn't negligible.
Rather they should be thought as in-process RPC, that actually do a bunch of work per call.
It is still faster than doing IPC across processes.
On managed languages FFI should never be done 1:1, as you very well point out it isn't negligible.
Rather they should be thought as in-process RPC, that actually do a bunch of work per call.
It is still faster than doing IPC across processes.
Question is, would you prefer to re-write Spark in C or use GraalVM to get a boost in speed? It's not feasible to re-write everything from scratch.
Rust rewrites are already in progress.
When you make a better compiler/runtime, that work on one program benefits many programs. So it is often more cost-effective to improve the compiler/runtime than to improve all the user programs. Developing higher-level languages creates a similar situation: many programmers can be more productive.
70% of memory corruption issues causing huge increase in development costs happened.
Right now their only use for green field projects is on ecosystems where there are no alternatives.
Right now their only use for green field projects is on ecosystems where there are no alternatives.
Java's used in HFT, so that's enough
Yeah, why won't you use one if the most complicated, error prone and complex languages instead of Java.
Just curious, is there any kind of standardized JMX and remote debug in C/C++ world (on Linux)?
That was the question I was asking too. Guess CS grads now a days know Java best. and therefore they have to have java. optimization comes next. Leading to all these tech challenges.
[deleted]
The more a Oracle product is attractive at a given time, the more my competitors will use it, which is very good for my company in the long term. Because it's just a matter of time before my competitors who fell into the trap will receive an insane invoice and a letter from the Oracle lawyers.
When will this FUD stop? Any concrete example of said thing happneing? And don’t get me started on the Google fiasco, as that’s entirely different and everyone knows about it who doesn’t live under a rock.
My first internship was in an research organization mostly about nuclear energy. They were migrating everything they could to PostgreSQL after they received one of these insane invoices. I haven't seen the invoice myself and the organization is not the kind that publish about it on a blog though.
I don't like Graal. Java used to be free without any performance restrictions, you can pay for support and that's about it. There were niche JVMs like Azul. Hopefully Graal will not overshadow OpenJDK, but the fact that both implementations are from one company makes that worrisome.
I think there is good reason to get worried. My understanding is that third party proposed changes and PRs on the open source version have been denied because they would lessen the benefits of Enterprise. In addition, the lack of certification prevents commercial 3rd party JDK vendors from attempting to support it.
Unfortunate, because I'd love to build some prototypes based on graal features, but Oracle's apparent disinterest in supporting community contributions, and the questions around licensing of parts of the graal ecosystem leaves me worried enough to avoid it for now.
Unfortunate, because I'd love to build some prototypes based on graal features, but Oracle's apparent disinterest in supporting community contributions, and the questions around licensing of parts of the graal ecosystem leaves me worried enough to avoid it for now.
Doesn't Graal require that none of Java's reflection stuff be used? e.g. Class.forName, Class.getFields, runtime DI frameworks, and so on. This would seem to majorly limit the cases where it might be used.
You're (understandably) conflating GraalVM, a JVM using Graal to jit, with Graal Native which compiles java to native code ahead of time. The latter needs some help with runtime features that obscure which code is run.
This is about the former.
This is about the former.
Ah right you are, and I've only experimented with Graal to build native images.
no it does not. if you use native-image, thats on another level tough.
One is still very much in the R&D phase, so they are hardly competitors.
Also, GraalVM needs OpenJDK (except for native, but that’s not the most interesting part), so I don’t see a problem arising from that.
The "Spark CPU usage with GraalVM" chart is ... not zero-based. Using that kind of chart to show 10% reduction isn't an honest way to show the improvement.
Use a zero-based chart, and show a longer time period. Then the gap is clear, even though not as dramatic.
Also, the article probably shouldn't talk about the general benchmark, and probably better to omit the performance of the Enterprise edition, because Facebook is probably not using it. (It's not clear from the article which version of GraalVM FB uses, but I don't think they pay for it.)
We all know 10% CPU reduction is superb, especially on the Facebook scale. And we also know GraalVM is great technology. So please don't try to fool the readers.
By the way, it also mentions that they moved Presto to GraalVM and saw an improvement. It can be as significant, and would be nice to show the number if there is a latency improvement because Presto is interactive tool and the improvement can end up productivity gain, in addition to saving the CPU cycles.
Use a zero-based chart, and show a longer time period. Then the gap is clear, even though not as dramatic.
Also, the article probably shouldn't talk about the general benchmark, and probably better to omit the performance of the Enterprise edition, because Facebook is probably not using it. (It's not clear from the article which version of GraalVM FB uses, but I don't think they pay for it.)
We all know 10% CPU reduction is superb, especially on the Facebook scale. And we also know GraalVM is great technology. So please don't try to fool the readers.
By the way, it also mentions that they moved Presto to GraalVM and saw an improvement. It can be as significant, and would be nice to show the number if there is a latency improvement because Presto is interactive tool and the improvement can end up productivity gain, in addition to saving the CPU cycles.
> Use a zero-based chart
Agreed, but that visualization is even worse because it lacks a y-axis scale entirely.
Agreed, but that visualization is even worse because it lacks a y-axis scale entirely.
One of the things I learned as a megacorp data scientist is that you should always remove the scales on the y-axis in anything vaguely public, because of the risk of material information leak.
(Think about user growth as a particularly good example of a variable like this).
(Think about user growth as a particularly good example of a variable like this).
If absolute values are a concern then why not replace the unit with % change? One could, assuming linear scale, reverse engineer that onto this plot anyway. Some plots, of course, might stand better on their own without a y-axis scale (histogram distribution probably).
To be honest, this plot is pretty useless either way; who cares about the trend it took downward since we have little or no context on what happened at any given point?
To be honest, this plot is pretty useless either way; who cares about the trend it took downward since we have little or no context on what happened at any given point?
> better to omit the performance of the Enterprise edition, because Facebook is probably not using it
unless the point of this post is to attempt to sell the Enterprise edition to FB
unless the point of this post is to attempt to sell the Enterprise edition to FB
Looks like it is a sales pitch for Enterprise Edition
Well it's on the GraalVM blog and GraalVM has two editions. Facebook probably don't care how many copies of EE Oracle sell, but it seems pretty reasonable for Oracle to use the adoption of GraalVM tech by large corporations to cross-sell EE especially because the justification for adopting it is performance, and EE yields much better performance gains again.
It's honestly pretty amazing that graal enterprise can offer 42% performance over HotSpot/C2. You would think Oracle would want to upstream those improvements to HotSpot to keep it as fast as possible.
The Graal team is huge. Like, I don't know, at least 70 people and probably more. So that's very expensive.
Oracle Java is best understood as two competing teams at this point. In theory GraalVM started out as a research project to feed improvements back to HotSpot and some of that they've done, like with the JVMCI interface that was added. But it didn't work out that way for whatever reason and GraalVM is now effectively a competitor to the 'classical' Sun Java product guys. They have different brand names, commercial models, feature priorities, price points, they are different organisations within the company. Fortunately GraalVM is not a fork of OpenJDK - it's a bunch of plugins and extra components, more or less. But at some level the difference is semantic because if you swap out the whole JIT compiler then maybe it actually is a fork? Not sure.
Anyway the original research vision was that C2 would be replaced by Graal indeed. The politics of merging such a total rewrite would be difficult at the best of times and it seems Oracle hasn't managed it, or perhaps they like having some internal competition for the OpenJDK guys. Certainly Graal team cares a lot more about modern marketing, about getting their tech adopted into other Oracle products and things that presumably Oracle management care about. Like the graalvm.org website vs the OpenJDK website is no competition. The former feels like an actual product, the latter is a bunch of wiki pages more or less.
Oracle Java is best understood as two competing teams at this point. In theory GraalVM started out as a research project to feed improvements back to HotSpot and some of that they've done, like with the JVMCI interface that was added. But it didn't work out that way for whatever reason and GraalVM is now effectively a competitor to the 'classical' Sun Java product guys. They have different brand names, commercial models, feature priorities, price points, they are different organisations within the company. Fortunately GraalVM is not a fork of OpenJDK - it's a bunch of plugins and extra components, more or less. But at some level the difference is semantic because if you swap out the whole JIT compiler then maybe it actually is a fork? Not sure.
Anyway the original research vision was that C2 would be replaced by Graal indeed. The politics of merging such a total rewrite would be difficult at the best of times and it seems Oracle hasn't managed it, or perhaps they like having some internal competition for the OpenJDK guys. Certainly Graal team cares a lot more about modern marketing, about getting their tech adopted into other Oracle products and things that presumably Oracle management care about. Like the graalvm.org website vs the OpenJDK website is no competition. The former feels like an actual product, the latter is a bunch of wiki pages more or less.
For one specific use case. Given that we're talking unpsecified Apache Spark workloads, it's a little hard to know exactly what's going on. I think that the author is correct, though, to point out that there's reason to believe that Spark workloads might see a larger benefit than other kinds of Java applications.
This is the product they are selling. Unfortunately, this approach is what's keeping me away from Graal in general as well.
> You would think Oracle would want to upstream ...
Why would I think this and not that Oracle would want to make money off their unique IP?
Why would I think this and not that Oracle would want to make money off their unique IP?
Conversely, the first chart understates the effect.
0% improvement (1.0) is 5/8th of the length of the Y axis, making a 42% improvement look barely interesting. Probably should have opted for a different chart here.
0% improvement (1.0) is 5/8th of the length of the Y axis, making a 42% improvement look barely interesting. Probably should have opted for a different chart here.
You don’t need zeros on y axis for line charts.
The information you are trying to convey is the variability of the change over time.
The information you are trying to convey is the variability of the change over time.
right, but what variability? how much? what time period? without labels and numbers, the graph is pretty meaningless in that department. All I know is that something changed, which is not enough information to be at all useful.
fvckzvck(2)
Disclaimer: You guessed it, I work at Oracle.