Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which >> JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the >> loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and >> require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems >> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for >> zero and some of the other ports. Additional ports can be contributed via >> PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels >> have been trimmed down for now to hotspot, serviceability and core-libs. >> We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from >> Doug Lea's CVS. These changes will probably be proposed and integrated in >> advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support >> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to >> make life a bit easier and avoid having to separate VM changes and juggle >> branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional > commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 Similar comments to @fisk. This is what I've been focusing on: * In-depth: gc/, oops/, memory/, utilities/ * Partially: runtime/ * Cleanups: hotspot/ - Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166
Re: Integrated: 8277649 [BACKOUT] JDK-8277507 Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures
On Tue, 23 Nov 2021 15:08:43 GMT, Daniel D. Daugherty wrote: > This reverts commit 12f08ba4d47cb70a0629b17bc3639ce170309f21. > > The fix for JDK-8277507 is causing 38 failures per Tier2 job set. Marked as reviewed by stefank (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6523
Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related >> to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module — the `jaotc` tool >> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT >> compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one > additional commit since the last revision: > > Remove exports from Graal module to jdk.aot GC changes look good. - Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398
Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]
On Wed, 31 Mar 2021 15:42:14 GMT, Brian Burkhalter wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Review Alan > > Marked as reviewed by bpb (Reviewer). Thanks for reviewing! - PR: https://git.openjdk.java.net/jdk/pull/3282
Integrated: 8264489: Add more logging to LargeCopyWithMark.java
On Wed, 31 Mar 2021 06:56:23 GMT, Stefan Karlsson wrote: > Add more logging to the LargeCopyWithMark.java test, to gather more > information when this test fails with OOME. > > The intention is to gather more info for JDK-8239089. > > I consider this patch trivial, and expect to push it after I've gotten one > Review. This pull request has now been integrated. Changeset: 0fa35728 Author:Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/0fa35728 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8264489: Add more logging to LargeCopyWithMark.java Reviewed-by: kbarrett, alanb, bpb - PR: https://git.openjdk.java.net/jdk/pull/3282
Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]
On Wed, 31 Mar 2021 09:29:43 GMT, Alan Bateman wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Review Alan > > test/jdk/java/io/BufferedInputStream/LargeCopyWithMark.java line 29: > >> 27: * @summary BufferedInputStream calculates negative array size with large >> 28: * streams and mark >> 29: * @run main/othervm -Xmx4G -Xlog:gc,gc+heap,gc+ergo+heap >> -XX:+CrashOnOutOfMemoryError -XX:+IgnoreUnrecognizedVMOptions >> -XX:+G1ExitOnExpansionFailure LargeCopyWithMark > > Looks okay but I assume you can split this line to avoid having a 170+ line > in this file, this helps with future side-by-side review. Thanks. I've added line breaks to make it easier to read. - PR: https://git.openjdk.java.net/jdk/pull/3282
Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]
> Add more logging to the LargeCopyWithMark.java test, to gather more > information when this test fails with OOME. > > The intention is to gather more info for JDK-8239089. > > I consider this patch trivial, and expect to push it after I've gotten one > Review. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review Alan - Changes: - all: https://git.openjdk.java.net/jdk/pull/3282/files - new: https://git.openjdk.java.net/jdk/pull/3282/files/a7260c86..1828df10 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3282&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3282&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3282.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3282/head:pull/3282 PR: https://git.openjdk.java.net/jdk/pull/3282
Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java
On Wed, 31 Mar 2021 08:39:02 GMT, Kim Barrett wrote: >> Add more logging to the LargeCopyWithMark.java test, to gather more >> information when this test fails with OOME. >> >> The intention is to gather more info for JDK-8239089. >> >> I consider this patch trivial, and expect to push it after I've gotten one >> Review. > > Looks good, and trivial. Thanks Kim! - PR: https://git.openjdk.java.net/jdk/pull/3282
RFR: 8264489: Add more logging to LargeCopyWithMark.java
Add more logging to the LargeCopyWithMark.java test, to gather more information when this test fails with OOME. The intention is to gather more info for JDK-8239089. I consider this patch trivial, and expect to push it after I've gotten on Review. - Commit messages: - 8264489: Add more logging to LargeCopyWithMark.java Changes: https://git.openjdk.java.net/jdk/pull/3282/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3282&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264489 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3282.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3282/head:pull/3282 PR: https://git.openjdk.java.net/jdk/pull/3282
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
On Tue, 9 Mar 2021 17:55:12 GMT, Anton Kozlov wrote:
>> src/hotspot/share/runtime/thread.cpp line 2515:
>>
>>> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread
>>> *thread) {
>>> 2514: // Enable WXWrite: called directly from interpreter native wrapper.
>>> 2515: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread));
>>
>> FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the
>> call sites increase the line-noise in the affected functions. I think I
>> would have preferred a version:
>> ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) {
>> MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {}
>> void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt.
>> inline.hpp)
>> With that said, I'm fine with taking this discussion as a follow-up.
>
> The former version used no such macros. I like that now it's clear the W^X
> management is relevant to macos/aarch64 only. I see the point to move the
> pre-processor condition into the class implementation. But I think it will
> bring a bit of inconsistency, as the rest of W^X implementation is explicitly
> guarded by preprocessor conditionals. I've also tried to push macro
> conditionals as far as possible down to implementation, providing a kind of
> generalized W^X interface. That required a few artificial decisions, e.g. how
> would we call the mode we execute on the rest of platforms with write and
> execute allowed, WXWriteExec?.. I abandoned that attempt.
I think we would use the same names, but I haven't given it more thought. I
might take a look at this after this has been integrated.
>> src/hotspot/share/runtime/thread.hpp line 848:
>>
>>> 846: void init_wx();
>>> 847: WXMode enable_wx(WXMode new_state);
>>> 848: #endif // __APPLE__ && AARCH64
>>
>> Now that this is only compiled into macOS/AArch64, could this be moved over
>> to thread_bsd_aarch64.hpp? The same goes for the associated functions.
>
> The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block
> belongs to Thread for now. Since W^X is an attribute of any operating system
> thread, I assumed Thread to be the right place for W^X bookkeeping.
>
> In most cases, we manage W^X state of JavaThread. But sometimes a GC thread
> needs the WXWrite state, or safefetch is called from non-JavaThread. Probably
> this can be dealt with (e.g. GCThread to always have the WXWrite state). But
> such change would be much more than a simple refactoring and it would require
> a significant amount of testing. Ideally, I would like to investigate this as
> a follow-up change, or at least after other fixes to this PR.
Good point about Thread vs JavaThread. Yes, this can be looked into as
follow-up cleanups.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks >> JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with >> necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), >> required on macOS/AArch64 platform. It's implemented with >> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a >> thread, so W^X mode change relates to the java thread state change (for java >> threads). In most cases, JVM executes in write-only mode, except when >> calling a generated stub like SafeFetch, which requires a temporary switch >> to execute-only mode. The same execute-only mode is enabled when a java >> thread executes in java or native states. This approach of managing W^X mode >> turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional > commit since the last revision: > > 8262903: [macos_aarch64] Thread::current() called on detached thread Marked as reviewed by stefank (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
On Fri, 5 Feb 2021 16:07:09 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
>> JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with
>> necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X),
>> required on macOS/AArch64 platform. It's implemented with
>> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a
>> thread, so W^X mode change relates to the java thread state change (for java
>> threads). In most cases, JVM executes in write-only mode, except when
>> calling a generated stub like SafeFetch, which requires a temporary switch
>> to execute-only mode. The same execute-only mode is enabled when a java
>> thread executes in java or native states. This approach of managing W^X mode
>> turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update signal handler part for debugger
Thanks for cleaning out WXWriteFromExecSetter.
src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 52:
> 50:
> 51: int BarrierSetNMethod::nmethod_stub_entry_barrier(address*
> return_address_ptr) {
> 52: // Enable WXWrite: the function is called direclty from
> nmethod_entry_barrier
direclty -> directly
src/hotspot/share/runtime/threadWXSetters.hpp line 28:
> 26: #define SHARE_RUNTIME_THREADWXSETTERS_HPP
> 27:
> 28: #include "runtime/thread.inline.hpp"
This breaks against our convention to forbid inline.hpp files from being
included from being included from .hpp files. You need to rework this by either
moving the implementation to a .cpp file, or convert this file into an
.inline.hpp
See the Source Files section in:
https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html
src/hotspot/share/runtime/thread.hpp line 848:
> 846: void init_wx();
> 847: WXMode enable_wx(WXMode new_state);
> 848: #endif // __APPLE__ && AARCH64
Now that this is only compiled into macOS/AArch64, could this be moved over to
thread_bsd_aarch64.hpp? The same goes for the associated functions.
src/hotspot/share/runtime/thread.cpp line 2515:
> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread
> *thread) {
> 2514: // Enable WXWrite: called directly from interpreter native wrapper.
> 2515: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread));
FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the
call sites increase the line-noise in the affected functions. I think I would
have preferred a version:
ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) {
MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {}
void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt.
inline.hpp)
With that said, I'm fine with taking this discussion as a follow-up.
-
Changes requested by stefank (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
>> JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with
>> necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X),
>> required on macOS/AArch64 platform. It's implemented with
>> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a
>> thread, so W^X mode change relates to the java thread state change (for java
>> threads). In most cases, JVM executes in write-only mode, except when
>> calling a generated stub like SafeFetch, which requires a temporary switch
>> to execute-only mode. The same execute-only mode is enabled when a java
>> thread executes in java or native states. This approach of managing W^X mode
>> turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Refactor CDS disabling
> - Redo builsys support for aarch64-darwin
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute
> (W^X), required on macOS/AArch64 platform. It's implemented with
> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a
> thread, so W^X mode change relates to the java thread state change (for java
> threads). In most cases, JVM executes in write-only mode, except when calling
> a generated stub like SafeFetch, which requires a temporary switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
I wonder if this is the right choice. I think it would have been good if this
could have been completely hidden in the transition classes. However, that
doesn't seem to have been enough and now there are explicit
Thread::WXWriteFromExecSetter instances where it's not at all obvious why they
are needed. For example, why was it added here?:
OopStorageParIterPerf::~OopStorageParIterPerf() {
// missing transition to vm state
Thread::WXWriteFromExecSetter wx_write;
_storage.release(_entries, ARRAY_SIZE(_entries));
}
You need to dig down in the OopStorage implementation to find that it's because
it uses SafeFetch, which has the opposite transition:
inline int SafeFetch32(int* adr, int errValue) {
assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
Thread::WXExecFromWriteSetter wx_exec;
return StubRoutines::SafeFetch32_stub()(adr, errValue);
}
I think this adds complexity to code that shouldn't have to deal with this. I'm
fine with having to force devs / code that writes to exec memory to have to
deal with a bit more complexity, but it seems wrong to let this leak out to
code that is staying far away from that.
For my understanding, was this choice made because the nmethods instances (and
maybe other types as well) are placed in the code cache memory segment, which
is executable? If the code cache only contained the JIT:ed code, and not object
instances, I think this could more easily have been contained a bit more.
If the proposed solution is going to stay, maybe this could be made a little
bit nicer by changing the SafeFetch implementation to use a new scoped object
that doesn't enforce the "from" state to be "write"? Instead it could check if
the state is "write" and only then flip the state back and forth. I think, this
would remove the change needed OopStorageParIterPerf, and probably other places
as well.
src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp line 38:
> 36: #include "runtime/os.hpp"
> 37: #include "runtime/stubRoutines.hpp"
> 38: #include "runtime/stubRoutines.inline.hpp"
Remove stubRutines.hpp line
src/hotspot/share/runtime/stubRoutines.inline.hpp line 29:
> 27:
> 28: #include
> 29: #include
Replace < > with " "
src/hotspot/os/aix/os_aix.cpp line 70:
> 68: #include "runtime/statSampler.hpp"
> 69: #include "runtime/stubRoutines.hpp"
> 70: #include "runtime/stubRoutines.inline.hpp"
Remove stubRutines.hpp line
-
Changes requested by stefank (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR(T) : 8244066 : ClassFileInstaller should be run in driver mode
Looks good. StefanK On 2020-04-29 06:41, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8244066/webrev.00 16 lines changed: 0 ins; 0 del; 16 mod; Hi all, could you please review this trivial cleanup in tests? from JBS: ClassFileInstaller is a test utility class which copies class files to the current directory, there is no point in running it w/ external flags, hence it should be run in a driver mode. testing: updated tests webrev: http://cr.openjdk.java.net/~iignatyev//8244066/webrev.00 JBS: https://bugs.openjdk.java.net/browse/JDK-8244066 Thanks, -- Igor
Re: RFR: 8204861 : fix for 8196993 has broken the build on linux
Looks good to me. Thanks for fixing this. StefanK On 2018-06-12 14:46, Srinivas Dama wrote: Hi, My earlier fix for https://bugs.openjdk.java.net/browse/JDK-8196993 has broken the build on linux. So I am reverting my fix for now. Bug : https://bugs.openjdk.java.net/browse/JDK-8204861 webrev: http://cr.openjdk.java.net/~sdama/8204861/webrev.00/ Regards, Srinivas
Re: RFR: 8072921: -Xincgc should be removed from output
On 2016-04-19 12:45, Alan Bateman wrote: On 19/04/2016 10:58, Stefan Karlsson wrote: I've left the locale specific launcher files untouched. Should I update them as well? Dropping -Xincgc rom the -X output looks okay to me. We usually don't touch the translations as they are updated in bulk periodically, often closer to the end a release. OK. Thanks for the review. StefanK -Alan.
RFR: 8072921: -Xincgc should be removed from output
Hi all, I hope this is the right list for this RFR. Please review this patch to remove the -Xincgc output from the java launcher. http://cr.openjdk.java.net/~stefank/8072921/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8072921 The output can be seen by running 'java -X': $ ../build/linux-x86_64-normal-server-release/jdk/bin/java -X -Xmixed mixed mode execution (default) -Xint interpreted mode execution only -Xbootclasspath/a: append to end of bootstrap class path -Xdiagshow additional diagnostic messages -Xdiag:resolver show resolver diagnostic messages -Xnoclassgc disable class garbage collection -Xincgc enable incremental garbage collection The -Xincgc flag was removed with JEP 214: https://bugs.openjdk.java.net/browse/JDK-8044022 JEP 214: Remove GC Combinations Deprecated in JDK 8 I've left the locale specific launcher files untouched. Should I update them as well? Thanks, StefanK
hg: jdk8/tl/jdk: 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2
Changeset: f15a0087181e Author:stefank Date: 2013-10-14 14:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f15a0087181e 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 Reviewed-by: coleenp, sla Contributed-by: stefan.karls...@oracle.com, coleen.phillim...@oracle.com ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh
hg: jdk8/tl/jdk: 8014659: NPG: performance counters for compressed klass space
Changeset: b606775fd1a3 Author:stefank Date: 2013-08-29 11:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b606775fd1a3 8014659: NPG: performance counters for compressed klass space Reviewed-by: jmasa, sla Contributed-by: erik.he...@oracle.com ! src/share/classes/sun/tools/jstat/resources/jstat_options ! test/sun/tools/jstat/gcCapacityOutput1.awk ! test/sun/tools/jstat/gcCauseOutput1.awk ! test/sun/tools/jstat/gcMetaCapacityOutput1.awk ! test/sun/tools/jstat/gcOldOutput1.awk ! test/sun/tools/jstat/gcOutput1.awk ! test/sun/tools/jstat/lineCounts1.awk ! test/sun/tools/jstat/lineCounts2.awk ! test/sun/tools/jstat/lineCounts3.awk ! test/sun/tools/jstat/lineCounts4.awk ! test/sun/tools/jstat/timeStamp1.awk ! test/sun/tools/jstatd/jstatGcutilOutput1.awk
hg: jdk8/tl/jdk: 8009427: Re-enable tests that were disable to ease complicated push
Changeset: caafe6dca35d Author:ehelin Date: 2013-03-21 20:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/caafe6dca35d 8009427: Re-enable tests that were disable to ease complicated push Reviewed-by: sla, mchung, dcubed Contributed-by: Erik Helin ! test/ProblemList.txt
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 470232a8e89d Author:stefank Date: 2013-03-22 15:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/470232a8e89d 8005116: NPG: Rename -permstat option for jmap in jdk8 to -clstats Reviewed-by: jmasa, sla Contributed-by: Erik Helin ! src/share/classes/sun/tools/jmap/JMap.java Changeset: 518d6087e01f Author:stefank Date: 2013-03-22 15:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/518d6087e01f 8004172: Update jstat counter names to reflect metaspace changes Reviewed-by: mchung Contributed-by: Erik Helin ! src/share/classes/sun/tools/jstat/resources/jstat_options ! test/sun/tools/jstat/gcCapacityOutput1.awk ! test/sun/tools/jstat/gcCauseOutput1.awk + test/sun/tools/jstat/gcMetaCapacityOutput1.awk ! test/sun/tools/jstat/gcOldOutput1.awk ! test/sun/tools/jstat/gcOutput1.awk - test/sun/tools/jstat/gcPermCapacityOutput1.awk + test/sun/tools/jstat/jstatGcMetaCapacityOutput1.sh - test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh ! test/sun/tools/jstat/lineCounts1.awk ! test/sun/tools/jstat/lineCounts2.awk ! test/sun/tools/jstat/lineCounts3.awk ! test/sun/tools/jstat/lineCounts4.awk ! test/sun/tools/jstat/options1.out ! test/sun/tools/jstat/options2.out ! test/sun/tools/jstat/timeStamp1.awk ! test/sun/tools/jstatd/jstatGcutilOutput1.awk
hg: jdk8/tl/jdk: 2 new changesets
Changeset: c6d77b2b4478 Author:stefank Date: 2013-01-22 13:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6d77b2b4478 8006506: Add test for redefining methods in backtraces to java/lang/instrument tests Reviewed-by: sspitsyn, coleenp + test/java/lang/instrument/RedefineMethodInBacktrace.sh + test/java/lang/instrument/RedefineMethodInBacktraceAgent.java + test/java/lang/instrument/RedefineMethodInBacktraceApp.java + test/java/lang/instrument/RedefineMethodInBacktraceTarget.java + test/java/lang/instrument/RedefineMethodInBacktraceTarget_2.java Changeset: 0e93015e77f6 Author:stefank Date: 2013-01-22 15:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e93015e77f6 7140852: Add test for 7022100 Reviewed-by: sspitsyn, coleenp + test/java/lang/instrument/RedefineMethodWithAnnotations.sh + test/java/lang/instrument/RedefineMethodWithAnnotationsAgent.java + test/java/lang/instrument/RedefineMethodWithAnnotationsAnnotations.java + test/java/lang/instrument/RedefineMethodWithAnnotationsApp.java + test/java/lang/instrument/RedefineMethodWithAnnotationsTarget.java + test/java/lang/instrument/RedefineMethodWithAnnotationsTarget_2.java
