On Feb 13, 2015, at 1:20 AM, Stuart Marks 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 (expectedCount
On Feb 12, 2015, at 10:16 PM, Louis Wasserman 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 wrote:
> Hi,
>
> the three Introspector test:
>
> java/beans/Introspector/7064279/Test7064279.java
> java/beans/Introspector/Test7172865.java
> java/beans/Introspector/Test7195106.
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 wrote:
> Hi,
>
> The Process and ProcessHandle API javadoc has been updat
On Feb 12, 2015, at 11:53 PM, Xueming Shen 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
> discarding the
> resul
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 wrote:
Hi,
The Process and
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
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")
|| ar
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 mul
On Feb 13, 2015, at 2:16 PM, Andrew Haley 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 and unal
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). F
On Feb 13, 2015, at 1:36 PM, Peter Levart 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 len = Arrays.asList(1, 2, 3)
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 thin
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 mo
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 jd
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:
http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/java/util/logging/package-
On Feb 13, 2015, at 3:31 PM, Andrew Haley 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 Unsafe.getLongMisaligne
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 cf = process.completableFuture();
>
>...but it doesn't hinder the use of above 'cf' quite so much as 'len' in List
example above, since 'T' in Completa
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 cf = process.completableFuture();
>
>...but it doesn't hinder the use of above 'cf' quite so much as 'len'
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 cf =
process.completableFuture();
>
>...but it doesn't hi
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 th
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 = arch.equals("i3
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 java.n
On 10/02/2015 16:20, Chris Hegarty wrote:
On 10 Feb 2015, at 11:35, Alan Bateman 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 had a chance yet to loo
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 granular
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 1
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 th
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 poten
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
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 ages.
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. In
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
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 wrote:
> On 10/02/2015 16:20, Chris Hegarty wrote:
>> On 10 Feb 2015, at 11:35, Alan Bateman wrote:
>>
>>> On 09/02/2015 14:57, Chris Hegarty wrote:
:
Updated webrev [ spec and implementation] :
http://cr.openjdk.java.net/~chegar/8064
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,
Function, or perhaps a builder pattern?
That way if XMLForm
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:
java.nio.Di
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 pref
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 settin
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, chris...@zoul
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
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 U
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 d
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 201
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
44 matches
Mail list logo
