> Some platforms like SPARC have built-in hardware support for pointer masking so it’s not an issue but for x86, the ZGC team use a neat multi-mapping trick.
Does anyone know what this instruction on SPARC is?
Java’s new garbage collector promises low pause times on multi-terabyte heaps
231–240 of 245 posts
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#232Earlier quoted context omitted.
Everyone I know in tech hates Java. They've all had to suffer through terrible poorly-performing Java desktop apps (or worse, applets) which has tainted the image of the language for a generation.
Not supporting bashing language in this thread, but this was a reason I never wanted to develop in Java. This terrible desktop experience created a notable bias towards Java, and only later I learned that it's not that slow for networking services (but it was too late).
This terrible desktop experience was created by developers that didn't bother to learn Swing before they jumped into the keyboard.
Writing everything on the main UI thread, not enabling system L&F, reading books like "Filthy Rich Clients", adopting third party Swing components with modern L&F....
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#233Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#234Earlier quoted context omitted.
512 bytes here.
What kind of PC had 512 bytes of RAM?
Kim-1, MK-14, other similar systems I built myself. I remember (a couple years later) at age 17 getting a summer job at a POS terminal company where we just took delivery of the first 64kbit DRAMs and being super excited when my boss allowed me to take some of my wages in ram chips at their high volume price..
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#235How much portion of these comments do consist of Reddit users? Or anyone who's remotely relate with that criminal organization?
LOL Fuck off Reddit. FUCK OFF.
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#236Earlier quoted context omitted.
He's just trying to bash Java. HN readers hate Java for some reason.
Everyone I know in tech hates Java. They've all had to suffer through terrible poorly-performing Java desktop apps (or worse, applets) which has tainted the image of the language for a generation.
I've found that terrible performing Java apps were created by terrible performing engineers.
Java, from my experience, has always been quick and flexible.
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#237Earlier quoted context omitted.
This is true, but it mainly just mitigates the problem. It can never solve the problem, because the whole concept of this kind of scheme is that the memory manager has some volition of its own ... thus it can choose to do things when you don't want or expect (actually this is unavoidable). Also note that this category of answer is basically saying, "look, if you mostly manage your own memory, then GC takes less time!…
you've talked about that before, "we very often have to do unsafe memory things", and that a lot of things done in game dev end up violating a lot of principles that are taught in college, but to be honest I'm not sure. granted, I haven't worked directly in game dev before, but i've worked on some projects where runtime perf was the _only_ requirement... and I'm just not convinced that these issues couldn't be worked…
The graphics APIs we use are often just about managing raw buffers of memory -- often different areas of memory that have different performance characteristics (Onion Bus vs Garlic Bus, yo). You simply can't do that under constraints of memory safety.
But beyond that ... "smart pointers" and the like make your program slow, because they postulate that your data is a lot of small things allocated far away from each other on the heap. I spoke about this in more depth at my Barcelona talk earlier this year.
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#238Earlier quoted context omitted.
Problem is memory locality, or lack thereof. Having to chase pointers around and not having things laid out in sequence doesn't play well with the CPU cache.
I'm not arguing against value types as I definitely want those too but it's not that simple nowadays - a moving garbage collector (like all modern server jvm's have) can do things for locality that non-moving systems (gc'd or not) can't - https://shipilev.net/jvm-anatomy-park/11-moving-gc-locality/
That only applies in a few specific cases. Basically, a linked list or an array of objects containing no further references. Otherwise, those internal references get immediately followed and significantly dilute the locality.
There have been garbage collectors designed to improve locality of predictable accesses, but they are not the norm.
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#239Who are these people that are designing systems that have terabytes of heap under a single GC, but still want/expect/need low pause times. I would think if there were processes that needed consistent latency you would isolate them.
I think I read somewhere, that the heaps of ecommerce website applications can be very huge, because of the loaded strings.
I think that was in the time of the java update (9?) where reduced string size was added
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#240Earlier quoted context omitted.
Everyone I know in tech hates Java. They've all had to suffer through terrible poorly-performing Java desktop apps (or worse, applets) which has tainted the image of the language for a generation.
Not supporting bashing language in this thread, but this was a reason I never wanted to develop in Java. This terrible desktop experience created a notable bias towards Java, and only later I learned that it's not that slow for networking services (but it was too late).
I suggest you check out JavaFX. It is a mature, modern, flexible UI library that is now considered the standard.
But of course, bad programmers make bad apps, no matter how good the ecosystem is.