hg: hsx/hotspot-rt/hotspot: 7182152: Instrumentation hot swap test incorrect monitor count
Changeset: 8d9fc28831cc Author:dcubed Date: 2013-02-06 14:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8d9fc28831cc 7182152: Instrumentation hot swap test incorrect monitor count Summary: Add/refine new tracing support using -XX:TraceRedefineClasses=16384. Reviewed-by: coleenp, acorn, sspitsyn ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/accessFlags.hpp
hg: jdk8/tl/jdk: 8006995: java launcher fails to open executable JAR > 2GB
Changeset: 2f1505c49e79 Author:martin Date: 2013-02-06 17:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f1505c49e79 8006995: java launcher fails to open executable JAR > 2GB Summary: Use O_LARGEFILE consistently when opening jar files Reviewed-by: alanb, sherman ! src/share/bin/parse_manifest.c
Re: RR(S): 8007536 Incorrect copyright header in JDP files
Looks good. Cheers, Mikael On 2013-02-06 06:05, Dmitry Samersoff wrote: Hi Everyone, Please, review this, copyright-only fix http://cr.openjdk.java.net/~dsamersoff/8007536.JDP-COPYRIGHT/webrev.01/jdk/ -Dmitry
hg: jdk8/tl/langtools: 8007698: jtreg test T6306137.java won't compile with ASCII encoding
Changeset: b386b8c45387 Author:jjh Date: 2013-02-06 23:10 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b386b8c45387 8007698: jtreg test T6306137.java won't compile with ASCII encoding Reviewed-by: ksrini ! test/tools/javac/api/T6306137.java
Re: JVM/TI code review request (XS and M) (7182152)
Thanks Serguei!
Dan
On 2/6/13 1:22 PM, serguei.spit...@oracle.com wrote:
Looks good.
Thanks,
Serguei
On 2/6/13 11:54 AM, Karen Kinnear wrote:
Thank you Dan - this is much better and sets a good model for the
rest of us.
thanks,
Karen
On Feb 6, 2013, at 9:05 AM, Daniel D. Daugherty wrote:
Adding other alias and people back onto the thread...
Thanks for the re-review!
On 2/6/13 6:41 AM, Coleen Phillimore wrote:
This is good that you added the INCLUDE_JVMTI. I didn't think it'd
add that much space, but it a good change.
I didn't think it would add much space either, but...
It gave me a chance to check out the MinimalVM stuff a bit and
it serves to identify those pieces of code as being associated
with JVM/TI.
Karen and Serguei, when you get the chance, please re-review.
Again, thanks for the re-review!
Dan
Thumbs up!
Coleen
On 2/6/2013 12:59 AM, Daniel D. Daugherty wrote:
Greetings,
The JPDA stack testing finished with no new regressions on HSX-23.6,
HSX-24 or HSX-25. The HSX-24 version of the fix has been pushed.
I've updated the HSX-25 version of the fix due to Karen's comments
about the MinimalVM configuration in Code Review Round 1. In this
latest round for HSX-25, I've made use of the INCLUDE_JVMTI define
to limit the exposure of new tracing code to configurations that
include JVM/TI support. The MinimalVM does not support JVM/TI so
none of the new code needs to be included there. While I was at it,
I also excluded some other JVM/TI RedefineClasses() support code
from the MinimalVM config that I hadn't previously touched.
In short, none of the functionality has been changed in this round.
Just the way it is built or not built has been changed.
Here is the URL for the latest HSX-25 webrev:
http://cr.openjdk.java.net/~dcubed/7182152-webrev/2-hsx25/
Thanks, in advance, for more comments, suggestions or questions.
Dan
On 2/4/13 2:08 PM, Daniel D. Daugherty wrote:
Greetings,
I've updated the fix due to comments in Code Review Round 0.
Here is a summary of changes made to the various files:
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24)
src/share/vm/oops/cpCache.cpp (HSX-25)
src/share/vm/oops/klassVtable.cpp
- removed the new RC_TRACE_NO_CR() macro calls at Coleen's
request;
these files are outside of JVM/TI RedefineClasses proper so the
tracing/debug style should not be dictated by JVM/TI
RedefineClasses
style that is currently in use
- did not touch the existing RC_TRACE... macros in the file;
removing
the existing macro calls would be outside the scope of this bug
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24)
src/share/vm/oops/cpCache.cpp (HSX-25)
- copy a comment from
ConstantPoolCacheEntry::is_interesting_method_entry()
to ConstantPoolCacheEntry::check_no_old_or_obsolete_entries()
src/share/vm/oops/klassVtable.cpp
- Copied the new comment intended to prevent the "break" from
re-materializing again from klassItable::adjust_method_entries()
to klassVtable::adjust_method_entries(); yes, I'm paranoid.
In the HSX-25 version only:
src/share/vm/oops/metadata.hpp
- revert changes
src/share/vm/oops/cpCacheOop.cpp
src/share/vm/oops/klassVtable.cpp
- wrap uses of is_valid() in NOT_PRODUCT macro as appropriate
Here are the URLs for the updated webrevs:
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx23.6/
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx24/
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx25/
The JPDA stack testing that I started on Friday is still running on
WinXP so I'm blocked for checking the recompile due to these
changes.
I'll start a recompile on Solaris X86, but that will take some time.
Thanks, in advance, for more comments, suggestions or questions.
Dan
On 2/1/13 12:55 PM, Daniel D. Daugherty wrote:
Greetings,
I have a fix for the following JVM/TI bug:
7182152 Instrumentation hot swap test incorrect monitor count
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182152
https://jbs.oracle.com/bugs/browse/JDK-7182152
The fix for the bug in the product code is one line:
src/share/vm/oops/klassVtable.cpp:
@@ -992,18 +1020,50 @@
// RC_TRACE macro has an embedded ResourceMark
RC_TRACE(0x0020, ("itable method update: %s(%s)",
new_method->name()->as_C_string(),
new_method->signature()->as_C_string()));
}
-break;
+// cannot 'break' here; see for-loop comment above.
}
ime++;
}
}
}
and is applicable to JDK7u10/HSX-23.6 and JDK7u14/HSX-24. Coleen
already fixed the bug as part of the Perm Gen Removal (PGR) project
in HSX-25. Yes, we found a 1-line bug fix buried in the monster PGR
changeset. Many thanks to Coleen for her help in this bug hunt!
The rest of the code in the webrevs are:
- additional JVM/TI tracing code backported from Coleen's PGR
changeset
- additional JVM/TI tracing code added by me and forward ported
to HSX-25
- a new -XX:TraceRedefineClasses=16384 f
Re: JVM/TI code review request (XS and M) (7182152)
Already reviewed. :)
It is good.
Thanks,
Serguei
On 2/6/13 12:09 PM, Daniel D. Daugherty wrote:
Karen,
Thanks for the re-review!
Serguei, just waiting for you to chime in!!
Dan
On 2/6/13 12:54 PM, Karen Kinnear wrote:
Thank you Dan - this is much better and sets a good model for the
rest of us.
thanks,
Karen
On Feb 6, 2013, at 9:05 AM, Daniel D. Daugherty wrote:
Adding other alias and people back onto the thread...
Thanks for the re-review!
On 2/6/13 6:41 AM, Coleen Phillimore wrote:
This is good that you added the INCLUDE_JVMTI. I didn't think it'd
add that much space, but it a good change.
I didn't think it would add much space either, but...
It gave me a chance to check out the MinimalVM stuff a bit and
it serves to identify those pieces of code as being associated
with JVM/TI.
Karen and Serguei, when you get the chance, please re-review.
Again, thanks for the re-review!
Dan
Thumbs up!
Coleen
On 2/6/2013 12:59 AM, Daniel D. Daugherty wrote:
Greetings,
The JPDA stack testing finished with no new regressions on HSX-23.6,
HSX-24 or HSX-25. The HSX-24 version of the fix has been pushed.
I've updated the HSX-25 version of the fix due to Karen's comments
about the MinimalVM configuration in Code Review Round 1. In this
latest round for HSX-25, I've made use of the INCLUDE_JVMTI define
to limit the exposure of new tracing code to configurations that
include JVM/TI support. The MinimalVM does not support JVM/TI so
none of the new code needs to be included there. While I was at it,
I also excluded some other JVM/TI RedefineClasses() support code
from the MinimalVM config that I hadn't previously touched.
In short, none of the functionality has been changed in this round.
Just the way it is built or not built has been changed.
Here is the URL for the latest HSX-25 webrev:
http://cr.openjdk.java.net/~dcubed/7182152-webrev/2-hsx25/
Thanks, in advance, for more comments, suggestions or questions.
Dan
On 2/4/13 2:08 PM, Daniel D. Daugherty wrote:
Greetings,
I've updated the fix due to comments in Code Review Round 0.
Here is a summary of changes made to the various files:
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24)
src/share/vm/oops/cpCache.cpp (HSX-25)
src/share/vm/oops/klassVtable.cpp
- removed the new RC_TRACE_NO_CR() macro calls at Coleen's
request;
these files are outside of JVM/TI RedefineClasses proper so the
tracing/debug style should not be dictated by JVM/TI
RedefineClasses
style that is currently in use
- did not touch the existing RC_TRACE... macros in the file;
removing
the existing macro calls would be outside the scope of this bug
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24)
src/share/vm/oops/cpCache.cpp (HSX-25)
- copy a comment from
ConstantPoolCacheEntry::is_interesting_method_entry()
to ConstantPoolCacheEntry::check_no_old_or_obsolete_entries()
src/share/vm/oops/klassVtable.cpp
- Copied the new comment intended to prevent the "break" from
re-materializing again from klassItable::adjust_method_entries()
to klassVtable::adjust_method_entries(); yes, I'm paranoid.
In the HSX-25 version only:
src/share/vm/oops/metadata.hpp
- revert changes
src/share/vm/oops/cpCacheOop.cpp
src/share/vm/oops/klassVtable.cpp
- wrap uses of is_valid() in NOT_PRODUCT macro as appropriate
Here are the URLs for the updated webrevs:
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx23.6/
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx24/
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx25/
The JPDA stack testing that I started on Friday is still running on
WinXP so I'm blocked for checking the recompile due to these
changes.
I'll start a recompile on Solaris X86, but that will take some time.
Thanks, in advance, for more comments, suggestions or questions.
Dan
On 2/1/13 12:55 PM, Daniel D. Daugherty wrote:
Greetings,
I have a fix for the following JVM/TI bug:
7182152 Instrumentation hot swap test incorrect monitor count
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182152
https://jbs.oracle.com/bugs/browse/JDK-7182152
The fix for the bug in the product code is one line:
src/share/vm/oops/klassVtable.cpp:
@@ -992,18 +1020,50 @@
// RC_TRACE macro has an embedded ResourceMark
RC_TRACE(0x0020, ("itable method update: %s(%s)",
new_method->name()->as_C_string(),
new_method->signature()->as_C_string()));
}
-break;
+// cannot 'break' here; see for-loop comment above.
}
ime++;
}
}
}
and is applicable to JDK7u10/HSX-23.6 and JDK7u14/HSX-24. Coleen
already fixed the bug as part of the Perm Gen Removal (PGR) project
in HSX-25. Yes, we found a 1-line bug fix buried in the monster PGR
changeset. Many thanks to Coleen for her help in this bug hunt!
The rest of the code in the webrevs are:
- additional JVM/TI tracing code backported from Coleen's PGR
changeset
- additional JVM/TI tracing code adde
Re: JVM/TI code review request (XS and M) (7182152)
Looks good.
Thanks,
Serguei
On 2/6/13 11:54 AM, Karen Kinnear wrote:
Thank you Dan - this is much better and sets a good model for the rest of us.
thanks,
Karen
On Feb 6, 2013, at 9:05 AM, Daniel D. Daugherty wrote:
Adding other alias and people back onto the thread...
Thanks for the re-review!
On 2/6/13 6:41 AM, Coleen Phillimore wrote:
This is good that you added the INCLUDE_JVMTI. I didn't think it'd add that
much space, but it a good change.
I didn't think it would add much space either, but...
It gave me a chance to check out the MinimalVM stuff a bit and
it serves to identify those pieces of code as being associated
with JVM/TI.
Karen and Serguei, when you get the chance, please re-review.
Again, thanks for the re-review!
Dan
Thumbs up!
Coleen
On 2/6/2013 12:59 AM, Daniel D. Daugherty wrote:
Greetings,
The JPDA stack testing finished with no new regressions on HSX-23.6,
HSX-24 or HSX-25. The HSX-24 version of the fix has been pushed.
I've updated the HSX-25 version of the fix due to Karen's comments
about the MinimalVM configuration in Code Review Round 1. In this
latest round for HSX-25, I've made use of the INCLUDE_JVMTI define
to limit the exposure of new tracing code to configurations that
include JVM/TI support. The MinimalVM does not support JVM/TI so
none of the new code needs to be included there. While I was at it,
I also excluded some other JVM/TI RedefineClasses() support code
from the MinimalVM config that I hadn't previously touched.
In short, none of the functionality has been changed in this round.
Just the way it is built or not built has been changed.
Here is the URL for the latest HSX-25 webrev:
http://cr.openjdk.java.net/~dcubed/7182152-webrev/2-hsx25/
Thanks, in advance, for more comments, suggestions or questions.
Dan
On 2/4/13 2:08 PM, Daniel D. Daugherty wrote:
Greetings,
I've updated the fix due to comments in Code Review Round 0.
Here is a summary of changes made to the various files:
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24)
src/share/vm/oops/cpCache.cpp (HSX-25)
src/share/vm/oops/klassVtable.cpp
- removed the new RC_TRACE_NO_CR() macro calls at Coleen's request;
these files are outside of JVM/TI RedefineClasses proper so the
tracing/debug style should not be dictated by JVM/TI RedefineClasses
style that is currently in use
- did not touch the existing RC_TRACE... macros in the file; removing
the existing macro calls would be outside the scope of this bug
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24)
src/share/vm/oops/cpCache.cpp (HSX-25)
- copy a comment from ConstantPoolCacheEntry::is_interesting_method_entry()
to ConstantPoolCacheEntry::check_no_old_or_obsolete_entries()
src/share/vm/oops/klassVtable.cpp
- Copied the new comment intended to prevent the "break" from
re-materializing again from klassItable::adjust_method_entries()
to klassVtable::adjust_method_entries(); yes, I'm paranoid.
In the HSX-25 version only:
src/share/vm/oops/metadata.hpp
- revert changes
src/share/vm/oops/cpCacheOop.cpp
src/share/vm/oops/klassVtable.cpp
- wrap uses of is_valid() in NOT_PRODUCT macro as appropriate
Here are the URLs for the updated webrevs:
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx23.6/
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx24/
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx25/
The JPDA stack testing that I started on Friday is still running on
WinXP so I'm blocked for checking the recompile due to these changes.
I'll start a recompile on Solaris X86, but that will take some time.
Thanks, in advance, for more comments, suggestions or questions.
Dan
On 2/1/13 12:55 PM, Daniel D. Daugherty wrote:
Greetings,
I have a fix for the following JVM/TI bug:
7182152 Instrumentation hot swap test incorrect monitor count
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182152
https://jbs.oracle.com/bugs/browse/JDK-7182152
The fix for the bug in the product code is one line:
src/share/vm/oops/klassVtable.cpp:
@@ -992,18 +1020,50 @@
// RC_TRACE macro has an embedded ResourceMark
RC_TRACE(0x0020, ("itable method update: %s(%s)",
new_method->name()->as_C_string(),
new_method->signature()->as_C_string()));
}
-break;
+// cannot 'break' here; see for-loop comment above.
}
ime++;
}
}
}
and is applicable to JDK7u10/HSX-23.6 and JDK7u14/HSX-24. Coleen
already fixed the bug as part of the Perm Gen Removal (PGR) project
in HSX-25. Yes, we found a 1-line bug fix buried in the monster PGR
changeset. Many thanks to Coleen for her help in this bug hunt!
The rest of the code in the webrevs are:
- additional JVM/TI tracing code backported from Coleen's PGR changeset
- additional JVM/TI tracing code added by me and forward ported to HSX-25
- a new -XX:TraceRedefineClasses=16384 flag value for finding these
elusive old or obsolete methods
- exposure of s
Re: JVM/TI code review request (XS and M) (7182152)
Karen,
Thanks for the re-review!
Serguei, just waiting for you to chime in!!
Dan
On 2/6/13 12:54 PM, Karen Kinnear wrote:
Thank you Dan - this is much better and sets a good model for the rest of us.
thanks,
Karen
On Feb 6, 2013, at 9:05 AM, Daniel D. Daugherty wrote:
Adding other alias and people back onto the thread...
Thanks for the re-review!
On 2/6/13 6:41 AM, Coleen Phillimore wrote:
This is good that you added the INCLUDE_JVMTI. I didn't think it'd add that
much space, but it a good change.
I didn't think it would add much space either, but...
It gave me a chance to check out the MinimalVM stuff a bit and
it serves to identify those pieces of code as being associated
with JVM/TI.
Karen and Serguei, when you get the chance, please re-review.
Again, thanks for the re-review!
Dan
Thumbs up!
Coleen
On 2/6/2013 12:59 AM, Daniel D. Daugherty wrote:
Greetings,
The JPDA stack testing finished with no new regressions on HSX-23.6,
HSX-24 or HSX-25. The HSX-24 version of the fix has been pushed.
I've updated the HSX-25 version of the fix due to Karen's comments
about the MinimalVM configuration in Code Review Round 1. In this
latest round for HSX-25, I've made use of the INCLUDE_JVMTI define
to limit the exposure of new tracing code to configurations that
include JVM/TI support. The MinimalVM does not support JVM/TI so
none of the new code needs to be included there. While I was at it,
I also excluded some other JVM/TI RedefineClasses() support code
from the MinimalVM config that I hadn't previously touched.
In short, none of the functionality has been changed in this round.
Just the way it is built or not built has been changed.
Here is the URL for the latest HSX-25 webrev:
http://cr.openjdk.java.net/~dcubed/7182152-webrev/2-hsx25/
Thanks, in advance, for more comments, suggestions or questions.
Dan
On 2/4/13 2:08 PM, Daniel D. Daugherty wrote:
Greetings,
I've updated the fix due to comments in Code Review Round 0.
Here is a summary of changes made to the various files:
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24)
src/share/vm/oops/cpCache.cpp (HSX-25)
src/share/vm/oops/klassVtable.cpp
- removed the new RC_TRACE_NO_CR() macro calls at Coleen's request;
these files are outside of JVM/TI RedefineClasses proper so the
tracing/debug style should not be dictated by JVM/TI RedefineClasses
style that is currently in use
- did not touch the existing RC_TRACE... macros in the file; removing
the existing macro calls would be outside the scope of this bug
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24)
src/share/vm/oops/cpCache.cpp (HSX-25)
- copy a comment from ConstantPoolCacheEntry::is_interesting_method_entry()
to ConstantPoolCacheEntry::check_no_old_or_obsolete_entries()
src/share/vm/oops/klassVtable.cpp
- Copied the new comment intended to prevent the "break" from
re-materializing again from klassItable::adjust_method_entries()
to klassVtable::adjust_method_entries(); yes, I'm paranoid.
In the HSX-25 version only:
src/share/vm/oops/metadata.hpp
- revert changes
src/share/vm/oops/cpCacheOop.cpp
src/share/vm/oops/klassVtable.cpp
- wrap uses of is_valid() in NOT_PRODUCT macro as appropriate
Here are the URLs for the updated webrevs:
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx23.6/
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx24/
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx25/
The JPDA stack testing that I started on Friday is still running on
WinXP so I'm blocked for checking the recompile due to these changes.
I'll start a recompile on Solaris X86, but that will take some time.
Thanks, in advance, for more comments, suggestions or questions.
Dan
On 2/1/13 12:55 PM, Daniel D. Daugherty wrote:
Greetings,
I have a fix for the following JVM/TI bug:
7182152 Instrumentation hot swap test incorrect monitor count
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182152
https://jbs.oracle.com/bugs/browse/JDK-7182152
The fix for the bug in the product code is one line:
src/share/vm/oops/klassVtable.cpp:
@@ -992,18 +1020,50 @@
// RC_TRACE macro has an embedded ResourceMark
RC_TRACE(0x0020, ("itable method update: %s(%s)",
new_method->name()->as_C_string(),
new_method->signature()->as_C_string()));
}
-break;
+// cannot 'break' here; see for-loop comment above.
}
ime++;
}
}
}
and is applicable to JDK7u10/HSX-23.6 and JDK7u14/HSX-24. Coleen
already fixed the bug as part of the Perm Gen Removal (PGR) project
in HSX-25. Yes, we found a 1-line bug fix buried in the monster PGR
changeset. Many thanks to Coleen for her help in this bug hunt!
The rest of the code in the webrevs are:
- additional JVM/TI tracing code backported from Coleen's PGR changeset
- additional JVM/TI tracing code added by me and forward ported to HSX-25
- a new -XX:TraceRedefineClasses=16384 flag value for finding
Re: JVM/TI code review request (XS and M) (7182152)
Greetings,
I've revised the tests based on Coleen's and Serguei's feedback
in Code Review Round 0.
Here is the URL for the webrev for Code Review Round 1:
http://cr.openjdk.java.net/~dcubed/8007420-webrev/1-jdk8-tl/
Summary of the changes:
- RedefineAbstractClass.sh - cleaned up the header comment
- RedefineAbstractClass.sh
- more clear description of what's being tested
- add comments describing what the guarantee failure looks like
- add checks for proper pre-RedefineClasses output
- add checks for proper post-RedefineClasses output
- RedefineSubclassWithTwoInterfacesApp.java
- RedefineSubclassWithTwoInterfacesRemote.java
- refactor the test app's echo() method call into echo1() and
echo2() so it is easier to check for the failure mode
- RedefineSubclassWithTwoInterfacesImpl.java
- RedefineSubclassWithTwoInterfacesImpl_1.java
- add comment to explain why these sources are identical
Diffs are below since the webrev above is relative to JDK8-T&L
and everything is "new".
Dan
Here are diffs (ignoring whitespace) to make it clear what has
changed between Code Review Round 0 and Code Review Round 1:
$ diff -w test/com/sun/jdi/RedefineAbstractClass.sh{.cr0,}
31a32
> # @author Daniel D. Daugherty
$ diff -w
test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh{.cr0,}
26c26,27
< # @summary Redefining a subclass that implements two interfaces is broken.
---
> # @summary Redefine a subclass that implements two interfaces and
> # verify that the right methods are called.
101a103,104
>
> echo "INFO: "
102a106,107
> echo "INFO: "
>
108,112c113,127
< MESG="guarantee"
< grep "$MESG" output.log
< result=$?
< if [ "$result" = 0 ]; then
< echo "FAIL: found '$MESG' in the test output"
---
> # When this bug manifests, RedefineClasses() will fail to update
> # one of the itable entries to refer to the new method. The log
> # will include the following line when the bug occurs:
> #
> # guarantee(false) failed: OLD and/or OBSOLETE method(s) found
> #
> # If this guarantee happens, the test should fail in the status
> # check above, but just in case it doesn't, we check for "guarantee".
> #
>
> FAIL_MESG="guarantee"
> grep "$FAIL_MESG" output.log
> status=$?
> if [ "$status" = 0 ]; then
> echo "FAIL: found '$FAIL_MESG' in the test output."
115c130,131
< echo "PASS: did NOT find '$MESG' in the test output"
---
> echo "INFO: did NOT find '$FAIL_MESG' in the test output."
> # be optimistic here
118a135,164
> PASS1_MESG="before any redefines"
> cnt=`grep "$PASS1_MESG" output.log | grep 'version-0' | wc -l`
> case "$cnt" in
> 2)
> echo "INFO: found 2 version-0 '$PASS1_MESG' mesgs."
> ;;
> *)
> echo "FAIL: did NOT find 2 version-0 '$PASS1_MESG' mesgs."
> echo "INFO: grep '$PASS1_MESG' output:"
> grep "$PASS1_MESG" output.log
> result=1
> esac
>
> PASS2_MESG="after redefine"
> cnt=`grep "$PASS2_MESG" output.log | grep 'version-1' | wc -l`
> case "$cnt" in
> 2)
> echo "INFO: found 2 version-1 '$PASS2_MESG' mesgs."
> ;;
> *)
> echo "FAIL: did NOT find 2 version-1 '$PASS2_MESG' mesgs."
> echo "INFO: grep '$PASS2_MESG' output:"
> grep "$PASS2_MESG" output.log
> result=1
> esac
>
> if [ "$result" = 0 ]; then
> echo "PASS: test passed both positive and negative output checks."
> fi
>
$ diff
test/java/lang/instrument/RedefineSubclassWithTwoInterfacesApp.java{.cr0,}
43,45c43,45
< // make an echo() call before any redefinitions:
< mesg = remote.echo("test message #0");
< System.out.println("RedefineSubclassWithTwoInterfacesApp: mesg='"
---
> // make echo() calls before any redefinitions:
> mesg = remote.echo1("test message #1.1");
> System.out.println("RedefineSubclassWithTwoInterfacesApp: echo1 mesg='"
46a47,49
> mesg = remote.echo2("test message #2.1");
> System.out.println("RedefineSubclassWithTwoInterfacesApp: echo2 mesg='"
> + mesg + "' before any redefines");
54,56c57,62
< mesg = remote.echo("test message #1");
< System.out.println("RedefineSubclassWithTwoInterfacesApp: mesg='"
< + mesg + "' after redefine #1");
---
> mesg = remote.echo1("test message #1.2");
> System.out.println("RedefineSubclassWithTwoInterfacesApp: echo1 mesg='"
> + mesg + "' after redefine");
> mesg = remote.echo2("test message #2.2");
> System.out.println("RedefineSubclassWithTwoInterfacesApp: echo2 mesg='"
> + mesg + "' after redefine");
$ diff
test/java/lang/instrument/RedefineSubclassWithTwoInterfacesImpl.java{.cr0,}
23a24,27
> // Reproducing this bug only requires an EMCP version of the
> // RedefineSubclassWithTwoInterfacesImpl class so
> // RedefineSubclassWithTwoInterfacesImpl.java and
> // RedefineSubclassWithTwoInterfacesImpl_1.java are identical.
$ diff
test/java/lang/instrument/RedefineSubclassWithTwoInterfacesImpl_1.java{.cr0,}
23a24,27
> // Reproducing this bug only requires an EMCP version of the
> // RedefineSubcla
Re: JVM/TI code review request (XS and M) (7182152)
Thank you Dan - this is much better and sets a good model for the rest of us.
thanks,
Karen
On Feb 6, 2013, at 9:05 AM, Daniel D. Daugherty wrote:
> Adding other alias and people back onto the thread...
>
> Thanks for the re-review!
>
>
> On 2/6/13 6:41 AM, Coleen Phillimore wrote:
>>
>> This is good that you added the INCLUDE_JVMTI. I didn't think it'd add that
>> much space, but it a good change.
>
> I didn't think it would add much space either, but...
>
> It gave me a chance to check out the MinimalVM stuff a bit and
> it serves to identify those pieces of code as being associated
> with JVM/TI.
>
> Karen and Serguei, when you get the chance, please re-review.
>
> Again, thanks for the re-review!
>
> Dan
>
>
>> Thumbs up!
>> Coleen
>>
>> On 2/6/2013 12:59 AM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> The JPDA stack testing finished with no new regressions on HSX-23.6,
>>> HSX-24 or HSX-25. The HSX-24 version of the fix has been pushed.
>>>
>>> I've updated the HSX-25 version of the fix due to Karen's comments
>>> about the MinimalVM configuration in Code Review Round 1. In this
>>> latest round for HSX-25, I've made use of the INCLUDE_JVMTI define
>>> to limit the exposure of new tracing code to configurations that
>>> include JVM/TI support. The MinimalVM does not support JVM/TI so
>>> none of the new code needs to be included there. While I was at it,
>>> I also excluded some other JVM/TI RedefineClasses() support code
>>> from the MinimalVM config that I hadn't previously touched.
>>>
>>> In short, none of the functionality has been changed in this round.
>>> Just the way it is built or not built has been changed.
>>>
>>> Here is the URL for the latest HSX-25 webrev:
>>>
>>> http://cr.openjdk.java.net/~dcubed/7182152-webrev/2-hsx25/
>>>
>>> Thanks, in advance, for more comments, suggestions or questions.
>>>
>>> Dan
>>>
>>>
>>> On 2/4/13 2:08 PM, Daniel D. Daugherty wrote:
Greetings,
I've updated the fix due to comments in Code Review Round 0.
Here is a summary of changes made to the various files:
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24)
src/share/vm/oops/cpCache.cpp (HSX-25)
src/share/vm/oops/klassVtable.cpp
- removed the new RC_TRACE_NO_CR() macro calls at Coleen's request;
these files are outside of JVM/TI RedefineClasses proper so the
tracing/debug style should not be dictated by JVM/TI RedefineClasses
style that is currently in use
- did not touch the existing RC_TRACE... macros in the file; removing
the existing macro calls would be outside the scope of this bug
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24)
src/share/vm/oops/cpCache.cpp (HSX-25)
- copy a comment from
ConstantPoolCacheEntry::is_interesting_method_entry()
to ConstantPoolCacheEntry::check_no_old_or_obsolete_entries()
src/share/vm/oops/klassVtable.cpp
- Copied the new comment intended to prevent the "break" from
re-materializing again from klassItable::adjust_method_entries()
to klassVtable::adjust_method_entries(); yes, I'm paranoid.
In the HSX-25 version only:
src/share/vm/oops/metadata.hpp
- revert changes
src/share/vm/oops/cpCacheOop.cpp
src/share/vm/oops/klassVtable.cpp
- wrap uses of is_valid() in NOT_PRODUCT macro as appropriate
Here are the URLs for the updated webrevs:
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx23.6/
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx24/
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx25/
The JPDA stack testing that I started on Friday is still running on
WinXP so I'm blocked for checking the recompile due to these changes.
I'll start a recompile on Solaris X86, but that will take some time.
Thanks, in advance, for more comments, suggestions or questions.
Dan
On 2/1/13 12:55 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> I have a fix for the following JVM/TI bug:
>
>7182152 Instrumentation hot swap test incorrect monitor count
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182152
>https://jbs.oracle.com/bugs/browse/JDK-7182152
>
> The fix for the bug in the product code is one line:
>
> src/share/vm/oops/klassVtable.cpp:
>
> @@ -992,18 +1020,50 @@
> // RC_TRACE macro has an embedded ResourceMark
> RC_TRACE(0x0020, ("itable method update: %s(%s)",
> new_method->name()->as_C_string(),
> new_method->signature()->as_C_string()));
> }
> -break;
> +// cannot 'break' here; see for-loop comment above.
> }
> ime++;
> }
> }
> }
>
> and is applicable to JDK7u10/HSX-23.6 and JDK7u14/HSX-24. Coleen
> already fi
hg: jdk8/tl/jdk: 8006505: additional changes for JSR 310 support
Changeset: 1574fa3df1c0 Author:lancea Date: 2013-02-06 14:15 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1574fa3df1c0 8006505: additional changes for JSR 310 support Reviewed-by: naoto, ulfzibis ! src/share/classes/java/sql/JDBCType.java ! src/share/classes/java/sql/SQLInput.java ! src/share/classes/java/sql/SQLOutput.java ! src/share/classes/java/sql/Types.java
hg: jdk8/tl: 8004726: Link bug ids to jbs rather than monaco.
Changeset: 168dd033604a Author:mduigou Date: 2013-02-06 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/168dd033604a 8004726: Link bug ids to jbs rather than monaco. Reviewed-by: ohair, chegar, katleman ! make/scripts/webrev.ksh
Re: 8007277: JDK-8002048 testcase fails to compile
Mandy,
The test designed to leave as much as possible to JTReg but work without
JTRreg as well.
so if test run under JTReg, --no-compile option used and test is
compiled by JTReg it requires both @compile header tag and explicit
compilation code.
Actual changes contains a comment explaining it.
_testclasses variable points to ${TESTCLASSES} under JTreg or
to `pwd`/.classes directory common for all my tests, if run standalone.
-Dmitry
On 2013-02-06 19:50, Mandy Chung wrote:
>
> On 2/6/2013 2:47 AM, Alan Bateman wrote:
>>
>> diff --git a/test/sun/management/jdp/JdpTest.sh
>> b/test/sun/management/jdp/JdpTest.sh
>> --- a/test/sun/management/jdp/JdpTest.sh
>> +++ b/test/sun/management/jdp/JdpTest.sh
>> @@ -23,7 +23,7 @@
>>
>> # @test
>> # @bug 7169888
>> -# @build JdpUnitTest JdpClient JdpDoSomething
>> +# @compile -XDignore.symbol.file JdpUnitTest.java JdpClient.java
>> JdpDoSomething.java
>> # @run shell JdpTest.sh --jtreg --no-compile
>> # @summary No word Failed expected in the test output
>>
>> @@ -55,7 +55,7 @@
>> rm -f ${_testclasses}/*.class
>>
>> # Compile testcase
>> -${TESTJAVA}/bin/javac -d ${_testclasses} JdpUnitTest.java \
>> +${COMPILEJAVA}/bin/javac -XDignore.symbol.file -d ${_testclasses}
>> JdpUnitTest.java \
>> JdpDoSomething.java \
>> JdpClient.java
>
> The fix itself looks good. This question is more for the original test:
> Is @compile line needed? Is $_testclasses same as $TESTCLASSES?
>
> Mandy
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
hg: jdk8/tl/langtools: 8007566: DocLint too aggressive with not allowed here:
Changeset: 153d20d0cac5 Author:jjg Date: 2013-02-06 07:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/153d20d0cac5 8007566: DocLint too aggressive with not allowed here: Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/ParaTagTest.java
Re: 8007277: JDK-8002048 testcase fails to compile
On 2/6/2013 2:47 AM, Alan Bateman wrote:
diff --git a/test/sun/management/jdp/JdpTest.sh
b/test/sun/management/jdp/JdpTest.sh
--- a/test/sun/management/jdp/JdpTest.sh
+++ b/test/sun/management/jdp/JdpTest.sh
@@ -23,7 +23,7 @@
# @test
# @bug 7169888
-# @build JdpUnitTest JdpClient JdpDoSomething
+# @compile -XDignore.symbol.file JdpUnitTest.java JdpClient.java
JdpDoSomething.java
# @run shell JdpTest.sh --jtreg --no-compile
# @summary No word Failed expected in the test output
@@ -55,7 +55,7 @@
rm -f ${_testclasses}/*.class
# Compile testcase
-${TESTJAVA}/bin/javac -d ${_testclasses} JdpUnitTest.java \
+${COMPILEJAVA}/bin/javac -XDignore.symbol.file -d ${_testclasses}
JdpUnitTest.java \
JdpDoSomething.java \
JdpClient.java
The fix itself looks good. This question is more for the original test:
Is @compile line needed? Is $_testclasses same as $TESTCLASSES?
Mandy
Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
Alan,
thanks for the review!
// Katja
On 02/05/2013 12:54 PM, Alan Bateman wrote:
On 05/02/2013 10:51, Yekaterina Kantserova wrote:
On 02/04/2013 02:18 PM, Alan Bateman wrote:
On 04/02/2013 11:03, Yekaterina Kantserova wrote:
But JDKToolFinder.getJDKTool is used even for finding java, e.g. I
need to fork a java process - JDKToolFinder.getJDKTool("java") for
some JRE tests?
It might be better to rename JDKToolFinder to something like
JdkFinder and have it define getJavaLauncher() and getTool(String
tool) methods.
I think it's good idea to separate java launcher and tools. Here is
the new JdkFinder:
http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/JdkFinder.java.html.
It now possible to retrieve java/tools both from the test.jdk and
compile.jdk.
If you don't agree then you could at least change
ProcessTools.createJavaProcessBuilder so that it looks like "java"
in the JDK/JRE under test.
JDKToolFinder.getJDKTool("java") became JdkFinder.getJavaLauncher in
the createJavaProcessBuilder
(http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/ProcessTools.java.html).
-Alan.
It looks right to me now.
-Alan
hg: jdk8/tl/langtools: 2 new changesets
Changeset: 1df20330f6bd Author:mcimadamore Date: 2013-02-06 14:03 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1df20330f6bd 8007463: Cleanup inference related classes Summary: Make Infer.InferenceContext an inner class; adjust bound replacement logic in Type.UndetVar Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/util/List.java ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/lib/DPrinter.java Changeset: 8cdd96f2fdb9 Author:mcimadamore Date: 2013-02-06 14:04 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8cdd96f2fdb9 8007479: Refactor DeferredAttrContext so that it points to parent context Summary: Move DeferredAttrNode out of DeferredAttrContext; add support for nested deferred contexts Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java
RR(S): 8007536 Incorrect copyright header in JDP files
Hi Everyone, Please, review this, copyright-only fix http://cr.openjdk.java.net/~dsamersoff/8007536.JDP-COPYRIGHT/webrev.01/jdk/ -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer
Re: JVM/TI code review request (XS and M) (7182152)
Adding other alias and people back onto the thread...
Thanks for the re-review!
On 2/6/13 6:41 AM, Coleen Phillimore wrote:
This is good that you added the INCLUDE_JVMTI. I didn't think it'd
add that much space, but it a good change.
I didn't think it would add much space either, but...
It gave me a chance to check out the MinimalVM stuff a bit and
it serves to identify those pieces of code as being associated
with JVM/TI.
Karen and Serguei, when you get the chance, please re-review.
Again, thanks for the re-review!
Dan
Thumbs up!
Coleen
On 2/6/2013 12:59 AM, Daniel D. Daugherty wrote:
Greetings,
The JPDA stack testing finished with no new regressions on HSX-23.6,
HSX-24 or HSX-25. The HSX-24 version of the fix has been pushed.
I've updated the HSX-25 version of the fix due to Karen's comments
about the MinimalVM configuration in Code Review Round 1. In this
latest round for HSX-25, I've made use of the INCLUDE_JVMTI define
to limit the exposure of new tracing code to configurations that
include JVM/TI support. The MinimalVM does not support JVM/TI so
none of the new code needs to be included there. While I was at it,
I also excluded some other JVM/TI RedefineClasses() support code
from the MinimalVM config that I hadn't previously touched.
In short, none of the functionality has been changed in this round.
Just the way it is built or not built has been changed.
Here is the URL for the latest HSX-25 webrev:
http://cr.openjdk.java.net/~dcubed/7182152-webrev/2-hsx25/
Thanks, in advance, for more comments, suggestions or questions.
Dan
On 2/4/13 2:08 PM, Daniel D. Daugherty wrote:
Greetings,
I've updated the fix due to comments in Code Review Round 0.
Here is a summary of changes made to the various files:
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24)
src/share/vm/oops/cpCache.cpp (HSX-25)
src/share/vm/oops/klassVtable.cpp
- removed the new RC_TRACE_NO_CR() macro calls at Coleen's request;
these files are outside of JVM/TI RedefineClasses proper so the
tracing/debug style should not be dictated by JVM/TI
RedefineClasses
style that is currently in use
- did not touch the existing RC_TRACE... macros in the file; removing
the existing macro calls would be outside the scope of this bug
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24)
src/share/vm/oops/cpCache.cpp (HSX-25)
- copy a comment from
ConstantPoolCacheEntry::is_interesting_method_entry()
to ConstantPoolCacheEntry::check_no_old_or_obsolete_entries()
src/share/vm/oops/klassVtable.cpp
- Copied the new comment intended to prevent the "break" from
re-materializing again from klassItable::adjust_method_entries()
to klassVtable::adjust_method_entries(); yes, I'm paranoid.
In the HSX-25 version only:
src/share/vm/oops/metadata.hpp
- revert changes
src/share/vm/oops/cpCacheOop.cpp
src/share/vm/oops/klassVtable.cpp
- wrap uses of is_valid() in NOT_PRODUCT macro as appropriate
Here are the URLs for the updated webrevs:
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx23.6/
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx24/
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx25/
The JPDA stack testing that I started on Friday is still running on
WinXP so I'm blocked for checking the recompile due to these changes.
I'll start a recompile on Solaris X86, but that will take some time.
Thanks, in advance, for more comments, suggestions or questions.
Dan
On 2/1/13 12:55 PM, Daniel D. Daugherty wrote:
Greetings,
I have a fix for the following JVM/TI bug:
7182152 Instrumentation hot swap test incorrect monitor count
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182152
https://jbs.oracle.com/bugs/browse/JDK-7182152
The fix for the bug in the product code is one line:
src/share/vm/oops/klassVtable.cpp:
@@ -992,18 +1020,50 @@
// RC_TRACE macro has an embedded ResourceMark
RC_TRACE(0x0020, ("itable method update: %s(%s)",
new_method->name()->as_C_string(),
new_method->signature()->as_C_string()));
}
-break;
+// cannot 'break' here; see for-loop comment above.
}
ime++;
}
}
}
and is applicable to JDK7u10/HSX-23.6 and JDK7u14/HSX-24. Coleen
already fixed the bug as part of the Perm Gen Removal (PGR) project
in HSX-25. Yes, we found a 1-line bug fix buried in the monster PGR
changeset. Many thanks to Coleen for her help in this bug hunt!
The rest of the code in the webrevs are:
- additional JVM/TI tracing code backported from Coleen's PGR
changeset
- additional JVM/TI tracing code added by me and forward ported to
HSX-25
- a new -XX:TraceRedefineClasses=16384 flag value for finding these
elusive old or obsolete methods
- exposure of some printing code to the PRODUCT build so that the new
tracing is available in a PRODUCT build
You might be wondering why the new tracing code is exposed in a
PRODUCT
build. Well, it appears that more and more
hg: jdk8/tl/jdk: 8007277: JDK-8002048 testcase fails to compile
Changeset: 0e7d5dd84fdf Author:dsamersoff Date: 2013-02-06 16:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e7d5dd84fdf 8007277: JDK-8002048 testcase fails to compile Summary: sun.* classes is not included to ct.sym file and symbol file have to be ignored Reviewed-by: alanb ! test/sun/management/jdp/JdpTest.sh
Re: RR(S) Re: 8007277: JDK-8002048 testcase fails to compile
On 06/02/2013 12:28, Dmitry Samersoff wrote: Hi Everyone, Please review the fix: http://cr.openjdk.java.net/~dsamersoff/8007277.JDP-TEST/webrev.01/jdk/ -Dmitry This looks fine to me (and good to get this one fixed as it is failing everywhere since the original changes were pushed). -Alan
RR(S) Re: 8007277: JDK-8002048 testcase fails to compile
Hi Everyone,
Please review the fix:
http://cr.openjdk.java.net/~dsamersoff/8007277.JDP-TEST/webrev.01/jdk/
-Dmitry
On 2013-02-06 14:47, Alan Bateman wrote:
>
> Dmitry - I realize you might be looking at this already but
> test/sun/management/jdp/JdpTest.sh is failing on all platforms since it
> was pushed. We can either put it on the exclude list (ProblemList.txt)
> or fix it. Since it is trivial to fix then I'd like to do that -
> attached is the proposed patch.
>
> -Alan.
>
> diff --git a/test/sun/management/jdp/JdpTest.sh
> b/test/sun/management/jdp/JdpTest.sh
> --- a/test/sun/management/jdp/JdpTest.sh
> +++ b/test/sun/management/jdp/JdpTest.sh
> @@ -23,7 +23,7 @@
>
> # @test
> # @bug 7169888
> -# @build JdpUnitTest JdpClient JdpDoSomething
> +# @compile -XDignore.symbol.file JdpUnitTest.java JdpClient.java
> JdpDoSomething.java
> # @run shell JdpTest.sh --jtreg --no-compile
> # @summary No word Failed expected in the test output
>
> @@ -55,7 +55,7 @@
> rm -f ${_testclasses}/*.class
>
> # Compile testcase
> -${TESTJAVA}/bin/javac -d ${_testclasses} JdpUnitTest.java \
> +${COMPILEJAVA}/bin/javac -XDignore.symbol.file -d ${_testclasses}
> JdpUnitTest.java \
> JdpDoSomething.java \
> JdpClient.java
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
Re: 8007277: JDK-8002048 testcase fails to compile
Alan,
Thank you! I plan to fix it shortly.
-Dmitry
On 2013-02-06 14:47, Alan Bateman wrote:
>
> Dmitry - I realize you might be looking at this already but
> test/sun/management/jdp/JdpTest.sh is failing on all platforms since it
> was pushed. We can either put it on the exclude list (ProblemList.txt)
> or fix it. Since it is trivial to fix then I'd like to do that -
> attached is the proposed patch.
>
> -Alan.
>
> diff --git a/test/sun/management/jdp/JdpTest.sh
> b/test/sun/management/jdp/JdpTest.sh
> --- a/test/sun/management/jdp/JdpTest.sh
> +++ b/test/sun/management/jdp/JdpTest.sh
> @@ -23,7 +23,7 @@
>
> # @test
> # @bug 7169888
> -# @build JdpUnitTest JdpClient JdpDoSomething
> +# @compile -XDignore.symbol.file JdpUnitTest.java JdpClient.java
> JdpDoSomething.java
> # @run shell JdpTest.sh --jtreg --no-compile
> # @summary No word Failed expected in the test output
>
> @@ -55,7 +55,7 @@
> rm -f ${_testclasses}/*.class
>
> # Compile testcase
> -${TESTJAVA}/bin/javac -d ${_testclasses} JdpUnitTest.java \
> +${COMPILEJAVA}/bin/javac -XDignore.symbol.file -d ${_testclasses}
> JdpUnitTest.java \
> JdpDoSomething.java \
> JdpClient.java
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
hg: jdk8/tl: 8007625: race with nested repos in /common/bin/hgforest.sh
Changeset: 8dd61906da5f Author:chegar Date: 2013-02-06 11:36 + URL: http://hg.openjdk.java.net/jdk8/tl/rev/8dd61906da5f 8007625: race with nested repos in /common/bin/hgforest.sh Reviewed-by: dholmes, ohair, ohrstrom ! common/bin/hgforest.sh ! get_source.sh
8007277: JDK-8002048 testcase fails to compile
Dmitry - I realize you might be looking at this already but
test/sun/management/jdp/JdpTest.sh is failing on all platforms since it
was pushed. We can either put it on the exclude list (ProblemList.txt)
or fix it. Since it is trivial to fix then I'd like to do that -
attached is the proposed patch.
-Alan.
diff --git a/test/sun/management/jdp/JdpTest.sh
b/test/sun/management/jdp/JdpTest.sh
--- a/test/sun/management/jdp/JdpTest.sh
+++ b/test/sun/management/jdp/JdpTest.sh
@@ -23,7 +23,7 @@
# @test
# @bug 7169888
-# @build JdpUnitTest JdpClient JdpDoSomething
+# @compile -XDignore.symbol.file JdpUnitTest.java JdpClient.java
JdpDoSomething.java
# @run shell JdpTest.sh --jtreg --no-compile
# @summary No word Failed expected in the test output
@@ -55,7 +55,7 @@
rm -f ${_testclasses}/*.class
# Compile testcase
-${TESTJAVA}/bin/javac -d ${_testclasses} JdpUnitTest.java \
+${COMPILEJAVA}/bin/javac -XDignore.symbol.file -d ${_testclasses}
JdpUnitTest.java \
JdpDoSomething.java \
JdpClient.java
Re: jmx-dev [PATCH] JDK-8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows
On 02/05/2013 11:47 PM, Stuart Marks wrote: > Hi, thanks for the updates. > > Capturing the Client output in a file seems preferable to putting a > shell pipeline in backquotes. But, the old code piped both stdout and > stderr into grep using 2>&1, whereas the new code redirects only stdout, > which is then searched by grep. Was that intentional? I'm not sure > whether the error message in question occurs in stdout or stderr. Argh. I missed the redirect :/ Thanks! I will update the webrev shortly. > > Otherwise, it looks like you've taken care of the common failure modes. > It just goes to show how deceptively simple shell programming can be, > when in fact catching all the potential errors can be quite tedious. > > The following discussion is mainly for your information, to consider the > next time you decide to write a shell test. :-) I'm not suggesting any > action for this changeset. > > You had mentioned earlier (see thread below) that you needed to compile > incompatible versions of the same class. It's indeed difficult to coerce > jtreg to do that, so this is the rationale for writing a shell test. > > It's possible and somewhat hacky to use jtreg for this, though; see > > http://hg.openjdk.java.net/lambda/lambda/jdk/file/tip/test/java/io/Serializable/defaultSVID/ > > > Basically it uses the @compile tag to compile the first version of the > file, then @run with an arg that tells the test to move the generated > classfile somewhere, another @compile tag to compile the second version > of the file, and finally an @run tag to run the test for real. > > I don't suggest that you copy this technique. :-) > > Jon Gibbons suggested invoking the compiler API directly from java > instead of writing a shell script. Doing this seems fairly simple, and I > think it would be advantageous to keep things entirely in Java. I may > attempt to rewrite the defaultSVID test using the compiler API. This seems rather feasible. I had just assumed that writing the shell script would have been easier. But apparently wasn't ... Anyway, thanks for going through this extensive review. -JB- > > s'marks > > > On 2/5/13 6:40 AM, Jaroslav Bachorik wrote: >> Updates in http://cr.openjdk.java.net/~jbachorik/8005472/webrev.05 >> >> Comments inline >> >> On 01/10/2013 10:44 PM, Stuart Marks wrote: >>> On 1/10/13 7:20 AM, Jaroslav Bachorik wrote: Update: http://cr.openjdk.java.net/~jbachorik/8005472/webrev.04 >>> >>> Thanks for the update. >>> >>> Note, argv[0] is used before argv.length is checked, so if no args are >>> passed this gives index out of bounds instead of the usage message. >> >> It's gone. Shouldn't have been left there anyway. >> >>> >>> I see you take pains to write and flush the URL to stdout before writing >>> the signaling file. Good. The obvious alternative (which I started >>> writing but then erased) is just to put the URL into the signaling file. >>> But this has a race between creation of the file and the writing of its >>> contents. So, what you have works. (This kind of rendezvous problem >>> occurs a lot; it seems like there ought to be a simpler way.) >>> >>> I suspect the -e option caused hangs because if something failed, it >>> would leave the server running, spoiling the next test run. The usual >>> way to deal with this is to use the shell 'trap' statement, to kill >>> subprocesses and remove temp files before exiting the shell. Probably a >>> good practice in general, but perhaps too much shell hackery for this >>> change. (Up to you if you want to tackle it.) >> >> I would rather not ... >> >>> >>> Regarding how the test is detecting success/failure, the concern is that >>> if the client fails for some reason other than the failure being checked >>> for, the test will still report passing. Since the error message is >>> coming out of the client JVM, in principle it ought to be possible to >>> redirect it somehow in order to do the assertion checking in Java. With >>> the current shell scheme, not only are other failures reported as the >>> test passing, these other failures are erased in the grep pipeline, so >>> they're not even visible in the test log. >> >> I've changed the logic slightly to check for the java process exit >> status as well as for the presence of the trigger text in the process >> output. This should catch all the regular failures. >> >> Unfortunately, the way the notification handling is implemented now it >> is not really possible to check for the error from within the >> application - the error state is captured by the *NotificationForwarder >> class and only reported to the logger. >> >> -JB- >> >>> >>> This last issue is rather far afield from this webrev, and fixing it >>> will probably require some rearchitecting of the test. So maybe it >>> should be considered independently. I just happened to notice this going >>> on, and I noticed the similarity to what's going on in the RMI tests. >>> >>> s'marks >>> >>> >>> On 01/10/2013 09:52 AM, Stuart M
