[
https://issues.apache.org/jira/browse/KAFKA-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15059436#comment-15059436
]
Ismael Juma commented on KAFKA-2992:
------------------------------------
Thanks for the reference Grant, I was planning to link to KAFKA-2285 once I had
access to a computer.
With regards to SI-4767, I've been tracking that for a really long time and
it's great that it was fixed. Sadly, we won't benefit for quite a while still
since it was only implemented in the new compiler back-end (GenBCode) which is
experimental in 2.11.x (an experimental optimisation would be less risky than
an experimental back-end with a new optimisation). In any case, 2.12 will be
out in the middle of next year and it will be an interesting release.
> Trace log statements in the replica fetcher inner loop create large amounts
> of garbage
> --------------------------------------------------------------------------------------
>
> Key: KAFKA-2992
> URL: https://issues.apache.org/jira/browse/KAFKA-2992
> Project: Kafka
> Issue Type: Improvement
> Components: core
> Affects Versions: 0.8.2.1, 0.9.0.0
> Environment: Centos 6, Java 1.8.0_20
> Reporter: Cory Kolbeck
> Priority: Minor
> Labels: garbage, logging, trace
> Fix For: 0.9.1.0
>
>
> We're seeing some GC pause issues in production, and during our investigation
> found that the thunks created during invocation of three trace statements
> guarded in the attached PR were responsible for ~98% of all allocations by
> object count and ~90% by size. While I'm not sure that this was actually the
> cause of our issue, it seems prudent to avoid useless allocations in a tight
> loop.
> I realize that the trace() call does its own guarding internally, however
> it's insufficient to prevent allocation of the thunk. I can work on getting
> profiling results to attach here, but I used YourKit and the license has
> since expired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
