On Jul 24, 2012, at 2:55 AM, Aleksey Shipilev <aleksey.shipi...@oracle.com> wrote:
> On 07/23/2012 10:31 PM, John Rose wrote: >> On Jul 23, 2012, at 2:27 AM, Aleksey Shipilev wrote: >> The code does not need to be scalable, because the number of entries in >> the cache is small (order of 10-100) and scales only with type schema >> complexity, not workload complexity. > > If I had a nickel... > > Not sure if this logic is applicable in this particular case. This is > the potential "performance cliff" you are eager to get rid of with new > implementation. No it's not. We know exactly what causes the performance cliff. It's a completely unrelated issue in the VM. -- Chris > Given enough users and applications make use of this > code, someone will eventually step and burn on this. > > This wishful thinking "it's okay to use synchronized here, because this > couldn't possibly get contended" lead to many beautiful scalability > bottlenecks throughout the JDK. While it is usually a simple thing to > fix, I'm keen on not allowing to make the same mistakes over and over again. > >> So in this case, "static synchronized" is the correct choice. > > I shall wait for mainline integration to complete and then try to run > the microbenchmarks against the new backend; will see if this potential > issue is the practical one. > > -Aleksey. > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
