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...
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
On 07/24/2012 07:15 PM, Christian Thalinger wrote:
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
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.
+
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,
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
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
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
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:
On Jul 18, 2012, at 1:43 AM, Aleksey Shipilev wrote:
This feels outright wrong:
+static MapString, Data CACHE = new IdentityHashMap();
I couple of questions pops out in my mind:
1. Is this code supposed to be thread-safe? It is then wrong to use
unguarded IdentityHashMap without
(sorry for not replying to original message, just subscribed)
This feels outright wrong:
+static MapString, Data CACHE = new IdentityHashMap();
+
+static Data get(String types) {
+final String key = types.intern();
+Data d = CACHE.get(key);
+if
On Fri, Jul 13, 2012 at 5:41 AM, John Rose john.r.r...@oracle.com wrote:
On Jul 11, 2012, at 5:53 PM, John Rose wrote:
As some of you have noticed, Chris Thalinger, Michael Haupt, and I have been
working on the mlvm patches [1] for JEP-160 [2] for several months. These
changes make method
On 07/14/2012 02:02 PM, David Schlosnagle wrote:
On Fri, Jul 13, 2012 at 5:41 AM, John Rose john.r.r...@oracle.com
wrote:
On Jul 11, 2012, at 5:53 PM, John Rose wrote:
As some of you have noticed, Chris Thalinger, Michael Haupt, and I
have been working on the mlvm patches [1] for JEP-160
BoundMethodHandle.java:
I am concern that BMH subclass names are looks like constants names:
BMH_LLI.
In several places you have BMH constants and variables:
+ final ClassBoundMethodHandle BMH = BoundMethodHandle.class;
+ static final String BMH = java/lang/invoke/BoundMethodHandle;
14 matches
Mail list logo
