[logback-dev] [JIRA] Commented: (LBCORE-97) Starvation on AppenderBase.doAppend

Joern Huxhorn jhuxhorn at googlemail.com
Thu Jun 4 21:09:20 CEST 2009

Maarten Bosteels wrote:
> Hello all,
> While I have not tested any of the scenario's described above, I think the
> remarks from Ralph make a lot of sense.
> And I am also interested in knowing the impact on throughput of using fair
> locks.
> When the fairness of non-fair locks has changed so drastically with 1.6, I
> would guess that more people would suffer from it, no ?
> Logback is certainly not the only code using non-fair locks.
> I googled a bit about "java 1.6 starvation" but nothing really alarming came
> up.
> regards,
> Maarten

I just googled for "java synchronized fairness" and the first two links
that came up were

I've also found the following PDF:
See page 12:
Fairness vs throughput
> Optimized for system-wide throughput at the expensive
of short-term thread-specific fairness
> Succession policy: try to wake recently run threads
> Improved $ and TLB utilization

TLB means http://en.wikipedia.org/wiki/Translation_lookaside_buffer

This post from the author of the PDF is quite technical but on the
topic: http://blogs.sun.com/dave/entry/biased_locking_in_hotspot

So it is a performance enhancement as I guessed. I highly doubt that
this will be reverted. I'd more or less expect the other implementations
to follow.
After all, this is *not* a bug at all. This behavior, while obviously
being extreme, is absolutely in conformance with all documentation.
So if it doesn't breach the documentation contract and means a
worthwhile performance increase: why switch it back?


More information about the logback-dev mailing list