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

[Joern Huxhorn]

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
http://tutorials.jenkov.com/java-concurrency/starvation-and-fairness.html
and
http://tutorials.jenkov.com/java-concurrency/locks.html

I've also found the following PDF:
http://home.comcast.net/~pjbishop/Dave/MustangSync.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?

Regards,
Joern.