Where is Tristan

I will be OOO from Aug 24th to Sept 7th. I will be checking Email intermittently but I won't be online. Drop me a mail if you need something from me. Tristan

RFR for 8068761 : Test java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed with SocketTimeoutException

Hi Please review small fix for test java/nio/channels/ServerSocketChannel/AdaptServerSocket.java. webrev: http://cr.openjdk.java.net/~tyan/8068761/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8068761

Re: RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

Thanks Joe and Lance. do you mind sponsor this for me. Tristan > On Jan 8, 2015, at 2:54 PM, huizhe wang wrote: > > Thanks for the update. I think the webrev is ready for putback. > > Best, > Joe > > On 1/7/2015 9:41 PM, Tristan Yan wrote: >> Hi Joe/Lance an

Re: RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

Jan 6, 2015, at 5:04 PM, Lance Andersen > <mailto:lance.ander...@oracle.com>> wrote: >> >>> >>> On Jan 6, 2015, at 4:31 PM, Tristan Yan >> <mailto:tristan@oracle.com>> wrote: >>> >>>> Thank you Lance and Joe. >>>

Re: RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

as well :-) > > Joe > >> >> Best >> Lance >> On Jan 6, 2015, at 5:04 PM, Lance Andersen > <mailto:lance.ander...@oracle.com>> wrote: >> >>> >>> On Jan 6, 2015, at 4:31 PM, Tristan Yan >> <mailto:tristan@oracle.com>

Re: RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

method in between tests. I would suggest grouping all >> methods such as this DataProviders before or after the actual tests for >> better organization >> >> - TraxSAXWrapper.java, not sure I understand the "Sorry I could not resist >> comment" >> >

Re: RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

;> >> Best, >> Lance >> >> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington,

RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

Hi All Can I get your review on this change. http://cr.openjdk.java.net/~tyan/8051563/webrev.00/ These fixes originally come from bug https://bugs.openjdk.java.net/browse/JDK-8051563 as p

Re: RFR: JDK-8065673: Makefile enable JAXP tests running

.02/ <http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.02/> Tristan > On Dec 12, 2014, at 9:45 AM, huizhe wang wrote: > > > On 12/12/2014 2:45 AM, Alan Bateman wrote: >> On 11/12/2014 21:10, Tristan Yan wrote: >>> Thanks Alan and Joe >>> I added ja

Re: RFR: JDK-8065673: Makefile enable JAXP tests running

webrev.00/ <http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/> Thanks > On Dec 11, 2014, at 9:46 AM, huizhe wang wrote: > > > On 12/11/2014 7:07 AM, Alan Bateman wrote: >> On 11/12/2014 14:38, Tristan Yan wrote: >>> Hi everyone >>> &g

RFR: JDK-8065673: Makefile enable JAXP tests running

Hi everyone Could you please to review this small makefile change for JAXP tests http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/ http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/

Re: RFR 8067183: TEST_BUG:File locked when processing the cleanup on test jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java

12:42 PM, Tristan Yan wrote: Hi All Could you please review a small fix for JAXP test bug. We found this one in JPRT running. It’s caused by resource isn’t released correctly. webrev: http://cr.openjdk.java.net/~tyan/8067183/webrev.01/ <http://cr.openjdk.java.net/%7Etyan/8067183/webrev

RFR 8067183: TEST_BUG:File locked when processing the cleanup on test jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java

Hi All Could you please review a small fix for JAXP test bug. We found this one in JPRT running. It’s caused by resource isn’t released correctly. webrev: http://cr.openjdk.java.net/~tyan/8067183/webrev.01/ bug: https://bugs.openjdk.java.net

Re: RFR 8047962: XML test colocation: AuctionPortal test for bid.com

JDK-8047962/webrev.04/> I appreciate you can push it if you’re okay with this change. Thank you Tristan > On Nov 5, 2014, at 4:01 PM, Tristan Yan wrote: > > Thanks again > This makes more sense to me. Now they look clearer. > > http://cr.openjdk.java.net/~tyan/JDK-804

Re: Review request for XML JAXP unit test colocation

an account to access > cr.openjdk.java.net <http://cr.openjdk.java.net/>? Certainly I want, thanks > in advance. > > Best Regards > Frank > > From: Tristan Yan [mailto:tristan@oracle.com] > Sent: Thursday, November 06, 2014 3:54 AM > To: Frank Yuan > Cc: Core Java Libr

