RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed
Hello all! The MemLeakTest had been added with the fix for 8022584. Since that, the test was reported to fail intermittently, even though the leak was eliminated. I couldn't ever reproduce the failure even on the machines where the failure was detected. Here are the changes I propose: - Increase number of both warm-up and measured iterations, - Number of iterations now indicates how many times a single interface is probed. It used to probe all the interfaces that many times. - Increase the memory consumption threshold - Increase the timeout These should add some confidence that the failure of the test really indicates a memory leak. In addition to that, in the case of a failure the list of all the network interfaces is displayed, so there will be some more information about the environment. Here is the webrev: http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/ Sincerely yours, Ivan Gerasimov
Re: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed
This looks like one for the net-dev list. On 09/10/2013 09:10, Ivan Gerasimov wrote: Hello all! The MemLeakTest had been added with the fix for 8022584. Since that, the test was reported to fail intermittently, even though the leak was eliminated. I couldn't ever reproduce the failure even on the machines where the failure was detected. Here are the changes I propose: - Increase number of both warm-up and measured iterations, - Number of iterations now indicates how many times a single interface is probed. It used to probe all the interfaces that many times. - Increase the memory consumption threshold - Increase the timeout These should add some confidence that the failure of the test really indicates a memory leak. In addition to that, in the case of a failure the list of all the network interfaces is displayed, so there will be some more information about the environment. Here is the webrev: http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/ Sincerely yours, Ivan Gerasimov
Re: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed
Do you have a sense of how long this test runs for, on an average machine, with the extra iterations? -Chris. On 09/10/2013 09:24, Ivan Gerasimov wrote: Hello all! The MemLeakTest had been added with the fix for 8022584. Since that, the test was reported to fail intermittently, even though the leak was eliminated. I couldn't ever reproduce the failure even on the machines where the failure was detected. Here are the changes I propose: - Increase number of both warm-up and measured iterations, - Number of iterations now indicates how many times a single interface is probed. It used to probe all the interfaces that many times. - Increase the memory consumption threshold - Increase the timeout These should add some confidence that the failure of the test really indicates a memory leak. In addition to that, in the case of a failure the list of all the network interfaces is displayed, so there will be some more information about the environment. Here is the webrev: http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/ Sincerely yours, Ivan Gerasimov
Re: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed
Hi Chris! I've run the test on JPRT and it took 84, 99 and 146 seconds on three different machines. When I run it locally in the virtualbox, it takes approximately 300 seconds. Please note that even though the number of iterations was increased by 3.5 times, now only one NetworkInterface is accessed during one iteration. So on systems with many network interfaces the total time should even be less than before. Nevertheless I doubled the timeout. Sincerely yours, Ivan On 09.10.2013 19:57, Chris Hegarty wrote: Do you have a sense of how long this test runs for, on an average machine, with the extra iterations? -Chris. On 09/10/2013 09:24, Ivan Gerasimov wrote: Hello all! The MemLeakTest had been added with the fix for 8022584. Since that, the test was reported to fail intermittently, even though the leak was eliminated. I couldn't ever reproduce the failure even on the machines where the failure was detected. Here are the changes I propose: - Increase number of both warm-up and measured iterations, - Number of iterations now indicates how many times a single interface is probed. It used to probe all the interfaces that many times. - Increase the memory consumption threshold - Increase the timeout These should add some confidence that the failure of the test really indicates a memory leak. In addition to that, in the case of a failure the list of all the network interfaces is displayed, so there will be some more information about the environment. Here is the webrev: http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/ Sincerely yours, Ivan Gerasimov
Re: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed
On 10.10.2013 15:52, Ivan Gerasimov wrote: Hi Chris! I've run the test on JPRT and it took 84, 99 and 146 seconds on three different machines. When I run it locally in the virtualbox, it takes approximately 300 seconds. Please note that even though the number of iterations was increased by 3.5 times, now only one NetworkInterface is accessed during one iteration. Not 3.5, but of course 14 times. Silly arithmetic mistake. However the rest remains true. So on systems with many network interfaces the total time should even be less than before. Nevertheless I doubled the timeout. Sincerely yours, Ivan On 09.10.2013 19:57, Chris Hegarty wrote: Do you have a sense of how long this test runs for, on an average machine, with the extra iterations? -Chris. On 09/10/2013 09:24, Ivan Gerasimov wrote: Hello all! The MemLeakTest had been added with the fix for 8022584. Since that, the test was reported to fail intermittently, even though the leak was eliminated. I couldn't ever reproduce the failure even on the machines where the failure was detected. Here are the changes I propose: - Increase number of both warm-up and measured iterations, - Number of iterations now indicates how many times a single interface is probed. It used to probe all the interfaces that many times. - Increase the memory consumption threshold - Increase the timeout These should add some confidence that the failure of the test really indicates a memory leak. In addition to that, in the case of a failure the list of all the network interfaces is displayed, so there will be some more information about the environment. Here is the webrev: http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/ Sincerely yours, Ivan Gerasimov
Re: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed
I'm really not sure that the effort this test is going to is really necessary here ( to verify such a minor leak ). I'd be happy to see the test simply removed. Other opinions? -Chris. On 11/10/2013 20:24, Ivan Gerasimov wrote: On 10.10.2013 15:52, Ivan Gerasimov wrote: Hi Chris! I've run the test on JPRT and it took 84, 99 and 146 seconds on three different machines. When I run it locally in the virtualbox, it takes approximately 300 seconds. Please note that even though the number of iterations was increased by 3.5 times, now only one NetworkInterface is accessed during one iteration. Not 3.5, but of course 14 times. Silly arithmetic mistake. However the rest remains true. So on systems with many network interfaces the total time should even be less than before. Nevertheless I doubled the timeout. Sincerely yours, Ivan On 09.10.2013 19:57, Chris Hegarty wrote: Do you have a sense of how long this test runs for, on an average machine, with the extra iterations? -Chris. On 09/10/2013 09:24, Ivan Gerasimov wrote: Hello all! The MemLeakTest had been added with the fix for 8022584. Since that, the test was reported to fail intermittently, even though the leak was eliminated. I couldn't ever reproduce the failure even on the machines where the failure was detected. Here are the changes I propose: - Increase number of both warm-up and measured iterations, - Number of iterations now indicates how many times a single interface is probed. It used to probe all the interfaces that many times. - Increase the memory consumption threshold - Increase the timeout These should add some confidence that the failure of the test really indicates a memory leak. In addition to that, in the case of a failure the list of all the network interfaces is displayed, so there will be some more information about the environment. Here is the webrev: http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/ Sincerely yours, Ivan Gerasimov
Re: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed
On 14.10.2013 14:28, Chris Hegarty wrote: I'm really not sure that the effort this test is going to is really necessary here ( to verify such a minor leak ). I'd be happy to see the test simply removed. Other opinions? I agree. I only regret that this method of measurement of native memory usage turns out to be unreliable. At first it seemed promising. Sincerely yours, Ivan -Chris. On 11/10/2013 20:24, Ivan Gerasimov wrote: On 10.10.2013 15:52, Ivan Gerasimov wrote: Hi Chris! I've run the test on JPRT and it took 84, 99 and 146 seconds on three different machines. When I run it locally in the virtualbox, it takes approximately 300 seconds. Please note that even though the number of iterations was increased by 3.5 times, now only one NetworkInterface is accessed during one iteration. Not 3.5, but of course 14 times. Silly arithmetic mistake. However the rest remains true. So on systems with many network interfaces the total time should even be less than before. Nevertheless I doubled the timeout. Sincerely yours, Ivan On 09.10.2013 19:57, Chris Hegarty wrote: Do you have a sense of how long this test runs for, on an average machine, with the extra iterations? -Chris. On 09/10/2013 09:24, Ivan Gerasimov wrote: Hello all! The MemLeakTest had been added with the fix for 8022584. Since that, the test was reported to fail intermittently, even though the leak was eliminated. I couldn't ever reproduce the failure even on the machines where the failure was detected. Here are the changes I propose: - Increase number of both warm-up and measured iterations, - Number of iterations now indicates how many times a single interface is probed. It used to probe all the interfaces that many times. - Increase the memory consumption threshold - Increase the timeout These should add some confidence that the failure of the test really indicates a memory leak. In addition to that, in the case of a failure the list of all the network interfaces is displayed, so there will be some more information about the environment. Here is the webrev: http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/ Sincerely yours, Ivan Gerasimov
Re: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed
On 10/15/2013 11:19 AM, Ivan Gerasimov wrote: On 14.10.2013 14:28, Chris Hegarty wrote: I'm really not sure that the effort this test is going to is really necessary here ( to verify such a minor leak ). I'd be happy to see the test simply removed. Other opinions? I agree. I only regret that this method of measurement of native memory usage turns out to be unreliable. At first it seemed promising. In which case, and if others do not object, I'd be happy to sponsor a changeset that simply removes the test: 'hg rm java/net/NetworkInterface/MemLeakTest.java'. -Chris. Sincerely yours, Ivan -Chris. On 11/10/2013 20:24, Ivan Gerasimov wrote: On 10.10.2013 15:52, Ivan Gerasimov wrote: Hi Chris! I've run the test on JPRT and it took 84, 99 and 146 seconds on three different machines. When I run it locally in the virtualbox, it takes approximately 300 seconds. Please note that even though the number of iterations was increased by 3.5 times, now only one NetworkInterface is accessed during one iteration. Not 3.5, but of course 14 times. Silly arithmetic mistake. However the rest remains true. So on systems with many network interfaces the total time should even be less than before. Nevertheless I doubled the timeout. Sincerely yours, Ivan On 09.10.2013 19:57, Chris Hegarty wrote: Do you have a sense of how long this test runs for, on an average machine, with the extra iterations? -Chris. On 09/10/2013 09:24, Ivan Gerasimov wrote: Hello all! The MemLeakTest had been added with the fix for 8022584. Since that, the test was reported to fail intermittently, even though the leak was eliminated. I couldn't ever reproduce the failure even on the machines where the failure was detected. Here are the changes I propose: - Increase number of both warm-up and measured iterations, - Number of iterations now indicates how many times a single interface is probed. It used to probe all the interfaces that many times. - Increase the memory consumption threshold - Increase the timeout These should add some confidence that the failure of the test really indicates a memory leak. In addition to that, in the case of a failure the list of all the network interfaces is displayed, so there will be some more information about the environment. Here is the webrev: http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/ Sincerely yours, Ivan Gerasimov
Re: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed
Thank you Chris! Here's the exported patch with the test removal: http://cr.openjdk.java.net/~igerasim/2commit/8023390-jdk8-remove-MemLeakTest.patch Sincerely yours, Ivan Gerasimov On 15.10.2013 16:54, Chris Hegarty wrote: On 10/15/2013 11:19 AM, Ivan Gerasimov wrote: On 14.10.2013 14:28, Chris Hegarty wrote: I'm really not sure that the effort this test is going to is really necessary here ( to verify such a minor leak ). I'd be happy to see the test simply removed. Other opinions? I agree. I only regret that this method of measurement of native memory usage turns out to be unreliable. At first it seemed promising. In which case, and if others do not object, I'd be happy to sponsor a changeset that simply removes the test: 'hg rm java/net/NetworkInterface/MemLeakTest.java'. -Chris. Sincerely yours, Ivan -Chris. On 11/10/2013 20:24, Ivan Gerasimov wrote: On 10.10.2013 15:52, Ivan Gerasimov wrote: Hi Chris! I've run the test on JPRT and it took 84, 99 and 146 seconds on three different machines. When I run it locally in the virtualbox, it takes approximately 300 seconds. Please note that even though the number of iterations was increased by 3.5 times, now only one NetworkInterface is accessed during one iteration. Not 3.5, but of course 14 times. Silly arithmetic mistake. However the rest remains true. So on systems with many network interfaces the total time should even be less than before. Nevertheless I doubled the timeout. Sincerely yours, Ivan On 09.10.2013 19:57, Chris Hegarty wrote: Do you have a sense of how long this test runs for, on an average machine, with the extra iterations? -Chris. On 09/10/2013 09:24, Ivan Gerasimov wrote: Hello all! The MemLeakTest had been added with the fix for 8022584. Since that, the test was reported to fail intermittently, even though the leak was eliminated. I couldn't ever reproduce the failure even on the machines where the failure was detected. Here are the changes I propose: - Increase number of both warm-up and measured iterations, - Number of iterations now indicates how many times a single interface is probed. It used to probe all the interfaces that many times. - Increase the memory consumption threshold - Increase the timeout These should add some confidence that the failure of the test really indicates a memory leak. In addition to that, in the case of a failure the list of all the network interfaces is displayed, so there will be some more information about the environment. Here is the webrev: http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/ Sincerely yours, Ivan Gerasimov
