Re: Question: "Garbage-Free" AbstractFilter#filter(...) methods.

[Remko Popma]

Garbage free is mostly about predictable latency. 

In my work we create trading applications that send orders to the stock 
exchange when market conditions change. If the JVM would decide to stop the 
world to collect garbage, we might not get the orders sent out in time. 

Our whole stack (messaging, persistence, business logic) is garbage free. We 
log a lot, to ensure visibility on what the application is doing, and for fast 
troubleshooting. Log4j being garbage free is essential to our success.



> On Mar 2, 2025, at 9:55, Jeff Thomas  wrote:
> 
> Hello Dev Team,
> 
> I am a totally fresh "committer" so forgive me if I ask a silly question.
> 
> I got into a discussion with Piotr about the Log4j Filters and the overloaded 
> filter methods (14 in total) and asked if the extra API is necessary when 
> there is a varargs "filter(, final Object ... params)" method.  
> 
> He explained that this the "garbage-free" approach, and that it avoids the 
> creation of the temporary varargs object array.
> 
> I noticed however that all but one of the MessageFactory2 implementations 
> (ReusableMessageFactory) ultimately calls some varargs method anyways at the 
> tail end of the call chain.
> 
> I asked if the situation hasn't changed since Log4j 3.x targets JDK 17 and 
> there have been major improvements in garbage-collection.  Ultimately this is 
> *a lot* of boilerplate code since all are implemented in every concrete 
> Filter implementation.
> 
> Piotr suggested I ask on this mailing list what the general opinion is.
> 
> A few comments from our discussion:
> * "Garbage-free semantics were important for the financial industry 10 years 
> ago. I am not sure if they still are."
> * "the size of those methods considerably bloats log4j-api"
> * "We recently revamped the performance page: 
> Profiting from the occasion we added warnings that "async" and "garbage-free" 
> doesn't necessarily mean better performance"
> * "Garbage-free" does not mean less memory consumption. Users ask: 'I enabled 
> garbage-free mode, how come I have 200 MiB more memory usage?''"
> * "a performance specialist at Amazon) told us that memory allocation is 
> painfully slow on AWS Graviton CPUs, so garbage-free is nice there." (I found 
> this 2022 article about this: 
> https://aws.amazon.com/blogs/big-data/understanding-the-jvmmemorypressure-metric-changes-in-amazon-opensearch-service/)
> * "We all have the same question."
> 
> Thoughts?
> 
> Best regards,
> Jeff Thomas
> 
> Note: I also had a discussion with my AI tool ***which never makes 
> mistakes*** 🤐and it argued the following:
> 
> Historical Importance of Garbage-Free Semantics:
> * 10+ years ago, the financial industry and other performance-critical fields 
> (e.g., gaming, telemetry, high-frequency trading) placed significant emphasis 
> on garbage-free semantics because older garbage collectors (like CMS) 
> struggled to deal with short-lived allocations efficiently.
> * For example, creating Object[] allocations for each log event could 
> overwhelm the GC in high-throughput applications, leading to unpredictable 
> pauses.
> * The focus back then was mitigating GC pressure by avoiding temporary 
> garbage altogether in performance-critical paths.
> 
> Today:
> * Modern GCs (e.g., G1GC, ZGC, Shenandoah) have evolved significantly to 
> handle short-lived garbage extremely efficiently, as it resides in the "Young 
> Generation" and is quickly reclaimed.
> * Garbage-free semantics usually don't improve latency or throughput 
> significantly anymore unless the application is running in a very specialized 
> environment (e.g., AWS Graviton CPUs with slower allocation mechanics) or has 
> custom performance constraints.
> 
> Bottom Line:
> * The importance of garbage-free semantics has diminished in most 
> applications, especially for typical logging use cases, but specific 
> environments (e.g., AWS Graviton or highly latency-sensitive systems) may 
> still care deeply.

Re: How to unsubscribe (was: New committer: Jeff Thomas)

[Carol Brickley]

thanx

From: Piotr P. Karwasz 
Sent: 01 March 2025 12:27
To: dev@logging.apache.org ; Carol Brickley 

Subject: How to unsubscribe (was: New committer: Jeff Thomas)

Hi Carol,

On 1.03.2025 10:56, Carol Brickley wrote:
> Pleas unsubscribe me

To unsubscribe, you need to follow a similar process as the one you used
to subscribe: send an e-mail to dev-unsubscr...@logging.apache.org and
follow the instruction the bot will send you. For more information see:

https://www.apache.org/foundation/mailinglists

Tip: if you ever forget these special addresses, they are contained in
the headers of every mailing list e-mail:

List-Help: 
List-Unsubscribe: 
List-Post: 

Piotr

Question: "Garbage-Free" AbstractFilter#filter(...) methods.

