Hacker News Reader

Comment by TheLoneWolfling | Hacker News Reader

So, I have to wonder. If I as a random nobody have been affected adversely by this change (Parser that now takes >10x the time), what business applications have been affected by this?

And I have a question: why could it not be done like this:

Java currently has weak references, soft references, and phantom references. If there was an additional type of weak-like reference, that had a callback with an object before it was garbage collected, this conundrum would be simple. Have any substrings have a weak-like reference to the character array. If the parent string is garbage-collected, then do the copying like the new behavior, but until then don't: use the old behavior.

View on HN

> If there was an additional type of weak-like reference, that had a callback with an object before it was garbage collected, this conundrum would be simple.

You've basically described weak references to objects with finalizers. Unfortunately, I'd wager this is even more expensive, not less.

No, TheLoneWolfling's idea can't be implemented with weak references with finalizers. Firstly, finalizers only run after weak references are cleared (i think - please correct me if i'm wrong!). Secondly, he needs GC to trigger code that mutates the no-longer-referring object; the finalizer runs in the no-longer-referred-to object.

He's right that a new VM-level hook would be required to implement his idea. The benefits don't clearly justify making a change of that magnitude.

Depends. I'm imagining e.g. your large parent string invasively giving it's sub-slices copies on finalization through it's own list, in which case the weak references clearing isn't much of an issue. Not easy to make fast and thread safe however.

In C#, WeakReference can take a boolean parameter during construction to specify if it tracks post-finalize or not (defaulting to the same behavior as Java which google tells me is as you say: not), and you can re-register your finalizer, but even so this kind of thing isn't what the GC is primarily designed for and it will probably show. I'm not sure if you can re-register finalizers in Java.

Finalisers run before weak references are cleared. You do, however, have the GC cost of having a finalized.

If you have such callback that means your code can block a GC thread, which then affects the GC pacing params. I think it will be quite difficult to design such feature in a robust manner. You will definitely need some new internal flags on objects that are pending the callback and possibly extra locks around them. New threadpool just for that callback, blocking timeouts, lock coordination with all GC algorithms.

Your idea would make it easy to add an unacceptable amount of overhead to GC. Since GC is already the biggest performance killer on the JVM, I don't think it makes sense to give developers this particular loaded gun to shoot themselves in the foot with.

GC is probably the biggest performance killer of most if not all managed languages (i.e. where you can't explicitly free memory).

And Java probably has the best GC algos out there.

I dunno, can you build a special kind of CharSequence which works like the old String did?

Speaking of CharSequence, one sneaky and bizarre option would be to make String's implementation of CharSequence::subSequence work the old way. subSequence returns a CharSequence, not a String, so it is free to return some specialised object which specifically represents a substring rather than a first-class string. Rather like slices in go, which would win Java some trendiness points.

This would be a surprising bit of behaviour, which means it's probably a bad idea. However, it wouldn't break any current code, because it preserves current behaviour, and hopefully wouldn't break future code, because people could learn about the quirk. Also, i think subSequence tends to be used to create temporary objects as computational intermediaries, rather than new long-lived objects which escape to the heap, so it shouldn't lead to excessive packratting in the way the old-style substring did.

Okay, so of course they considered this, and decided it was a bad move:

http://www.reddit.com/r/programming/comments/1qw73v/til_orac...

Reply on news.ycombinator.com