I support reluctance in fixing performance. AFAIK, no performance
change should be done without demonstrating incerase on real loads.
2009/11/13 Tim Ellison t.p.elli...@gmail.com:
On 12/Nov/2009 19:20, Vijay Menon wrote:
Right, writes - even unsynchronized ones - to the same cache line are
On 12/Nov/2009 19:20, Vijay Menon wrote:
Right, writes - even unsynchronized ones - to the same cache line are
problematic. Here's a good quick read on this:
http://en.wikipedia.org/wiki/MESI_protocol. Recent Intel architectures
adapt this protocol. Here's the interesting bit:
A write
On 09/Nov/2009 17:05, Vijay Menon wrote:
Perhaps a dumb question - but is there a really a performance issue with
always using a stack-local localBuf and removing the shared static? The
code is simpler, and memory allocation is usually a fast operation.
The code below does look semantically
Tim,
AFAIU, this is a second level effect. By themselves unsynchronized
writes are quick and parallel. But.
The processor cache line which corresponds to the common buffer is
always invalidated. This means that the common bus is constantly
stressed with synchronization. My friend Alexei Shipilev
Right, writes - even unsynchronized ones - to the same cache line are
problematic. Here's a good quick read on this:
http://en.wikipedia.org/wiki/MESI_protocol. Recent Intel architectures
adapt this protocol. Here's the interesting bit:
A write may only be performed if the cache line is in the
On 05/Nov/2009 20:43, Alexei Fedotov wrote:
I enjoyed the simple, but neat optimization. Let me question if the
enlarged buffer should be stored at skipBuf.
1. Escaping reference always causes optimization problems. A
reasonable JIT can drop a local array allocation if it is possible to
Perhaps a dumb question - but is there a really a performance issue with
always using a stack-local localBuf and removing the shared static? The
code is simpler, and memory allocation is usually a fast operation.
The code below does look semantically safe, but there is a potential
performance
I enjoyed the simple, but neat optimization. Let me question if the
enlarged buffer should be stored at skipBuf.
1. Escaping reference always causes optimization problems. A
reasonable JIT can drop a local array allocation if it is possible to
de-virtualize the call and see that the array is
Could somebody please take a look a the patch below and see if they
believe my explanation for why it fixes a findbugs problem in InputStream?
The problem: We have a static, skipBuf, that we only use to read junk
data from the stream when skipping a number of bytes. The static is
lazily
On Thu, Oct 1, 2009 at 7:19 AM, Tim Ellison t.p.elli...@gmail.com wrote:
Could somebody please take a look a the patch below and see if they
believe my explanation for why it fixes a findbugs problem in InputStream?
Looks good to me.
Yes, this should fix the concurrency problem.
Tim Ellison wrote:
Could somebody please take a look a the patch below and see if they
believe my explanation for why it fixes a findbugs problem in InputStream?
The problem: We have a static, skipBuf, that we only use to read junk
data from the stream when skipping a number of bytes. The
Thanks guys, fixed at r820776.
Regards,
Tim
On 01/Oct/2009 18:11, Oliver Deakin wrote:
Tim Ellison wrote:
Could somebody please take a look a the patch below and see if they
believe my explanation for why it fixes a findbugs problem in
InputStream?
The problem: We have a static, skipBuf,
12 matches
Mail list logo
