Re: build error on OSX
I think the patch after meth-lazy needs rebasing. Just comment it out in the series file for now. how could I comment it ? ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: build error on OSX
Am Montag, den 23.07.2012, 09:47 +0200 schrieb Henri Gomez: I think the patch after meth-lazy needs rebasing. Just comment it out in the series file for now. how could I comment it ? Edit the series file with a text editor and prefix the line that shows the name of that patch with # . Roman ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: build error on OSX
Edit the series file with a text editor and prefix the line that shows the name of that patch with # . Thanks Roman Since it won't be in phase with mlvm mercurial repo, I should patch it after syncing, right ? ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code
On 07/22/2012 03:45 AM, John Rose wrote:
On Jul 18, 2012, at 1:43 AM, Aleksey Shipilev wrote:
Yes.
Thanks John. I'm having a glance over the fix in new webrev, and this
feels even worse:
+ private static SpeciesData get(String types) {
+// Acquire cache lock for query.
+SpeciesData d = lookupCache(types);
+if (!d.isPlaceholder())
+return d;
+Class? extends BoundMethodHandle cbmh;
+synchronized (d) {
+// Use synch. on the placeholder to prevent multiple
instantiation of one species.
+// Creating this class forces a recursive call to
getForClass.
+cbmh = Factory.generateConcreteBMHClass(types);
+}
+// Reacquire cache lock.
+d = lookupCache(types);
+// Class loading must have upgraded the cache.
+assert(d != null !d.isPlaceholder());
+return d;
+}
+ static SpeciesData getForClass(String types, Class? extends
BoundMethodHandle clazz) {
+// clazz is a new class which is initializing its
SPECIES_DATA field
+return updateCache(types, new SpeciesData(types, clazz));
+}
+ private static synchronized SpeciesData lookupCache(String types) {
+SpeciesData d = CACHE.get(types);
+if (d != null) return d;
+d = new SpeciesData(types);
+assert(d.isPlaceholder());
+CACHE.put(types, d);
+return d;
+}
+ private static synchronized SpeciesData updateCache(String types,
SpeciesData d) {
+SpeciesData d2;
+assert((d2 = CACHE.get(types)) == null || d2.isPlaceholder());
+assert(!d.isPlaceholder());
+CACHE.put(types, d);
+return d;
+}
Global synchronization is the performance smell, and this looks to be
potential scalability bottleneck (it sends shivers down my spine every
time I see static synchronized in the same line. That is not to
mention synchronizing on placeholder looks suspicious and error-prone.
Do you need help rewriting this with CHM?
-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
Re: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code
On 07/22/2012 04:16 AM, John Rose wrote: P.S. If there's something you don't like in one of the files, let us know. As I noted before, we can (and will) roll more adjustments into the next push. I have a question about $PREPARED_FORMS there. It looks like it is not used anywhere in the code, should we eliminate it whatsoever? If not, then I have trouble understanding if we need to explicitly override CHM defaults, especially concurrency level there. (I know Doug pushes back on specialized constructors in CHMv8 because some of the parameters are meaningless there). -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
hg: mlvm/mlvm/hotspot: meth-lazy: fixed 32-bit SPARC C1 problem
Changeset: a8cb0e14256a Author:twisti Date: 2012-07-23 10:12 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a8cb0e14256a meth-lazy: fixed 32-bit SPARC C1 problem ! meth-lazy-7023639.review.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: meth-lazy: consolidate for review
Changeset: b078b2c12089 Author:jrose Date: 2012-07-23 10:36 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b078b2c12089 meth-lazy: consolidate for review ! meth-lazy-7023639.patch - meth-lazy-7023639.review.patch ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/jdk: meth-lazy: consolidate for review
Changeset: 0cd0e35d7fe6 Author:jrose Date: 2012-07-23 10:44 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/0cd0e35d7fe6 meth-lazy: consolidate for review ! meth-lazy-7023639.patch - meth-lazy-7023639.review.patch ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code
John, Both webrevs point to jdk changes. Where are hotspot changes? Vladimir John Rose wrote: On Jul 13, 2012, at 2:41 AM, John Rose wrote: Here is that webrev: http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.00/ These are the changes to JDK code that accompany the JVM changes already under review. I have updated both webrevs to their final contents, as follows: http://cr.openjdk.java.net/~jrose/7023639/webrev.01/ http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.01/ In the same folder are incremental webrevs, for the record. Thanks to all reviewers for their help. — John P.S. If there's something you don't like in one of the files, let us know. As I noted before, we can (and will) roll more adjustments into the next push. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code
On Jul 23, 2012, at 2:27 AM, Aleksey Shipilev wrote: Global synchronization is the performance smell, and this looks to be potential scalability bottleneck (it sends shivers down my spine every time I see static synchronized in the same line. That is not to mention synchronizing on placeholder looks suspicious and error-prone. I believe the code is correct. The purpose is to load as many distinct species of BMH tuples as the application type schema requires. The use of placeholders is patterned after the JVM's internal class loading algorithm. 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. So in this case, static synchronized is the correct choice. Do you need help rewriting this with CHM? No, but thanks for the help! — John___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code
On Jul 23, 2012, at 11:15 AM, Vladimir Kozlov wrote: Both webrevs point to jdk changes. Where are hotspot changes? Oops, fixed. Please try again: http://cr.openjdk.java.net/~jrose/7023639/webrev.01/ http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.01/ — John ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
