[concurrency-interest] Array allocation and access on the JVM

Nathan Reynolds nathan.reynolds at oracle.com
Fri Jan 27 12:06:33 EST 2012


I am not sure.  I think the concurrent version requires a branch to 
first check if the card is marked and if not then set it.  Branches are 
very expensive on some platforms.  I think the non-concurrent version 
simply sets the card every time.

The contention comes from every core trying to put the cache line in the 
exclusive state so that the write can happen.  On uni-core uni-socket 
machines there is no point to adding the branch.  On uni-socket machines 
there may not be a point to adding the branch.  That would require 
testing.  On multi-socket multi-core machines, adding the branch reduces 
contention but decreases performance.  If there is no contention to 
reduce, then we just get decreased performance.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology

On 1/27/2012 9:44 AM, Ismael Juma wrote:
> On Fri, Jan 27, 2012 at 4:29 PM, Nathan Reynolds 
> <nathan.reynolds at oracle.com <mailto:nathan.reynolds at oracle.com>> wrote:
>
>     Making the card table concurrent for these workloads would slow
>     them down.
>
>
> Are there measurements for the slowdown experienced in these cases?
>
> Best,
> Ismael
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120127/e34cb5c6/attachment-0001.html>


More information about the Concurrency-interest mailing list