On 11/12/2014 07:27 PM, David Chase wrote:
Hello Peter,
Sadly, this seems not to be the case for MemberNames or for “Types”.
That statement is inoperative. Mistakes were made.
It’s compareTo that they lack.
Yes, I say your quite tricky implementation of MemberName.compareTo,
based on
Hello Peter,
I was looking at this (thinking it would be a useful thing to benchmark,
looking for possible improvements)
and noticed that you rely on the hashed objects having a sensible
value-dependent hashcode (as opposed
to the default Object hashcode). Sadly, this seems not to be the case
Hello Peter,
Sadly, this seems not to be the case for MemberNames or for “Types”.
That statement is inoperative. Mistakes were made.
It’s compareTo that they lack.
David
On 2014-11-09, at 7:55 AM, Peter Levart peter.lev...@gmail.com wrote:
Hi David,
I played a little with the idea of
On 2014-11-08, at 10:07 AM, Peter Levart peter.lev...@gmail.com wrote:
Now let's take for example one of the MemberName.make() methods that return
interned MemberNames:
206 public static MemberName make(Method m, boolean wantSpecial) {
207 // Unreflected member names are
On 11/11/2014 07:58 PM, David Chase wrote:
I’ve incorporated your other changes (not yet the linear-scan hash table) and
will be retesting.
One thing I wonder about for both hash table and binary search is if the first
try should be attempted with no lock to avoid the overhead of
Hi David,
I played a little with the idea of having a hash table instead of packed
sorted array for interning. Using ConcurrentHashMap would present quite
some memory overhead. A more compact representation is possible in the
form of a linear-scan hash table where elements of array are
Hi David,
As previously, I feel competent to comment only the Java side of the patch.
Using linked list to publish to VM is a safer and easier way for the
desired purpose and using a separate data structure for interning makes
it easier to change it in the future should need arise. That need
On 11/03/2014 09:41 PM, David Chase wrote:
On 2014-11-03, at 3:09 PM, Peter Levart peter.lev...@gmail.com wrote:
Hi David,
I was thinking about the fact that java.lang.invoke code is leaking into
java.lang.Class. Perhaps, If you don't mind rewriting the code, a better code
structure would
On 2014-11-04, at 5:07 AM, Peter Levart peter.lev...@gmail.com wrote:
Are you thinking of an IdentityHashMap type of hash table (no linked-list of
elements for same bucket, just search for 1st free slot on insert)? The
problem would be how to pre-size the array. Count declared members?
It
On 11/04/2014 04:19 PM, David Chase wrote:
On 2014-11-04, at 5:07 AM, Peter Levart peter.lev...@gmail.com wrote:
Are you thinking of an IdentityHashMap type of hash table (no linked-list of
elements for same bucket, just search for 1st free slot on insert)? The problem
would be how to
I’m working on the initial benchmarking, and so far this arrangement (with
synchronization
and binary search for lookup, lots of barriers and linear cost insertion) has
not yet been any
slower.
I am nonetheless tempted by the 2-tables solution, because I think the simpler
JVM-side
interface
On 2014-11-02, at 10:49 PM, David Holmes david.hol...@oracle.com wrote:
The change is to load the volatile size for the loop bound; this stops the
stores
in the loop from moving earlier, right?
Treating volatile accesses like memory barriers is playing a bit
fast-and-loose with the
On 11/03/2014 01:49 PM, David Chase wrote:
On 2014-11-02, at 10:49 PM, David Holmes david.hol...@oracle.com wrote:
The change is to load the volatile size for the loop bound; this stops the
stores
in the loop from moving earlier, right?
Treating volatile accesses like memory barriers is
My main concern is that the compiler is inhibited from any peculiar code
motion; I assume that taking a safe point has a bit of barrier built into it
anyway, especially given that the worry case is safepoint + JVMTI.
Given the worry, what’s the best way to spell “barrier” here?
I could
On 11/03/2014 05:16 PM, Peter Levart wrote:
On 11/03/2014 01:49 PM, David Chase wrote:
On 2014-11-02, at 10:49 PM, David Holmes david.hol...@oracle.com
wrote:
The change is to load the volatile size for the loop bound; this
stops the stores
in the loop from moving earlier, right?
Treating
On 2014-11-03, at 11:42 AM, Peter Levart peter.lev...@gmail.com wrote:
You're worried that writes moving array elements up for one slot would
bubble up before write of size = size+1, right? If that happens, VM could
skip an existing (last) element and not update it.
It seems that
Hi David,
I was thinking about the fact that java.lang.invoke code is leaking into
java.lang.Class. Perhaps, If you don't mind rewriting the code, a better
code structure would be, if j.l.Class changes only consisted of adding a
simple:
+ // A reference to canonicalizing cache of
On 2014-11-03, at 3:09 PM, Peter Levart peter.lev...@gmail.com wrote:
Hi David,
I was thinking about the fact that java.lang.invoke code is leaking into
java.lang.Class. Perhaps, If you don't mind rewriting the code, a better code
structure would be, if j.l.Class changes only consisted
On Nov 3, 2014, at 12:41 PM, David Chase david.r.ch...@oracle.com wrote:
On 2014-11-03, at 3:09 PM, Peter Levart peter.lev...@gmail.com wrote:
Hi David,
I was thinking about the fact that java.lang.invoke code is leaking into
java.lang.Class. Perhaps, If you don't mind rewriting the
19 matches
Mail list logo
