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. 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