[Jeff Thomas]

Hello Dev Team,

I am a totally fresh "committer" so forgive me if I ask a silly question.

I got into a discussion with Piotr about the Log4j Filters and the overloaded 
filter methods (14 in total) and asked if the extra API is necessary when there 
is a varargs "filter(, final Object ... params)" method.  

He explained that this the "garbage-free" approach, and that it avoids the 
creation of the temporary varargs object array.

I noticed however that all but one of the MessageFactory2 implementations 
(ReusableMessageFactory) ultimately calls some varargs method anyways at the 
tail end of the call chain.

I asked if the situation hasn't changed since Log4j 3.x targets JDK 17 and 
there have been major improvements in garbage-collection.  Ultimately this is 
*a lot* of boilerplate code since all are implemented in every concrete Filter 
implementation.

Piotr suggested I ask on this mailing list what the general opinion is.

A few comments from our discussion:
* "Garbage-free semantics were important for the financial industry 10 years 
ago. I am not sure if they still are."
* "the size of those methods considerably bloats log4j-api"
* "We recently revamped the performance page: 
Profiting from the occasion we added warnings that "async" and "garbage-free" 
doesn't necessarily mean better performance"
* "Garbage-free" does not mean less memory consumption. Users ask: 'I enabled 
garbage-free mode, how come I have 200 MiB more memory usage?''"
* "a performance specialist at Amazon) told us that memory allocation is 
painfully slow on AWS Graviton CPUs, so garbage-free is nice there." (I found 
this 2022 article about this: 
https://aws.amazon.com/blogs/big-data/understanding-the-jvmmemorypressure-metric-changes-in-amazon-opensearch-service/)
* "We all have the same question."

Thoughts?

Best regards,
Jeff Thomas

Note: I also had a discussion with my AI tool ***which never makes mistakes*** 
🤐and it argued the following:

Historical Importance of Garbage-Free Semantics:
* 10+ years ago, the financial industry and other performance-critical fields 
(e.g., gaming, telemetry, high-frequency trading) placed significant emphasis 
on garbage-free semantics because older garbage collectors (like CMS) struggled 
to deal with short-lived allocations efficiently.
* For example, creating Object[] allocations for each log event could overwhelm 
the GC in high-throughput applications, leading to unpredictable pauses.
* The focus back then was mitigating GC pressure by avoiding temporary garbage 
altogether in performance-critical paths.

Today:
* Modern GCs (e.g., G1GC, ZGC, Shenandoah) have evolved significantly to handle 
short-lived garbage extremely efficiently, as it resides in the "Young 
Generation" and is quickly reclaimed.
* Garbage-free semantics usually don't improve latency or throughput 
significantly anymore unless the application is running in a very specialized 
environment (e.g., AWS Graviton CPUs with slower allocation mechanics) or has 
custom performance constraints.

Bottom Line:
* The importance of garbage-free semantics has diminished in most applications, 
especially for typical logging use cases, but specific environments (e.g., AWS 
Graviton or highly latency-sensitive systems) may still care deeply.

Re: New committer: Jeff Thomas

[Carol Brickley]

Hi

Pleas unsubscribe me

Thanks

Carol

From: Jan Friedrich 
Sent: 26 February 2025 21:59
To: Apache Logging Developers List 
Subject: Re: New committer: Jeff Thomas

Hi Jeff,

Congratulations on becoming a committer for Apache Logging!
It’s great to see you take on this new role, and I'm looking forward to your 
contributions to the project.

Welcome to the team!

Jan

Wednesday, February 26, 2025, 8:25:46 PM, you wrote:

> Welcome aboard Jeff!

> Gary


> On Wed, Feb 26, 2025, 14:02 Piotr P. Karwasz 
> wrote:

>> The Project Management Committee (PMC) for Apache Logging
>> has invited Jeff Thomas to become a committer and we are pleased
>> to announce that he has accepted.
>>
>> Please join us in welcoming Jeff to their new role and
>> responsibility in our project community.
>>
>> Welcome to Apache Logging, Jeff!
>>
>> Piotr
>> On behalf of the Apache Logging PMC
>>
>>

How to unsubscribe (was: New committer: Jeff Thomas)

[Piotr P. Karwasz]

Hi Carol,

On 1.03.2025 10:56, Carol Brickley wrote:

Pleas unsubscribe me


To unsubscribe, you need to follow a similar process as the one you used 
to subscribe: send an e-mail to dev-unsubscr...@logging.apache.org and 
follow the instruction the bot will send you. For more information see:


https://www.apache.org/foundation/mailinglists

Tip: if you ever forget these special addresses, they are contained in 
the headers of every mailing list e-mail:


List-Help: 
List-Unsubscribe: 
List-Post: 

Piotr