Hi Dmitry,
On 06/02/2015 01:12 PM, 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
In th
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 @li
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 th
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 term
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 ProcessH
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 in the new javadoc
comment
- DriverManagerTests.test19() - For the new test, if you could add a sim
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 Proces
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 depend
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 D
Hello,
Am Fri, 29 May 2015 12:18:06 +1000
schrieb David Holmes :
> 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
demanding workloads a
Very nice. I just looked over the spec, for now.
* @param predicate a non-interfering,
* stateless
* predicate to apply elements to determine the longest
* prefix of elements.
Is this missing a *to*, “… predicate to apply to
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 wrote
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 overfl
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:
http://cr.openjdk.java.net/~rriggs/webrev-bu
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 05/18/201
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 wrote:
> Hi,
>
> Thanks for views and opinions. I'
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 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 beneficia
On Jun 2, 2015, at 3:50 PM, Stefan Zobel 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);
> +} else
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 &&
spliterator.tryAdvance(nodeBui
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)
.takeWhile(Object
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 oppor
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 ter
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 b
On 02.06.2015 12:15, Paul Sandoz wrote:
On Jun 2, 2015, at 10:56 AM, Ivan Gerasimov 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 b
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 th
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 10:56 AM, Ivan Gerasimov 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, so
>> one can sim
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
wrote:
Which is right here:
http://cr.openjdk.java.net/~igerasim/8058779/05/we
On 02.06.2015 11:20, Paul Sandoz wrote:
On Jun 1, 2015, at 8:53 PM, Ivan Gerasimov wrote:
On 01.06.2015 11:33, Paul Sandoz wrote:
On May 31, 2015, at 6:03 PM, Ivan Gerasimov wrote:
Which is right here:
http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/
Much better.
For the test c
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
wrote:
Which is right here:
http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/
Much better.
For the test can you use Ra
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 i
On Jun 1, 2015, at 8:53 PM, Ivan Gerasimov wrote:
>
>
> On 01.06.2015 11:33, Paul Sandoz wrote:
>> On May 31, 2015, at 6:03 PM, Ivan Gerasimov
>> wrote:
>>> Which is right here:
>>> http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/
>>>
>> Much better.
>>
>> For the test can you use R
[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 hotspot
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 d
36 matches
Mail list logo
