possible NIO selector leak in 7u25
Hello, we see a possible handle/selector leak very similiar to this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7118373 We see on linux unix domain sockets and on windows /dev/afd handles which are not backed up by any socket/selector/handle/channel in the heapdump. This is a applicxation using NIO (via JBoss XNIO). We would like to nail down the source of it and therefore it would be good if we have the actual code from the old bug above "e.java" to see if this helps us to reproduce the problem. Can any Oracle developer with access to it sent it? (and cvonfirm the bug is fixed) In our case we see >500 of those internal sockets, but the related tcp sockets (and java objects) are gone. Bernd
hg: jdk8/tl/langtools: 8009924: some langtools tools do not accept -cp as an alias for -classpath
Changeset: d6158f8d7235 Author:vromero Date: 2013-07-04 10:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d6158f8d7235 8009924: some langtools tools do not accept -cp as an alias for -classpath Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! src/share/classes/com/sun/tools/javadoc/ToolOption.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/resources/l10n.properties ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties ! test/tools/doclint/tool/HelpTest.out
Re: possible NIO selector leak in 7u25
On 04/07/2013 09:36, Bernd Eckenfels wrote: Hello, we see a possible handle/selector leak very similiar to this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7118373 We see on linux unix domain sockets and on windows /dev/afd handles which are not backed up by any socket/selector/handle/channel in the heapdump. This is a applicxation using NIO (via JBoss XNIO). We would like to nail down the source of it and therefore it would be good if we have the actual code from the old bug above "e.java" to see if this helps us to reproduce the problem. Can any Oracle developer with access to it sent it? (and cvonfirm the bug is fixed) In our case we see >500 of those internal sockets, but the related tcp sockets (and java objects) are gone. Bernd Do you know if JBoss XNIO uses socket adapters to do timed reads? These were implemented as temporary Selectors and cached on a per thread basis. We've replaced this in jdk8 but for jdk7 and older then it is possible to have scenarios where there are a lot of threads or short-lived threads and the temporarily Selectors hang around until they are GC'ed. If you are using lsof or equivalent then it would be visible as an apparently build up of Unix domain sockets. You mention that the heap dump doesn't appear to have references and that make sense if the heap dump is generated from only the live objects (would be interesting to know if the Unix domain sockets are closed as as result of a heap dump that does a full GC first). There isn't an "e.java" attached to the bug. This bug is actually a "shadow bug" for something that came via another support/customer system so it has been filtered. When Rob fixed 7118373 then he wasn't able to come up with a reliable test case that demonstrated the issue in a reasonable amount of time. So are you able to duplicate the issue in your environment? I'm just wondering if you could try a preview build of 8 or event 7u40 to double check that the issue still duplicates. -Alan
hg: jdk8/tl/langtools: 6356530: -Xlint:serial does not flag abstract classes with concrete methods/members
Changeset: 79c3146e417b Author:vromero Date: 2013-07-04 10:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79c3146e417b 6356530: -Xlint:serial does not flag abstract classes with concrete methods/members Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.java + test/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.out
hg: jdk8/tl/jdk: 8019622: (sl) ServiceLoader.next incorrect when creation and usages are in different contexts
Changeset: dd69273a0240 Author:alanb Date: 2013-07-04 14:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd69273a0240 8019622: (sl) ServiceLoader.next incorrect when creation and usages are in different contexts Reviewed-by: mchung, ahgross, forax, psandoz ! src/share/classes/java/util/ServiceLoader.java
Re: possible NIO selector leak in 7u25
On 7/4/13 4:42 AM, Alan Bateman wrote: On 04/07/2013 09:36, Bernd Eckenfels wrote: Hello, we see a possible handle/selector leak very similiar to this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7118373 We see on linux unix domain sockets and on windows /dev/afd handles which are not backed up by any socket/selector/handle/channel in the heapdump. This is a applicxation using NIO (via JBoss XNIO). We would like to nail down the source of it and therefore it would be good if we have the actual code from the old bug above "e.java" to see if this helps us to reproduce the problem. Can any Oracle developer with access to it sent it? (and cvonfirm the bug is fixed) In our case we see >500 of those internal sockets, but the related tcp sockets (and java objects) are gone. Bernd Do you know if JBoss XNIO uses socket adapters to do timed reads? These were implemented as temporary Selectors and cached on a per thread basis. We've replaced this in jdk8 but for jdk7 and older then it is possible to have scenarios where there are a lot of threads or short-lived threads and the temporarily Selectors hang around until they are GC'ed. If you are using lsof or equivalent then it would be visible as an apparently build up of Unix domain sockets. You mention that the heap dump doesn't appear to have references and that make sense if the heap dump is generated from only the live objects (would be interesting to know if the Unix domain sockets are closed as as result of a heap dump that does a full GC first). There isn't an "e.java" attached to the bug. This bug is actually a "shadow bug" for something that came via another support/customer system so it has been filtered. When Rob fixed 7118373 then he wasn't able to come up with a reliable test case that demonstrated the issue in a reasonable amount of time. So are you able to duplicate the issue in your environment? I'm just wondering if you could try a preview build of 8 or event 7u40 to double check that the issue still duplicates. XNIO uses Selectors (usually PollSelectorImpls) which are cached per thread in order to mix blocking and non-blocking I/O. If you are starting many short-lived threads and doing blocking operations on XNIO channels then this might explain what is happening. The answer is basically "don't do that". -- - DML
Re: possible NIO selector leak in 7u25
On 04/07/2013 19:43, David M. Lloyd wrote: XNIO uses Selectors (usually PollSelectorImpls) which are cached per thread in order to mix blocking and non-blocking I/O. If you are starting many short-lived threads and doing blocking operations on XNIO channels then this might explain what is happening. The answer is basically "don't do that". When you say "usually PollSelectorImpls" then it normally run with it configured to use the poll based Selector? BTW: Sean Coffey mailed me off-list so say that he tried the original support/customer test case that lead to 7118373 and confirms that it doesn't duplicate with 7u25. Anyway, it would be good to hear more from Bernd to know if this duplicates with 7u40 or 8. Also interesting to know if this is a case of lots of short-lived threads doing timed reads on socket adapters (which was the motive for replace this part of the implementation in 8). -Alan.
hg: jdk8/tl/jdk: 8017231: Add StringJoiner.merge
Changeset: aa9fefb5d9c4 Author:alanb Date: 2013-07-04 20:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aa9fefb5d9c4 8017231: Add StringJoiner.merge Reviewed-by: psandoz, alanb Contributed-by: brian.go...@oracle.com, henry@oracle.com ! src/share/classes/java/util/StringJoiner.java + test/java/util/StringJoiner/MergeTest.java ! test/java/util/StringJoiner/StringJoinerTest.java
Re: possible NIO selector leak in 7u25
Hello, I will have a look at 7u40 and 8 as soon as I get some time. But I dont think it is thread(caching) related as it does not show up in the heapdump (and we have a controled thread creation rate). It looks more like some close/cancel interactions (and a real leak). I will let you know what I find. Thanks David, Alan and Sean! Greetings Bernd
Re: possible NIO selector leak in 7u25
On 7/4/13 1:53 PM, Alan Bateman wrote: On 04/07/2013 19:43, David M. Lloyd wrote: XNIO uses Selectors (usually PollSelectorImpls) which are cached per thread in order to mix blocking and non-blocking I/O. If you are starting many short-lived threads and doing blocking operations on XNIO channels then this might explain what is happening. The answer is basically "don't do that". When you say "usually PollSelectorImpls" then it normally run with it configured to use the poll based Selector? Yeah it will prefer PollSelectorImpl for temporary selectors, but will ultimately fall back to whatever the default provider gives. BTW: Sean Coffey mailed me off-list so say that he tried the original support/customer test case that lead to 7118373 and confirms that it doesn't duplicate with 7u25. Good to know, thanks. -- - DML
hg: jdk8/tl/jdk: 8019381: HashMap.isEmpty is non-final, potential issues for get/remove
Changeset: ed111451b77a Author:zhangshj Date: 2013-07-05 10:51 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ed111451b77a 8019381: HashMap.isEmpty is non-final, potential issues for get/remove Reviewed-by: chegar, mduigou ! src/share/classes/java/util/HashMap.java + test/java/util/HashMap/OverrideIsEmpty.java
