71–80 of 245 posts
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...
Earlier quoted context omitted.
Doesn't matter. Our legal system is such that Oracle can still burn you down, even if you are right.
How so in the case of using GPL code?
This can also destroy investment rounds for many startups.
Earlier quoted context omitted.
ZGC is part of OpenJDK and licensed under GPL.
Doesn't matter. Our legal system is such that Oracle can still burn you down, even if you are right.
Do you happen to know of any real-world case that's similar to the scenario you've described?
Isn’t Java a pay-to-play runtime now? I thought Oracle changed the licensing model after Java 8?
[1] http://blog.joda.org/2018/08/java-is-still-available-at-zero...
I'm glad they didn't buy into the refcount meme that's so inexplicably popular these days.
"It is time to unmask the computing community as a Secret Society for the Creation and Preservation of Artificial Complexity." ~Dijkstra It's very impressive work, no doubt. And as long as no one asks me to debug anything running on top, I don't have any issues with it. At least with straight reference counting I know what's going on under the hood, that's worth a lot. Sharing pointers across threads is tricky busine…
https://www.youtube.com/watch?v=1f-kfRREA8M
And the Ministry of Silly Walks is the perfect metaphor for user interface design.
Earlier quoted context omitted.
i did google search for "refcount meme", and found out your comment as 3rd result, so it's not that popular...
I did a search for "freecodyx user", and found no results, so I guess you don't exist.
It's like you're claiming you are famous because your mom knows who you are.
Earlier quoted context omitted.
> With refcount you need to sync every time you add/remove a reference to an object. For many (most?) workloads that's going to be quite substantially more frequent than tracing collections. Whether one or the other wins out probably depends a lot on your use case. That's not actually true of deferred reference counting with update coalescing. Instead, it defers the refcount increments and decrements to periodic inte…
How many languages use this approach though? This probably also removes one major advantage of RC'ed systems though: deterministic destruction (e.g. close resource as soon as last reference disappears). And suddenly you need some kind of runtime too.
As I noted, there's at least one high performance GC implementation for Java that uses it, with effectively identical performance to a state of the art tracing GC on all benchmarks considered--it's not a toy idea. I don't think the fact that most production languages don't use it means very much, given how much more effort has been spent tuning tracing compared to reference counting.
> This probably also removes one major advantage of RC'ed systems though: deterministic destruction (e.g. close resource as soon as last reference disappears). And suddenly you need some kind of runtime too.
Completely deterministic destruction in the sense that you describe is pretty much incompatible with achieving the highest collection throughput. In particular it means you always have to trace dead objects independently (and, if all cores are busy, block someone from doing useful work while you deallocate), so most young object optimizations are a nonstarter. If you can stack allocate (or equivalent, e.g. push and pop from a vector with a trivial destructor) almost all your young objects, great; otherwise, for my money, keeping latency-sensitive things in well-scoped regions is far more deterministic and effective than either RC or tracing. The number of non-memory resources in most programs is usually rather low; you can always use traditional reference counting (or linear types or whatever) just for those.
> And suddenly you need some kind of runtime too.
Yes, which I mentioned a number of times. However, I don't think it's unreasonable to afford reference counting the same conveniences that tracing has when you want to talk about performance; otherwise you're not really comparing reference counting to tracing, but naive reference counting to highly optimized tracing. The fact that tracing essentially requires a runtime is certainly a point against it in some contexts (though conservative GCs like Boehm perform surprisingly well, they are usually no match for anything with precise liveness information), but I think people are a bit too conditioned to believe that things like stack maps have to be used for tracing--especially when features like exceptions and destructors that people consider acceptable in languages with small runtimes require similar metadata.
Earlier quoted context omitted.
I think a lack of value types also hurts Java significantly here. Though I believe they're also on the roadmap.
Can you please elaborate?
* I think Java has escape analysis, which means that if it can determine that an object you created doesn't leave its context, it will go on the stack and won't add work for the garbage collector.
Earlier quoted context omitted.
I wonder if that would make java more suitable to game development since pauses need to be <8ms, ideally.
I think a lack of value types also hurts Java significantly here. Though I believe they're also on the roadmap.