[HN Gopher] GraalVM at Facebook
___________________________________________________________________
GraalVM at Facebook
Author : pjmlp
Score : 170 points
Date : 2021-07-09 11:10 UTC (11 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| fvckzvck wrote:
| It is shocking to me that anyone who has a conscience still works
| at facebook. Just a bunch of don't give af mercenaries or what?
| worker767424 wrote:
| The article wasn't really about working at Facebook. Except for
| mentioning things no one else uses like Hack, this article
| could be about any large company using GraalVM.
| void_mint wrote:
| Making enough money such that your entire family is secure for
| the rest of their lives is a big thing for lots of people.
|
| _edit_ Hilarious downvotes.
| shelajev wrote:
| 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
| jwsta wrote:
| 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?
| __jem wrote:
| 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?
| nobody0 wrote:
| Let alone lines of code would be even more when it's written
| in C++.
| tormeh wrote:
| 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.
| mumblemumble wrote:
| 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.
| bpodgursky wrote:
| 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.
| jollybean wrote:
| 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.
| pjmlp wrote:
| 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.
| jollybean wrote:
| 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'.
| pjmlp wrote:
| 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.
| EvilEy3 wrote:
| Yeah, why won't you use one if the most complicated, error
| prone and complex languages instead of Java.
| [deleted]
| Agingcoder wrote:
| Because 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.
| disgruntledphd2 wrote:
| 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++.
| lifty wrote:
| 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.
| justinholmes wrote:
| Rust rewrites are already in progress.
| tester756 wrote:
| Java's used in HFT, so that's enough
| habibur wrote:
| 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.
| nobody0 wrote:
| Writing safe C++ is harder than plain simple Java.
| rustissoviet wrote:
| You seems to be a Javascript/Rust guy looking at your post
| history. It seems that you have learnt C with classes
| instead Modern C++ because you commented that C++ program
| has more lines.
|
| Modern C++ is concise and much more like Javascript these
| days. There is this conference video that compare both.
|
| You have RAII in Modern C++ so no need to cry for seg
| faults.
|
| It lacks a NPM like package manager but rest is I swear
| amazing. C++20 Modules will solve this too.
|
| Safe is nobody's word except Rustic Propagandists. Writing
| safe "Modern" C++ is much easier than it was prior 2011.
|
| Modern C++ abstractions sometimes made me wonder why people
| still use Java.
|
| C++20's Concepts Lite will make Modern C++ even more safer.
|
| Rust is unsafe and you yet to see a software that written
| in Rust for the Airplane companies, railway etc ...
| pjmlp wrote:
| Modern C++ is great, but unfortunately most people keep
| ignoring it, including some major contributors to ISO
| C++.
|
| https://google.github.io/styleguide/cppguide.html
|
| By the way, do you know in C++20 how many ways there are
| to initialize a variable, without looking at ISO C++20
| standard reference?
| ign0ramus wrote:
| I wouldn't say they are ignoring it. Case in the point
| that guide, you linked, recommends targeting recommends
| using C++17 which I think qualifies as modern. Compiler
| support for some of the newer features of C++2x hasn't
| matured yet.[0] That recommendation to avoid them seems
| sensible.
|
| [0]
| https://en.cppreference.com/w/cpp/compiler_support#cpp20
| pjmlp wrote:
| Except ISO C++17 doesn't prevent random devs to call
| malloc()/free()/strcpy()/.... so modern is relative.
|
| After reading those guidelines, I suggest reading
| Google's own code on the context of Android.
| EvilEy3 wrote:
| Too fat.
| bidirectional wrote:
| 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.
| pkolaczk wrote:
| 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.
| pjmlp wrote:
| 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.
| pkolaczk wrote:
| 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.
| pjmlp wrote:
| 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.
| dragontamer wrote:
| 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.
| nightpool wrote:
| 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.
| viraptor wrote:
| You can do the same in C - for example:
| LD_PRELOAD=libjemalloc.so MALLOC_CONF=narenas:1
| /your/unmodified/app
| imhoguy wrote:
| Just curious, is there any kind of standardized JMX and remote
| debug in C/C++ world (on Linux)?
| kd0amg wrote:
| 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.
| pjmlp wrote:
| 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.
| habibur wrote:
| My first question was licensing cost. Here's the rate :
|
| $18 per processor per month to use GraalVM Enterprise.
| alberth wrote:
| > "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...
| viraptor wrote:
| > 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.
| e12e wrote:
| $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
| MrBuddyCasino wrote:
| Per socket or per core? Whats the business case where this
| makes sense, it seems a pretty steep price?
| chrisseaton wrote:
| Since there's a free version either the extra performance of
| the paid version pays for itself or it doesn't.
| native_samples wrote:
| 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).
| bradleyjg wrote:
| 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.
| lifty wrote:
| In true Oracle style, they will bleed you dry.
| anthk wrote:
| OpenJDK > 11 has GraalVM inside, you can activate it with a
| switch.
|
| https://openjdk.java.net/projects/graal/
| vips7L wrote:
| 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-...
| chrisseaton wrote:
| > 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.
| grashalm wrote:
| 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.
| vips7L wrote:
| I see! I must have misinterpreted the mailing list.
| luma wrote:
| 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"
| pjmlp wrote:
| 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.
| disgruntledphd2 wrote:
| 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.
| pjmlp wrote:
| Yeah something like that would be quite possible.
| alberth wrote:
| 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.
| izacus wrote:
| 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.
| viraptor wrote:
| The document is about cloud licensing. You're replying to a
| comment about vmotion which most likely means on-premise
| setup.
| grumblenum wrote:
| 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.
| derefr wrote:
| 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.
| grumblenum wrote:
| 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.
| hobs wrote:
| 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."
| derefr wrote:
| > 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?
| grumblenum wrote:
| 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.
| edoceo wrote:
| I replace Rich with Raging - but both work.
| native_samples wrote:
| 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!
| tomcam wrote:
| There is no chance Facebook is paying anywhere close to the
| published price.
| speedgoose wrote:
| 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.
| kaba0 wrote:
| 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.
| speedgoose wrote:
| 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.
| rapsey wrote:
| I guess they made a deal for a discount on GraalVM if they
| promote it?
| smalltalks wrote:
| 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".
| alberth wrote:
| > " 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.
| polskibus wrote:
| What are the differences between versions that contribute most
| to the performance difference ?
| papercrane wrote:
| Oracle advertises the enterprise edition has having a more
| advanced compiler that does more and better optimizations.
| njitbew wrote:
| I don't understand the negativity in this thread about Oracle and
| the pricing model. GraalVM is an amazing piece of technology that
| enables many new applications. Oracle has the courage to invest
| heavily in this research, provides a community edition for free,
| and asks a very reasonable fee for the enterprise version. 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.
| And if you use the enterprise version in a way that is not
| allowed, you risk facing the consequences; no surprises there.
|
| Disclaimer: You guessed it, I work at Oracle.
| carlosf wrote:
| > 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.
| tw04 wrote:
| 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.
| reilly3000 wrote:
| +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.
| vbezhenar wrote:
| 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.
| kaba0 wrote:
| 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.
| vips7L wrote:
| It is worrisome. For native-image they're restricting the G1GC
| behind the enterprise license even though G1 is the default in
| OpenJdk/HotSpot.
| kaba0 wrote:
| Just another view point - it is very much a research project
| at this phase from Oracle Lab. They do need some form of
| funding for that.
| perrylaj wrote:
| 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.
| sk5t wrote:
| 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.
| merb wrote:
| no it does not. if you use native-image, thats on another
| level tough.
| shellac wrote:
| 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.
| sk5t wrote:
| Ah right you are, and I've only experimented with Graal to
| build native images.
| Mizza wrote:
| 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.
| [deleted]
| pjmlp wrote:
| Twitter was already using it in 2019.
|
| https://jeeconf.com/program/performance-tuning-twitter-servi...
| hocuspocus wrote:
| The parent poster is specifically asking about native images,
| which Twitter doesn't use.
| pjmlp wrote:
| 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
| _old_dude_ wrote:
| Or use Spring Native (in beta)
|
| https://docs.spring.io/spring-
| native/docs/current/reference/...
| flakiness wrote:
| 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.
| vips7L wrote:
| 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.
| mumblemumble wrote:
| 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.
| native_samples wrote:
| 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.
| geodel wrote:
| > 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?
| mey wrote:
| This is the product they are selling. Unfortunately, this
| approach is what's keeping me away from Graal in general as
| well.
| dariusj18 wrote:
| > 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
| the_arun wrote:
| Looks like it is a sales pitch for Enterprise Edition
| native_samples wrote:
| 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.
| hinkley wrote:
| 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.
| nojito wrote:
| 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.
| toomanyducks wrote:
| 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.
| amarshall wrote:
| > Use a zero-based chart
|
| Agreed, but that visualization is even worse because it lacks a
| y-axis scale _entirely_.
| disgruntledphd2 wrote:
| 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).
| amarshall wrote:
| 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?
| darksaints wrote:
| 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.
| belter wrote:
| 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.
| native_samples wrote:
| 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.
| cxr wrote:
| > 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.
| kaba0 wrote:
| 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.
| setr wrote:
| The risk with google is they'll drop maintaining the
| project. The risk with Oracle is they'll break your legs,
| and ask to be reimbursed for damages to their bat.
| pjmlp wrote:
| At least they know how to make something out of it,
| instead of putting another tombstone on the graveyard.
| viraptor wrote:
| > 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...
| Twirrim wrote:
| The lawsuit came about from actions before Java was open
| source.
| pjmlp wrote:
| > 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/
| suyash wrote:
| Your loss, it's a pretty amazing technology and also totally
| available under friendly open source license.
| mumblemumble wrote:
| 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.
| josefx wrote:
| Which parts are "non-open-source" and "essential"?
| mumblemumble wrote:
| 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.
| chrisseaton wrote:
| https://openjdk.java.net/groups/conformance/JckAccess/
| fn1 wrote:
| The testing suite for the JDK, which allows you to tell
| if something is compatible to Oracle Java.
| blacktriangle wrote:
| 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.
| hocuspocus wrote:
| 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.
| antonvs wrote:
| 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.
| hocuspocus wrote:
| Nobody is talking about native images. The article is
| about big data workloads, specifically Spark.
| blacktriangle wrote:
| 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.
| native_samples wrote:
| 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.
| hocuspocus wrote:
| 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.
| geodel wrote:
| Thats fine. For independent developers there is not much use of
| it. For enterprise types Oracle would reach folks who pay for
| licenses instead of hordes of JIRA slaves.
___________________________________________________________________
(page generated 2021-07-09 23:01 UTC)