Looks Ok to me,
thumb up :)
Rémi
On 06/01/2015 08:53 PM, Ivan Gerasimov wrote:
On 01.06.2015 11:33, Paul Sandoz wrote:
On May 31, 2015, at 6:03 PM, Ivan Gerasimov
ivan.gerasi...@oracle.com wrote:
Which is right here:
http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/
Much better.
On 02.06.2015 11:20, Paul Sandoz wrote:
On Jun 1, 2015, at 8:53 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
On 01.06.2015 11:33, Paul Sandoz wrote:
On May 31, 2015, at 6:03 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
Which is right here:
TL;DR: In principle, we'd love to do more early testing of Hotspot / JDK
features, but our benchmarks are, honestly, not all that great. We end up
having to test against live services, which makes this sort of thing really
hard.
More info than you need:
There are two real problems here:
1) To
On 01.06.2015 22:10, Xueming Shen wrote:
Ivan,
The code looks fine for me.
Just wonder what's the motivation of using the newStringUnsafe() in
the test case. Simply
to save the char[] copy to speed up the test? I don't think we really
care about it here,
right?
Yes, right. I'll replace
Thanks!
On 02.06.2015 11:54, Remi Forax wrote:
Looks Ok to me,
thumb up :)
Rémi
On 06/01/2015 08:53 PM, Ivan Gerasimov wrote:
On 01.06.2015 11:33, Paul Sandoz wrote:
On May 31, 2015, at 6:03 PM, Ivan Gerasimov
ivan.gerasi...@oracle.com wrote:
Which is right here:
On Jun 1, 2015, at 8:53 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
On 01.06.2015 11:33, Paul Sandoz wrote:
On May 31, 2015, at 6:03 PM, Ivan Gerasimov ivan.gerasi...@oracle.com
wrote:
Which is right here:
http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/
Much better.
[Adding core-libs-dev@openjdk.java.net since this update includes
changes to jdk/test library code]
Please review the updated webrev:
Webrev: http://cr.openjdk.java.net/~cjplummer/8054386/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8054386
There were concerns about the new
On Jun 2, 2015, at 10:56 AM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
You could simplify the data provider sourceTargetReplacementWithNull, there
is no point testing with a null source. String.replace accepts two
arguments, each can be either null or non-null. Thats 2 bits of state,
Very nice. I just looked over the spec, for now.
* @param predicate a a
href=package-summary.html#NonInterferencenon-interfering/a,
* a
href=package-summary.html#Statelessnessstateless/a
* predicate to apply elements to determine the longest
I'm going to have to separate out the ProcessTool.java changes into a
separate changeset (and CR). In the meantime, feel free to review what I
have below. The code won't be changing at all when I separate out the
ProcessTool.java changes.
thanks,
Chris
On 6/2/15 12:36 AM, Chris Plummer
Please review test cleanup to make process id testing more reliable.
It now spawns javaChild to report the child pid instead of parsing
the output of OS specific commands.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-builder-8067808/
Issue:
Konstantin,
It seems we have only this bug that manifests the problem. As I
understand, this is a product issue, not test.
My question was about the symptoms - how the test can fail. If the test
ignores NSME VME exceptions, will it always pass w.r.t. code cache
overflows?
Code cache
Hello,
Am Fri, 29 May 2015 12:18:06 +1000
schrieb David Holmes david.hol...@oracle.com:
I guess I'm very concerned about the premise that finalization should
scale to millions of objects and be performed highly concurrently.
I would agree that it is a bad idea to design applications for such
Mikael,
The reason of placing get_filed_offset_by_name to the oop.inline is that
hotspot widely duplicate this code.
Symbol is used to identify a field within klass, not a klass them self
so I think it's OK to have it tied to the oopDesc.
-Dmitry
On 2015-06-02 15:06, Mikael Gerdin wrote:
Hi
Changes look good to me.
Misha
On 6/2/2015 11:55 AM, Chris Plummer wrote:
I'm going to have to separate out the ProcessTool.java changes into a
separate changeset (and CR). In the meantime, feel free to review what
I have below. The code won't be changing at all when I separate out
the
Hi Paul,
All the changes seem reasonable. A couple minor suggestions
- DriverManager.drivers() - I do not think we need to repeat the note from
getDrivers(), otherwise, I would use {@code} vs code in the new javadoc
comment
- DriverManagerTests.test19() - For the new test, if you could add
Hi Roger!
On 02.06.2015 0:38, Roger Riggs wrote:
Please review a change to report the user/owner in ProcessHandle.info to
have the same form for the owner identification as provided by
java.nio.Files.
On Windows it includes the domain with the user name.
The test is updated to remove a
Hi Ivan,
Thanks for the review.
Updated the webrev in place with 2 corrections.
http://cr.openjdk.java.net/~rriggs/webrev-whoami-8081567
On 6/2/2015 5:37 PM, Ivan Gerasimov wrote:
Hi Roger!
On 02.06.2015 0:38, Roger Riggs wrote:
Please review a change to report the user/owner in
Hi Paul,
Some comments on the spec.
On 6/2/15 6:13 AM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071597-take-drop-while/webrev/
I opted to weight the documentation of the operations towards ordered streams in the
first paragraph. That is what makes most sense in
Please review the following:
Webrev: http://cr.openjdk.java.net/~cjplummer/8054386/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8081771
This review only concerns the changes to ProcessTool.java. The
CDSJDITests and filemapp.cpp changes will be committed under CR
JDK-8054386, but
lib/testlibrary/OutputAnalyzerReportingTest.java
lib/testlibrary/OutputAnalyzerTest.java
These tests fail with jtreg4.1/b12 because jtreg4.1/b12 adds stricter
checking of @library tags and the library directory defined in the test
doesn't exist.
Please review the fix, removed the unneeded
Hello,
Please review new tests fro DTLS feature for JDK 9:
bug: https://bugs.openjdk.java.net/browse/JDK-8072515
webrev: http://cr.openjdk.java.net/~kshefov/8072515/webrev.00/
Thanks
-Konstantin
Hi Dmitry,
On 2015-06-02 13:12, Dmitry Samersoff wrote:
Staffan,
Instead of hardcoding the field offsets, you can use
InstanceKlass::find_field and fieldDescriptor::offset to find the
offset at runtime.
Done. Please, see
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.11
I put
Staffan,
Instead of hardcoding the field offsets, you can use
InstanceKlass::find_field and fieldDescriptor::offset to find the
offset at runtime.
Done. Please, see
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.11
I put the function int get_filed_offset_by_name(Symbol*,Symbol*)
On Jun 2, 2015, at 3:50 PM, Stefan Zobel splitera...@gmail.com wrote:
Hi Paul,
Looks good.
I was wondering why the truncate method in Node.OfInt / OfLong / OfDouble
did not receive the same
+if (to == count()) {
+spliterator.forEachRemaining(nodeBuilder);
+
Hi Alan, Daniel,
would you have some time to check the changes in this one?
Thanks a lot
Miran
On 27/05/15 00:50, Miroslav Kos wrote:
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
On 02.06.2015 12:15, Paul Sandoz wrote:
On Jun 2, 2015, at 10:56 AM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
You could simplify the data provider sourceTargetReplacementWithNull, there is
no point testing with a null source. String.replace accepts two arguments, each
can be either
Nice,
another example of takeWhile is how to iterate over a linked list,
class Entry {
private final Entry next;
private final Object value;
Entry getNext() { return next; }
Object getValue() { return value; }
}
Entry head = ...
Stream.iterate(head, Entry::getNext)
Hi Paul,
Looks good.
I was wondering why the truncate method in Node.OfInt / OfLong / OfDouble
did not receive the same
+if (to == count()) {
+spliterator.forEachRemaining(nodeBuilder);
+} else {
+for (int i = 0; i size
Hi,
Please review this webrev that adds take/dropWhile operations to streams:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071597-take-drop-while/webrev/
I opted to weight the documentation of the operations towards ordered streams
in the first paragraph. That is what makes most sense in
Hi,
Please review a follow up to Stuart's Enumeration.asIterator patch that adds
some Stream return methods to classes where there is only Enumeration returning
methods to support traversal:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8081678-enumeration-and-stream/webrev/
I took the
Hi Moh,
However, I was hoping this would have the effect of improving
(non-finalizable) reference handling. We've seen serious issues in
WeakReference handling and have had to write some twisted code to deal with
this.
Better reference life-cycle handling would actually be beneficial
Hi Peter,
Interesting email. I think it is a thoughtful contribution and these are great
responses to concerns and questions. I hope it receives the due consideration
it deserves.
Kind regards,
Kirk
On May 31, 2015, at 9:32 PM, Peter Levart peter.lev...@gmail.com wrote:
Hi,
Thanks for
Hi,
can I please have review (and a sponsor) for these changes:
https://bugs.openjdk.java.net/browse/JDK-8081674
http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk
http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.hs
Please notice that the fix requires synchronous changes in
On 05/22/2015 01:15 PM, Staffan Friberg wrote:
On 05/22/2015 11:51 AM, Xueming Shen wrote:
On 05/22/2015 11:41 AM, Staffan Friberg wrote:
On 05/21/2015 11:00 AM, Staffan Friberg wrote:
On 05/21/2015 09:48 AM, Staffan Friberg wrote:
On 05/20/2015 10:57 AM, Xueming Shen wrote:
On
35 matches
Mail list logo
