I support reluctance in fixing performance. AFAIK, no performance
change should be done without demonstrating incerase on real loads.
2009/11/13 Tim Ellison :
> On 12/Nov/2009 19:20, Vijay Menon wrote:
>> Right, writes - even unsynchronized ones - to the same cache line are
>> problematic. Here's
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 wri
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
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 t
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 semantic
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 iss
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
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 never
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,
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 stat
On Thu, Oct 1, 2009 at 7:19 AM, 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?
>
Looks good to me.
Yes, this should fix the concurrency problem.
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 initiali
12 matches
Mail list logo
