Refresh LogstashBasicMarker implementation and remove synchronisation

[brenuart]

fixes #613

[brenuart]

Also fixes #616

[philsttr]

I realize this is coming from slf4j-api's implementation, but this seems like a step in the wrong direction, since it will result in a lot of unused lists being allocated.

If markers and/or structured args are used heavily by an application, this will have an impact on memory usage and garbage collection.

The previous logic of deferring list creation until a reference is added seems better from a memory and garbage collection standpoint.

Having said that, I don't have exact numbers to back these claims up, so probably better to go with slf4j-api's implementation until proven otherwise.

[brenuart]

I agree with you... creating the list lazily would be better. However, this makes supporting concurrent accesses without synchronisation far less easier...

AFAIK people are not supposed to create many markers - hence the MarkerFactory caching previously created markers. Is it still true with Logstash?

[philsttr]

LogstashBasicMarker is the superclass of all of the markers and structured argument implementations provided by logstash-logback-encoder. Caching is not used for any of these. So, for example, a marker (with an unused list) will be created every time this log line is executed.

logger.info("Foo {}", StructuredArguments.keyValue("bar", "baz"));

If that line is executed frequently, it'll create a lot of unused list garbage.

slf4j-api can cache the markers it creates, since those markers are simple string values, so they are easily cachable.

In any case, I understand the synchronization problems being addressed, so we can leave it as is. It's prioritizing performance over memory usage. Classic tradeoff.

[brenuart]

I understand the synchronization problems being addressed, so we can leave it as is. It's prioritizing performance over memory usage

But I'm also fighting against excessive memory allocations ;-)
The key point is whether LogstashBasicMarker must be thread-safe or not... IMHO, markers are not shared/mutated by multiple threads in most scenarios.

[brenuart]

@philsttr I'm tempted to "drop" the thread-safe nature of the marker... certainly if we consider what has been said in #613 (comment)

[brenuart]

@philsttr Back on the referenceList again... The overhead of creating the COW list up-front is:

• a zero-size object array
• a ReentrantLock

Not much - but still too much if we consider that most LogstashMarkers won't have any children/references. BTW, what would be the use case? Can't we simply drop support for references and make the relevant methods "not implemented" ?

Alternatives:

(1) make it 'not thread-safe'. Start with a null reference list and lazy initialise it with a standard ArrayList when needed. Behaviour becomes unexpected if the Marker is accessed from multiple threads concurrently. Note that a COW list won't probably make multi-threaded usage more predictable: a first call to hasReferences() may return true but the list may be empty when you start iterating over it if another thread removed the elements in the meantime.

(2) keep it "thread-safe" but use an AtomicReference to hold the COW list. The overhead when no reference is ever added to the marker is limited to this atomic reference which is cheaper than the empty COW itself.

What's your opinion?

[philsttr]

BTW, what would be the use case? Can't we simply drop support for references and make the relevant methods "not implemented" ?

Unfortunately not, since the slf4j-api Logger methods only accept a single Marker argument. Support for multiple markers is implemented by having markers reference others.

Regarding thread-safety. I would rather keep it threadsafe. Another option (3).... similar to (2) but instead of using an AtomicReference, we could use a volatile field accessed via a static AtomicReferenceFieldUpdater. This prevents memory overhead of creating a lot of AtomicReference instances, at the expense of slightly slower access time and slightly more complex code.