There's a good chance COWAL access to the array can be optimized as you
suggest using VarHandles.
Write using release; read using acquire, or plain if holding the lock.
Doesn't buy much on x86 but performance improvement should be measurable on
ppc.
On Wed, Apr 24, 2019 at 10:33 PM Frank Yuan wro
Hello!
This enhancement was inspired by a recent discussion at
compiler-...@openjdk.java.net.
It seems to be a non-uncommon situation when String.replace(CS, CS) is
called with this and both arguments being Latin1 strings, so it seems
reasonable to optimize for such case.
Here are the fres
>
> Hi Frank,
> a VarHandle is a glorified integer value that correspond to the number of
> bytes from a pointer to a field address,
> so you give it a reference and you have access to the field at the address:
> reference + shift, given that the shift value is the same for all the
> instances o
> merely to serve as a discussion point about the policy for throwing
> ConcurrentModificationException?
Yes, for the time being, I want to see and welcome more ideas on this. It seems
to me that the policy for throwing CME here is not a unified one, mostly based
on experience and testing. Clea
On 4/24/2019 8:44 PM, Andy Herrick wrote:
Please review changes for [1] which is the implementation bug for
JEP-343.
The webrev at [2] is the total cumulative webrev of changes for the
jpackage tool, currently in the JDK-8200758-branch branch of the open
sandbox repository.
The webrev at
Please review changes for [1] which is the implementation bug for JEP-343.
The webrev at [2] is the total cumulative webrev of changes for the
jpackage tool, currently in the JDK-8200758-branch branch of the open
sandbox repository.
The webrev at [3] shows the changes from EA-05 to EA-06.
T
Hi Patrick,
I guess I'm not sure what you're proposing here. You've updated the patch; are
you proposing that this change be integrated?
Or are you posting code changes, not as a proposal to integrate, but merely to
serve as a discussion point about the policy for throwing
ConcurrentModifica
Hi Adam,
Thanks for finding this bug!
This is a bug in ConcurrentSkipListMap itself, not some test named
ConcurrentSkipListMapTest. I'd suggest changing the bug summary line and the
commit message accordingly.
Thanks,
s'marks
On 4/24/19 9:20 AM, Adam Farley8 wrote:
ConcurrentSkipListMapTe
Adam,
Thanks for finding this. I will be your shepherd.
Normally we make changes to j.u.c. via Doug's CVS.
I also think we can leverage the testing infrastructure in the tck/
directory to generalize the test - we should be able to test any cloneable
Map.
I'll work on doing this.
On Wed, Apr 24,
Hi All,
ConcurrentSkipListMapTest.clone() produces a clone that shares the array
size variable of the original, and then doubles it.
So both arrays, original and clone, tell the user that each is twice as
big as it actually is.
The proposed fix is to simply set the clone's array size variable
On 4/24/19 3:12 AM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8222518
webrev: http://cr.openjdk.java.net/~dholmes/8222518/webrev/
src/hotspot/share/classfile/javaClasses.cpp
L1629: macro(_park_blocker_offset, k, "parkBlocker",
object_signature, false);
L
looks good to me,
Vicente
On 4/23/19 10:58 AM, Jim Laskey wrote:
Revision based on Joe review
webrev: http://cr.openjdk.java.net/~jlaskey/8212975/webrev-03
On Apr 22, 2019, at 3:34 PM, Jim Laskey wrote:
ClassDesc.displayName(boolean detail) allows the user the option to fetch the
fully qu
Hi,
recent changes to the String concatenation bootstrap sequence[1]
accidentally uncovered an issue introduced earlier by changing the
ClassSpecializer to use Lookup.defineClass[2].
The issue with this is the introduction of a call to SM.checkPermission
deep inside the ClassSpecializer code use
On 23/04/2019 22:53, Sciampacone, Ryan wrote:
Agreed on the changes since JDK9.
This specific problem doesn't exist in jdk/jdk because even in a (for my
example, linux) product image, although FileSystems isn't touched,
sun.nio.fs.UnixNativeDispatcher gets initialized as part of startup - this
Hi Frank,
a VarHandle is a glorified integer value that correspond to the number of bytes
from a pointer to a field address,
so you give it a reference and you have access to the field at the address:
reference + shift, given that the shift value is the same for all the instances
of the same cla
> On 4/24/19 11:51 AM, Frank Yuan wrote:
> > My test code is as below:
> > ...
> > final VarHandle vhf;
> > final VarHandle vhvf;
> > ...
>
> Make these two "static final", initialize them in class initializer, then try
> again.
>
> VarHandle (like Atomic*FieldUpdaters, MethodHandle, etc
On 4/24/19 11:51 AM, Frank Yuan wrote:
> My test code is as below:
> ...
> final VarHandle vhf;
> final VarHandle vhvf;
> ...
Make these two "static final", initialize them in class initializer, then try
again.
VarHandle (like Atomic*FieldUpdaters, MethodHandle, etc), have internal check
Hi Aleksey
I happened to see the performance to access a field by VarHandle API is much
worse than the native access.
I tested the following situations:
1. reading a volatile field directly
2. calling getVolatile against this volatile field
3. calling getVolatile against another non-volatile fie
Sherman,
I actually left the ExChannelCloser out as I was stepping back the
changes one by one, thinking it had nothing to do with the behavior
we're trying to restore here, but then I ran into some obscure test
failures (IIRC some zip files not being generated as expected) - when I
restored the
Alan, Claes,
If my memory was correct, ExChannelClose was not being used even in
previous implementation.
Actually it should never have been used in any of the released JDK. I
might have been missing some discussions ... so I might be wrong here.
But the original reason of having a exchannel
Bug: https://bugs.openjdk.java.net/browse/JDK-8222518
webrev: http://cr.openjdk.java.net/~dholmes/8222518/webrev/
The original implementation of Unsafe.unpark simply extracted the
JavaThread reference from the java.lang.Thread oop and if non-null
extracted the Parker instance from it and invoke
21 matches
Mail list logo
