Thanks Roger.
On 2019/1/31 下午11:16, Roger Riggs wrote:
Pushed
On 01/30/2019 10:12 PM, Jie Fu wrote:
Hi Roger,
I really hope you can still sponsor this.
Could you help me, please?
Thanks again.
Best regards,
Jie
On 2019/1/31 上午10:59, David Holmes wrote:
On 31/01/2019 12:44 pm, Jie Fu
Pushed
On 01/30/2019 10:12 PM, Jie Fu wrote:
Hi Roger,
I really hope you can still sponsor this.
Could you help me, please?
Thanks again.
Best regards,
Jie
On 2019/1/31 上午10:59, David Holmes wrote:
On 31/01/2019 12:44 pm, Jie Fu wrote:
Hi David,
I prefer the original patch[1].
Could you
Hi Roger,
I really hope you can still sponsor this.
Could you help me, please?
Thanks again.
Best regards,
Jie
On 2019/1/31 上午10:59, David Holmes wrote:
On 31/01/2019 12:44 pm, Jie Fu wrote:
Hi David,
I prefer the original patch[1].
Could you please sponsor this issue or help me find a
On 31/01/2019 12:44 pm, Jie Fu wrote:
Hi David,
I prefer the original patch[1].
Could you please sponsor this issue or help me find a sponsor.
I really appreciate it. Thank you very much.
Hopefully Roger will still sponsor this.
Thanks,
David
Also thanks Roger. We had a pleasant
Hi David,
I prefer the original patch[1].
Could you please sponsor this issue or help me find a sponsor.
I really appreciate it. Thank you very much.
Also thanks Roger. We had a pleasant discussion offlist.
Best regards,
Jie
[1]
Hi Jie, Roger,
I think this has now consumed far too many cycles for everyone, dealing
with a test that is checking for a leak that can't even exist any more.
Alan was fine with the original proposed patch, as was I, so I think we
can should proceed with that. Obviously there is more than one
Hi,
I agree that the simplest way to fix the issue is just adding the
reachabilityFence.
But this patch might also fail since the VM doesn't guarantee that a GC
would be performed.
I didn't make such patch since I've learned from Sergey and Alan that
calling "System.gc()" several times is
Hi,
The simplest fix for this failing test is to add a call to
reachabilityFence to prevent
the loader and loaderRef from going out of scope early. It maintains
getting debug
output on a failure.
Offlist, Jie and I explored some alternate ways to write the test and
settled on this one.
Thanks David and Roger.
On 2019年01月12日 06:52, David Holmes wrote:
Hi Roger,
On 12/01/2019 2:22 am, Roger Riggs wrote:
Hi,
The proposed patch changes the test in a way that is unintended.
Adding the infinite loop of gc() and sleep, will change the timeout
behavior
from the existing timeout
Hi Roger,
On 12/01/2019 2:22 am, Roger Riggs wrote:
Hi,
The proposed patch changes the test in a way that is unintended.
Adding the infinite loop of gc() and sleep, will change the timeout
behavior
from the existing timeout of TIMEOUT to the jtreg default timeout of the
whole test.
Hi,
The proposed patch changes the test in a way that is unintended.
Adding the infinite loop of gc() and sleep, will change the timeout behavior
from the existing timeout of TIMEOUT to the jtreg default timeout of the
whole test.
Further, it renders the check at lines 114-120 irrelevant
Thanks Alan.
On 2019年01月11日 22:14, Alan Bateman wrote:
On 11/01/2019 04:16, David Holmes wrote:
I see three choices for you here :)
1. Don't try to run all tests under Xcomp but just stick to the
"core" sets of tests already tested by others.
2. Fix the given test as outlined. (I tested
On 11/01/2019 04:16, David Holmes wrote:
I see three choices for you here :)
1. Don't try to run all tests under Xcomp but just stick to the "core"
sets of tests already tested by others.
2. Fix the given test as outlined. (I tested it on linux-x64 and it
fixed the problem.)
3. Exclude
Thanks David.
Could someone from core-libs help to review it?
Thanks.
On 2019/1/11 下午1:33, David Holmes wrote:
On 11/01/2019 3:07 pm, Jie Fu wrote:
Hi David,
Thank you very much. I'd like to choose option 2.
A test case is more valuable if it can be used for both interpreter
and JIT tests.
On 11/01/2019 3:07 pm, Jie Fu wrote:
Hi David,
Thank you very much. I'd like to choose option 2.
A test case is more valuable if it can be used for both interpreter and
JIT tests.
Here is the patch based on your comments.
Hi David,
Thank you very much. I'd like to choose option 2.
A test case is more valuable if it can be used for both interpreter and
JIT tests.
Here is the patch based on your comments.
--
diff -r 02e648ae46c3
Hi Jie,
On 11/01/2019 1:24 pm, Jie Fu wrote:
I'm sorry to miss the JBS link.
JBS: https://bugs.openjdk.java.net/browse/JDK-8216528
Could you please review it and give me some advice?
Thanks.
I see three choices for you here :)
1. Don't try to run all tests under Xcomp but just stick to the
17 matches
Mail list logo
