Neuter ReferenceCache

[limpb...@gmail.com]

I've prepared a change that strips out our dear friend,
FinalizableReferenceQueue. This limits ReferenceCache to
STRONG,STRONG.

Benefits: no extra thread, so our redepoy in Java EE leakiness goes
away. Also good for Java-like environments where starting threads is
forbidden.

Drawbacks: the caches in BytecodeGen (classloaders) and
StackTraceElements are a bit uglier. For example, a WeakHashMap<Class<?
>,SoftReference<LineNumbers>> is now used instead.

Despite the ugliness, I figure I'll check this in as it makes an ugly
problem go away for our users. Let me know if you've got any
reservations, I could go either way on this one.

[limpb...@gmail.com]

[Bob Lee]

I'm wary of introducing unnecessary synchronization into critical code paths.

I'm pretty sure I can make ReferenceMap not start the thread unless you try to use a weak or soft reference.

Bob

[limpb...@gmail.com]

On Dec 26, 9:34 am, "Bob Lee" <crazy...@crazybob.org> wrote:
> I'm wary of introducing unnecessary synchronization into critical code
> paths.

My patch introduces synchronization only in the two places where we're
using ReferenceCache with non-String references:
- LineNumbers
- BytecodeGen

Both of these only happen at Injector-creation time. We've already set
a precedent that we permit global (ie. static) synchronization at
Injector-creation time in the implementation of Scopes.SINGLETON. So
this code doesn't introduce any real performance degradation.

> I'm pretty sure I can make ReferenceMap not start the thread unless you try
> to use a weak or soft reference.

If you do, we'll still need to avoid ReferenceCache in LineNumbers and
BytecodeGen. So this synchronization doesn't really go away.

I still think this fix is a net-win for our users...