Thanks Roger. Can you please also take a look on another code review request at
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-October/044260.html?
--Max
> On Oct 22, 2016, at 2:18 AM, Roger Riggs wrote:
>
> Hi Max,
>
> Looks ok.
> An additional reviewer would be good too.
>
> Rog
Hi,
in https://bugs.openjdk.java.net/browse/JDK-8025619 the logic for
closing a FileInputStream was changed from a volatile boolean + lock to
use an AtomicBoolean with rather benign effect on startup - up until the
point where VarHandles was integrated, which now means we're
transitively init
On 10/25/2016 12:51 PM, Claes Redestad wrote:
> Avoiding AtomicBoolean improves startup and footprint for a sample of
> small applications:
>
> Webrev: http://cr.openjdk.java.net/~redestad/8168640/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8168640
I would generally disagree to avo
Hi Claes,
On 10/25/2016 01:09 PM, Aleksey Shipilev wrote:
On 10/25/2016 12:51 PM, Claes Redestad wrote:
Avoiding AtomicBoolean improves startup and footprint for a sample of
small applications:
Webrev: http://cr.openjdk.java.net/~redestad/8168640/webrev.01/
Bug: https://bugs.openjdk.java.net/
On 2016-10-25 13:09, Aleksey Shipilev wrote:
On 10/25/2016 12:51 PM, Claes Redestad wrote:
Avoiding AtomicBoolean improves startup and footprint for a sample of
small applications:
Webrev: http://cr.openjdk.java.net/~redestad/8168640/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-816
On 2016-10-25 14:36, Peter Levart wrote:
Hi Claes,
On 10/25/2016 01:09 PM, Aleksey Shipilev wrote:
On 10/25/2016 12:51 PM, Claes Redestad wrote:
Avoiding AtomicBoolean improves startup and footprint for a sample of
small applications:
Webrev: http://cr.openjdk.java.net/~redestad/8168640/we
On 10/25/2016 02:57 PM, Claes Redestad wrote:
FileChannelImpl.close() may be idempotent, but why not making sure it
is called just once?
Hmm, it would seem like a pre-existing issue that was not dealt with
neither before nor after JDK-8025619, no?
And FileChannel inherits AbstractInterrupt
Hi JAXP experts,
please review a fix for a new issue regarding namespace handling in Xalan with
xsl:element.
Bug: https://bugs.openjdk.java.net/browse/JDK-8168664
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8168664.0/
I'm not 100% sure if this is the right way to go or if it would break
Hi Max,
It might be worth a comment (Lines 258 and 270) that the names are
generated to be different than the original.
Otherwise, looks fine.
Roger
On 10/19/2016 10:47 PM, Wang Weijun wrote:
Please review the code change at
http://cr.openjdk.java.net/~weijun/8168127/webrev.00/
Two c
Please review a test fix for an address-in-use problem in this CORBA
serialization test.
The test is simplified to just communicate client to server via the orb
in the process.
It does not need activation, a name service, or the orbd to exercise the
necessary serialization implementation. And
I've skimmed through the code and I'm not sure I can see any asynchronicity
(you were pointing at the lack of it in BufferedReader).
And the mechanics of this is very puzzling to me, to be honest:
void blockingFill(boolean forced) throws IOException {
fill(forced);
while (read
Hi Roger,
Do you need to use a double-checked locking idiom in getEchoStub?
I cannot recall the life-cycle of per test execution, but i suspect you might
be able to turn the static field and method getEchoStub into a non-static field
and just make the method synchronized, but you might ned to a
> On 25 Oct 2016, at 05:49, Claes Redestad wrote:
>
>
> On 2016-10-25 13:09, Aleksey Shipilev wrote:
>> On 10/25/2016 12:51 PM, Claes Redestad wrote:
>>> Avoiding AtomicBoolean improves startup and footprint for a sample of
>>> small applications:
>>>
>>> Webrev: http://cr.openjdk.java.net/~re
Hi,
On 10/25/2016 4:31 PM, Paul Sandoz wrote:
Hi Roger,
Do you need to use a double-checked locking idiom in getEchoStub?
Probably not, I'm just practicing the idiom.
We are unlikely to move to concurrent test execution in testng (when it
supports it).
I cannot recall the life-cycle of per
Thank you for your time. I'll try to explain it. I hope I can clear it up.
First of it, I made a meaning mistake between asynchronous and
non-blocking. This implementation uses a non-blocking algorithm
internally while providing a blocking-like algorithm on the surface. It
is single-threaded a
> On 25 Oct 2016, at 13:50, Roger Riggs wrote:
>
> Hi,
>
> On 10/25/2016 4:31 PM, Paul Sandoz wrote:
>> Hi Roger,
>>
>> Do you need to use a double-checked locking idiom in getEchoStub?
> Probably not, I'm just practicing the idiom.
> We are unlikely to move to concurrent test execution in te
Hi Martin,
Hmm…
The intent of ArrayList/Vector/LinkedList implementations is clear, leave the
iterator in the same state as a last successful next call.
I believe ArrayDeque’s iterator (in repo, unsure about your updates) has
different behaviour e.g.
ad.next();
ad.forEachRemaining(…);
a
> On 25 Oct 2016, at 14:28, Roger Riggs wrote:
>
> Hi Paul,
>
> Thanks for explanation and suggestions.
>
> I updated the webrev to use instance methods and fields and using
> synchronized.
> (And a bit of long-line cleanup.)
>
> webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-orb-addr
Hi Paul,
Thanks for explanation and suggestions.
I updated the webrev to use instance methods and fields and using
synchronized.
(And a bit of long-line cleanup.)
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-orb-addrinuse-8168613/
Thanks, Roger
On 10/25/2016 5:18 PM, Paul Sandoz wr
Actually, the ArrayList implementation updates fields only at the end of
the iteration, so if an action throws in the middle, the iterator is
semi-corrupted (in the sense that remove() will remove the "wrong" element
and next will return previously visited elements). I think it's best to
say in th
> On 25 Oct 2016, at 15:16, Martin Buchholz wrote:
>
> Actually, the ArrayList implementation updates fields only at the end of the
> iteration, so if an action throws in the middle, the iterator is
> semi-corrupted (in the sense that remove() will remove the "wrong" element
> and next will r
I assigned this to Paul (hope that's OK)
JDK-8168745
Iterator.forEachRemaining vs. Iterator.remove
On Tue, Oct 25, 2016 at 4:13 PM, Paul Sandoz wrote:
>
> > On 25 Oct 2016, at 15:16, Martin Buchholz wrote:
> >
> > Actually, the ArrayList implementation updates fields only at the end of
> the i
Hi all
Please help with one more reviewer comment.
Regards
Srinivasan Raghavan
> On 19-Oct-2016, at 9:38 AM, Srinivasan Raghavan
> wrote:
>
> Thanks for the review.
>> On 18-Oct-2016, at 4:16 PM, Chris Hegarty wrote:
>>
>>
>>> On 17 Oct 2016, at 09:51, Srinivasan Raghavan
>>> wrote:
>>>
Hallo Brunoais,
In the past I die some experiments with non-blocking file channels in the hope
to increase throughput in a similiar way then your buffered stream. I also used
direct allocated buffers. However my results have not been that encouraging
(especially If a upper layer used larger rea
Hey Bernd!
I don't know how far back you did such thing but I'm getting positive
results with my non-JMH tests. I do have to evaluate my results against
logic. After some reads, the OS starts caching the file which is not
what I want. It's easy to know when that happens, though. The times fall
25 matches
Mail list logo
