[HN Gopher] GC progress from JDK 8 to JDK 17
___________________________________________________________________
GC progress from JDK 8 to JDK 17
Author : carimura
Score : 246 points
Date : 2021-11-24 14:12 UTC (8 hours ago)
(HTM) web link (kstefanj.github.io)
(TXT) w3m dump (kstefanj.github.io)
| seanwilson wrote:
| How much do you need to worry about the GC causing frame
| stuttering when writing games now? Object pools are still
| important?
| zokier wrote:
| Well, jdk17 was released just few months ago so I doubt anyone
| has real experience with it for gamedev. But considering that
| game heaps are relatively small (as in <100G) and modern Java
| GCs can manage consistent <1ms pause times, I'd imagine Java is
| more viable for gamedev from that point of view. I'd also
| emphasize that there is large spectrum of performance
| requirements for games and you can make quite a lot these days
| with relatively poor performance characteristics, and on the
| other hand in the top end Java probably is still not good
| enough.
| adgjlsfhk1 wrote:
| IMO java for gamedev is pretty much un-viable due to the lack
| of control over memory layout. You clearly can make it work
| (see Minecraft), but it just sounds painful, and there isn't
| a clear benefit.
| 5e92cb50239222b wrote:
| Minecraft wouldn't be anywhere near where it is today if it
| was not written in Java (which made modding much easier
| compared to native code, and made heavy modding possible).
| So there is a strong benefit, it's just not very obvious.
| Thaxll wrote:
| Minecraft performance is a joke in 2021, when you see how
| much CPU you need to get 10 players in a world.
|
| It is written in Java because the original devs probably
| did not know anything better.
| kaba0 wrote:
| It uses that much CPU because the original devs did not
| know how to program well and it allocates a shitton of
| objects. It is not a good example of a well-written java
| game.
| billfruit wrote:
| Why is controls over memmory layout important for Games?
|
| If you work on Android games for example would you get any
| kind of control over mem layout, irrespective of the stack
| you will be using?
| adgjlsfhk1 wrote:
| For a simple example if you make a simple type to store
| the color of a pixel
|
| class RGB { float r float g float b ... }
|
| and then make an `ArrayList<RGB>` the list will end up
| using over 2x the memory (128 bytes for object headers,
| 64 bytes for pointers in the list) compared to a language
| with value types. What makes this even worse is that
| since you are using a list of pointers, you can't use
| SIMD for any of your computations, and accessing elements
| will be slow since the values won't be in cache.
| kaba0 wrote:
| Just to add, the really performance oriented hot loops
| can be rewritten with Class-of-Arrays with three int
| arrays for r, g and b values, or even a single one with
| flattened ints, with a user-friendly wrapper RGB class
| provided for outside use. With good OOP-usage it would
| not even be ugly. Performant java code has been written
| like that for decades, and these will get really close to
| C-programs.
|
| Also, there is now a Vector API that let's you use SIMD
| operations with configurable lane width (and a safe
| fallback to for loops for processors without the
| necessary instructions)
| throwaway34241 wrote:
| To add to adgjlsfhk1's answer, if you are writing Android
| games you are probably using a cross-platform game engine
| that doesn't use Java (like Unity) which solves the issue
| but more importantly also allows you to sell your game on
| iOS without a re-write.
| kllrnohj wrote:
| Look up "data oriented design" GDC talks or "AoS and SoA"
| for more in depth information to your question. The very
| brief tldr is that if you want to go fast, you have to
| design for cache locality and memory access patterns.
|
| In particular for Java there's regularly dependent
| pointer loads, which are dreadfully slow on modern CPUs
| and also waste a significant amount of L1/L2 cache.
| kaba0 wrote:
| While not the most ergonomic, one can definitely create
| SoAs in Java and those will be just as fast as they are
| in low level languages.
| kaba0 wrote:
| There are many types of games. For 2D games Java is more
| than performant enough, without question.
|
| Java can be ridiculously fast when only primitives are used
| so I wouldn't put a quite performant game engine past it,
| but yeah, it would perhaps not be my first choice for a new
| AAA game engine.
| 6gvONxR4sf7o wrote:
| What kind of games do you need to worry about memory layout
| for? From the outside, I'd expect that it's as diverse as
| most software, where sometimes you need control like C and
| other times python will do.
| actuallyalys wrote:
| > From the outside, I'd expect that it's as diverse as
| most software, where sometimes you need control like C
| and other times python will do.
|
| I develop games as a hobby, and my understanding is that
| this is literally true, but a little misleading. Games
| are as diverse as other areas of software, but they're
| skewed toward the more complex and demanding end. I don't
| think it's that atypical for a moderately complex game by
| an indie studio to get to the point where memory layout
| is a concern, which I don't think is as true for web
| apps, desktop apps, or other areas of development. That
| being said, I think worrying about memory layout is more
| than a lot of games need.
| shawnz wrote:
| C# has a similar memory model and it's the primary language
| used by Unity games... would you say that's un-viable?
| throwaway34241 wrote:
| For memory layout C# actually has an important difference
| in that it supports value types (so you can have an array
| of vertices without individually allocating each one,
| which has a lot of overhead and drastically reduces cache
| efficiency). They've been working on adding support for
| that to Java for some time but it's not in yet.
| kllrnohj wrote:
| The game engine is different from the game logic. This
| may mean Java is more viable for game logic, but still
| not viable for the engine itself
|
| That said, C# has value types and has for years now.
| Which is hugely important for arrays, and a major, major
| missing piece to the Java performance puzzle. C#'s FFI is
| also way better than the disaster that is JNI, which also
| plays a role here.
| kaba0 wrote:
| You are right, but I would like to add that both of these
| concerns will be solved in the near-far future. Java's
| project Panama tries to tackle the less than ideal FFI
| case with a tool that can create java classes from a C
| header and an API for manually managing memory regions.
|
| While Valhalla is in the works, but it is, I quote, at
| least 3 PhD's worth of knowledge combined to figure it
| out in a backwards compatible way with all the
| interactions of generics, etc.
| gregaccount wrote:
| Looking at that, why isn't ZGC the standard GC in Java 17?
| jbellis wrote:
| One of the graphs shows ZGC with almost 50% more overhead (in
| heap space) than G1, which could very well take some
| applications from "works fine" to "broken." So I can see why
| they'd leave it something to opt in to.
| __s wrote:
| Only stabilized in Java 15
| kaba0 wrote:
| Latency and throughput are fundamentally opposite ends of the
| same axis. And perhaps the majority of Java applications prefer
| better throughput.
| twic wrote:
| But the graph in the article shows that ZGC now gets _better_
| throughput than G1! [EDIT no it doesn 't]
|
| I suspect the answer is that ZGC is not considered mature
| enough, and has a higher memory overhead than G1.
| dralley wrote:
| There are also other GCs that are heavily competitive with
| ZGC, such as Shenandoah. It might make sense to see how
| they all pan out before choosing a new default.
| Sindisil wrote:
| Shenandoah isn't an Oracle maintained feature, so they'll
| never allow it to become the OpenJDK default (though
| another vendor make it so in their distribution).
| cpitman wrote:
| No, that graph may be hard to understand. It shows the
| _relative_ improvement each GC has made since Java 8, not
| the absolute performance.
| twic wrote:
| Ah, i realised it was relative, but i had assumed they
| were all relative to the same baseline! Should have been
| obvious from the way the bars are all level for JDK 8,
| really. That seems a needlessly unhelpful graph.
| kevincox wrote:
| They are essentially 3 graphs displayed together. It
| probably would have make sense to present them more
| separately.
| kevincox wrote:
| The article does not compare the throughput of different
| GCs other than different improvements. The baseline for the
| G1 graph is JDK8 G1 performance and the baseline for the
| ZGC graph is JDK11 ZGC performance. There is really nothing
| that can be directly compared between the two.
| vips7L wrote:
| G1 is probably still a better choice as it "balances throughput
| and latency". ZGC also wasn't generational until recently.
| hashmash wrote:
| I see that generational ZGC is under development, but have
| you been able to try it out? I don't see any EA releases for
| it.
| vips7L wrote:
| I have not tried it. I just saw the commits (it was 5
| months ago), so I had assumed it was merged.
| Rovanion wrote:
| Absolute gc throughput and overhead.
| thomascgalvin wrote:
| Those latency and pause-time numbers are pretty sexy. 200ms is
| still probably too high for some applications, but for everything
| I work on, this is incredible.
| hedora wrote:
| Those are P99 latencies. Not sure how they measure, but my
| assumption is that, if you probe the JVM at a random point in
| time, ZGC (P99 = 0.1) will be unresponsive for 100us 1% of the
| time.
|
| That's... not incompatible with being useable in a low latency
| service, but 100us is 2.5 x longer than a sync disk write these
| days, and they don't report max latency.
|
| My take on the article is that GC has gotten quantifiably
| better since Java 8, but not qualitatively better:
|
| The types of projects that had to abandon Java due to GC (and
| JIT) latency 10 (or 20) years ago still shouldn't consider
| using Java.
| kaba0 wrote:
| I'm by no means an expert but even the OS's scheduler can
| cause pauses on the range of 1ms -- so the applications that
| can't use Java, cannot really use ordinary OSs to begin with,
| can they?
|
| Like, yeah, I would probably not write something like
| pipewire (linux's new audio processing project) in Java, but
| other than that and like some really low latency trading
| niche (where FPGAs are dominant now as even general CPUs are
| slow), where would it preclude the usage of Java?
| adgjlsfhk1 wrote:
| The Linux kernel has realtime and lowlatency versions that
| help a lot here.
| pjmlp wrote:
| Note, only relevant for OpenJDK and the JVMs based on it, there
| are other GC available to other JVMs, including real time ones.
| pkoperek wrote:
| Genuinely interested - could you share some good resources
| about it?
| Thaxll wrote:
| https://www.azul.com/
| vips7L wrote:
| OpenJ9 as well: https://www.eclipse.org/openj9/
| ece wrote:
| Some more info on OpenJ9 GCs here:
| https://developer.ibm.com/articles/garbage-collection-
| tradeo...
| pjmlp wrote:
| For example, in what concerns real time GCs, these are good
| books,
|
| "Hard Realtime Garbage Collection in Modern Object Oriented
| Programming Languages."
|
| https://www.amazon.com/Realtime-Collection-Oriented-
| Programm...
|
| The author is one of the founders of Aicas real time JVM,
| https://www.aicas.com/wp/products-services/jamaicavm/
|
| "Distributed, Embedded and Real-time Java Systems"
|
| https://link.springer.com/book/10.1007/978-1-4419-8158-5
|
| PTC is the other company alongside Aicas, that still sells
| real time Java systems,
| https://www.ptc.com/en/products/developer-tools/perc
|
| IBM J9 has the evolution of the Metronome GC, https://www.res
| earchgate.net/publication/220829995_The_Metro...
|
| And it has extensions for value types, via packed object
| data, https://www.ibm.com/docs/en/sdk-java-
| technology/7.1?topic=ob...
|
| Someone else already referred Azul, they also have extensions
| for value types, called object layouts,
| https://www.slideshare.net/AzulSystems/jvm-language-
| summit-o...
|
| Then there are special flavours like microEJ or the Android
| Java snowflake.
| tannhaeuser wrote:
| graalvm and graalvm's svm/native-image as well, the latter
| having only SerialGC, with G1 in EE only, and crashing ;(
| bob1029 wrote:
| As a .NET developer I am a little envious of all the GC knobs
| that Java developers get to play with.
|
| If I could have only 1 new GC thing from Microsoft, it would be
| the ability to totally disable GC during the lifetime of a
| process. I don't even want to be able to turn it back on.
|
| I have a lot of scenarios where I could get away with the cruise
| missile approach to garbage collection. No reason to keep things
| tidy if the whole world is gonna get vaporized after whatever
| activity completes. Why waste cycles cleaning things up when you
| could be providing less jitter to your users or otherwise
| processing more things per unit time?
| zokier wrote:
| Shenandoah GC is conspicuously missing despite having similar
| availability to ZGC and competitive performance characteristics.
| maxpert wrote:
| I've used Shenandoah GC with great success and I recommend
| anyone considering ZGC (specially on Kube and container
| environments) to try Shenandoah first. You won't have to do
| additional work to enable large pages, yet your performance is
| pretty close.
| papercrane wrote:
| It would be good to see the numbers, but I suspect the reason
| is just that the author used the Oracle build of OpenJDK which
| doesn't include it.
| twic wrote:
| Shame this doesn't show the CMS collector, which was present in 8
| and 11, but removed before 17. CMS was the go-to option for low-
| latency collection for a long time, so it would be good to see
| how it compares to the modern options.
|
| It would be particularly interesting from the perspective of
| someone working in a shop which still has lots of latency-
| sensitive-ish workloads running on JDK 8 with CMS!
| jbellis wrote:
| Here is the comparison I did with Cassandra workloads,
| comparing CMS with ZGC: https://jaxenter.com/apache-cassandra-
| java-174575.html.
|
| (TLDR, ZGC is a huge improvement.)
| lmilcin wrote:
| Also, it would be interesting to see this progression from at
| least 1.4. By the time 1.8 was released I had the impression
| that GC is already pretty well optimized for throughput.
| twic wrote:
| Although if your ulterior motive is to persuade people to
| upgrade beyond 8 and 11, you probably don't want to suggest
| that performance has basically plateaued.
| lmilcin wrote:
| I don't see how this is bad.
|
| JVM is pretty well optimized and it is much closer to raw C
| performance than most other popular languages. You could
| also say that C is bad because its performance plateaued a
| long time ago.
| jonhohle wrote:
| C maps more closely to assembly/hardware than most other
| languages. Saying C has plateaued gets pretty close to
| saying it's hardware performance that's plateaued.
| SubjectToChange wrote:
| If C mapped to "hardware" so well then OpenCL, CUDA
| C/C++, SYCL, ispc, etc wouldn't be necessary. The rising
| importance of accelerators is a big issue for the future
| of C.
| Jensson wrote:
| Those languages maps to GPU's, C maps to CPU's. Those are
| on the same level as C, they aren't the real instructions
| that GPU's run but they are a pretty good abstraction for
| GPU instructions.
| SubjectToChange wrote:
| ispc is explicitly designed to take advantage of SIMD on
| CPUs and GPUs, its existence is directly related to the
| shortcomings of C in this area. Likewise, SYCL exists to
| target accelerators because C isn't even close to
| supporting heterogeneous hardware or programming. In any
| case, C does not map well to a massive amount of hardware
| running in production right now.
| Jensson wrote:
| A CPU can run any program written for a GPU, yes. But the
| languages you talk about are no closer to how a CPU work
| than C is, they might be more ergonomic if you want to
| take advantage of SIMD instructions but they don't do
| anything you can't do in C and there are a lot of things
| you can't do in them since GPU's are much more limited
| than CPU's.
| kaba0 wrote:
| C doesn't map any more closely to assembly/hardware than
| most other low level languages. If anything, hardware
| tries to conform as much to C programmers as they can.
|
| Hell, now Java has much better SIMD support than C, even
| as a high level language.
| Jensson wrote:
| Not sure what you mean, SIMD instructions maps perfectly
| well to C. You just call them like you call any other
| thing. What C doesn't do well are the exact CPU memory
| load order, how it caches things in the CPU etc. But no
| language can do that as you can't even control that in
| the machine code sent to the CPU. But most things you can
| do in machine code can also be done in C, and then things
| you can't can be done in inline assembly.
| gunnarmorling wrote:
| I suppose what they referred to is Java's (currently
| incubating) vector computation API. It lets you express
| vectorized algorithms in high-level way, with the API's
| methods being translated of the corresponding SIMD
| instructions of the underlying platform. I.e. you'll get
| vectorized execution on x86 and AArch-64 in a portable
| way, including transparent fallback to scalar execution
| if specific operations aren't supported on a specific
| target platform.
| Jensson wrote:
| Right, but that would still mean that C is closer to the
| hardware than Java. Java has a high level but less
| powerful solution, since you can only use it on vectors
| and not arbitrary data anywhere. You can write a similar
| function in C which compiles differently depending on
| where you compile and falls back in the same way, just
| that C gives you the option to use the hardware dependent
| instructions anywhere if you want.
| kaba0 wrote:
| I'm not sure I understand you: in C there is no standard
| way for SIMD afaik. There are pragmas on for loops, or
| other compiler specific tools but the language itself
| don't have any notion of lanes or SIMD instructions.
| Jensson wrote:
| > but the language itself don't have any notion of lanes
| or SIMD instructions.
|
| C doesn't need it, you can just call CPU instructions
| like functions. SIMD is just another kind of CPU
| instruction, so C supports it. That works in C since you
| have a direct view of the memory layout. It doesn't work
| in higher level languages where memory is abstracted away
| from you, in those you need the higher level concepts you
| are talking about in order to take advantage of SIMD.
| gunnarmorling wrote:
| These instructions are ISA specific though; i.e. in C
| you'd have to implement your solution once using x86 SIMD
| instructions and once using the AArch64 counterparts.
| You'd also have to account for different vector lengths.
| Whereas the Java API does all that for you automatically,
| e.g. automatically taking advantage of longer vectors
| when running on AVX512, and shorter ones elsewhere.
|
| I think that's what people consider "better" about the
| Java approach (at least I do). That's of course not to
| say that you cannot do all this in C as well, but I think
| having these capabilities in that portable way available
| in Java makes SIMD useable for a huge audience for the
| first time which didn't consider that a realistic option
| before.
| ozim wrote:
| Which does not matter because most of stuff still rides Java 8.
| JanecekPetr wrote:
| ...and they're missing out, that's exactly the message. By the
| way, I'd be shocked if Java 8 was still more than half of the
| running server-side JVMs. There's a lot of them for sure, but
| I'd be willing to bet it's gonna be less than a half now, and
| declining.
| guenthert wrote:
| They continue to use Java 8 as they see to reason to change.
| Article like this are meant to motivate those laggards.
| Thaxll wrote:
| What is not shown is those benchmark is how much CPU is used for
| each GC. For example the latency for ZGC is much lower but does
| it means it uses more CPU than G1.
| [deleted]
| kaba0 wrote:
| Just sharing this really great benchmark series on JVM GCs,
| though it doesn't include the latest versions of OpenJDK:
|
| https://jet-start.sh/blog/2020/06/23/jdk-gc-benchmarks-remat...
| jimsimmons wrote:
| These GCs have a 1GB overhead when working with a 16GB heap.
| That's 6% of your available memory. I was expecting modern GCs to
| be way more efficient so I'm kinda shocked this is what state of
| the art is.
|
| I also wonder how much of the progress to "Sub (200) millisecond"
| latency target is due us just having faster machines. I honestly
| have no model to tie this to actual performance of my code. I
| guess it translates but not really sure how.
|
| Not bagging on Java ---- I am just surprised how inefficient an
| industrial strength GC can be. I understand why manual memory
| management still holds its own now.
| dehrmann wrote:
| It's worth noting glibc isn't zero-overhead, either.
| naasking wrote:
| > These GCs have a 1GB overhead when working with a 16GB heap.
| That's 6% of your available memory.
|
| 6% memory overhead while preserving throughput is actually
| quite excellent. Just a little more than the average
| fragmentation overhead under manual memory management.
|
| Manual memory management can "hold its own" because it can
| tailor the allocation/release profile to the problem and
| aggregate some of those overheads.
| cowsandmilk wrote:
| > due us just having faster machines
|
| ?? These benchmarks keep the machine constant. And I'm not sure
| we've seen faster machines in a long time. Clock speeds have
| remained fairly constant and gains are solely in more cores.
| kaba0 wrote:
| Seeing that RAM is the cheapest resource to scale (and that
| cleverly using it saves energy, given that Java uses the least
| energy out of managed languages) it seems to be a very good
| tradeoff.
| kllrnohj wrote:
| Accessing RAM is very slow and CPU caches don't scale,
| though. So it's not as simple as you're presenting it
| kaba0 wrote:
| Well, for general computing I don't think we have an answer
| either way. Yeah, for some hot loop with an array we get
| insane performance, but that is a very specific workload
| and not applicable everywhere. What about a chat
| application, which parts of the memory should be physically
| close to each other?
|
| Also, Java's GCs are compacting, putting similarly old
| objects relatively close to each other. The same random
| chat program in C might use a linked list with worse
| characteristics so it is really not that obvious to me what
| would be a good solution.
| foldr wrote:
| Manual memory management can also have overhead due to e.g.
| fragmentation. I don't know if it approaches 6% in realistic
| scenarios.
| pkolaczk wrote:
| Wait, fragmentation is not included in that 6%. It is that a
| GC with no fragmentation will already suffer a 6% overhead. A
| region-based GC will suffer from additional temporary
| fragmentation on top of those 6% as well, because some
| segments can be filled only partially with live objects until
| they are compacted. That effect might be actually bigger
| because allocations are done only from contiguous space, and
| it can't just try to allocate from the "holes" until it
| compacts them. And you also need some additional room to do
| allocations from in order to avoid too frequent GCs. So I'm
| practice it is not 6% but sometimes 600%.
| foldr wrote:
| Yes, sure. But you do still need to compare the total
| overhead associated with manual memory management (which is
| not zero) to the total overhead associated with GC. It's an
| empirical question which is larger in any given case. And
| of course it depends on the implementation of malloc and
| the implementation of GC.
|
| I'm not expressing a view as to whether the overheads of
| manual memory management are typically comparable or not. I
| really don't know.
| pkolaczk wrote:
| The total memory overhead of manual memory management can
| be virtually zero if you're careful enough to avoid
| fragmentation (and you can because it is manual, so you
| control a lot of details). There is for example no
| constant header for each allocated chunk. In Java you pay
| additional 16B for each allocated object and you can't
| get away from that overhead.
| foldr wrote:
| Yes, manual memory management can always be better with
| arbitrary amounts of tuning. However, I think the more
| interesting question is how the overheads compare in
| typical applications written in a reasonably
| straightforward and maintainable style. In practice,
| fragmentation can be a difficult problem to avoid when
| using manual memory management. For example, Firefox
| struggled with it for a long time.
| pkolaczk wrote:
| A web browser is a huge and complex app. The argument it
| struggled with memory issues is moot if you can't show a
| comparably featured app written in Java to compare memory
| use.
|
| Anyways, I've got plenty of anecdotal evidence where Java
| apps take order of magnitude more memory than their close
| counterparts written in languages that use manual memory
| management. Not browsers, but things like benchmarking
| tools, webservers or even duplicate file finders
| (shameless plug:
| https://github.com/pkolaczk/fclones#benchmarks - there is
| one Java app there, see its memory use :D)
| foldr wrote:
| We're talking at cross purposes here. I did say that I
| wasn't expressing a view as to whether the overheads of
| manual memory management are typically larger than the
| overheads of GC. I don't know if they are or not.
|
| The point I was making was just that you do need to
| compare empirically the typical overheads of each to make
| a meaningful comparison. The 6% figure in isolation
| doesn't tell us very much.
|
| As you point out, it is difficult to make these
| comparisons on the basis of anything other than anecdotal
| evidence, since it is rare for applications of
| significant size or complexity to be implemented in
| multiple languages.
| atom3 wrote:
| According to the cppcon talk about Mesh [1] (an allocator
| that implement compaction for C++ programs), the overhead can
| be massive too (17% overhead measured on firefox, 50% on
| redis!)
|
| [1] https://youtu.be/XRAP3lBivYM?t=1374
| jimsimmons wrote:
| Nice link. I guess theoretically you can always optimise
| this in languages with manual management. With complex GC
| you have to figure out a way to tame the beast and I'm not
| sure if it's easier to reason about
| pron wrote:
| Sub-millisecond is already here with ZGC, and it's not much to
| do with faster machines (machines haven't become that much
| faster over the past ten years) but with more sophisticated
| algorithms.
| dandotway wrote:
| As Java is generally the fastest GC'd language, what's the
| current state of Java gamedev?
|
| Once upon a time, this indie Java game called Minecraft became
| the most successful game of all time.
|
| But from the few minutes of research I just did, Java cannot be
| deployed to many commercially important systems -
| Nintendo Switch - PlayStation - iOS
|
| It appears Java is only still viable for Windows and Android, and
| the 1% Linux desktop market.
|
| There used to be the GCJ project which would in theory let you
| run Java anywhere you had a C/C++ compiler, but Oracle's
| litigiousness killed that because the Java[TM] "platform" must
| run the official Java[TM] bytecode.
|
| It appears C# via Monogame lets you deploy to all desktops
| (Win/Mac/Linux), mobiles (iOS/Android), and consoles
| (PS/Switch/Xbox). So ironically C# seems to now be the "write
| once, run anywhere" fulfillment of the original Java promise.
|
| [EDIT: grammar.]
| admax88qqq wrote:
| Seriously, with sub-ms pause times of ZGC you could run a GC
| every frame and have tons of time to space for actual
| processing.
| dandotway wrote:
| It sounds very nice but if more than half an indie game's
| revenue comes from Nintendo Switch then you need a low
| friction way to get your .java files running there. You also
| need a proven audio mixer stack so you can load
| background_music.mp3 and play bang.wav and boom.wav without
| any popping or leaks. Right now Java seems sort of iffy on
| consoles, as in, you could maybe spend a ton of time and/or
| money to get an effort like GraalVM production-grade working
| there, but no one has bothered to do it yet. It seems to be
| much lower friction to just use C#/MonoGame, or SDL2 with
| your scripting language of choice that compiles with a C/C++
| compiler, or a proven game engine.
| JanecekPetr wrote:
| For native binaries, we now have
| https://www.graalvm.org/reference-manual/native-image/, but it
| probably doesn't yet work nicely with game frameworks? Not
| sure.
|
| There are some engines, frameworks: https://jmonkeyengine.org/,
| https://litiengine.com/, https://libgdx.com/,
| https://www.lwjgl.org/.
|
| But I have no real experience with any of those.
| pjmlp wrote:
| You can on iOS, for example with Codename One or Gluon Mobile,
|
| https://www.codenameone.com
|
| https://gluonhq.com/products/mobile/
|
| They are also quite happy to sponsor possible console ports.
| aetherspawn wrote:
| Is Java GC ("the best") really that much better than something
| with immutable heap ie Haskell?
| dandotway wrote:
| I love functional languages but is anyone actually using
| Haskell to develop for Nintendo Switch and PlayStation? Can
| you use Haskell on the Nintendo Switch to access a robust
| audio mixer stack?
|
| F# can be used with C#/MonoGame which seems to run well
| everywhere so that's one route to functional programming
| gamedev. Another route appears to be to use SDL2 with a
| functional language that supports ANSI C bytecode runtime
| fallback. E.g. OCaml has a bytecode compiler and an ocamlrun
| runtime that can be compiled with an ANSI C compiler. But I
| don't know what the GC latency guarantees are for the
| bytecode runtime. OCaml's native low latency GC benefits from
| Jane Street's contributions because Jane Street uses OCaml
| for high frequency trading. But bytecode OCaml running on
| Nintendo Switch isn't the same thing as native Linux OCaml.
| kllrnohj wrote:
| Java's FFI and value type situation are the two major missing
| pieces for Java gamedev. C# has better stories for both, and
| has from the beginning.
|
| Don't confuse Java having the fastest GC with Java being the
| fastest GC'd language (especially not in all situations)
| kaba0 wrote:
| Java's new better FFI is almost ready with project Panama and
| value types will come, but it is exceedingly hard to retrofit
| into a language (but the idea for the exact semantics might
| have formed already!)
| cesarb wrote:
| > Don't confuse Java having the fastest GC with Java being
| the fastest GC'd language
|
| I've always wondered, it's likely that Java has the fastest
| GC because it _needs_ to have the fastest GC, otherwise it
| would be a bottleneck. Other popular languages probably don
| 't depend as much on the performance of their memory
| allocation primitives.
| winrid wrote:
| You can compile to iOS/Android with libgdx.
|
| I've been doing this with a game I'm building that has a custom
| 3D OSM map renderer.
| mcdonje wrote:
| The throughput & latency charts have JDK8 pegged at 100%. Since
| that's meaningless and the value is in the difference between the
| JDK versions, it should be represented as a delta.
| vletal wrote:
| I like how this reached the top page soon after "Go does not need
| a Java-style GC" (https://news.ycombinator.com/item?id=29319160).
|
| Moreover, are the significantly lower GC pause times help improve
| snappiness of GUI apps, such as IntelliJ IDEA?
| fnord123 wrote:
| Current IntelliJ uses Java11 and has gotten slower over the
| past few years (anecdata from my own use) - so probably not.
| hiram112 wrote:
| This is what I've noticed too. Intellij has never exactly
| been speedy, but it had so many great features that it was
| worth it compared to other slow IDEs like Eclipse. And using
| a basic text editor like VIM or even VS Code with a big Java
| project isn't really feasible like it might be in other
| languages like Python or Node.
|
| However, now it is really bogging down. I'm sure it doesn't
| help that I've got several IDEs open along with some
| monstrosity of a "microservice" framework running half a
| dozen docker services and DBs on an older Macbook Pro, but
| it's true that app and OS devs tend to use all increases in
| CPU and ram, and so absolute performance and battery life
| never seems to get better over the years, regardless of how
| much the underlying hardware itself has improved.
| vips7L wrote:
| VS Code is fine with with big projects, I've been using it
| for 2 years. The language server is Eclipse after all.
| pjmlp wrote:
| Red-Hat is behind most of the Java plugins, so their
| quality is quite good, there is only the pain to live
| with Electron.
| thies wrote:
| Since 2020.x it's definitely slower. The addition of
| jetbrains space doesn't seem to help either and removing the
| plugin itself makes the whole ide unstable
| vips7L wrote:
| I wish they would just release a light version, without all
| the database, spring integration, and other crap. I just
| want a light language server.
| matsemann wrote:
| Just deactivate the plugins?
| 5e92cb50239222b wrote:
| Try power saving mode (look in ctrl+shift+a).
| absove wrote:
| wouldn't community edition fit the bill? Those things you
| mention are the main difference with ultimate.
| vips7L wrote:
| Not sure. I moved to VS Code + Eclipse LS and it's such a
| more pleasurable experience. However, it doesn't support
| SBT which is the build tool my company uses.
| aenis wrote:
| Not just slower, also energy hugry. My m1 max running pycharm
| loses about 10pct of charge an hour on their crappy bundled
| jvm, and around 4% on the latest java17-based ones, but does
| act weird at times when using them. Its probably down to
| metal vs opengl. Disappointing.
| pjmlp wrote:
| The GC might help, but it doesn't do magic when threads aren't
| used the correct way, too much stuff lands on the UI thread or
| synchronous IO is used all over the place.
| [deleted]
| edgyquant wrote:
| That's the magic of HN (or maybe it's a form of the Baader-
| Meinhof Phenomenon.) When one topic reaches the front page it
| seems like a couple more based around it hit the front page the
| same or next day, which allows us to expand on what we've
| learned.
| Erlangen wrote:
| Intellij uses UseConcMarkSweepGC gc, which has been deprecated
| since Java 9. Jetbrains is still investigating the use of ZGC.
| https://youtrack.jetbrains.com/issue/IDEA-247824
| darksaints wrote:
| Honestly this is the most frustrating thing about Jetbrains.
| Stop investigating shit and just use the new JVMs already.
| There is no excuse for using deprecated JVMs.
| lmilcin wrote:
| I am pretty sure Jetbrains cares their product works well
| for a lot of people and they know better than you which JVM
| is better for their product.
|
| It is not like it restricts what you can build with it.
|
| We may not know their exact decision process but it is
| incredibly ignorant to assume they are just doing this out
| of laziness or incompetence.
| darksaints wrote:
| They've already explained their reasoning, I don't have
| to assume anything. Their reasoning is bad:
|
| * They've fixed long-known bugs in the JVM
|
| * They've added sub-pixel anti-aliasing and other visual
| rendering enhancements.
|
| Both of these are clear improvements on the JVM, and very
| likely to be accepted upstream, but instead of
| upstreaming them, they decided to create a long-running
| fork and package it as their own runtime. And like all
| long-running forks, they're struggling to keep up.
|
| So we are left with two choices: abandon the hope of a
| functional IDE that only works well on a customized
| runtime, or abandon the litany of performance,
| capability, security, and stability improvements in the
| JVM standard and reference JVM implementation.
| astange wrote:
| This is so removed from reality that it's difficult to
| know where to start.
|
| For starters, sub-pixel aliasing is a standard part of
| the JDK and isn't a Jetbrains addition.
|
| What exactly is stopping you from using a standard JDK17
| build with Intellij? How is the IDE not functional for
| you when doing so? How is it improved when using the
| JDK17 runtime they have on their github page?
| darksaints wrote:
| This is easy:
|
| Standard Jetbrains Runtime - slow as fuck, missing a
| whole host of performance improvements, security updates,
| and bug fixes since the fork occurred back in JDK8/9 Era.
|
| OpenJDK - ugly as sin, gui becomes glitchy, lose out on
| customer support channels (first thing they tell you is
| to use the standard jetbrains runtime)
|
| Newer versions of Jetbrains Runtime - have to reinstall
| manually every time you update your IDEs. You also lose
| out on customer support, as they are beta software.
|
| This isn't really a hard problem to solve: find a way to
| upstream your improvements to the JVM, and then package
| the upstreamed version. All of these problems go away,
| and you're even relieved of the burden of maintain a long
| running fork.
| astange wrote:
| Yes, this is easy:
|
| - The current JBR is JDK11, not JDK8. - You don't need to
| reinstall anything to use an alternative JDK with the
| IDE. Just set the IDEA_JDK envar to the JDK of choice. -
| Ugly as sin is an opinion. I use the IDE with linux on a
| hidpi display. Looks perfectly acceptable to me...even
| running with JDK18. - I just reported an issue while
| running with the JBR17 a few days ago. Jetbrains was
| perfectly responsive to my issue.
| lmilcin wrote:
| But what is _your_ problem with this? Do you _really_
| care which JVM is being packaged or you are just picking
| on something that isn 't a problem?
|
| Have you had a problem running IntelliJ IDEA?
|
| I am pretty sure that if I was distributing a very, very
| complex Java application for a very, very wide variety of
| audience (like people who aren't even developers because
| IDEA also caters to these people) I would distribute it
| with JVM packaged.
|
| And then the user should not care which JVM exactly is
| being distributed. You only need to care about the end
| result.
|
| Let me know the last time you cared which version of JVM
| is used by any of the SAS products you subscribe to.
| darksaints wrote:
| Yes, I care. Because while jetbrains makes an excellent
| IDE in terms of functionality, they have extremely shitty
| startup times and garbage collection pauses. These are
| both areas that have received a lot of attention in the
| reference JVM in the versions subsequent to their fork.
| All of the performance problems literally disappear by
| using a newer OpenJDK version, but then the GUI starts to
| look and act weird.
|
| I don't know why you would assume that I am asking for
| them to not package a JDK at all. That's a fucking absurd
| assumption, and nothing i have said has even suggested
| that. All I'm asking for is for them to upstream their
| improvements and package their IDEs with OpenJDK by
| default so we don't have to choose between Jetbrains
| improvements or OpenJDK improvements.
| melony wrote:
| I don't understand why they are not shipping their own
| bespoke GC to go with Intellij, Jetbrains is already
| building their own JVMs.
| astange wrote:
| Edit the idea64.vmoptions config file and use the GC of
| your choice. I've been running with ShenandoahGC for quite
| some time now and it's been working great.
|
| Also, see https://github.com/JetBrains/JetBrainsRuntime/rel
| eases/tag/j... for a JDK17 runtime for Intellij products.
| I've been running this too and it works great (but does
| require some tweaks to the vmoptions file).
| vips7L wrote:
| I tried this last year but the version they shipped with
| IDEA didn't have ZGC and using an external JVM caused
| some weirdness in the GUI for me.
| parhamn wrote:
| Curious before I try it, is the speed/performance any
| better?
| astange wrote:
| It depends. There is less latency in the IDE due
| primarily to better GC (just as the article describes). I
| think the speed is better too on things like indexing the
| code base, but that could depend on your computer. I'm
| running on a 32core high end AMD system with lots of RAM,
| and I increase the heap setting in Intellij to 4G, etc. I
| think the IDE is subjectively better.
|
| We run all our production applications on JDK17 too,
| which is why I push to run everything on 17.
| 5e92cb50239222b wrote:
| Text can look pretty bad if you're using other JVMs
| without their patches.
| hawk_ wrote:
| Yes particularly on Linux, any non jetbrains jdk running
| intellij looks awful. I don't know if the consider it as
| some kind of competitive advantage to not submit fixes
| upstream.
| The_rationalist wrote:
| A part of their patches (at least for emojis?) got
| recently merged
| belter wrote:
| What are they doing in the JVM to make text look good?
| pjmlp wrote:
| They are in bed with Google, so they need to spend their
| resources improving Kotlin use cases instead.
| Ind007 wrote:
| It is defaulted to G1 now(I have 2021.2.2 version).
| Erlangen wrote:
| I am running 2021.2.3 now. `ps aux | grep GC` still shows
| "-XX:+UseConcMarkSweepGC"
| stusmall wrote:
| -XX:+UseG1GC on my install of clion. Maybe old JVM
| parameters have persisted in settings somewhere?
| cesarb wrote:
| > Maybe old JVM parameters have persisted in settings
| somewhere?
|
| This is an annoying behavior on at least Intellij Idea (I
| don't know about other Intellij products). If you ever
| increased its memory limit (it's an option on one of the
| top-level menus, and it will also occasionally suggest
| increasing it if it ever notices it's using too much
| memory), it copies the idea64.vmoptions file which
| contains not only the memory limit (-Xmx), but all the
| JVM parameters, from the binary directory to your
| configuration directory, and so the JVM parameters on it
| will be kept forever, instead of being changed when you
| update the IDE. The fix is easy: find that copied
| idea64.vmoptions file, write down the memory limit on it,
| remove that file, restart the IDE, and go to that top-
| level menu option to set the limit again. This will copy
| an updated set of VM options to your configuration
| directory.
| finalfantasia wrote:
| They changed the default garbage collector to G1 last
| year.[1]
|
| [1] https://github.com/JetBrains/intellij-
| community/commit/edf1c...
| [deleted]
| Sankozi wrote:
| Snappiness problems are often due to lazy loading Java classes.
|
| For example first time loading project settings takes 1+
| seconds while next less than 0.5. This value might get lower
| later if JVM decides to optimize more some parts of UI
| application.
| fnord123 wrote:
| I don't think that's where the issues are. IntelliJ freezes
| when reindexing a project when you change branches from the
| command line.
| msie wrote:
| I've given up on IntelliJ and java-based UI's long ago. So
| disappointing.
| coliveira wrote:
| That's the right way to go. Like IntelliJ or not, Java is a
| legacy technology. I wouldn't want to depend on that.
| kaba0 wrote:
| Lol, you are laughably bad to think that java is legacy.
|
| The JVM is improving with never before seen speed, has
| state of the art GCs, a very good JIT compiler, upcoming
| green threads that will make blocking code automagically
| unblocking and once Valhalla hits with value types, there
| really will be very few areas where java would not be
| applicable.
|
| And on top of that, there is also Graal, which is a novel
| way to run and optimize mixed-language code bases.
___________________________________________________________________
(page generated 2021-11-24 23:00 UTC)