hg: jdk8/tl/jdk: 8032190: Specifications of stream flatMap methods should require mapped streams to be closed
Changeset: 68eb0c55a8c0 Author:psandoz Date: 2014-01-21 10:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68eb0c55a8c0 8032190: Specifications of stream flatMap methods should require mapped streams to be closed Reviewed-by: chegar, alanb ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java
Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests
On Mon, Jan 20, 2014 at 4:24 PM, Alan Bateman wrote:
> On 20/01/2014 13:45, Volker Simonis wrote:
>>
>> :
>> Hi everybody,
>>
>> so here's the second version of this webrev:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/
>
> This looks okay to me.
Thanks.
>
> The typo ("legel" -> "legal") still exists in zip_util.c and maybe that can
> be fixed before you push this (no need to generate a few webrev of course).
>
Sorry, I've just fixed it in my patch queue and will used the fixed
version for pushing.
@Vladimir: could you please run this change
(http://cr.openjdk.java.net/~simonis/webrevs/8031581_2) through JPRT
as well. I'll push it (together with the fixed typo in the comment) if
everything is OK.
> For the JDWP socket transport then it's interesting that shutdown is being
> used to cause the reader thread to be preempted. That may be useful when it
> comes to addressing the bigger async close issue.
>
>
>>
>> The main changes compared to the first webrew are as follows:
>>
>> - the POLL-constants related stuff has been factored out into its own
>> webrev ("8031997: PPC64: Make the various POLL constants system
>> dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997).
>
> I see this has been pushed to ppc-aix-port/stage-9. Would you have any
> objection if I brought this into jdk9/dev (minus the AixPollPort change)? We
> can use a different bug number so as not to cause duplicate bug issues. It
> should trivially merge when you come to sync'ing up the staging forest.
>
I have no objections of course. I'm just not sure what exact
implications this will have.
@Vladimir: what do you think - can Alan push "8031997: PPC64: Make the
various POLL constants system dependant" minus the Aix-specific stuff
to jdk9/dev now, without causing you any harm during integration.
@Alan: on the other hand, the bulk integration from
ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so
maybe you could wait until that happens?
Thanks,
Volker
>
>> - the "Async close on AIX" workarounds have been taken out as well
>> and will be handled separately
>
> Thanks for separating this one out as I suspect this that doing this cleanly
> is going to involve changes for all platforms.
>
> -Alan.
Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions
Am 16.01.2014 17:26, schrieb roger riggs: Please review: webrev: http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ I more would like a "while (true)" loop, rather than a "do" loop. -Ulf
Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests
On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > On 14/01/2014 08:40, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > I'd like to review this but I won't have time until later in the week. From > an initial look then there are a few things are not pretty (the changes to > fix the AIX problems with I/O cancellation in particular) and I suspect that > some refactoring is going to be required to handle some of this cleanly. A > minor comment is that bug synopsis doesn't really communicate what these > changes are about. > > -Alan. Just forwarded the following message from another thread here where it belongs: On 17/01/2014 16:57, Alan Bateman wrote: I've finally got to this one. As the event translation issue is now a separate issue then I've ignored that part. I'm not comfortable with the changes to FileDispatcherImpl.c as I don't think we shouldn't be calling into IO_ or NET_* functions here. I think I get the issue that you have on AIX (and assume it's the preClose/dup2 that blocks rather than close) but need a bit of time to suggest alternatives. It may be that it will require an AIX specific SocketDispatcher. Do you happen to know which tests fail due to this part? The other changes look okay. There is a typo in the change to zip_util.c, s/legel/legal/. In DatagramChannelImpl.c then you handle connect failing with EAFNOSUPPORT. I would be tempted to replace the comment to say that it EAFNOSUPPORT can be ignored on AIX. A minor comment but the indentation for rv = errno can be fixed (I see the BSD code has it wrong too).
Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests
On Mon, Jan 20, 2014 at 12:41 PM, Alan Bateman wrote:
> On 20/01/2014 09:59, Volker Simonis wrote:
>>
>> :
>> Hi Alan,
>>
>> yes, that's interesting. Sounds like a very similar problem on Mac.
>>
>> I would suggest the following:
>>
>> I cut out the "Async Close AIX FIX" stuff from this change (i.e.
>> "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression
>> tests" and send out a new webrev for the remaining part. I think that
>> the remaining part was more or less reviewed and we can then push it
>> faster.
>>
>> In the mean time, I'll recheck which tests exactly fail with my
>> missing "Async Close AIX FIX" stuff and which of these tests will be
>> fixed by your 7133499 webrev. Maybe we can really get trough with it
>> or with it and a few enhancements. I'll let you know my results later
>> today. By the way, my webrev already contained a AixNativeThread.c
>> implementation in src/aix/native/sun/nio/ch.
>>
>> The only remaining problem I see with this approach is that we would
>> need to downport your 7133499 change to 8u-dev in the 8u20 time frame
>> to make our AIX port work. Would this be OK for you?
>>
> I'm okay with this plan and if you re-generate the webrev without the async
> close changes then I can look at it quickly so that you can get it into the
> stage-9 forest.
>
> On 7133499 then it would be a good candidate for 8u-dev too, I don't expect
> any problems but we will need to get it approved on the jdk8u-dev list.
>
> -Alan.
Hi everybody,
so here's the second version of this webrev:
http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/
The main changes compared to the first webrew are as follows:
- the POLL-constants related stuff has been factored out into its own
webrev ("8031997: PPC64: Make the various POLL constants system
dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997).
- the "Async close on AIX" workarounds have been taken out as well
and will be handled separately (probably together with Alans fix for
http://cr.openjdk.java.net/~alanb/7133499/webrev/).
- in the remaining files I've applied the changes suggested by
Staffan, so I think the changes to the following files can be
considered as reviewed:
src/share/native/sun/management/DiagnosticCommandImpl.c
src/solaris/native/sun/management/OperatingSystemImpl.c
src/share/transport/socket/socketTransport.c
src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider
- I've added the following additional files to the change:
src/aix/classes/sun/nio/ch/sctp/SctpChannelImpl.java
src/aix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
src/aix/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java
which are just empty stub implementations of the SCTP classes needed
to pass the SCTP jtreg tests.
All other changes should be the same like in the first review round.
Thanks,
Volker
Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests
On Fri, Jan 17, 2014 at 10:15 PM, Volker Simonis wrote: > On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman > wrote: >> On 14/01/2014 08:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> I'd like to review this but I won't have time until later in the week. From >> an initial look then there are a few things are not pretty (the changes to >> fix the AIX problems with I/O cancellation in particular) and I suspect that >> some refactoring is going to be required to handle some of this cleanly. A >> minor comment is that bug synopsis doesn't really communicate what these >> changes are about. >> >> -Alan. > > Just forwarded the following message from another thread here where it > belongs: > > On 17/01/2014 16:57, Alan Bateman wrote: > > I've finally got to this one. As the event translation issue is now a > separate issue then I've ignored that part. > > I'm not comfortable with the changes to FileDispatcherImpl.c as I > don't think we shouldn't be calling into IO_ or NET_* functions here. > I think I get the issue that you have on AIX (and assume it's the > preClose/dup2 that blocks rather than close) but need a bit of time to > suggest alternatives. It may be that it will require an AIX specific > SocketDispatcher. Do you happen to know which tests fail due to this > part? > > The other changes look okay. There is a typo in the change to > zip_util.c, s/legel/legal/. > > In DatagramChannelImpl.c then you handle connect failing with > EAFNOSUPPORT. I would be tempted to replace the comment to say that it > EAFNOSUPPORT can be ignored on AIX. A minor comment but the > indentation for rv = errno can be fixed (I see the BSD code has it > wrong too). > On 17/01/2014 21:23, Volker Simonis wrote: > > > You're right, one race is with preClose/dup2 but also with other calls > > like read/fcntl/... > > > > There were several tests that failed and once I fixed it they all > > succeeded. But I can recreate some of the failures for you. The > > symptoms are always the same: the VMis locked. If you trigger a stack > > trace you can see that at least on thread is blocked in a I/O > > operation on a file descriptor like fcntl (e.g. for file locking), > > read, etc. while another thread is trying to close that socket. > > > > As it happens, we have some carry over issues from the Mac port, > one of which is that async close of FileChannels will block > indefinitely in dup2 when there is another thread blocked (on > fnctl or reading from a pipe ...). I haven't time time to work on > it but this discussion has reminded me that we need to sort it > out. I've put a preliminary webrev with the changes here: > > http://cr.openjdk.java.net/~alanb/7133499/webrev/ > > The important part is that it's using signal consistently on > Linux/Solaris/OSX so that any blocked threads are interrupted. My > guess is that if NativeThread.c is updated to define a signal on > AIX they this should resolve some of the issues on AIX. > > I would like to see the list of tests failing. If there is an > issue with dup2 with sockets (and OS X doesn't seem to have that > issue) then it will require further work but I would at least > like to start by understanding if this patch will help with the > FileChannel issues. Hi Alan, yes, that's interesting. Sounds like a very similar problem on Mac. I would suggest the following: I cut out the "Async Close AIX FIX" stuff from this change (i.e. "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests" and send out a new webrev for the remaining part. I think that the remaining part was more or less reviewed and we can then push it faster. In the mean time, I'll recheck which tests exactly fail with my missing "Async Close AIX FIX" stuff and which of these tests will be fixed by your 7133499 webrev. Maybe we can really get trough with it or with it and a few enhancements. I'll let you know my results later today. By the way, my webrev already contained a AixNativeThread.c implementation in src/aix/native/sun/nio/ch. The only remaining problem I see with this approach is that we would need to downport your 7133499 change to 8u-dev in the 8u20 time frame to make our AIX port work. Would this be OK for you? Regards, Volker
