Reference count, don't garbage collect • Hacker News Board

Re: Reference count, don't garbage collect

#331

Post by kibwen » Sat, Jul 30, 2022, 1:39 PM UTC

pjmlp wrote: post #256

kibwen wrote: post #188

Earlier quoted context omitted.

If you want to get even more precise, call it automatic dynamic memory management. Automatic static memory management would be something like Rust's scope-based memory reclamation via ownership.

Great to confuse more people instead of properly learning about affine type systems.

There's no confusion here? This is a perfectly natural classification, that satisfies many people's intuition about Rust as having "compile-time GC". If anything, bringing up affine type systems is more liable to confuse people in this context; just because a language has an affine type system doesn't necessarily mean it needs to use it for memory management.

Re: Reference count, don't garbage collect

#332

Post by lumost » Sat, Jul 30, 2022, 1:49 PM UTC

brabel wrote: post #262

lumost wrote: post #113

Earlier quoted context omitted.

It’s gotten better over the years. Java originally did not have generics, then there was the factory/uml everything crowd. Recently modern Java has been evolving towards ergonomics with streams/loom/guice/Lombok etc. However we still don’t have something like auto/let from cpp/rust.

Typical criticism of Java: outdated by several years... Java has had "var" since at least Java 11 (current version is 18, with version increasing every 6 months, so you're talking about Java from 4 years ago). With new features every 6 months, yes, 4 years ago is an eternity in Java world these days... 4 years in the future, almost certainly Java will already have virtual threads (like Go coroutines), full support fo…

Fair, my Java experience recently has been on a code base with jdk8/10 semantics. Super pumped for loom though.

Re: Reference count, don't garbage collect

#333

Post by kgeist » Sat, Jul 30, 2022, 2:40 PM UTC

viktorcode wrote: post #249

kgeist wrote: post #190

Earlier quoted context omitted.

>One reason you'd choose ref counting is because it's deterministic behavior Not sure if it's entirely deterministic. A variable going out of a scope can trigger deallocation of a large object graph and it's not always clear by just looking at a code what will happen (especially if objects have destructors with side effects, your object graph is highly mutable, and your code is on a hot path). A common trick is to de…

Deterministic means that running the same part of the program will take the same amount of time. Deallocating the same memory object graph is pretty much deterministic. GC can throw a spanner in that by deciding that now is the time to do its thing.

>Deterministic means that running the same part of the program will take the same amount of time

The object graph can easily be different from run to run depending on user input, timing, etc. Say, in the first run, the graph has a large subgraph due to a runtime condition (a property is set to a certain value), and on the next run, the graph is more lightweight because the property was not updated. It will take different amounts of time to collect such graphs (especially if they have destructors). I don't see how GC is any different here, it also depends on input, timing, etc. It's true though that a programmer has less control of GC because the rules when it is triggered are not always 100% clear (implementation details of a particular runtime) but imho they are as deterministic as RC; RC is just a form of GC which has very simple rules which are eaiser to understand.

Re: Reference count, don't garbage collect

#334

Post by al_mandi » Sat, Jul 30, 2022, 2:55 PM UTC

pkolaczk wrote: post #277

al_mandi wrote: post #207

Earlier quoted context omitted.

Java (the JVM) doesn't really have 10 second pauses anymore. G1GC and ZGC and Shenandoah have been a thing for a while now.

G1 can do 10 second pauses. I observed them many, many times. It tries not to, but there are no guarantees.

Have you tried ZGC or Shenandoah?

Re: Reference count, don't garbage collect

#335

Post by pjmlp » Sat, Jul 30, 2022, 3:11 PM UTC

rowanG077 wrote: post #323

pjmlp wrote: post #241

Earlier quoted context omitted.

Because we have studied the literature instead of what a random dude in tells at a coffee https://gchandbook.org/ https://www.sigplan.org/ https://ieeexplore.ieee.org/Xplore/home.jsp

Nice appeal to authority instead of trying to engage in a meaningful way.

When one is open to learning, the best path to enlightenment is to use the same books as the Wizards on the tower of knowledge.

Re: Reference count, don't garbage collect

#336

Post by _se » Sat, Jul 30, 2022, 3:17 PM UTC

becquerel wrote: post #315

ncmncm wrote: post #237

Earlier quoted context omitted.

Java's fundamental problems are well beyond reach of any syntactic sugar.

Please explain these fundamental problems.

Generic type erasure and primitive boxing are two examples that cause daily headaches for many.

Re: Reference count, don't garbage collect

#337

Post by hinkley » Sat, Jul 30, 2022, 3:25 PM UTC

bcrosby95 wrote: post #114

hinkley wrote: post #54

Earlier quoted context omitted.

To be fair, they definitely got into a rut in the JDK 6-7 timeframe. I maintain it's no accident that memcache came into its own during this period. That was a major pain point, and going out-of-process shouldn't have been necessary.

I always figured memcached gained popularity because it let your monolithic LAMP-like-stack scale better, not because of anything about Java. Just wedge it between your N stateless application servers and MySQL and you could handle 10x more users. At least, that's how most people I knew back in 2006ish were using it.

I think each ecosystem had a very different experience with memcached adoption. In Java it was really limiting to do in process cache, and that limitation hit a wall while memcached usage was starting to spread. I assume Rails and maybe Python had similar problems, because all of the papers about GC techniques up to about that point were talking about Java. They got a lot of good stuff first or second.

What’s common though is that hard drives were not getting faster, but network hardware was hitting its stride. Full bandwidth (port speed X port count) routers and multi NIC were recently ubiquitous.

I had just come off a carrier grade software project when memcached finally hit my radar, and we had only spec’ed 3-5 servers for the web tier. That was still enough local cache hit rate to keep us running relatively smoothly. Or at least once we got done being honorary QA members for F5. We had lots of problems on that project with data modeling and so we actually were using too much caching vs precalculation but that’s a different story.

Re: Reference count, don't garbage collect

#338

Post by hinkley » Sat, Jul 30, 2022, 3:32 PM UTC

pclmulqdq wrote: post #106

hinkley wrote: post #52

Earlier quoted context omitted.

I don't know what the current state of the art is, but at one point the answer to GC in a realtime environment was to amortize free() across malloc(). Each allocation would clear up to 10 elements from queue of free-able memory locations. That gives a reasonably tight upper bound on worst case alloc time, and most workflows converge on a garbage-free heap. Big malloc after small free might still blow your deadlines,…

This is normal today inside malloc implementations.

I think that’s been normal in malloc for some time. I maintain that we should all thank Java, and the hype train around it, for forcing operating systems to implement more robust threading support. Everyone wanted to be able to say they did Java well, and nearly every OS had capital ‘I’ Issues, including Solaris. Boy I bet those closed room arguments were epic.

Where GCed languages pulled ahead for a while, particularly Java, was that they had mature concurrent memory allocation before most OSes did, so many people found on early two and four core hardware that malloc started to show up as a bottleneck.

Re: Reference count, don't garbage collect

#339

Post by klodolph » Sat, Jul 30, 2022, 3:41 PM UTC

eru wrote: post #163

klodolph wrote: post #70

Earlier quoted context omitted.

It's not always obvious to know which reference to mark as weak, and there's not necessarily a clear indication of which reference is a back-reference. You can find various algorithms in journals or whatnot written with the assumption that there's GC. Algorithms designed with this assumption may not have clear ownership for objects, and those objects my have cyclic references. It's easy to say, "objects should have c…

And if you have really clear ownership, you don't need reference counting either..

That's definitely not true. "Clear ownership" may still be shared ownership.

Re: Reference count, don't garbage collect

#340

Post by klodolph » Sat, Jul 30, 2022, 3:42 PM UTC

ahartmetz wrote: post #235

klodolph wrote: post #81

Earlier quoted context omitted.

> Yeah, I think it's an inelegant, brute-force solution to a language problem - and that we continue to throw good money after bad improving it. Having studied GC, implemented GC, and used it extensively (either as a dev or someone in operations) I'd say that there's just a lot of people out there who don't understand it. That's why people come to the wrong conclusion that it's somehow "inelegant" or "brute-force", w…

Even the best "real world" garbage collectors pause the program for order of magnitude a hundred milliseconds, no? I was recently reading some blog posts of the V8 JS engine team. There is nothing to understand or not understand there, it's hard data.

> Even the best "real world" garbage collectors pause the program for order of magnitude a hundred milliseconds, no?

If you think GC pauses are measured in milliseconds, and not microseconds, then you're reading horribly outdated material. You're off by three orders of magnitude for an off-the-shelf GC with no tuning.