Expunge stale entries in `InternalLoggerRegistry`

[vy]

InternalLoggerRegistry is essentially a Map<MessageFactory, Map<String, WeakReference<Logger>>>. As reported by @tristantarrant in #3399, stale entries are not expunged in its current form. That is, the inner map does not get compacted for entries whose associated WeakReferences are reclaimed by the garbage collector. This might cause high memory usage if an excessive amount of ephemeral loggers get registered.

Reclaimed references can be tracked by a ReferenceQueue passed to the WeakReference::new and processed as follows:

private final ReferenceQueue<Logger> staleLoggerRefs = new ReferenceQueue<>();

private void expungeStaleEntries() {
    Reference<? extends Logger> loggerRef;
    while ((loggerRef = staleLoggerRefs.poll()) != null) {
        Logger logger = loggerRef.get();
        if (logger != null) {
            removeLogger(logger);
        }
    }
}

When to run expungeStaleEntries() should be decided with care, since removeLogger() mutates the registry map.

On method invocation

All ILR methods (getLogger(), computeIfAbsent(), etc.) can first try to expunge stale entries.
This approach is exercised by WeakHashMap itself and in #3427.

Pros:

• Implies no changes besides ILR

Cons:

• Read-only operations, which are accessed most, might try to acquire the write-lock.
• If ILR is not accessed, stale entries will still be kept. Consider an application where all Loggers are assigned, and a temporary operation creates excessive amount of loggers and completes. All created temporary Logger instances will be reclaimed by GC, yet will continue taking space for the associated Map.Entry<String, WeakReference<Logger>>.

By a janitor thread

ILR can start a janitor thread listening on the ReferenceQueue<Logger>.

Cons:

• ILR must have a life cycle (to start/stop the janitor thread) managed by LoggerContext.

[Suvrat1629]

Hi, I'd like to work on this issue. My approach was using a ReferenceQueue to track stale WeakReference entries and expunge them before operations like getLogger() and computeIfAbsent(). Does this approach sit right?

[vy]

I'd like to work on this issue. My approach was using a ReferenceQueue to track stale WeakReference entries and expunge them before operations like getLogger() and computeIfAbsent(). Does this approach sit right?

@Suvrat1629, certainly – this is the "On method invocation" approach I described in the ticket. Please try to keep your changes at minimum. Even though it will be difficult, please try to add tests.

[Suvrat1629]

@vy I will try my best with the test cases but where do I put the test case file? And is there any example I can refer to?

[vy]

I will try my best with the test cases but where do I put the test case file? And is there any example I can refer to?

@Suvrat1629, try searching for InternalLoggerRegistry tests first, please. Once you've found it, you can create an extra test (e.g., InternalLoggerRegistryGcTest) next to it.

[jhl221123]

Hi @vy,

I've taken a look at issue #3430 and PR #3474.

If @Suvrat1629 is not currently working on this, I would be interested in contributing to move it forward.

Please let me know if I could try to contribute to this.

Thanks!

[vy]

@jhl221123, please go ahead.

[ppkarwasz]

@jhl221123,

Thanks for your interest in continuing this work!

While we can’t grant you direct access to @Suvrat1629’s PR, you can absolutely pick up where he left off by creating your own branch from his work. Please note that we now require all commits to be GPG-signed, so you’ll need to rebase the branch and sign the commits with your key.

# Fetch the latest commits from Suvrat's branch
git fetch git@github.com:Suvrat1629/logging-log4j2.git expunge-stale-entries

# Create a new local branch from the fetched work
git checkout -b feat/expunge-stale-entries FETCH_HEAD

# Rebase onto the current base branch and sign all commits with your GPG key
git rebase --gpg-sign origin/2.x

Let us know if you run into any issues—we’re happy to help!

[jhl221123]

@ppkarwasz,

Thanks a lot for the kind and detailed guidance! I'll proceed as you suggested.