Hi,
Sadly, but not entirely unexpectedly there is an anomaly in the include
files:
It seems that Windows does not define O_SYNC and O_DSYNC.
To make up for the absence jdk/src/java.base/share/native/libjava/io_util.h
conditionally defines them. There is no problem if the system include
files
On May 22, 2015, at 9:56 PM, O'Leary, Kristen Kristen.O'le...@gs.com wrote:
Hi Paul,
We've created an additional test based on your suggestion: an array of size
10,000,000, 32 pair flips, a run of zeroes in the middle, and 32 pair flips
at the end. Here are the results for int:
Benchmark
On May 26, 2015, at 4:19 AM, Chan, Sunny sunny.c...@gs.com wrote:
I have looked at the mailing list archive and so far I haven’t identify any
progress on the “space for benchmark” – so we could include the performance
test as a part of the patch but it will required JMH access somehow.
I
On 05/11/2015 04:37 PM, Florian Weimer wrote:
On 05/08/2015 07:19 PM, Andrew Haley wrote:
Do we want to add side-channel protection as part of this effort
(against timing attacks and cache-flushing attacks)?
I wouldn't have thought so. It might make sense to add an optional
path without
Here is an updated webrev:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080945-nearly-sorted-primitives/webrev/
I took the liberty of:
- in DualPivotQuicksort sprinkling some more comments; and
- moving and renaming the test. Code was also reformatted to better fit the
JDK style. I
On 21/05/15 14:34, Alan Bateman wrote:
On 19/05/2015 10:38, Miroslav Kos wrote:
:
JBS: https://bugs.openjdk.java.net/browse/JDK-8080502
webrev: http://cr.openjdk.java.net/~mkos/8080502/jaxws.01/index.html
testing: JAX-WS unit test; basically it is fix for existing tests
(JCK, ...)
One thing
Hello Lance,
Thank you.
One suggestion for webrevs is to change code/code to {@code}
Please see the updated webrev (Blob.java and Clob.java were changed):
http://cr.openjdk.java.net/~avstepan/8040147/webrev.02/jdk.upd01/
Regards,
Alexander
On 25.05.2015 18:53, Lance Andersen wrote:
Hi
Thanks!
On 26.05.2015 15:30, Lance Andersen wrote:
Hi Alexander,
the updates look fine as well
Best
Lance
On May 26, 2015, at 7:45 AM, alexander stepanov
alexander.v.stepa...@oracle.com
mailto:alexander.v.stepa...@oracle.com wrote:
Hello Lance,
Thank you.
One suggestion for webrevs is
Hi Alexander,
the updates look fine as well
Best
Lance
On May 26, 2015, at 7:45 AM, alexander stepanov
alexander.v.stepa...@oracle.com wrote:
Hello Lance,
Thank you.
One suggestion for webrevs is to change code/code to {@code}
Please see the updated webrev (Blob.java and Clob.java
On 5/26/15 10:16 AM, Dmitry Samersoff wrote:
Hi Everybody,
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.09/
Please review updated webrev -
printFinalizationQueue now returns and array of Map.EntryString, int[])
and all formatting is done on VM side.
-Dmitry
Hi Dmitry,
I
I know it was like that before :) I asked similar question about fixing
String.contains to not call toString on it's CharSequence argument (
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032394.html).
Responses were generally encouraging.
Regards,
Tomasz
On Tue, May 26, 2015 at
Hi Ivan,
Did you consider doing the optimization inside of
Pattern.compile/replaceAll.
That would have a broader impact and benefit.
Roger
On 5/26/2015 12:36 PM, Ivan Gerasimov wrote:
Thank you Mark for looking at this!
On 26.05.2015 18:39, mark.reinh...@oracle.com wrote:
Your
Thank you Mark for looking at this!
On 26.05.2015 18:39, mark.reinh...@oracle.com wrote:
Your micro-benchmark improvements are significant, but do you have
evidence to suggest that the performance of this method is actually
critical to real applications?
In other words, is the added code
Your micro-benchmark improvements are significant, but do you have
evidence to suggest that the performance of this method is actually
critical to real applications?
In other words, is the added code complexity really worth it?
- Mark
On 22/05/2015 17:16, Xueming Shen wrote:
Alan, I agree that we should just remove this old regression test. It
does not server an purpose after those jar files are gone.
Please help review.
issue: https://bugs.openjdk.java.net/browse/JDK-8060161
webrev:
Hi,
Please help review the changes for JDK-8028480 and JDK-8034773
issues:
https://bugs.openjdk.java.net/browse/JDK-8028480
https://bugs.openjdk.java.net/browse/JDK-8034773
webrev:
http://cr.openjdk.java.net/~sherman/8028480_8034773/
Thanks,
-Sherman
Looks fine.
Mandy
On 05/22/2015 09:16 AM, Xueming Shen wrote:
Alan, I agree that we should just remove this old regression test. It
does not server an purpose after those jar files are gone.
Please help review.
issue: https://bugs.openjdk.java.net/browse/JDK-8060161
webrev:
Hi Everybody,
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.09/
Please review updated webrev -
printFinalizationQueue now returns and array of Map.EntryString, int[])
and all formatting is done on VM side.
-Dmitry
On 2015-05-21 02:07, Mandy Chung wrote:
On May 19, 2015, at
On 2015-05-21 02:07, Mandy Chung wrote:
On May 19, 2015, at 11:51 PM, Dmitry Samersoff
dmitry.samers...@oracle.com mailto:dmitry.samers...@oracle.com wrote:
Other alternatives could be to do all hashing/sorting/printing on native
layer i.e. implement printFinalizationQueue inside VM.
Both
I updated the webrev:
http://cr.openjdk.java.net/~igerasim/8058779/02/webrev/
In the check at 2300-2301 and 2351-2352 I replaced MAX_ARRAY_SIZE with
Integer.MAX_VALUE, which seems to be more accurate here.
And I want to add that this proposed implementation is not only faster,
but also more
Ivan,
It might be worth trying String.index + StringBuilder, instead of
writing/handling everything yourself.
Yes, it inevitably adds an arraycopy at the end to convert the
StrinbBuilder to String, but it might have
better balance between performance and code complexity. The regex is
probably
On 20/05/15 15:30, Daniel Fuchs wrote:
Hi Miroslav,
I haven't looked in all details, but this text in JAXBContext.java looks
odd to me - it seems that the bullet is repeated twice (or if they
differ - the diff must be subtle):
lines 241-257 seem identical to lines 259-275
241 * li
242 *
But the current implementation converts the argument to String in the
first place too:
return Pattern.compile(*target.toString()*,
Pattern.LITERAL).matcher(
this).replaceAll(Matcher.quoteReplacement(*replacement.toString()*));
So I didn't introduce this conversion
Hi Paul,
We've created an additional test based on your suggestion: an array of size
10,000,000, 32 pair flips, a run of zeroes in the middle, and 32 pair flips at
the end. Here are the results for int:
Benchmark (listType)
Thank you Roger for looking at this!
On 26.05.2015 19:40, Roger Riggs wrote:
Hi Ivan,
Did you consider doing the optimization inside of
Pattern.compile/replaceAll.
That would have a broader impact and benefit.
In Pattern.compile the flag LITERAL can be combined with several other
flags,
On 5/26/15 10:08 AM, Ivan Gerasimov wrote:
Thank you Roger for looking at this!
On 26.05.2015 19:40, Roger Riggs wrote:
Hi Ivan,
Did you consider doing the optimization inside of
Pattern.compile/replaceAll.
That would have a broader impact and benefit.
In Pattern.compile the flag LITERAL
The spec changes have been finalised and agreed. This is a final review call,
for implementation and test coverage.
http://cr.openjdk.java.net/~chegar/8080835/webrev.00/
-Chris.
On 20 May 2015, at 15:33, Chris Hegarty chris.hega...@oracle.com wrote:
On 20/05/15 15:17, Alan Bateman wrote:
I second that. API accepts CharSequence for a reason. The benchmarks might
look a little different if you pass StringBuilder in a call to replace. It
looks like removing toString() call on CharSequences will be easy with one
drawback of loosing the benefit of System.arraycopy call. Note that
28 matches
Mail list logo