Re: RFR 8047962: XML test colocation: AuctionPortal test for bid.com

that makes it easier to move files around. > > Yes, I'll sponsor that for you. > > Thanks, > Joe > > On 11/5/2014 2:57 PM, Tristan Yan wrote: >> Thank you. Joe. >> Git plugin for mercurial works well for hg command but webrev script still >> doesn’t

Re: RFR 8047962: XML test colocation: AuctionPortal test for bid.com

st/content/movies.xml`: $?=0, err= 1 ). > hg diff works fine generally, but not for changes in binary files. Use the > git option, "-git", can fix the problem. You may see the following in your > configuration: > > [diff] > git = true > > Thanks, > Joe &

RFR 8047962: XML test colocation: AuctionPortal test for bid.com

Hi Joe, Alan and all others Would you please help reviewing these tests? The intent is moving some JAXP tests from closed to open. The associated bug number is https://bugs.openjdk.java.net/browse/JDK-8047962 . These tests have been ran with and

Re: Review request for JDK-8051540: Convert JAXP functin tests: org.xml.sax to jtreg (testNG) tests

Hi Joe Could you be my sponsor to push this if you’re okay with the code. Thank you Tristan > On Aug 27, 2014, at 4:38 PM, huizhe wang wrote: > > > On 8/27/2014 4:03 PM, Tristan Yan wrote: >> Hi Joe and others >> >> I updated the tests with putting them in jax

Re: Review request for JDK-8051561: Convert JAXP function tests: javax.xml.xpath.* to jtreg (testNG) tests

comment section as a record and status > of the original test development. > > Thanks, > Joe > > On 8/29/2014 9:50 AM, Tristan Yan wrote: >> Hi Joe, Alan and others >> I took over Eric’s last work and did some refactor for his code. Please help >> to review the c

Re: Review request for JDK-8051561: Convert JAXP function tests: javax.xml.xpath.* to jtreg (testNG) tests

Hi Joe, Alan and others I took over Eric’s last work and did some refactor for his code. Please help to review the code change again. webrev: http://cr.openjdk.java.net/~tyan/JDK-8051561/webrev.01/ bug: https://bugs.openjdk.java.net/brows

Re: Review request for JDK-8051540: Convert JAXP functin tests: org.xml.sax to jtreg (testNG) tests

v/jdk. I hope it doesn't mean you're checking tests into > the jdk repo. > > Thanks, > Joe > > On 8/18/2014 4:42 PM, Tristan Yan wrote: >> Thanks Joe >> We intend to replace the base class with test library because that doesn’t >> look like a real ba

Re: Review request for JDK-8051540: Convert JAXP functin tests: org.xml.sax to jtreg (testNG) tests

> repo shall be moved to jaxp/test as well. I see that your webrev was > generated in jdk9/dev/jdk. I hope it doesn't mean you're checking tests into > the jdk repo. > > Thanks, > Joe > > On 8/18/2014 4:42 PM, Tristan Yan wrote: >> Thanks Joe >> We

Re: Review request for JDK-8051540: Convert JAXP functin tests: org.xml.sax to jtreg (testNG) tests

Thanks Joe We intend to replace the base class with test library because that doesn’t look like a real base class but an utilities class. I haven’t tried to run these tests with security manager, I will run them with security manager then get back you soon. Thank you. Tristan > On Aug 18, 2014,

Review request for JDK-8051540: Convert JAXP functin tests: org.xml.sax to jtreg (testNG) tests

Hi Joe, Alan and others We’re working on moving our internal jaxp functional tests to open idk repo(Include refactoring effort). This is the first open review I am asking for SAX and Transform. Would you please review these tests. Any comment will be appreciated. I put the webrev as follows: ht

RFR for JDK-8035388: TEST_BUG: java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java fails

Hi All Could you please help to review code fix for JDK-8035388. http://cr.openjdk.java.net/~tyan/JDK-8035388/webrev.00/ Description: method inactiveObject in ActivationGroupImpl.java, release lock happen before checkInactiveGroup. This makes groupInactive reset even before next inactiveObjec

答复: RFR for JDK-8031374: java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java fails Intermittently

Thank you for taking care of this. Chris Filed a bug for this https://bugs.openjdk.java.net/browse/JDK-8035661 Tristan -邮件原件- 发件人: Chris Hegarty 发送时间: Monday, February 24, 2014 5:05 PM 收件人: Tristan Yan 抄送: Martin Buchholz; core-libs-dev 主题: Re: RFR for JDK-8031374: java/util/concurrent

答复: 答复: 答复: RFR for JDK-8031374: java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java fails Intermittently

I am ok with this unfix for now. Martin. And thank you for bringing the improvement to jsr166 CVS. Regards Tristan   发件人: Martin Buchholz [mailto:marti...@google.com] 发送时间: Monday, February 24, 2014 10:59 AM 收件人: Tristan Yan 抄送: core-libs-dev 主题: Re: 答复: 答复: RFR for JDK-8031374: java/util

答复: 答复: RFR for JDK-8031374: java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java fails Intermittently

人: Tristan Yan 抄送: core-libs-dev 主题: Re: 答复: RFR for JDK-8031374: java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java fails Intermittently   I may very well be missing something, but the actual extra timeout for threads to finish is 10 whole seconds, which should be long enough to

答复: RFR for JDK-8031374: java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java fails Intermittently

] 发送时间: Monday, February 24, 2014 3:47 AM 收件人: Tristan Yan 抄送: core-libs-dev 主题: Re: RFR for JDK-8031374: java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java fails Intermittently   Hi Tristan,   (thanks for working on my old crappy tests, and apologies for always giving you a hard time

RFR for JDK-8031374: java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java fails Intermittently

Hi All Could you please help to review fix for JDK-803174. http://cr.openjdk.java.net/~tyan/JDK-8031374/webrev.00/ Description: There are a couple of code change for this code. 1. Original code has used known problematic Thread.stop. Which could cause ThreadDeath as all we know. I change it to a

Re: RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently

to the suppressed exception list of the > exception variable, but it's not clear to me that this is worth it.) > > At the end of the test, if the exception variable is non-null, call > TestLibrary.bomb() with it to fail the test. > > Finally, one typo: "prcoess". &

Re: RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently

between 'if' and the opening paren - line 156, typo, "gracefuuly" Finally, it would be helpful if you could get webrev to generate the actual changeset instead of the plain patch, per my other review email. Thanks, s'marks On 2/11/14 9:39 PM, Tristan Yan wrote: Thank

Re: RFR for JDK-8030844:sun/rmi/rmic/classpath/RMICClassPathTest.java timeout in same binaries run

Can you regenerate the webrev so that it includes the actual changeset? Sorry, this is a small thing, but as someone who is sponsoring changesets, I'd appreciate an actual changeset in the webrev instead of having to construct one manually. I think other sponsors would appreciate this too. s

Re: RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently

learly indicate that this is going on. > > A good way to test this last case is to change rmid's security manager to the > normal security manager java.lang.SecurityManager instead of > TestSecurityManager. > > Thanks, > > s'marks > > > > &g

Re: RFR for JDK-8030844:sun/rmi/rmic/classpath/RMICClassPathTest.java timeout in same binaries run

rev with the changeset in it (as opposed to a bare > patch). I'll then push it for you. > > s'marks > > On 2/10/14 4:08 AM, Alan Bateman wrote: >> On 10/02/2014 10:57, Tristan Yan wrote: >>> Ping: Can anyone give a review on this. >>> Thank

Re: RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently

Hi Stuart Could you help to review this. Thank you Tristan On Jan 31, 2014, at 4:36 PM, Tristan Yan wrote: > Thank you for fixing JDK-8023541. Then I leave ActivationLibrary.java for now. > I still did some clean up following your suggestion. > 1. I changed waitFor(long timeout) met

Re: RFR for JDK-8030844:sun/rmi/rmic/classpath/RMICClassPathTest.java timeout in same binaries run

Ping: Can anyone give a review on this. Thank you Tristan On Feb 6, 2014, at 5:13 PM, Tristan Yan wrote: > Hi All > > Please help to review a simple fix for > https://bugs.openjdk.java.net/browse/JDK-8030844 > > http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.00/

RFR for JDK-8030844:sun/rmi/rmic/classpath/RMICClassPathTest.java timeout in same binaries run

Hi All Please help to review a simple fix for https://bugs.openjdk.java.net/browse/JDK-8030844 http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.00/. Description: Change replace a “/home/~user" folder with an test source path. Folder “/home/~user” cause some problem whenever something wrong

答复: Demo for Parallel Core Collection API

ank you Tristan -邮件原件- 发件人: Paul Sandoz 发送时间: Tuesday, February 04, 2014 5:34 PM 收件人: Tristan Yan 抄送: core-libs-dev@openjdk.java.net; Aleksandre Iline; Mikhail Kondratyev 主题: Re: Demo for Parallel Core Collection API On Feb 4, 2014, at 2:58 AM, Tristan Yan wrote: > Hi Paul >

答复: Demo for Parallel Core Collection API

already pushed. Could you please review it again? Thank you so much Tristan -邮件原件- 发件人: Paul Sandoz 发送时间: Tuesday, January 14, 2014 9:27 PM 收件人: core-libs-dev@openjdk.java.net 抄送: Tristan Yan 主题: Re: Demo for Parallel Core Collection API Hi Tristan, See below for a patch. The location of

Re: RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently

edn't use a new waitFor(timeout, unit) call. Removing the commented-out code that starts with "no longer needed" is good, and removing the ShutdownDetectThread is also good, since that's unnecessary. There are some more cleanups I have in mind here but I'd like to see a

Re: RFR(s): 8023541 Race condition in rmid initialization

Hi Stuart I didn’t make my comment clear. You set interrupted as true when thread gets interrupted. Here it's still going to wait until systemStub is not null. Why do you still need interrupt current thread in this case. Thank you Tristan On Jan 30, 2014, at 11:24 AM, David Holmes wrote: >> h

Re: RFR(s): 8023541 Race condition in rmid initialization

Hi Stuart Looks like in you new webrev. The wait will continue to go loop until systemStub is not null. If it’s what you meant to do that? Thank you Tristan On Jan 30, 2014, at 10:57 AM, Stuart Marks wrote: > Hi all, wow, lots of comments on this. Let me see if I can tackle them in one > mes

Re: RFR(s): 8023541 Race condition in rmid initialization

Hi Stuart Should variable initialized be volatile here? Otherwise looks good. Thank you Tristan On Jan 29, 2014, at 2:51 PM, Stuart Marks wrote: > Hi all, > > Please review this fix to a race condition in rmid initialization. Briefly, > rmid subclasses the RMI registry implementation and provi

Re: RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently

et/~tyan/JDK-8032050/webrev.01/ Thank you Tristan On 01/25/2014 10:20 AM, Stuart Marks wrote: On 1/23/14 10:34 PM, Tristan Yan wrote: Hi All Could you review the bug fix for JDK-8032050. http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.00/ Description: This rare happened failure caused beca

RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently

Hi All Could you review the bug fix for JDK-8032050. http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.00/ Description: This rare happened failure caused because when RMID starts. It don't guarantee sun.rmi.server.Activation.startActivation finishes. Fix by adding a iterative getSystem with

Re: Move forward for JDK-8029891

Thank you Mandy If you want to fix it soon. I am okay to use this bug as the one tracking the fix. BTW This is an intermittent failure. Regards Tristan On Jan 22, 2014, at 8:52 AM, Mandy Chung wrote: > Hi Tristan, > > On 1/21/2014 4:26 PM, Tristan Yan wrote: >> Hi Mandy

Move forward for JDK-8029891

Hi Mandy We have discussed bug https://bugs.openjdk.java.net/browse/JDK-8029891 in JBS. And we don't think this is a good time to fix it. I suggest we do two things for this bug if it's okay for you. 1. We open a new JDK bug for tracking down future JDK change. Also link JDK-8029891 to this new

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

Thank you Alan. I have changed this bug's synopsis. Is it okay you could push this? Tristan On 01/14/2014 09:48 PM, Alan Bateman wrote: On 14/01/2014 12:40, Tristan Yan wrote: Okay. But I think we all agree we should at least bring this test back for further tacking.

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

Okay. But I think we all agree we should at least bring this test back for further tacking. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.06/ Thank you. Tristan On 01/14/2014 10:39 AM, David Holmes wrote: On 13/01/2014 4:21 PM, Tristan Yan wrote: Hi All I add more trace output to

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

Hi All I add more trace output to track down possible reason of this failure. Please help to review it again. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.05/ Thank you Tristan On 01/10/2014 07:20 AM, Tristan Yan wrote: Hi David I wasn't able to reproduce this failure either in

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

Hi David I wasn't able to reproduce this failure either in local or in our same binaries running(This is a continuous running with same JDK binaries). So intention for this code change is bringing this test back; add some debug info and try to avoid possible issues in this test. I agree this

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

David Holmes wrote: On 9/01/2014 9:07 PM, Tristan Yan wrote: Thank you Paul I change turn to local variable as well. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/ <http://cr.openjdk.java.net/%7Etyan/JDK-7027502/webrev.03/> Okay I think I get it now. Both MonitorTest and Waiters

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

value) doesn't equal total_turns_taken. Regards Tristan On 01/09/2014 06:28 PM, Paul Sandoz wrote: On Jan 9, 2014, at 10:52 AM, Tristan Yan wrote: Can someone else give a second review on this. In a comment the bug you state: "here total_turns_taken is a static variable, it could

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

Can someone else give a second review on this. Thank you Tristan On 01/07/2014 07:29 PM, David Holmes wrote: On 7/01/2014 8:36 PM, Tristan Yan wrote: Hi David You're totally right. Sorry I ask you review it again. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.02/ Looks goo

Re: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds

Thank you. This is a very detailed explanation. I had new webrev with removing othervm. http://cr.openjdk.java.net/~tyan/JDK-8030089/webrev.01/ Regards Tristan On 01/08/2014 08:51 PM, Alan Bateman wrote: On 08/01/2014 11:01, Tristan Yan wrote: Hi Alan Maybe my understanding is wrong. Are you

Re: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds

Hi Alan Maybe my understanding is wrong. Are you saying even in agentvm mode, there will be still different VM for every test. If the answer is yes, when should we use othervm mode? Thank you Tristan On 01/08/2014 06:45 PM, Alan Bateman wrote: On 08/01/2014 10:09, Tristan Yan wrote: Thank

Re: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds

Thank you Alan. I am appreciated that you sponsor this. The reason I changed it to othervm is I don't want System.gc do any impact to other tests, assume in concurrent mode. Regards Tristan On 01/08/2014 05:58 PM, Alan Bateman wrote: On 08/01/2014 02:38, Tristan Yan wrote: Hi All P

RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds

Hi All Please help to review code fix for bug JDK-8030089. http://cr.openjdk.java.net/~tyan/JDK-8030089/webrev.00/ Description: 1. Set test running on othervm mode. 2. Use infinite wait to the CountDownLatch. Thank you Tristan

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

Hi David You're totally right. Sorry I ask you review it again. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.02/ Thank you very much. Tristan On 01/07/2014 05:18 PM, David Holmes wrote: On 7/01/2014 6:16 PM, Tristan Yan wrote: Thank you, David I fixed copyright and change back

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

.01/ Regards Tristan On 01/07/2014 03:10 PM, David Holmes wrote: Hi Tristan, On 7/01/2014 4:43 PM, Tristan Yan wrote: Hi All Please help to review the code change for JDK-7027502. http://cr.openjdk.java.net/~tyan/JDK-7027502/ Description: This test was failed in JPRT test but recently we test

RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

Hi All Please help to review the code change for JDK-7027502. http://cr.openjdk.java.net/~tyan/JDK-7027502/ Description: This test was failed in JPRT test but recently we test with same binaries run, it doesn't fail any more. The intention for this code change is bringing this test back to nor

Re: RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI bench/serial test

Hi Stuart I did an experiment that set a small thread stack size using the -Xss228k or -Xss512k. The result is surprised that jtreg reports the test passed. Although I can see the StackOverflowError showing in the log even when I set thread stack size as 512k . So the problem is old shell scri

Re: RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests (activation and others)

d update the changeset to revert all of the changes to ReadTimeoutTest.java except for those necessary to implement the use of CountDownLatch. Either way is fine with me. Which would you prefer? s'marks On 12/18/13 6:51 AM, Tristan Yan wrote: Hi Everyone Please review the code fix for bug JDK-716

Re: Demo for Parallel Core Collection API

PM, Paul Sandoz wrote: On Oct 15, 2013, at 4:35 PM, Tristan Yan <mailto:tristan@oracle.com>> wrote: Hi Paul you have comments "suggest that all streams are sequential. There is an inconsistency in the use and in some cases it is embedded in other stream usages." We do no

RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI bench/serial test

Hi Everyone Please help to review the fix for JDK-8030284. http://cr.openjdk.java.net/~tyan/JDK-8030284/webrev.00/ This is a one line fix that add -Xss to prevent StackOverflowError. Thank you Tristan

RFR for JDK-8030057: speed up forceLogSnapshot and checkAnnotations

Hi Everyone Please help to review the code change for bug JDK-8030057. http://cr.openjdk.java.net/~tyan/JDK-8030057/webrev.00/ Description: Performance improvement for two RMI tests java/rmi/activation/Activatable/forceLogSnapshot

Re: RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests (activation and others)

ristan On 12/12/2013 05:33 AM, Stuart Marks wrote: On 12/10/13 6:10 PM, Tristan Yan wrote: /Hi everyone I am working on bug JDK-7168267 Correct link is https://bugs.openjdk.java.net/browse/JDK-7168267 Root Cause: - Per Stuart's comment, this is a clean up bug. Suggested Fix: - Will use

RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests (activation and others)

s written. Also use two thread wait output string and error string to be not null. Please let me know if you have any comments or suggestions. / / Thank you Tristan On 12/05/2013 09:02 AM, Stuart Marks wrote: / /On 12/3/13 11:05 PM, Tristan Yan wrote: / /I am working on https://bugs.openjdk.jav

Initial with JDK-7168267

ub-cr. Please let me know your opinion on this. Thank you. Tristan Yan(Haibo Yan)

答复: 答复: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port

Thank you Stuart, next time I will keep the last version. I'm appreciated that you can sponsor this for me. Thank you very much. Tristan. -邮件原件- 发件人: Stuart Marks 发送时间: Tuesday, December 03, 2013 9:11 AM 收件人: Tristan Yan 抄送: core-libs-dev@openjdk.java.net 主题: Re: 答复: RFR for JDK-71

Re: RFR for JDK-6933803 Bring back test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java

Thank you. Chris. Tristan On 11/26/2013 11:16 PM, Chris Hegarty wrote: Tristan, The removal of this test from the ProblemList.txt looks like the right thing to do. I can push this for you. -Chris. On 26 Nov 2013, at 12:47, Tristan Yan wrote: Hi Alan Could you sponsor this small change for

Re: RFR for JDK-6933803 Bring back test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java

Hi Alan Could you sponsor this small change for me if you're ok with this change. Thank you very much. Tristan On 11/20/2013 12:45 PM, Tristan Yan wrote: Hi Everyone We have a test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java that was put into ProblemList because o

Re: 答复: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port

ending "/bin/java". (Hmmm. I observe that the RMI testlibrary invokes JVM subprocesses using java.home.) Thanks, s'marks On 11/20/13 1:49 PM, Stuart Marks wrote: Hi, sorry about the delay, I'm still backlogged from traveling. I'll get to this soon. s'marks

RFR for JDK-6933803 Bring back test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java

sdiff.html Please let me know if you have comment on this. Thank you. Tristan Yan(Haibo Yan)

答复: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port

Hi Stuart Did you get chance to review it again. Let me know if you have any new comments or suggestions. Thanks Tristan -邮件原件- 发件人: Tristan Yan 发送时间: Thursday, November 14, 2013 11:09 PM 收件人: Stuart Marks 抄送: core-libs-dev@openjdk.java.net 主题: 答复: RFR for JDK-7190106 RMI benchmark

答复: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port

件- 发件人: Stuart Marks 发送时间: Tuesday, November 12, 2013 11:38 PM 收件人: Tristan Yan 抄送: core-libs-dev@openjdk.java.net; Alexandre (Shura) Iline 主题: Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port Unfortunately we can't use jdk.testlibrary.Utils.getFreePor

答复: Demo for Parallel Core Collection API

axBy ? maxBy(comp) : minBy(comp))); -邮件原件- 发件人: Paul Sandoz 发送时间: Monday, October 14, 2013 11:28 PM 收件人: Tristan Yan 抄送: core-libs-dev@openjdk.java.net; lambda-...@openjdk.java.net; Taras Ledkov; Andrey Nazarov; Aleksandre Iline 主题: Re: Demo for Parallel Core Collection API Hi, Some high-lev

答复: Demo for Parallel Core Collection API

ename this, we need to develop another one, do you have a scenario for that? Thank you -邮件原件- 发件人: Paul Sandoz 发送时间: Monday, October 14, 2013 11:28 PM 收件人: Tristan Yan 抄送: core-libs-dev@openjdk.java.net; lambda-...@openjdk.java.net; Taras Ledkov; Andrey Nazarov; Aleksandre Iline

答复: Demo for Parallel Core Collection API

pl that we should use stream more than parallelStream? Thank you -邮件原件- 发件人: Paul Sandoz 发送时间: Monday, October 14, 2013 11:28 PM 收件人: Tristan Yan 抄送: core-libs-dev@openjdk.java.net; lambda-...@openjdk.java.net; Taras Ledkov; Andrey Nazarov; Aleksandre Iline 主题: Re: Demo for Parallel Core Coll

Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port

Maybe we should think about to merge them at the same time. Thank you Tristan On 11/10/2013 11:19 AM, Tristan Yan wrote: Hi Stuart I tried your suggestion but unfortunately all the benchmarks have dependencies to Main class because they need get stub from server. I suggest we move the benc

Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port

#x27;marks On 11/8/13 3:00 AM, Tristan Yan wrote: Thank you, Stuart There is one review point I want to ask you opinion. Which is the reason that I moved from test/java/rmi/reliability/benchmark/bench/rmi to test/java/rmi/reliability/benchmark is Main.java need access class TestLibrary for supporti

Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port

class, I couldn't find a way to let a class which has Package to access the class without package. Do you have suggestion on that? Thank you so much. Tristan On 11/06/2013 09:50 AM, Stuart Marks wrote: / / / / On 11/1/13 9:18 AM, Tristan Yan wrote: / /Hi Everyone http://cr.openjdk.jav

Re: RFR: 8027822: ProblemList.txt Updates (11/2013)

Sorry, I replied to the wrong thread, please ignore my previous mail Tristan On 06/11/2013 11:04, Tristan Yan wrote: Hi Amy Can we exclude below two also test/com/sun/net/httpserver/Test9a.java test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java Thank you Tristan On 06/11

Re: RFR: 8027822: ProblemList.txt Updates (11/2013)

Hi Amy Can we exclude below two also test/com/sun/net/httpserver/Test9a.java test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java Thank you Tristan On 06/11/2013 10:45, Amy Lu wrote: On 11/5/13 7:09 PM, Amy Lu wrote: On 11/5/13 6:01 PM, Alan Bateman wrote: On 05/11/2013 09:26,

Re: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

lessThanCorePoolSize "blank final"; final boolean lessThanCorePoolSize; - add spaces after // and before { On Sun, Nov 3, 2013 at 4:49 PM, Tristan Yan <mailto:tristan@oracle.com>> wrote: Thank you Martin I had code change. I took the similar way as you do here. Ple

RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

nexpected(x); } beforeExecuteCount.getAndIncrement(); On Fri, Nov 1, 2013 at 6:48 PM, Tristan Yan <mailto:tristan@oracle.com>> wrote: This only happened when I tried a 1000 times loop run, see the jstack out put below: Also by using jmap/jhat, below values hel

Re: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

This only happened when I tried a 1000 times loop run, see the jstack out put below: Also by using jmap/jhat, below values help me find the reason flakes.size() = 25 allStarted.state = 1 beforeExecuteCount.count = 1 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0

RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

/Hi Everyone / /I am working on bug https://bugs.openjdk.java.net/browse/JDK-8025198. Root cause for this bug is //there is a race condition on below code. //there is a very small chance that when 11th thread finishes allStarted.countDown() and before check the count, 10th thread does countD

Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port

nvert other shell script test runSerialBench.sh to java program test also Thank you Tristan On 01/11/2013 23:58, Stuart Marks wrote: On 10/31/13 10:22 PM, Tristan Yan wrote: I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. Based on my research, it looks like the issue of

RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port

Hi Everyone I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. Based on my research, it looks like the issue of fixed port was already addressed by Stuart Marks in other RMI tests which are Java based. I would like to reuse his solution, however it does not work for shell