Looks good!
Thanks,
/Staffan
On 19 aug 2014, at 12:25, Stefan Karlsson stefan.karls...@oracle.com wrote:
Hi all,
Please review this patch harden two MemoryMXBean tests. These tests cause
intermittent test failures when the allocated objects are put in the young
gen instead of the old
Hi Stefank,
Seems reasonable. Reviewed.
Bengt
On 2014-08-19 12:25, Stefan Karlsson wrote:
Hi all,
Please review this patch harden two MemoryMXBean tests. These tests
cause intermittent test failures when the allocated objects are put in
the young gen instead of the old gen. The proposed
On 2014-08-19 12:51, Staffan Larsen wrote:
Looks good!
Thanks!
StefanK
Thanks,
/Staffan
On 19 aug 2014, at 12:25, Stefan Karlsson stefan.karls...@oracle.com wrote:
Hi all,
Please review this patch harden two MemoryMXBean tests. These tests cause
intermittent test failures when the
Hi Stefan,
On 2014-08-19 12:25, Stefan Karlsson wrote:
Hi all,
Please review this patch harden two MemoryMXBean tests. These tests
cause intermittent test failures when the allocated objects are put in
the young gen instead of the old gen. The proposed fix/workaround is to
lower the young gen
Hello again!
I updated the patch to cover situations when the exiting thread isn't
daemon.
I also added load_acquire/store_release for the sake of accuracy, even
though on Windows they seem to add nothing to the volatile access.
http://cr.openjdk.java.net/~igerasim/8055338/1/webrev/
If the
Is there any reason why this link is only accessible if I log-in?
Mario
2014-08-18 23:19 GMT+02:00 Ivan Gerasimov ivan.gerasi...@oracle.com:
Hello!
This is a request to temporarily add some instrumentation code to hotspot to
help diagnose the intermittent failure on Windows, which results in
This is a sub-task and it inherits its security level from the parent bug.
It appears that Jira doesn't allow editing the security level of sub-tasks.
Sincerely yours,
Ivan
On 19.08.2014 17:16, Mario Torre wrote:
Is there any reason why this link is only accessible if I log-in?
Mario
Hi Everybody,
Please review the fix:
http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/
JDWP call jniFatalError if transport can't be initialized (e.g. wrong
parameters) and jniFatalError call os::abort(). Therefor all transport
initialization errors cause vm to coredump.
I see no
Hi Dmitry,
The fix seems to be Ok.
Just want to make it clear...
This fix just changes the bug pattern.
It a case of incorrect transport parameters the test is still going to
fail but without crash, right?
Thanks,
Serguei
On 8/19/14 12:09 PM, Dmitry Samersoff wrote:
Hi Everybody,
Please
On 8/15/14 2:18 PM, Coleen Phillimore wrote:
Summary: Use scratch_class to find EMCP methods for breakpoints if the
old methods are still running
See bug for more details. This fix also includes a change to
nmethod::metadata_do() to not walk the _method multiple times (the
_method is added
On 8/19/14 3:53 PM, Daniel D. Daugherty wrote:
On 8/19/14 3:39 PM, Daniel D. Daugherty wrote:
On 8/15/14 2:18 PM, Coleen Phillimore wrote:
Summary: Use scratch_class to find EMCP methods for breakpoints if
the old methods are still running
See bug for more details. This fix also includes a
11 matches
Mail list logo
