On Feb 13, 2015, at 1:20 AM, Stuart Marks stuart.ma...@oracle.com wrote:
On 2/12/15 3:15 AM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
OK, overall looks pretty good. Two minor comments on Matcher.java:
1202 if
On Feb 12, 2015, at 10:16 PM, Louis Wasserman lowas...@google.com wrote:
Sure. The if present:if present else:if absent ratio is ~24:6:1.
Thanks! Given those rations i think we are good with just one extra method. I
have added you as a reviewer.
Paul.
Hi,
can somebody please review this small test fix.
Thanks,
Volker
On Mon, Feb 9, 2015 at 3:27 PM, Volker Simonis volker.simo...@gmail.com wrote:
Hi,
the three Introspector test:
java/beans/Introspector/7064279/Test7064279.java
java/beans/Introspector/Test7172865.java
Hi,
I am not sure everyone is aware of the sandbox repo that was setup, but it's
rather handy to see the changes:
http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/9a02f23ca186
On Feb 12, 2015, at 11:02 PM, Roger Riggs roger.ri...@oracle.com wrote:
Hi,
The Process and ProcessHandle API
On Feb 12, 2015, at 11:53 PM, Xueming Shen xueming.s...@oracle.com wrote:
Hi Paul, my apology for taking so long :-)
No problem, thanks for putting up with me hassling you :-)
The change looks fine.
Thanks.
With regarding the edge case .split(), I am fine with the idea of
On 02/10/2015 07:48 PM, Martin Buchholz wrote:
People will continue to want to access byte arrays (and direct byte
buffers) with C-like performance, and are currently using Unsafe to
do so. Hard to fix for real. Endianness and unaligned access are
both non-portable aspects. People don't
Hi,
Please find below a patch for:
8072645: java.util.logging should use java.time to get more
precise time stamps
http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
specdiff:
On 02/13/2015 08:47 AM, Peter Levart wrote:
On 02/13/2015 03:54 AM, David Holmes wrote:
Hi Tom,
If you are potentially messing with the (identity) hash of all Java objects in
the 32-bit case then this needs a broader discussion eg on core-libs-dev
(cc'd) as this will impact end-user code the
On 02/13/2015 03:54 AM, David Holmes wrote:
Hi Tom,
If you are potentially messing with the (identity) hash of all Java
objects in the 32-bit case then this needs a broader discussion eg on
core-libs-dev (cc'd) as this will impact end-user code the most!
The rest seems okay but I'm still
Please review and push:
http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8073124
Lev
On 02/13/2015 05:20 AM, David Holmes wrote:
Hi Lev,
On 13/02/2015 2:56 AM, Lev Priima wrote:
Christos,
Test may fail on shorter arrays(page 8 of paper).
On 02/13/2015 01:56 PM, Paul Sandoz wrote:
John suggested that a general array mis-match method could be achieved with
carefully written Java code [1], and slightly hidden within that is the
comment FIXME: Add Unsafe.getLongMisaligned to avoid this cutout.
Right, so we're definitely thinking
On Feb 13, 2015, at 3:31 PM, Andrew Haley a...@redhat.com wrote:
On 02/13/2015 01:56 PM, Paul Sandoz wrote:
John suggested that a general array mis-match method could be achieved with
carefully written Java code [1], and slightly hidden within that is the
comment FIXME: Add
On Feb 13, 2015, at 2:16 PM, Andrew Haley a...@redhat.com wrote:
On 02/10/2015 07:48 PM, Martin Buchholz wrote:
People will continue to want to access byte arrays (and direct byte
buffers) with C-like performance, and are currently using Unsafe to
do so. Hard to fix for real. Endianness
Seconded. For the hash code, talk to Coleen and ask her who did the work in
core libs recently.
In addition, those bits are fiercely sought after - we have other things we
would like to do with any available bits and I am
not convinced this is more valuable. We just resisted using one for the
On 02/13/2015 03:22 PM, Paul Sandoz wrote:
It*is* inconvenient for the user to have to use wildcards in specifying types:
CompletableFuture? extends Process cf = process.completableFuture();
...but it doesn't hinder the use of above 'cf' quite so much as 'len' in List
example above, since
java.nio.DirectByteBuffer.getXXX is slow for types larger than byte
because the runtime does not know that AArch64 can perform unaligned
memory accesses.
The problem is due to this code in java.nio.Bits.unaligned():
unaligned = arch.equals(i386) || arch.equals(x86)
||
On 02/13/2015 09:15 AM, Peter Levart wrote:
On 02/13/2015 03:22 PM, Paul Sandoz wrote:
It*is* inconvenient for the user to have to use wildcards in specifying types:
CompletableFuture? extends Process cf = process.completableFuture();
...but it doesn't hinder the use of above 'cf' quite so
On Feb 13, 2015, at 1:36 PM, Peter Levart peter.lev...@gmail.com wrote:
The use of wild cards in this context is generally discouraged because it
propagates to the caller as you have found out. You cannot do what you want
for the same reasons you cannot do this:
List? extends Number
On 02/13/2015 04:37 PM, Tom Benson wrote:
Hi,
Based on comments here and elsewhere on possible future uses for this
unused bit (in the 64-bit version), I'm more inclined to close both
6764713 and 6719225 with no change. With a comment along the lines of
evolution of the JVM since the time
On 02/13/2015 04:05 PM, Alan Bateman wrote:
On 13/02/2015 13:38, Andrew Haley wrote:
java.nio.DirectByteBuffer.getXXX is slow for types larger than byte
because the runtime does not know that AArch64 can perform unaligned
memory accesses.
The problem is due to this code in
On 13/02/2015 13:38, Andrew Haley wrote:
java.nio.DirectByteBuffer.getXXX is slow for types larger than byte
because the runtime does not know that AArch64 can perform unaligned
memory accesses.
The problem is due to this code in java.nio.Bits.unaligned():
unaligned =
Changes are fine.
I agree with Alan. Please, wait when we merge aarch64 stage into jdk9/dev and then push this fix into jdk9 (by sponsor).
We should finish testing of stage repo soon.
Thanks,
Vladimir
On 2/13/15 8:07 AM, Andrew Haley wrote:
On 02/13/2015 04:05 PM, Alan Bateman wrote:
On
On 02/13/2015 05:13 PM, Carsten Varming wrote:
Dear Tom,
If you want very large MaxTenuringThresholds, then you could add an option
to reinterpret the value of the four bits to be a power of 2. One way is to
only bump the age from i to i+1 when the gc count is divisible by 2^i. You
lose
On 10/02/2015 16:20, Chris Hegarty wrote:
On 10 Feb 2015, at 11:35, Alan Bateman alan.bate...@oracle.com wrote:
On 09/02/2015 14:57, Chris Hegarty wrote:
:
Updated webrev [ spec and implementation] :
http://cr.openjdk.java.net/~chegar/8064924/04/
The updated javadoc looks good. I haven't
On 02/13/2015 04:18 PM, David M. Lloyd wrote:
On 02/13/2015 09:15 AM, Peter Levart wrote:
On 02/13/2015 03:22 PM, Paul Sandoz wrote:
It*is* inconvenient for the user to have to use wildcards in
specifying types:
CompletableFuture? extends Process cf =
process.completableFuture();
...but
Hi,
On 2015-02-13 16:37, Tom Benson wrote:
Hi,
Based on comments here and elsewhere on possible future uses for this
unused bit (in the 64-bit version), I'm more inclined to close both
6764713 and 6719225 with no change. With a comment along the lines of
evolution of the JVM since the time
Hi,
Based on comments here and elsewhere on possible future uses for this
unused bit (in the 64-bit version), I'm more inclined to close both
6764713 and 6719225 with no change. With a comment along the lines of
evolution of the JVM since the time the age field was reduced has
revealed
Hi,
Note that not taking this bit for the age field would open the door to
reducing the alignment of the JavaThread*. It's the fact that there was
already an unclaimed bit there (in the 64-bit version) that made the age
size increase seem more reasonable.
However, I'd propose not changing
Hi Tom,
Some background on some observations and strategies folks have tended to take
wrt GC tuning.
With both Parallel GC and CMS GC, a common approach by folks tuning GC and heap
sizes is to employ a strategy of promoting as few objects as possible from
young generation to old generation.
Dear Tom,
If you want very large MaxTenuringThresholds, then you could add an option
to reinterpret the value of the four bits to be a power of 2. One way is to
only bump the age from i to i+1 when the gc count is divisible by 2^i. You
lose granularity and precision, but gain some very large
OK, this looks great. Thanks for the updates.
There is also
in same order - in the same order
in the doc for the results() method, as Brian pointed out internally.
No need for another webrev.
s'marks
On 2/13/15 1:17 AM, Paul Sandoz wrote:
On Feb 13, 2015, at 1:20 AM, Stuart Marks
On 13 Feb 2015, at 16:11, Alan Bateman alan.bate...@oracle.com wrote:
On 10/02/2015 16:20, Chris Hegarty wrote:
On 10 Feb 2015, at 11:35, Alan Bateman alan.bate...@oracle.com wrote:
On 09/02/2015 14:57, Chris Hegarty wrote:
:
Updated webrev [ spec and implementation] :
My understanding is that whether or not aarch64 allows unaligned
accesses is based on a
system setting, so this change is too simplistic. I would prefer that
this was controlled with
something more flexible, like sun.cpu.unaligned.
dl
On 2/13/2015 5:38 AM, Andrew Haley wrote:
On Feb 13, 2:52pm, dean.l...@oracle.com (Dean Long) wrote:
-- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
| My understanding is that whether or not aarch64 allows unaligned=20
| accesses is based on a
| system setting, so this change is too simplistic. I would
Bon{jour,soir},
Are we in general happy with this approach or should some effort be put into
something more elaborate (hence expensive)?
Note that the addition of lines 492-493 in j.u.prefs.Preferences will I imagine
imply a CCC request, the submission of which I prefer to defer until there is
Daniel,
In the XMLFormatter.format you can get rid of the double call to
getNanoAdjustment() since you have stored the value in the local var 'nanos'.
For the new XMLFormatter constructor what do you think about using Properties,
FunctionString, String, or perhaps a builder pattern?
That
There is a system register bit to read, but I don't think it can be
accessed by an application, only the kernel.
If the OS won't provide this information, you could do something similar
to safeFetchN and catch the
resulting SIGBUS.
dl
On 2/13/2015 4:05 PM, Vladimir Kozlov wrote:
x86 has flag
These queries need to go into Unsafe.
We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
second-best mechanism the platform offers.
— John
On 2/13/15 4:22 PM, Dean Long wrote:
There is a system register bit to read, but I don't think it can be
accessed by an application, only the kernel.
If the OS won't provide this information, you could do something similar
to safeFetchN and catch the
resulting SIGBUS.
Yes, I agree it could be
On 2/13/2015 3:04 PM, chris...@zoulas.com wrote:
On Feb 13, 2:52pm, dean.l...@oracle.com (Dean Long) wrote:
-- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
| My understanding is that whether or not aarch64 allows unaligned=20
| accesses is based on a
| system
x86 has flag UseUnalignedLoadStores which is set to true depending on
which version of CPU VM runs. The CPU version is determined based on
CPUID instruction results.
Does AARCH64 has something similar?
Regards,
Vladimir
On 2/13/15 3:41 PM, Dean Long wrote:
On 2/13/2015 3:04 PM,
On 02/13/2015 11:02 AM, Paul Sandoz wrote:
Hi,
I am not sure everyone is aware of the sandbox repo that was setup, but it's
rather handy to see the changes:
http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/9a02f23ca186
On Feb 12, 2015, at 11:02 PM, Roger Riggs roger.ri...@oracle.com wrote:
On Feb 13, 4:29pm, vladimir.koz...@oracle.com (Vladimir Kozlov) wrote:
-- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
| On 2/13/15 4:22 PM, Dean Long wrote:
| There is a system register bit to read, but I don't think it can be
| accessed by an application, only
Hello,
it is good to see new features beeing used. I wonder what the
performance impact is. I think the new accesor is not yet an intrinsic
- but on the other hand it seems not so worse. In addition to that the
splitting in long+int also takes some additional time.
Gruss
Bernd
Am Fri, 13 Feb
44 matches
Mail list logo
