Add RestoringWeakReference #1357

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
3 participants
Owner

Shadowfiend commented Nov 9, 2012

RestoringWeakReference contains a scala.ref.WeakReference that,
after it has been nulled out, uses a restorer function to restore
the value. This can be used for data that can afford to be evicted
by the garbage collector, but will be needed later. One good example
is Lift form callbacks, which may need the value of an object, but
where you don't necessarily want to be retaining the object
indefinitely while someone is on a page in the face of GC contention.

Examples are in the doc header.

@Shadowfiend Shadowfiend Add RestoringWeakReference to utils.
RestoringWeakReference contains a scala.ref.WeakReference that, after it
has been nulled out, uses a restorer function to restore the value.
This can be used for data that can afford to be evicted by the garbage
collector, but will be needed later. One good example is Lift form
callbacks, which may need the value of an object, but where you don't
necessarily want to be retaining the object indefinitely while someone
is on a page in the face of GC contention.
5833892
Owner

Shadowfiend commented Nov 9, 2012

We've used this class to great effect at OpenStudy to manage GC overhead from closure object retention.

Owner

fmpwizard commented on 5833892 Nov 9, 2012

Thanks for adding this, any chance to get a spec test with the pull req?

Contributor

nafg replied Nov 12, 2012

Looks nice.
It might be more in line with scala conventions to rename value to apply. Then you would write ref() instead of ref.value.

P.S. Would you you mind to fix the indentation?
Thanks.

Owner

Shadowfiend replied Nov 12, 2012

Wow. No idea what happened to the indentation there. I'll definitely fix that.

As for apply vs value… Let me ponder that one for a bit.

Owner

Shadowfiend replied Nov 12, 2012

Indeed, looks like WeakReference uses apply, no reason why we shouldn't do the same. Pushed that change to master.

Shadowfiend was assigned Nov 9, 2012

Owner

Shadowfiend commented Nov 9, 2012

So, I'm not sure that's the greatest idea, as I don't know what effect it'll have on the test suite. The only real way to test something like this is to force a WeakReference's eviction. And the only semi-reliable way to do that (that I've found) is to basically create objects until you get an OutOfMemory exception, which you then catch, and allow those objects to go out of scope after the try/catch. It's a bit of a pain, definitely a hack, and may or may not hose the rest of the suite when it runs.

Owner

fmpwizard commented Nov 9, 2012

yes, I thought that adding a spec test for it would prove a challenge( well, this is more like, it will messed with all the other tests), so I guess it is ok not to have a test here, we do have plenty of scaladoc explaining it, so that's great, thanks!

Owner

fmpwizard commented Nov 10, 2012

rebased to master

fmpwizard closed this Nov 10, 2012

Shadowfiend deleted the asc_issue_1357 branch Mar 1, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment