I'm glad they didn't buy into the refcount meme that's so inexplicably popular these days.
i did google search for "refcount meme", and found out your comment as 3rd result, so it's not that popular...
Java’s new garbage collector promises low pause times on multi-terabyte heaps
21–30 of 245 posts
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#22Isn’t Java a pay-to-play runtime now? I thought Oracle changed the licensing model after Java 8?
http://www.oracle.com/technetwork/java/javase/eol-135779.htm..., The Oracle JDK will cost for production deployments but free for development beginning with Java SE 11. OpenJDK will be interchangeable with the Oracle JDK and Oracle will provide OpenJDK builds for free.
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#23I'm glad they didn't buy into the refcount meme that's so inexplicably popular these days.
Could you elaborate? Why would refcount be a bad idea ? (genuine question)
Many think that refcount isn't a GC algorithm and that it is faster than GC.
Well, refcounting is the basic way of implementing GC and is listed as GC algorithm in any serious CS book about GC algorithms like "The Garbage Collection Handbook".
What many refer as GC is actually the GC algorithms that fall under the umbrella of tracing GC.
Then refcounting is only faster than GC in very constrained scenarios:
- no sharing across threads, otherwise locking is required for refcount updates
- no deep datastructures, otherwise the call stack of cascading deletions will produce a stop similar to tracing GC
- implementations need to be clever about nested deletions when refcount reaches 0, otherwise a stack overflow might happen
- cyclic datastructures need programmer help to break cycles via weak dependencies or are just not allowed
This is only relevant for naive refcount implementations, there are many optimisations, which endup turning a refcounting implementation into a tracing GC in disguise.
Also just because a language uses a tracing GC algorithm, it does not prevent the existence of value types, or manual memory allocation for hot code paths, thus allowing for more productive coding, while offering the tools for memory optimisation when needed.
This is not yet the case with Java, but even here it is part of the language's roadmap to fix this.
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#24Earlier quoted context omitted.
Load-increment-store is slow. Load-decrement-branch-if-zero is slow. And you still need a tracing collector for cycles. So it's slow and still nondeterministic.
Okay, what's better, from a generalist standpoint? I have a decent but very high-level sketched-out understanding of refcounting, but I know nothing else about what's out there, and would be curious to find out. Particularly what would work well on x86 and ARM. An odd and probably completely wrongheaded idea just came to mind: add collectible objects to a lock-free queue in one thread, collect them in another. I wond…
Start by reaching out to "The Garbage Collection Handbook" that I mention in another thread.
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#25Earlier quoted context omitted.
No it’s still free, they (Oracle) are just not supplying the free JVMs. There are plenty of alternatives for OpenJDK builds that are FOSS.
Oracle still supplies free JVMs. The change was that to get updates for older versions of the JVM, you need to pay.
And even here, it is something that Sun used to do as well.
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#26Earlier quoted context omitted.
Load-increment-store is slow. Load-decrement-branch-if-zero is slow. And you still need a tracing collector for cycles. So it's slow and still nondeterministic.
Okay, what's better, from a generalist standpoint? I have a decent but very high-level sketched-out understanding of refcounting, but I know nothing else about what's out there, and would be curious to find out. Particularly what would work well on x86 and ARM. An odd and probably completely wrongheaded idea just came to mind: add collectible objects to a lock-free queue in one thread, collect them in another. I wond…
Better, depends on tradeoff's. RefCounting misses a key feature that ZGC, C4, Shenandoah and other Java GCs do (but not e.g. GO) and that is compacting. Secondly when accessing ref counted objects concurrently ref counting needs to be thread safe. i.e. using atomics, this does have significant performance overheads.
Pragmatically in high-throughput situations modern GC's perform better than simple GC. The new things in Java land is that the newest GCs have vastly reduced stop the world times (trending towards OS jitter times), while preserving compaction and without to bad throughput hits. (Even with the misfeatures of finalizers)
My personal experience with Shenandoah shows that this changes the way we think about heap settings for java. i.e. just set -Xmx to 60% of machine ram and let idle collections make sure we never use more than 4% in normal days.
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#27The site pops up a modal JS popup asking for your e-mail address after a bit of scrolling. That's an instant tab close and blacklist site for me. Why the hell are people doing that to their readers and themselves?
How do you blacklist the site? Because I'm thinking that would be an interesting extension or browser feature of an anti-bookmark.
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#28I'm glad they didn't buy into the refcount meme that's so inexplicably popular these days.
i did google search for "refcount meme", and found out your comment as 3rd result, so it's not that popular...
I figured he was talking about Rust, given that it is basically a refcount system but with the added constraint that the refcount can not exceed 1.
It's the only language that is anywhere close to meme status that I know of.
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#29I'm glad they didn't buy into the refcount meme that's so inexplicably popular these days.
i did google search for "refcount meme", and found out your comment as 3rd result, so it's not that popular...
If reference counting were going to help, they'd probably have switched to it already by now. I wonder if the poster just is angling for an opportunity to embark on a rant about one of Swift/Objective-C/ARC, Python, Rust, C++ - or perhaps all of them?
Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps
#30The memory mapping trick they use on x86 to avoid masking only works up to the maximum 48 bits of addressable virtual memory, so there is much less than 22 free bits in that case. It's also not quite free since it takes up TLB space.
Agreed - I'd go farther to say it only works for addresses in the userspace half, so on Linux you lose an extra bit and only get 47 (I don't know how the mappings are setup for Windows/OSX, sorry). It also might be worth pointing out that you now need 16x the page mappings (Since every mapping needs 15 duplicates for the possible flag states) - I don't know how Java does it's memory management but if it does lots of small mappings (Which I'm guessing it does not) then that could be a concern. And like you mentioned with the TLB, it takes up space and it also slows things down a bit since if the flags change the entry in the TLB will no longer be used (since the address is now different) and the MMU will have to walk the page-table again.
In practice, I would wager the performance concerns aren't huge, but that's mostly just a guess. I'd personally be interested in seeing a comparison to masking to see just how much slower masking would be, but obviously it's not like they can just flip a switch to use masking.