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
Hi
Please review small fix for test
java/nio/channels/ServerSocketChannel/AdaptServerSocket.java.
webrev: http://cr.openjdk.java.net/~tyan/8068761/webrev/
http://cr.openjdk.java.net/~tyan/8068761/webrev/
bug: https://bugs.openjdk.java.net/browse/JDK-8068761
Thanks Joe and Lance. do you mind sponsor this for me.
Tristan
On Jan 8, 2015, at 2:54 PM, huizhe wang huizhe.w...@oracle.com 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 and others.
Please
...@oracle.com wrote:
On Jan 6, 2015, at 4:31 PM, Tristan Yan tristan@oracle.com
mailto:tristan@oracle.com wrote:
Thank you Lance and Joe.
You are very welcome.
I am working on the fix.
No rush from my perspective, have a lot to keep me busy in the interim
before your next webrev
Lance
On Jan 6, 2015, at 5:04 PM, Lance Andersen lance.ander...@oracle.com
mailto:lance.ander...@oracle.com wrote:
On Jan 6, 2015, at 4:31 PM, Tristan Yan tristan@oracle.com
mailto:tristan@oracle.com wrote:
Thank you Lance and Joe.
You are very welcome.
I am working
understand the Sorry I could not resist
comment
- TransformerHandlerAPITest.java has typos in comments:
IllegalArgumentExceptionis thrown….
- Minitest.java, I would add a comment for your Data Provider
Best,
Lance
On Jan 2, 2015, at 1:49 PM, Tristan Yan tristan@oracle.com
30, 2014, at 5:28 PM, Tristan Yan tristan@oracle.com
mailto:tristan@oracle.com wrote:
Hi All
Can I get your review on this change.
http://cr.openjdk.java.net/~tyan/8051563/webrev.00/
http://cr.openjdk.java.net/%7Etyan/8051563/webrev.00/
http://cr.openjdk.java.net/~tyan
Hi All
Can I get your review on this change.
http://cr.openjdk.java.net/~tyan/8051563/webrev.00/
http://cr.openjdk.java.net/~tyan/8051563/webrev.00/
These fixes originally come from bug
https://bugs.openjdk.java.net/browse/JDK-8051563
https://bugs.openjdk.java.net/browse/JDK-8051563 as part
://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.02/
Tristan
On Dec 12, 2014, at 9:45 AM, huizhe wang huizhe.w...@oracle.com 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 jaxp testset, now jaxp_tests is under jaxp testset
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/webrev.00/
http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/
/
http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/
Thanks
On Dec 11, 2014, at 9:46 AM, huizhe wang huizhe.w...@oracle.com wrote:
On 12/11/2014 7:07 AM, Alan Bateman wrote:
On 11/12/2014 14:38, Tristan Yan wrote:
Hi everyone
Could you please to review this small makefile
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/~tyan/8067183/webrev.01/
bug:
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.01/
bug
-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 tristan@oracle.com wrote:
Thanks again
This makes more sense to me. Now they look clearer.
http://cr.openjdk.java.net/~tyan/JDK-8047962/webrev.03
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
On 10/31/2014 12:16 PM, Tristan Yan wrote:
Hi Joe, Alan and all others
Would you please help
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 support the binary file. I did one small change to replace
movies.xml with a Java string to suppress this error. Also
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 Libraries SQE
Subject: Re: Review request for XML JAXP unit
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
https://bugs.openjdk.java.net/browse/JDK-8047962.
These tests have been ran with and
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 code change again.
webrev: http://cr.openjdk.java.net
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/
http://cr.openjdk.java.net/~tyan/JDK-8051561/webrev.01/
bug:
in the jdk
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 intend to replace the base class with test library
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:
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,
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
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
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
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)
I couldn't find
人: 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
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
this webrev again.
s'marks
On 2/13/14 12:25 AM, Tristan Yan wrote:
Thank you Stuart
I have fixed comment in JavaVM.java. Dealing with different cases in
ShutdownGracefully.java, two variables were added. One is a flag indicate
test
passed or not. Other variable keeps the error message when test
- 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 you for your thorough mail. This is very educational. I took
you
? 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'marks
On 2/11/14 6:59 PM, Tristan Yan wrote:
Thank you Stuart
http
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 you
Tristan
Changing the test so that it doesn't try to /home/~user seems reasonable to
me.
Stuart - I see you've been sponsoring Tristan's
, and the messages
should clearly 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
On 2/10/14 2:59 AM, Tristan Yan wrote
Ping: Can anyone give a review on this.
Thank you
Tristan
On Feb 6, 2014, at 5:13 PM, Tristan Yan tristan@oracle.com 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
Hi Stuart
Could you help to review this.
Thank you
Tristan
On Jan 31, 2014, at 4:36 PM, Tristan Yan tristan@oracle.com 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
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
-邮件原件-
发件人: 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 tristan@oracle.com wrote:
Hi Paul
I know
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
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
revised webrev before proceeding.
Thanks,
s'marks
On 1/25/14 8:57 PM, Tristan Yan
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 stuart.ma...@oracle.com wrote:
Hi all, wow, lots of comments on this. Let me see if I can
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
Hi Stuart
Should variable initialized be volatile here? Otherwise looks good.
Thank you
Tristan
On Jan 29, 2014, at 2:51 PM, Stuart Marks stuart.ma...@oracle.com wrote:
Hi all,
Please review this fix to a race condition in rmid initialization. Briefly,
rmid subclasses the RMI registry
/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 because when RMID starts
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
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
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 mandy.ch...@oracle.com wrote:
Hi Tristan,
On 1/21/2014 4:26 PM, Tristan Yan wrote:
Hi Mandy
We
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
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.
http
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 local
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 good now
) 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 tristan@oracle.com 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
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 WaitersTest use
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
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
Please
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
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
.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
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 sleep
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
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
:
On Oct 15, 2013, at 4:35 PM, Tristan Yan tristan@oracle.com
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 not really understand
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-7168267
http://cr.openjdk.java.net/~tyan/JDK-7168267/webrev.01
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 timeout
Hi Everyone
Please help to review the code change for bug JDK-8030057.
http://cr.openjdk.java.net/~tyan/JDK-8030057/webrev.00/
http://cr.openjdk.java.net/%7Etyan/JDK-8030057/webrev.00/
Description:
Performance improvement for two RMI tests
java/rmi/activation/Activatable/forceLogSnapshot
Hi Everyone
Please help to review the fix for JDK-8030284.
http://cr.openjdk.java.net/~tyan/JDK-8030284/webrev.00/
http://cr.openjdk.java.net/%7Etyan/JDK-8030284/webrev.00/
This is a one line fix that add -Xss to prevent StackOverflowError.
Thank you
Tristan
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.java.net/browse/JDK
. Please let me know your
opinion on this.
Thank you.
Tristan Yan(Haibo Yan)
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-7190106
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 of bug
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
,
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
On 11/19/13 6:27 PM, Tristan Yan wrote:
Hi Stuart
Did you get chance to review it again.
Let me know if you have any new comments or suggestions
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
Please let me know if you have comment on this.
Thank you.
Tristan Yan(Haibo Yan)
: 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.getFreePort() for the RMI
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 benchmark
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
主题: Re: Demo for Parallel Core Collection API
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 Collection API
collect(groupingBy(
groupFunc,
maxBy ? 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
, 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 supporting random port. TestLibrary
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.java.net
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
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
); }
beforeExecuteCount.getAndIncrement();
On Fri, Nov 1, 2013 at 6:48 PM, Tristan Yan tristan@oracle.com
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 help me find
lessThanCorePoolSize blank final; final boolean
lessThanCorePoolSize;
- add spaces after // and before {
On Sun, Nov 3, 2013 at 4:49 PM, Tristan Yan tristan@oracle.com
mailto:tristan@oracle.com wrote:
Thank you Martin
I had code change. I took the similar way as you do here
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 fixed
/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
87 matches
Mail list logo
