From jon.masamitsu at oracle.com Mon May 3 17:55:56 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 03 May 2010 10:55:56 -0700 Subject: Free ratio based heap shrinking in the parallel collector In-Reply-To: References: <4BA3AE88.3090002@sun.com> <56E32EB8-AA26-477B-872F-6AD5C2104900@Sun.COM> <4BB4C3A4.40701@oracle.com> <4BD9F2E6.3090404@oracle.com> Message-ID: <4BDF0E2C.7020809@oracle.com> Hiroshi, In parallelScavengeHeap.cpp In the UseParallelGC collector the initial size (init_size) can be significantly larger than the minimum size. If you want to shrink down the heap to minimize footprint, do you really want to limit by the initial size instead of the minimum size? 1001 maximum_desired_capacity = MAX2(maximum_desired_capacity, init_size); Similarly here the amount of used data could be very small and setting the floor at the initial size may not be what you want. 1034 minimum_desired_capacity = MAX2(minimum_desired_capacity, init_size); In psYoungGen.cpp you guard output with PrintGC only. In similar cases this type of output is guarded with Verbose also. Does this output as is get printed in the middle of the usual -verbosegc (also known as PrintGC) line? 1000 if (PrintGC) { 1001 gclog_or_tty->print_cr(" Resizing young gen. expand_bytes=%d,%d", 1002 eden_expand_bytes, survivor_expand_bytes); 1003 gclog_or_tty->print("BEFORE: Young Gen: "); 1004 gclog_or_tty->print("eden capacity : " SIZE_FORMAT ", ", 1005 eden_space()->capacity_in_bytes()); 1006 gclog_or_tty->print("eden used : " SIZE_FORMAT ", " , 1007 eden_space()->used_in_bytes()); 1008 gclog_or_tty->print("survivor capacity : " SIZE_FORMAT ", ", 1009 from_space()->capacity_in_bytes()); 1010 gclog_or_tty->print_cr("survivor used : " SIZE_FORMAT ", " , 1011 from_space()->used_in_bytes()); 1012 } In psOldGen.cpp you could try to expand up to max_gen_size instead of returning? 501 void PSOldGen::try_to_expand_by(size_t expand_bytes) { 502 if (expand_bytes< MinHeapDeltaBytes || 503 capacity_in_bytes() + expand_bytes> max_gen_size()) { 504 return; Additionally PSOldGen::expand() chooses to use MinHeapDeltaBytes as the minimum expansion size (in the sense that sizes for expansion are round up to MinHeapDeltaBytes). You would rather not expand for less than MinHeapDeltaBytes? I'll admit that there maybe some inconsistencies in the way MinHeapDeltaBytes is used. Just checking that this is what you want to do. Again, seems to me that you want to shrink down to the minimum generation size as opposed to the initial size. 523 void PSOldGen::try_to_shrink_by(size_t shrink_bytes) { 524 if (shrink_bytes < MinHeapDeltaBytes || 525 capacity_in_bytes() - shrink_bytes < init_gen_size()) { 526 return; 527 } In globals.hpp. We may want this feature implemented in other collectors at some point - G1 comes to mind. I'd drop the leading PS on the flag so that it is ResizeByFreeRatioWithSystemGC. 3079 product(bool, PSResizeByFreeRatioWithSystemGC, false, \ 3080 "Resize the heap by free ratio in System.gc() " \ 3081 "under UseParallelGC") The rest looks fine. Jon On 4/29/10 2:48 PM, Hiroshi Yamauchi wrote: > OK. No problem. > > On Thu, Apr 29, 2010 at 1:58 PM, Jon Masamitsu wrote: > >> Hiroshi, >> >> These changes are what I was expecting after >> we had talked. I still have to look at the details but may not >> get to those for a couple of days. >> >> Jon >> >> On 04/28/10 13:37, Hiroshi Yamauchi wrote: >> >>> Jon, >>> >>> Here's an update based on what we discussed: >>> >>> http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.02/ >>> >>> The summary of the latest changes is that >>> >>> 1. On minor collections, the free ratio is computed based on the young >>> gen heap, rather than both the young gen and the old gen heaps. >>> >>> 2. When -XX:-UseAdaptiveSizePolicy, the free ratio based resizing >>> happens on normal collections, rather than just on System.gc() when >>> -XX:+PSResizeByFreeRatioWithSystemGC. >>> >>> Hiroshi >>> >>> >>> On Tue, Apr 13, 2010 at 11:21 AM, Hiroshi Yamauchi >>> wrote: >>> >>> >>>> Hi Jon, >>>> >>>> I finally got to this. Here's the webrev for a second version based on >>>> our discussion (thanks to Chuck Rasbold): >>>> >>>> http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ >>>> >>>> The summary of change is that the logic for expansion based on >>>> MinHeapFreeRatio was added and only the flag for the System.gc was >>>> retained (and renamed to PSResizeByFreeRatioWithSystemGC.) >>>> >>>> Thanks, >>>> Hiroshi >>>> >>>> >>>> On Thu, Apr 1, 2010 at 9:02 AM, Jon Masamitsu >>>> wrote: >>>> >>>> >>>>> On 03/31/10 11:26, Hiroshi Yamauchi wrote: >>>>> >>>>> >>>>>> ... >>>>>> >>>>>> I think we agree that it's a good idea to try to shrink the heap in >>>>>> response to System.gc() in such a scenario/app. >>>>>> >>>>>> >>>>> Yes on the shrinking on a System.gc() and perhaps for symmetry also >>>>> expanding >>>>> a small heap to MinFreeHeapRatio? UseAdaptiveSizePolicy will shrink the >>>>> heap >>>>> down during periods of low activity and it might be useful to swiftly >>>>> expand >>>>> the >>>>> heap on a System.gc(). >>>>> >>>>> >>>>>> Since we are talking about a setting where the free ratio flags takes >>>>>> precedence over the psAdaptiveSizePolicy's throughput goals, the >>>>>> suggested >>>>>> logic in the original webrev is perhaps not so terrible? If so, I >>>>>> suppose >>>>>> the logic for UseFreeRatioOnlyInSystemGCForParallelGC does help with >>>>>> that >>>>>> because it can shrink the heap regardless of the throughput goal. It >>>>>> may >>>>>> make sense to remove UseFreeRatioForParallelGC and keep >>>>>> UseFreeRatioOnlyInSystemGCForParallelGC only. If you'd like to see it >>>>>> happen >>>>>> inside psAdaptiveSizePolicy instead, the current webrev does not work. >>>>>> >>>>>> >>>>>> >>>>> I like the structure of the original webrev with regard to the logic for >>>>> using FreeRation. It's simpler than embedding it in the >>>>> PSAdaptivesizePolicy. >>>>> >>>>> >>>>> 243 if (UseFreeRatioOnlyInSystemGCForParallelGC&& >>>>> 245 gc_cause == GCCause::_java_lang_system_gc)) { >>>>> compute_new_size();<<<<<<<< generalization of >>>>> <<<<<<<< try_to_shrink_by_free_ratio() >>>>> 248 } else { >>>>> use current UseAdaptiveSizePolicy >>>>> } >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.s.ramakrishna at oracle.com Mon May 3 21:03:42 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Mon, 03 May 2010 21:03:42 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6948537: CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT Message-ID: <20100503210345.EE9E344CA9@hg.openjdk.java.net> Changeset: 3bfae429e2cf Author: ysr Date: 2010-05-03 10:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3bfae429e2cf 6948537: CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT Summary: On sun4v/CMT avoid use of memset() in BOT updates so as to prevent concurrent BOT readers from seeing the phantom zeros arising from memset()'s use of BIS. Reviewed-by: jmasa, johnc, minqi, poonam, tonyp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/runtime/globals.hpp From tony.printezis at oracle.com Tue May 4 01:56:50 2010 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Tue, 04 May 2010 01:56:50 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6 new changesets Message-ID: <20100504015702.F2FC444D42@hg.openjdk.java.net> Changeset: d7f654633cfe Author: never Date: 2010-04-26 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d7f654633cfe 6946040: add intrinsic for short and char reverseBytes Reviewed-by: never, twisti Contributed-by: Hiroshi Yamauchi ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/subnode.hpp + test/compiler/6431242/Test.java + test/compiler/6946040/TestCharShortByteSwap.java Changeset: b4776199210f Author: never Date: 2010-04-26 23:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b4776199210f 6943485: JVMTI always on capabilities change code generation too much Reviewed-by: twisti, dcubed ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiManageCapabilities.cpp Changeset: 314e17ca2c23 Author: iveresov Date: 2010-04-27 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/314e17ca2c23 6946892: c1 shouldn't sign-extend to upper 32bits on x64 Summary: c1 does sign-extension when it loads ints and shorts from memory to 64-bit registers. This causes problems for c2 because it relies on the fact the int passed in a 64-bit register is zero-extended. Reviewed-by: never ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 90acda19b80f Author: jrose Date: 2010-04-29 00:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/90acda19b80f Merge Changeset: befdf73d6b82 Author: tonyp Date: 2010-05-03 16:31 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/befdf73d6b82 Merge ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 7145628c2fa2 Author: tonyp Date: 2010-05-03 17:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7145628c2fa2 Merge From y.s.ramakrishna at oracle.com Tue May 4 05:27:56 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Tue, 04 May 2010 05:27:56 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6919638: CMS: ExplicitGCInvokesConcurrent misinteracts with gc locker Message-ID: <20100504052759.145C744DAF@hg.openjdk.java.net> Changeset: bb843ebc7c55 Author: ysr Date: 2010-05-03 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/bb843ebc7c55 6919638: CMS: ExplicitGCInvokesConcurrent misinteracts with gc locker Summary: GC-locker induced concurrent full gc should be asynchronous; policy now controlled by a separate flag, which defaults to false. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/globals.hpp From y.s.ramakrishna at oracle.com Wed May 5 19:56:02 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Wed, 05 May 2010 12:56:02 -0700 Subject: hg: jdk7/hotspot-gc/hotspot: 6919638: CMS: ExplicitGCInvokesConcurrent misinteracts with gc locker In-Reply-To: <20100504052759.145C744DAF@hg.openjdk.java.net> References: <20100504052759.145C744DAF@hg.openjdk.java.net> Message-ID: <4BE1CD52.9090201@oracle.com> I wanted to acknowledge the essential help from Chi Ho Kwok, wrt discovering this problem in the first place, responding patiently to my emails when i was trying to understand the issue, describing the symptoms of the problem, supplying a test case and then testing both my initial failed attempt and the subsequent successful fix. It's such a pleasure to work with the open jdk community of contributors and users like you. thanks! -- ramki On 05/03/10 22:27, y.s.ramakrishna at oracle.com wrote: > Changeset: bb843ebc7c55 > Author: ysr > Date: 2010-05-03 20:19 -0700 > URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/bb843ebc7c55 > > 6919638: CMS: ExplicitGCInvokesConcurrent misinteracts with gc locker > Summary: GC-locker induced concurrent full gc should be asynchronous; policy now controlled by a separate flag, which defaults to false. > Reviewed-by: jmasa > > ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp > ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.hpp > ! src/share/vm/memory/genCollectedHeap.cpp > ! src/share/vm/runtime/globals.hpp > From tony.printezis at oracle.com Thu May 6 19:32:30 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 06 May 2010 15:32:30 -0400 Subject: Feedback requested: HotSpot GC logging improvements Message-ID: <4BE3194E.902@oracle.com> Hi all, We would like your input on some changes to HotSpot's GC logging that we have been discussing. We have been wanting to improve our GC logging for some time. However we haven't had the resources to spend on it. We don't know when we'll get to it, but we'd still like to get some feedback on our plans. The changes fall into two categories. A. Unification and improvement of -verbosegc / -XX:+PrintGCDetails output. I strongly believe that maintaining two GC log formats is counter-productive, especially given that the current -verbosegc format is unhelpful in many ways (i.e., lacks a lot of helpful information). So, we would like to unify the two into one, with maybe -XX:+PrintGCDetails generating a superset of what -verbosegc would generate (so that a parser for the -XX:+PrintGCDetails output will also be able to parse the -verbosegc output). The new output will not be what -XX:+PrintGCDetails generates today but something that can be reliably parsed and it is also reasonably human-readable (so, no xml and no space/tab-separated formats). Additionally, we're proposing to enable -XX:+PrintGCTimeStamps by default (in fact, we'll probably deprecate and ignore that option, I can't believe that users will really not want a time stamp per GC log record). We'll leave -XX:+PrintGCDateStamps to be optional though. Specific questions: - Is anyone really attached to the old -verbosegc output? - Would anyone really hate having time stamps by default? - I know that a lot of folks have their own parsers for our current GC log formats. Would you be happy if we provided you with a (reliable!) parser for the new format in Java that you can easily adapt? B. Introducing "cyclic" GC logs. This is something that a lot of folks have asked for given that they were concerned with the GC logs getting very large (a 1TB disk is $85 these days, but anyway...). Given that each GC log record is of variable size, we cannot easily cycle through the log using the same file (I'd rather not have to overwrite existing records). Our current proposal is for the user to specify a file number N and a size target S for each file. For a given GC log -Xloggc:foo, HotSpot will generate foo.00000001 foo.00000002 foo.00000003 etc. (we'll create a new file as soon as the size of the one we are writing to exceeds S, so each file will be slightly larger than S but it will be helpful not to split individual log records between two files) When we create a new file, if we have more than N files we'll delete the oldest. So, in the above example, if N == 3, when we create foo.00000004 we'll delete foo.00000001. Note that in the above scheme, the logs are not really "cyclic" but, instead, we're pruning the oldest records every now and then, which has the same effect. Another (related) request has been to maybe append the GC log file name with the pid of the JVM that's generating it. Maybe we don't want to do this by default. But, would people find it helpful if we provide a new cmd line parameter to do that? So, for the above example and assuming that the JVM's pid is 1234, the GC log file(s) will be either: foo.1234 or foo.1234.00000001 foo.1234.00000002 foo.1234.00000003 etc. Specific questions: - Would people really hate it if HotSpot starts appending the GC log file name with a (zero-padded) sequence number? Maybe if N == 1 (the default), HotSpot will skip the sequence number and ignore S, i.e., behave as it does today. - To the people who have been asking for cyclic GC logs: is the sequence number scheme above good enough? Thanks in advance for your feedback, Tony, HotSpot GC Group _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From matt.khan at db.com Thu May 6 20:01:41 2010 From: matt.khan at db.com (Matt Khan) Date: Thu, 6 May 2010 21:01:41 +0100 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: <4BE3194E.902@oracle.com> Message-ID: Evening we currently manage the log overwriting issue by mv'ing the last gc.log to gc.log., if you're going to roll the logs then I would prefer a meaningful suffix rather than just a counter. I second the idea that datestamps should be the default. I think a unified, easily parseable but still readable output would be great though wouldn't you still need a verbose output that is specific to each collector in order to provide a "debug" level of detail? Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London Tony Printezis Sent by: hotspot-gc-use-bounces at openjdk.java.net 06/05/2010 20:32 To hotspot-gc-use at openjdk.java.net cc Subject Feedback requested: HotSpot GC logging improvements Hi all, We would like your input on some changes to HotSpot's GC logging that we have been discussing. We have been wanting to improve our GC logging for some time. However we haven't had the resources to spend on it. We don't know when we'll get to it, but we'd still like to get some feedback on our plans. The changes fall into two categories. A. Unification and improvement of -verbosegc / -XX:+PrintGCDetails output. I strongly believe that maintaining two GC log formats is counter-productive, especially given that the current -verbosegc format is unhelpful in many ways (i.e., lacks a lot of helpful information). So, we would like to unify the two into one, with maybe -XX:+PrintGCDetails generating a superset of what -verbosegc would generate (so that a parser for the -XX:+PrintGCDetails output will also be able to parse the -verbosegc output). The new output will not be what -XX:+PrintGCDetails generates today but something that can be reliably parsed and it is also reasonably human-readable (so, no xml and no space/tab-separated formats). Additionally, we're proposing to enable -XX:+PrintGCTimeStamps by default (in fact, we'll probably deprecate and ignore that option, I can't believe that users will really not want a time stamp per GC log record). We'll leave -XX:+PrintGCDateStamps to be optional though. Specific questions: - Is anyone really attached to the old -verbosegc output? - Would anyone really hate having time stamps by default? - I know that a lot of folks have their own parsers for our current GC log formats. Would you be happy if we provided you with a (reliable!) parser for the new format in Java that you can easily adapt? B. Introducing "cyclic" GC logs. This is something that a lot of folks have asked for given that they were concerned with the GC logs getting very large (a 1TB disk is $85 these days, but anyway...). Given that each GC log record is of variable size, we cannot easily cycle through the log using the same file (I'd rather not have to overwrite existing records). Our current proposal is for the user to specify a file number N and a size target S for each file. For a given GC log -Xloggc:foo, HotSpot will generate foo.00000001 foo.00000002 foo.00000003 etc. (we'll create a new file as soon as the size of the one we are writing to exceeds S, so each file will be slightly larger than S but it will be helpful not to split individual log records between two files) When we create a new file, if we have more than N files we'll delete the oldest. So, in the above example, if N == 3, when we create foo.00000004 we'll delete foo.00000001. Note that in the above scheme, the logs are not really "cyclic" but, instead, we're pruning the oldest records every now and then, which has the same effect. Another (related) request has been to maybe append the GC log file name with the pid of the JVM that's generating it. Maybe we don't want to do this by default. But, would people find it helpful if we provide a new cmd line parameter to do that? So, for the above example and assuming that the JVM's pid is 1234, the GC log file(s) will be either: foo.1234 or foo.1234.00000001 foo.1234.00000002 foo.1234.00000003 etc. Specific questions: - Would people really hate it if HotSpot starts appending the GC log file name with a (zero-padded) sequence number? Maybe if N == 1 (the default), HotSpot will skip the sequence number and ignore S, i.e., behave as it does today. - To the people who have been asking for cyclic GC logs: is the sequence number scheme above good enough? Thanks in advance for your feedback, Tony, HotSpot GC Group _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From adamh at basis.com Thu May 6 20:28:51 2010 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 6 May 2010 16:28:51 -0400 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: <4BE3194E.902@oracle.com> References: <4BE3194E.902@oracle.com> Message-ID: Tony, On Thu, May 6, 2010 at 15:32, Tony Printezis wrote: > Hi all, > > A. Unification and improvement of -verbosegc / -XX:+PrintGCDetails output. > [snip] > Specific questions: > > - Is anyone really attached to the old -verbosegc output? > We aren't. - Would anyone really hate having time stamps by default? > I'm in agreement with other folks; timestamps are okay, but date stamps by default would be better. - I know that a lot of folks have their own parsers for our current GC > log formats. Would you be happy if we provided you with a (reliable!) > parser for the new format in Java that you can easily adapt? > +1. Or +10. > > B. Introducing "cyclic" GC logs. > Specific questions: [snip] > - Would people really hate it if HotSpot starts appending the GC log file name with a (zero-padded) sequence number? Maybe if N == 1 (the > default), HotSpot will skip the sequence number and ignore S, i.e., > behave as it does today. How many digits in the sequence? Would that be configurable? Overall, having this is better than not having it. - To the people who have been asking for cyclic GC logs: is the sequence > number scheme above good enough? > > Much better than nothing at all for disk-conscious customers. Thanks, Adam -- Adam Hawthorne Software Engineer BASIS International Ltd. www.basis.com +1.505.345.5232 Phone -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From ycraig at cysystems.com Thu May 6 20:47:17 2010 From: ycraig at cysystems.com (craig yeldell) Date: Thu, 6 May 2010 16:47:17 -0400 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: <4BE3194E.902@oracle.com> References: <4BE3194E.902@oracle.com> Message-ID: A. - No I am not attached to the old -verbosegc output. - I would also think that having the time stamps should be default. - Having a reliable parser would definitely be a welcome addition. B. - We handle our own gc log rotation, but if you were to provide it I would prefer the zero padded sequence number. - Not one of those folks. Regards, Craig On May 6, 2010, at 3:32 PM, Tony Printezis wrote: > Hi all, > > We would like your input on some changes to HotSpot's GC logging > that we > have been discussing. We have been wanting to improve our GC logging > for > some time. However we haven't had the resources to spend on it. We > don't > know when we'll get to it, but we'd still like to get some feedback on > our plans. > > The changes fall into two categories. > > > A. Unification and improvement of -verbosegc / -XX:+PrintGCDetails > output. > > I strongly believe that maintaining two GC log formats is > counter-productive, especially given that the current -verbosegc > format > is unhelpful in many ways (i.e., lacks a lot of helpful information). > So, we would like to unify the two into one, with maybe > -XX:+PrintGCDetails generating a superset of what -verbosegc would > generate (so that a parser for the -XX:+PrintGCDetails output will > also > be able to parse the -verbosegc output). The new output will not be > what > -XX:+PrintGCDetails generates today but something that can be reliably > parsed and it is also reasonably human-readable (so, no xml and no > space/tab-separated formats). Additionally, we're proposing to enable > -XX:+PrintGCTimeStamps by default (in fact, we'll probably deprecate > and > ignore that option, I can't believe that users will really not want a > time stamp per GC log record). We'll leave -XX:+PrintGCDateStamps to > be > optional though. > > Specific questions: > > - Is anyone really attached to the old -verbosegc output? > - Would anyone really hate having time stamps by default? > - I know that a lot of folks have their own parsers for our current GC > log formats. Would you be happy if we provided you with a (reliable!) > parser for the new format in Java that you can easily adapt? > > > B. Introducing "cyclic" GC logs. > > This is something that a lot of folks have asked for given that they > were concerned with the GC logs getting very large (a 1TB disk is $85 > these days, but anyway...). Given that each GC log record is of > variable > size, we cannot easily cycle through the log using the same file (I'd > rather not have to overwrite existing records). Our current proposal > is > for the user to specify a file number N and a size target S for each > file. For a given GC log -Xloggc:foo, HotSpot will generate > > foo.00000001 > foo.00000002 > foo.00000003 > etc. > > (we'll create a new file as soon as the size of the one we are writing > to exceeds S, so each file will be slightly larger than S but it > will be > helpful not to split individual log records between two files) > > When we create a new file, if we have more than N files we'll delete > the > oldest. So, in the above example, if N == 3, when we create foo. > 00000004 > we'll delete foo.00000001. > > Note that in the above scheme, the logs are not really "cyclic" but, > instead, we're pruning the oldest records every now and then, which > has > the same effect. > > Another (related) request has been to maybe append the GC log file > name > with the pid of the JVM that's generating it. Maybe we don't want to > do > this by default. But, would people find it helpful if we provide a new > cmd line parameter to do that? So, for the above example and assuming > that the JVM's pid is 1234, the GC log file(s) will be either: > > foo.1234 > > or > > foo.1234.00000001 > foo.1234.00000002 > foo.1234.00000003 > etc. > > Specific questions: > > - Would people really hate it if HotSpot starts appending the GC log > file name with a (zero-padded) sequence number? Maybe if N == 1 (the > default), HotSpot will skip the sequence number and ignore S, i.e., > behave as it does today. > - To the people who have been asking for cyclic GC logs: is the > sequence > number scheme above good enough? > > > Thanks in advance for your feedback, > > Tony, HotSpot GC Group > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Matthew.H.Miller at Sun.COM Thu May 6 20:46:20 2010 From: Matthew.H.Miller at Sun.COM (Matthew Miller) Date: Thu, 06 May 2010 16:46:20 -0400 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: <0FCC438D62A5E643AA3F57D3417B220D0C6C5A2F@TORMAIL.algorithmics.com> References: <4BE3194E.902@oracle.com> <0FCC438D62A5E643AA3F57D3417B220D0C6C5A2F@TORMAIL.algorithmics.com> Message-ID: <4BE32A9C.8010705@sun.com> I'd like to say +1 to the idea below - if it were some how possible to (somewhat) easily tell all the GC options used from with in the GC Log itself, it would be very useful. (Especially to the support organization). -Matt On 5/6/2010 4:27 PM, jeff.lloyd at algorithmics.com wrote: [... Snip ...] > Can I make a suggestion for item B? Have you noticed everyone who posts > their GC log file additionally has to include in their email the gc > config options that they think they used for that particular run? In > our application we prefix _every_ "cyclic" log file with the config > options used to start the app. It makes reporting problems easier and > we can see which options the client used by looking at the top of the > log file instead of having to ask the client for what they thought they > used. > > Jeff > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From rainer.jung at kippdata.de Thu May 6 20:04:31 2010 From: rainer.jung at kippdata.de (Rainer Jung) Date: Thu, 06 May 2010 22:04:31 +0200 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: <4BE3194E.902@oracle.com> References: <4BE3194E.902@oracle.com> Message-ID: <4BE320CF.402@kippdata.de> Wonderful! Comments inline. On 06.05.2010 21:32, Tony Printezis wrote: > A. Unification and improvement of -verbosegc / -XX:+PrintGCDetails output. > > I strongly believe that maintaining two GC log formats is > counter-productive, especially given that the current -verbosegc format > is unhelpful in many ways (i.e., lacks a lot of helpful information). > So, we would like to unify the two into one, with maybe > -XX:+PrintGCDetails generating a superset of what -verbosegc would > generate (so that a parser for the -XX:+PrintGCDetails output will also > be able to parse the -verbosegc output). The new output will not be what > -XX:+PrintGCDetails generates today but something that can be reliably > parsed and it is also reasonably human-readable (so, no xml and no > space/tab-separated formats). Additionally, we're proposing to enable > -XX:+PrintGCTimeStamps by default (in fact, we'll probably deprecate and > ignore that option, I can't believe that users will really not want a > time stamp per GC log record). We'll leave -XX:+PrintGCDateStamps to be > optional though. > > Specific questions: > > - Is anyone really attached to the old -verbosegc output? Not at all if we have a chance to get something better. > - Would anyone really hate having time stamps by default? We had to do a lot of quirks to simulate GCDateStamps for years until they finally made it into Java 6. Having timestamps by default is a must, absolute timestamps should be at least optional. Personally I find the absolute timestamps more important than the once relative from the JVM start, but that depends on what you are doing. Gathering statistical data the relative ones are better, since you can do computations more easily, tracking problems sometimes the absolute ones are easier, because you quickly want to know whether the log lines match the time of day when you observed the problem. > - I know that a lot of folks have their own parsers for our current GC > log formats. Would you be happy if we provided you with a (reliable!) > parser for the new format in Java that you can easily adapt? Of course. Although I can imagine folks qould want to get it in different implementation techniques. I guess you plan to provide a parser written in Java? Would be great, if it could be provided in a way making it easy fr people to customize, so possibly Open Source with a nice license like Apache Software License 2. > B. Introducing "cyclic" GC logs. > > This is something that a lot of folks have asked for given that they > were concerned with the GC logs getting very large (a 1TB disk is $85 > these days, but anyway...). Given that each GC log record is of variable > size, we cannot easily cycle through the log using the same file (I'd > rather not have to overwrite existing records). Our current proposal is > for the user to specify a file number N and a size target S for each > file. For a given GC log -Xloggc:foo, HotSpot will generate > > foo.00000001 > foo.00000002 > foo.00000003 > etc. > > (we'll create a new file as soon as the size of the one we are writing > to exceeds S, so each file will be slightly larger than S but it will be > helpful not to split individual log records between two files) > > When we create a new file, if we have more than N files we'll delete the > oldest. So, in the above example, if N == 3, when we create foo.00000004 > we'll delete foo.00000001. > > Note that in the above scheme, the logs are not really "cyclic" but, > instead, we're pruning the oldest records every now and then, which has > the same effect. There's a lot of options here. When you doing log rotation, people who want to archive the logs might have regular jobs (cron and friends) fetching the old closed files and transferring them to another system. In that case it would be nice if the apparatus would not get into conflict by both the internal rotation and the external script operating on the same files. f00.00000001 might have been detected as old and copied to the remote host and during the same time GC decides to now reuse it. Of course people can increase the cycle length and so on, but I always found it a bit problematic if a log rotation mechanism touches old files long after the rotation happened. That's why I personally find externally organized pruning better. Of course than it's not carefree out of the box. Another thing I often miss is the ability to combine size and time based rotation. I want to say: rotate whenever 10MB are full so that the chunks I need to handle do not get to big, but please also rotate at midnight, so that I know that I can grab the complete files of the day after midnight. So specifying a max size and a time pattern and the first criterium fulfilled already triggers rotation. > Another (related) request has been to maybe append the GC log file name > with the pid of the JVM that's generating it. Maybe we don't want to do > this by default. But, would people find it helpful if we provide a new > cmd line parameter to do that? So, for the above example and assuming > that the JVM's pid is 1234, the GC log file(s) will be either: > > foo.1234 > > or > > foo.1234.00000001 > foo.1234.00000002 > foo.1234.00000003 > etc. > > Specific questions: > > - Would people really hate it if HotSpot starts appending the GC log > file name with a (zero-padded) sequence number? Maybe if N == 1 (the > default), HotSpot will skip the sequence number and ignore S, i.e., > behave as it does today. > - To the people who have been asking for cyclic GC logs: is the sequence > number scheme above good enough? Some time ago I asked whether it would be possible to get the %p substitution (replace it by the process id) that is already available for some files also for the GC log. I think it already exists in the JDK code either for the HeapDumpOnOutOfMemoryError or the hotspot error file. Forgot for which. The code is extremely simple. Would foo.%p.%8N be to complex? Great initiative! Will you start another discussion about the data contents of the file? It could be interesting when people describe what kind of information they extract out of the GC logs. Not everything is straightforward in the sense of it is based on individual lines. As an example I always calculate the total stopped time per minute (summing up) as a percentage of wallclock time. Regards, Rainer _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From rainer.jung at kippdata.de Thu May 6 20:18:09 2010 From: rainer.jung at kippdata.de (Rainer Jung) Date: Thu, 06 May 2010 22:18:09 +0200 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: <4BE3194E.902@oracle.com> References: <4BE3194E.902@oracle.com> Message-ID: <4BE32401.9070309@kippdata.de> Short addition to my previous post: On 06.05.2010 21:32, Tony Printezis wrote: > - Would people really hate it if HotSpot starts appending the GC log > file name with a (zero-padded) sequence number? Maybe if N == 1 (the > default), HotSpot will skip the sequence number and ignore S, i.e., > behave as it does today. > - To the people who have been asking for cyclic GC logs: is the sequence > number scheme above good enough? Another slight problem with the numbering scheme is that during archiving you'll overwrite old files. So your archive scripts need to intelligently rename the files. Not too easy. Maybe adding a couple of substitution characters (%p=pid, %N roll number, %Y, ... the usual strftime caharcters for timestamp formatting). Regards, Rainer _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Peter.B.Kessler at Oracle.COM Thu May 6 22:00:43 2010 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Thu, 06 May 2010 15:00:43 -0700 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: References: Message-ID: <4BE33C0B.5060009@Oracle.COM> +1 on using date stamps in the file names if you have to split a GC log into several files. If you use the same format as is used for the -XX:+PrintGCDateStamps, ISO 8601, then lexicographic order, e.g. from file listings, should also be in time sequence order, which would be convenient. (Then, if only we could get PID's to be monotonically increasing. :-) That might imply that you want PID's after (less significant than) time stamps in the split file names, so you still get them in time sequence order. If you want just the logs from PID 1234, you can use "ls *.1234.*" to get just those, in time sequence order. Do you want an option to start a new log file in a sequence after some period of time? E.g., once a day? That might make it easier to line up events across long-running JVM's that are collecting (and therefore generating logs) at different rates. +1 on including the command line arguments (or maybe the settings those provoke inside the VM) in the log file. For settings that change over time, e.g., because of ergonomics, it would be good to have a way to see those, too. Maybe "a new log file format" allows that to happen. ... peter Matt Khan wrote: > > Evening > > we currently manage the log overwriting issue by mv'ing the last gc.log > to gc.log., if you're going to > roll the logs then I would prefer a meaningful suffix rather than just a > counter. > > I second the idea that datestamps should be the default. > > I think a unified, easily parseable but still readable output would be > great though wouldn't you still need a verbose output that is specific > to each collector in order to provide a "debug" level of detail? > > Cheers > Matt > > Matt Khan > -------------------------------------------------- > GFFX Auto Trading > Deutsche Bank, London _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Johann.Loefflmann at Sun.COM Fri May 7 09:05:42 2010 From: Johann.Loefflmann at Sun.COM (Johann N. Loefflmann) Date: Fri, 07 May 2010 11:05:42 +0200 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: <4BE3194E.902@oracle.com> References: <4BE3194E.902@oracle.com> Message-ID: <4BE3D7E6.7050503@sun.com> Tony, > B. Introducing "cyclic" GC logs. > For the Java Fatal Error Log we can specify %p, for example: -XX:ErrorFile=/var/log/java/java_error%p.log IMHO it would be great if we could use %p also for -Xloggc:/var/log/java/gc%p.log See also http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/felog.html#gbwcy IMHO options in order to configure the format of the gc log filename would be more comfortable for an user than only hardcoding a particular schema. Proposal: %p the process ID %t a timestamp (the format could be controlled by a new option, I suggest -XX:TimeStampFormatForLogFileNames) %n an index or sequential number I suggest a default for the timestamp format, something like -XX:TimeStampFormatForLogFileNames=yyyy-MM-dd_HH-mm-ss because digits, hypen and underscore are file system independent, the format is human readable and the default can be changed by specifying the option if the default is not suitable. Furthermore, the option could be used by any log and not just only the gc log (the fatal error log for example). Pattern letters for the option could be borrowed from the SimpleDateFormat class. See also http://java.sun.com/javase/6/docs/api/java/text/SimpleDateFormat.html I'm sure that customer would find it quite comfortable to specify something like that -Xloggc:/var/log/java/gclog_pid%p_%n_%t.log -Johann (Software TSC Support engineer) _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From rainer.jung at kippdata.de Fri May 7 05:05:40 2010 From: rainer.jung at kippdata.de (Rainer Jung) Date: Fri, 07 May 2010 07:05:40 +0200 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: <4BE33C0B.5060009@Oracle.COM> References: <4BE33C0B.5060009@Oracle.COM> Message-ID: <4BE39FA4.10005@kippdata.de> On 07.05.2010 00:00, Peter B. Kessler wrote: > +1 on including the command line arguments (or maybe the settings those provoke inside the VM) in the log file. For settings that change over time, e.g., because of ergonomics, it would be good to have a way to see those, too. Maybe "a new log file format" allows that to happen. +1 _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From tony.printezis at oracle.com Fri May 7 16:15:19 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 07 May 2010 12:15:19 -0400 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: <4BE3194E.902@oracle.com> References: <4BE3194E.902@oracle.com> Message-ID: <4BE43C97.6000805@oracle.com> Hi all, First, thank you for all the excellent feedback (which I see as mostly positive to the proposals). We are glad that people still care about the GC logs. Instead of replying to individual e-mails, I'll consolidate my replies here. * "I would say that PrintGCDateStamps should be the default" (several folks brought this up) From the point of view of analyzing logs to just look at the GC's behavior, we only need time stamps. And this is the reason why I'd like to see them turned on by default (too many times we got a log without time stamps for which we said "damn, if it had time stamps we'd get a better idea of what was happening"). So, they are the minimum we need to get a good picture of how the GC behaved. Date stamps will increase the size of the log (which still seems to be an issue for some people) and be helpful in fewer places (i.e., when comparing application and GC events; but we generally do not do that). So, you'll have to turn them on yourselves. :-) * "successive runs overwrite the previous log file" (several folks brought this up) Don't you think that adding the JVM's pid to the log file name would eliminate this problem? * "I'm not attached to the old format" (several folks mentioned this) Oh, good. I'll be quoting you when I'll be making a case to remove it. * "A serial-attached-scsi (aka SAS) disk at 10k rpm is a little bit more expensive than $85/TB" (Ryan) Point taken, but do you really need super duper 10k rpm disks to store GC log files. :-) * "if you're going to roll the logs then I would prefer a meaningful suffix rather than just a counter." A counter seems like a perfectly meaningful suffix to me. * "wouldn't you still need a verbose output that is specific to each collector in order to provide a "debug" level of detail?" (Matt) Very good point. The verbose output will be as unified as possible, but with indeed GC-specific extensions not to lose that information. * "I guess you plan to provide a parser written in Java?" (Rainer) Java? We're HotSpot developers! We only work in C++, assembly, and awk! Just kidding... Yes, indeed in Java. * "so possibly Open Source with a nice license like Apache Software License 2" (Rainer) Maybe, and not up to me to decide. * "f00.00000001 might have been detected as old and copied to the remote host and during the same time GC decides to now reuse it... That's why I personally find externally organized pruning better. Another thing I often miss is the ability to combine size and time based rotation." (Rainer) The proposal never reuses log files. We'll never overwrite anything. Instead, we'll delete the oldest files as we create new ones. If we tell the users to prune the older log files themselves, I know what the first bug filed against the new policy will be. :-) Regarding rotating based on both size and time: most people care about size so I think that's what we'll do. If you want more advanced management of the logs you'll have to set N to infinity (at least we'll need a way to say "never delete older files") so that HotSpot doesn't delete any files and you'll be able to copy them and delete them yourself. But, seriously, this is excellent feedback. You guys are doing more wild stuff with our logs than I had imagined. :-) * "Will you start another discussion about the data contents of the file?" (Rainer) We'll do that separately, based most likely on a wiki. When we get to it. No promises though! * "For more debug detail per collector one could use PrintHeapAtGC" (Michael) Well, PrintHeapAtGC was supposed to be added for debugging purposes, i.e., to find out what the address range of each generation is. However, it has clearer information on how full each generation is which is why people use it today (it's very space inefficient though...). We are hoping to add that information to the standard GC log records to eliminate the need for PrintHeapAtGC. * "In our application we prefix _every_ "cyclic" log file with the config options used to start the app." (Jeff) Adding configuration / whatever information at the top of every log file fragment is an excellent suggestion. Thanks for bringing it up. * "How many digits in the sequence? Would that be configurable?" (Adam) 8 should be more enough (do you really see the need for more than 99m log fragments)? Actually, even 6 will probably be enough. And if we go over that, we won't cycle the numbers, we'll just expand the number field. * "IMHO it would be great if we could use %p also for" (Johann) I was going to say that this would start getting over the top. But I was not aware that you can do that with the fatal error log. I'll need to investigate that further. So, we'll leave this (and additional custom formatting in the GC log name) as a "maybe". :-) I'm not quite sure whether we'd want to use the same facility for the sequence numbers though, given that they'd be needed if we split the log and won't be needed if we don't. For those, I just vote to just add a suffix to the log file name when they are needed. Thanks again for all the good points, Tony, HotSpot GC Group On 5/6/2010 3:32 PM, Tony Printezis wrote: > Hi all, > > We would like your input on some changes to HotSpot's GC logging that > we have been discussing. We have been wanting to improve our GC > logging for some time. However we haven't had the resources to spend > on it. We don't know when we'll get to it, but we'd still like to get > some feedback on our plans. > > The changes fall into two categories. > > > A. Unification and improvement of -verbosegc / -XX:+PrintGCDetails > output. > > I strongly believe that maintaining two GC log formats is > counter-productive, especially given that the current -verbosegc > format is unhelpful in many ways (i.e., lacks a lot of helpful > information). So, we would like to unify the two into one, with maybe > -XX:+PrintGCDetails generating a superset of what -verbosegc would > generate (so that a parser for the -XX:+PrintGCDetails output will > also be able to parse the -verbosegc output). The new output will not > be what -XX:+PrintGCDetails generates today but something that can be > reliably parsed and it is also reasonably human-readable (so, no xml > and no space/tab-separated formats). Additionally, we're proposing to > enable -XX:+PrintGCTimeStamps by default (in fact, we'll probably > deprecate and ignore that option, I can't believe that users will > really not want a time stamp per GC log record). We'll leave > -XX:+PrintGCDateStamps to be optional though. > > Specific questions: > > - Is anyone really attached to the old -verbosegc output? > - Would anyone really hate having time stamps by default? > - I know that a lot of folks have their own parsers for our current GC > log formats. Would you be happy if we provided you with a (reliable!) > parser for the new format in Java that you can easily adapt? > > > B. Introducing "cyclic" GC logs. > > This is something that a lot of folks have asked for given that they > were concerned with the GC logs getting very large (a 1TB disk is $85 > these days, but anyway...). Given that each GC log record is of > variable size, we cannot easily cycle through the log using the same > file (I'd rather not have to overwrite existing records). Our current > proposal is for the user to specify a file number N and a size target > S for each file. For a given GC log -Xloggc:foo, HotSpot will generate > > foo.00000001 > foo.00000002 > foo.00000003 > etc. > > (we'll create a new file as soon as the size of the one we are writing > to exceeds S, so each file will be slightly larger than S but it will > be helpful not to split individual log records between two files) > > When we create a new file, if we have more than N files we'll delete > the oldest. So, in the above example, if N == 3, when we create > foo.00000004 we'll delete foo.00000001. > > Note that in the above scheme, the logs are not really "cyclic" but, > instead, we're pruning the oldest records every now and then, which > has the same effect. > > Another (related) request has been to maybe append the GC log file > name with the pid of the JVM that's generating it. Maybe we don't want > to do this by default. But, would people find it helpful if we provide > a new cmd line parameter to do that? So, for the above example and > assuming that the JVM's pid is 1234, the GC log file(s) will be either: > > foo.1234 > > or > > foo.1234.00000001 > foo.1234.00000002 > foo.1234.00000003 > etc. > > Specific questions: > > - Would people really hate it if HotSpot starts appending the GC log > file name with a (zero-padded) sequence number? Maybe if N == 1 (the > default), HotSpot will skip the sequence number and ignore S, i.e., > behave as it does today. > - To the people who have been asking for cyclic GC logs: is the > sequence number scheme above good enough? > > > Thanks in advance for your feedback, > > Tony, HotSpot GC Group > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From john.coomes at oracle.com Fri May 7 18:48:21 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 May 2010 18:48:21 +0000 Subject: hg: jdk7/hotspot-gc: Added tag jdk7-b92 for changeset 5f5c33d417f3 Message-ID: <20100507184821.EF4FB448EF@hg.openjdk.java.net> Changeset: b7b4797303cb Author: mikejwre Date: 2010-05-06 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/b7b4797303cb Added tag jdk7-b92 for changeset 5f5c33d417f3 ! .hgtags From john.coomes at oracle.com Fri May 7 18:48:24 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 May 2010 18:48:24 +0000 Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b92 for changeset 930582f667a1 Message-ID: <20100507184827.09462448F0@hg.openjdk.java.net> Changeset: ae18df0d4767 Author: mikejwre Date: 2010-05-06 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/ae18df0d4767 Added tag jdk7-b92 for changeset 930582f667a1 ! .hgtags From john.coomes at oracle.com Fri May 7 18:51:37 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 May 2010 18:51:37 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b92 for changeset e6a40e4bb104 Message-ID: <20100507185137.94C38448F1@hg.openjdk.java.net> Changeset: c725ca829c5a Author: mikejwre Date: 2010-05-06 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/c725ca829c5a Added tag jdk7-b92 for changeset e6a40e4bb104 ! .hgtags From john.coomes at oracle.com Fri May 7 18:51:40 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 May 2010 18:51:40 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b92 for changeset df7c033f6a11 Message-ID: <20100507185140.B1622448F2@hg.openjdk.java.net> Changeset: 797bef191975 Author: mikejwre Date: 2010-05-06 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/797bef191975 Added tag jdk7-b92 for changeset df7c033f6a11 ! .hgtags From john.coomes at oracle.com Fri May 7 18:51:46 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 May 2010 18:51:46 +0000 Subject: hg: jdk7/hotspot-gc/jdk: Added tag jdk7-b92 for changeset f2dce7210cc0 Message-ID: <20100507185214.0DC1D448F3@hg.openjdk.java.net> Changeset: fa09af0e5b7c Author: mikejwre Date: 2010-05-06 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/fa09af0e5b7c Added tag jdk7-b92 for changeset f2dce7210cc0 ! .hgtags From john.coomes at oracle.com Fri May 7 18:54:20 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 May 2010 18:54:20 +0000 Subject: hg: jdk7/hotspot-gc/langtools: Added tag jdk7-b92 for changeset 98cba5876cb5 Message-ID: <20100507185425.60338448F4@hg.openjdk.java.net> Changeset: 683cd1f6bc4b Author: mikejwre Date: 2010-05-06 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/683cd1f6bc4b Added tag jdk7-b92 for changeset 98cba5876cb5 ! .hgtags From vkleinschmidt at gmail.com Mon May 10 20:34:20 2010 From: vkleinschmidt at gmail.com (Volker Kleinschmidt) Date: Mon, 10 May 2010 15:34:20 -0500 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: <4BE43C97.6000805@oracle.com> References: <4BE3194E.902@oracle.com> <4BE43C97.6000805@oracle.com> Message-ID: Where is the advantage to using counter numbers in the log file names? If you take the sensible suggestion made by several others here to use ISO datetimestamps in the filenames, you have a natural sequence, no worries about name re-use, and easily automated log maintenance by those that want to keep these logs for a while. You could still implement an auto-deletion of "older" logs for those that want it. Each log can then easily be identified, and an optional PID in the filename would be helpful too. But a counter? What info does that give you by itself, without additional context? None whatsoever. That's why others declared it as "not meaningful". We mainly need gc logs for post-mortem performance problem analysis, so the date/time stamps on the logs would be really handy to identify which log to look at (we often don't get to look at the log on the client system, hence file dates don't help us, and they often don't have PrintGCDateStamps enabled). However the core issue for us is prevention of log overwriting when -Xloggc specifies a fixed filename and the VM gets restarted by the service wrapper watchdog feature, i.e. when you really needed that GC log. So any auto-log-rolling mechanism is much better than none and will make me yodel with joy :^) --Volker On Fri, May 7, 2010 at 11:15 AM, Tony Printezis wrote: > Hi all, > > First, thank you for all the excellent feedback (which I see as mostly > positive to the proposals). We are glad that people still care about the > GC logs. Instead of replying to individual e-mails, I'll consolidate my > replies here. > > * "I would say that PrintGCDateStamps should be the default" (several > folks brought this up) > > ?From the point of view of analyzing logs to just look at the GC's > behavior, we only need time stamps. And this is the reason why I'd like > to see them turned on by default (too many times we got a log without > time stamps for which we said "damn, if it had time stamps we'd get a > better idea of what was happening"). So, they are the minimum we need to > get a good picture of how the GC behaved. Date stamps will increase the > size of the log (which still seems to be an issue for some people) and > be helpful in fewer places (i.e., when comparing application and GC > events; but we generally do not do that). So, you'll have to turn them > on yourselves. :-) > > * "successive runs overwrite the previous log file" (several folks > brought this up) > > Don't you think that adding the JVM's pid to the log file name would > eliminate this problem? > > * "I'm not attached to the old format" (several folks mentioned this) > > Oh, good. I'll be quoting you when I'll be making a case to remove it. > > * "A serial-attached-scsi (aka SAS) disk at 10k rpm is a little bit more > expensive than $85/TB" (Ryan) > > Point taken, but do you really need super duper 10k rpm disks to store > GC log files. :-) > > * "if you're going to roll the logs then I would prefer a meaningful > suffix rather than just a counter." > > A counter seems like a perfectly meaningful suffix to me. > > * "wouldn't you still need a verbose output that is specific to each > collector in order to provide a "debug" level of detail?" (Matt) > > Very good point. The verbose output will be as unified as possible, but > with indeed GC-specific extensions not to lose that information. > > * "I guess you plan to provide a parser written in Java?" (Rainer) > > Java? We're HotSpot developers! We only work in C++, assembly, and awk! > Just kidding... Yes, indeed in Java. > > * "so possibly Open Source with a nice license like Apache Software > License 2" (Rainer) > > Maybe, and not up to me to decide. > > * "f00.00000001 might have been detected as old and copied to the remote > host and during the same time GC decides to now reuse it... ?That's why > I personally find externally organized pruning better. Another thing I > often miss is the ability to combine size and time based rotation." (Rainer) > > The proposal never reuses log files. We'll never overwrite anything. > Instead, we'll delete the oldest files as we create new ones. If we tell > the users to prune the older log files themselves, I know what the first > bug filed against the new policy will be. :-) Regarding rotating based > on both size and time: most people care about size so I think that's > what we'll do. If you want more advanced management of the logs you'll > have to set N to infinity (at least we'll need a way to say "never > delete older files") so that HotSpot doesn't delete any files and you'll > be able to copy them and delete them yourself. > > But, seriously, this is excellent feedback. You guys are doing more wild > stuff with our logs than I had imagined. :-) > > * "Will you start another discussion about the data contents of the > file?" (Rainer) > > We'll do that separately, based most likely on a wiki. When we get to > it. No promises though! > > * "For more debug detail per collector one could use PrintHeapAtGC" > (Michael) > > Well, PrintHeapAtGC was supposed to be added for debugging purposes, > i.e., to find out what the address range of each generation is. However, > it has clearer information on how full each generation is which is why > people use it today (it's very space inefficient though...). We are > hoping to add that information to the standard GC log records to > eliminate the need for PrintHeapAtGC. > > * "In our application we prefix _every_ "cyclic" log file with the > config options used to start the app." (Jeff) > > Adding configuration / whatever information at the top of every log file > fragment is an excellent suggestion. Thanks for bringing it up. > > * "How many digits in the sequence? ?Would that be configurable?" (Adam) > > 8 should be more enough (do you really see the need for more than 99m > log fragments)? Actually, even 6 will probably ?be enough. And if we go > over that, we won't cycle the numbers, we'll just expand the number field. > > * "IMHO it would be great if we could use %p also for" (Johann) > > I was going to say that this would start getting over the top. But I was > not aware that you can do that with the fatal error log. I'll need to > investigate that further. So, we'll leave this (and additional custom > formatting in the GC log name) as a "maybe". :-) I'm not quite sure > whether we'd want to use the same facility for the sequence numbers > though, given that they'd be needed if we split the log and won't be > needed if we don't. For those, I just vote to just add a suffix to the > log file name when they are needed. > > Thanks again for all the good points, > > Tony, HotSpot GC Group > > On 5/6/2010 3:32 PM, Tony Printezis wrote: >> Hi all, >> >> We would like your input on some changes to HotSpot's GC logging that >> we have been discussing. We have been wanting to improve our GC >> logging for some time. However we haven't had the resources to spend >> on it. We don't know when we'll get to it, but we'd still like to get >> some feedback on our plans. >> >> The changes fall into two categories. >> >> >> A. Unification and improvement of -verbosegc / -XX:+PrintGCDetails >> output. >> >> I strongly believe that maintaining two GC log formats is >> counter-productive, especially given that the current -verbosegc >> format is unhelpful in many ways (i.e., lacks a lot of helpful >> information). So, we would like to unify the two into one, with maybe >> -XX:+PrintGCDetails generating a superset of what -verbosegc would >> generate (so that a parser for the -XX:+PrintGCDetails output will >> also be able to parse the -verbosegc output). The new output will not >> be what -XX:+PrintGCDetails generates today but something that can be >> reliably parsed and it is also reasonably human-readable (so, no xml >> and no space/tab-separated formats). Additionally, we're proposing to >> enable -XX:+PrintGCTimeStamps by default (in fact, we'll probably >> deprecate and ignore that option, I can't believe that users will >> really not want a time stamp per GC log record). We'll leave >> -XX:+PrintGCDateStamps to be optional though. >> >> Specific questions: >> >> - Is anyone really attached to the old -verbosegc output? >> - Would anyone really hate having time stamps by default? >> - I know that a lot of folks have their own parsers for our current GC >> log formats. Would you be happy if we provided you with a (reliable!) >> parser for the new format in Java that you can easily adapt? >> >> >> B. Introducing "cyclic" GC logs. >> >> This is something that a lot of folks have asked for given that they >> were concerned with the GC logs getting very large (a 1TB disk is $85 >> these days, but anyway...). Given that each GC log record is of >> variable size, we cannot easily cycle through the log using the same >> file (I'd rather not have to overwrite existing records). Our current >> proposal is for the user to specify a file number N and a size target >> S for each file. For a given GC log -Xloggc:foo, HotSpot will generate >> >> foo.00000001 >> foo.00000002 >> foo.00000003 >> etc. >> >> (we'll create a new file as soon as the size of the one we are writing >> to exceeds S, so each file will be slightly larger than S but it will >> be helpful not to split individual log records between two files) >> >> When we create a new file, if we have more than N files we'll delete >> the oldest. So, in the above example, if N == 3, when we create >> foo.00000004 we'll delete foo.00000001. >> >> Note that in the above scheme, the logs are not really "cyclic" but, >> instead, we're pruning the oldest records every now and then, which >> has the same effect. >> >> Another (related) request has been to maybe append the GC log file >> name with the pid of the JVM that's generating it. Maybe we don't want >> to do this by default. But, would people find it helpful if we provide >> a new cmd line parameter to do that? So, for the above example and >> assuming that the JVM's pid is 1234, the GC log file(s) will be either: >> >> foo.1234 >> >> or >> >> foo.1234.00000001 >> foo.1234.00000002 >> foo.1234.00000003 >> etc. >> >> Specific questions: >> >> - Would people really hate it if HotSpot starts appending the GC log >> file name with a (zero-padded) sequence number? Maybe if N == 1 (the >> default), HotSpot will skip the sequence number and ignore S, i.e., >> behave as it does today. >> - To the people who have been asking for cyclic GC logs: is the >> sequence number scheme above good enough? >> >> >> Thanks in advance for your feedback, >> >> Tony, HotSpot GC Group >> >> > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -- Volker Kleinschmidt Senior Support Engineer Blackboard Client Support _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From tony.printezis at oracle.com Mon May 10 22:41:28 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Mon, 10 May 2010 18:41:28 -0400 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: References: <4BE3194E.902@oracle.com> <4BE43C97.6000805@oracle.com> Message-ID: <4BE88B98.8090705@oracle.com> Volker, Volker Kleinschmidt wrote: > Where is the advantage to using counter numbers in the log file names? > If you take the sensible suggestion made by several others here to use > ISO datetimestamps in the filenames, you have a natural sequence, no > worries about name re-use, and easily automated log maintenance by > those that want to keep these logs for a while. You could still > implement an auto-deletion of "older" logs for those that want it. > Each log can then easily be identified, and an optional PID Well, even with date stamps, if you don't have the JVM pid in the file name you won't know which JVM each log came from either. And, if you only have date stamps on the files names, you might not know whether you're missing a file in between the two your customer sent you (you'd need to look at the contents to see whether the time stamps are contiguous or there's a potential hole). Like the time stamps vs. date stamps argument, the sequence number is the minimum you'd need and some folks might want to also enable date stamps in addition to the seq numbers. BTW, something that I just thought of: if we do introduce a way for people to use %n, %d, whatever in the GC log file names, would it also be helpful to have %h for "host name"? > in the > filename would be helpful too. But a counter? What info does that give > you by itself, without additional context? None whatsoever. That's why > others declared it as "not meaningful". > > We mainly need gc logs for post-mortem performance problem analysis, > so the date/time stamps on the logs would be really handy to identify > which log to look at (we often don't get to look at the log on the > client system, hence file dates don't help us, Good point. > and they often don't > have PrintGCDateStamps enabled). However the core issue for us is > prevention of log overwriting when -Xloggc specifies a fixed filename > and the VM gets restarted by the service wrapper watchdog feature, > i.e. when you really needed that GC log. So any auto-log-rolling > mechanism is much better than none and will make me yodel with joy :^) > Yodel? This is almost a good reason to drop that proposal asap. ;-) ;-) ;-) Tony > On Fri, May 7, 2010 at 11:15 AM, Tony Printezis > wrote: > >> Hi all, >> >> First, thank you for all the excellent feedback (which I see as mostly >> positive to the proposals). We are glad that people still care about the >> GC logs. Instead of replying to individual e-mails, I'll consolidate my >> replies here. >> >> * "I would say that PrintGCDateStamps should be the default" (several >> folks brought this up) >> >> From the point of view of analyzing logs to just look at the GC's >> behavior, we only need time stamps. And this is the reason why I'd like >> to see them turned on by default (too many times we got a log without >> time stamps for which we said "damn, if it had time stamps we'd get a >> better idea of what was happening"). So, they are the minimum we need to >> get a good picture of how the GC behaved. Date stamps will increase the >> size of the log (which still seems to be an issue for some people) and >> be helpful in fewer places (i.e., when comparing application and GC >> events; but we generally do not do that). So, you'll have to turn them >> on yourselves. :-) >> >> * "successive runs overwrite the previous log file" (several folks >> brought this up) >> >> Don't you think that adding the JVM's pid to the log file name would >> eliminate this problem? >> >> * "I'm not attached to the old format" (several folks mentioned this) >> >> Oh, good. I'll be quoting you when I'll be making a case to remove it. >> >> * "A serial-attached-scsi (aka SAS) disk at 10k rpm is a little bit more >> expensive than $85/TB" (Ryan) >> >> Point taken, but do you really need super duper 10k rpm disks to store >> GC log files. :-) >> >> * "if you're going to roll the logs then I would prefer a meaningful >> suffix rather than just a counter." >> >> A counter seems like a perfectly meaningful suffix to me. >> >> * "wouldn't you still need a verbose output that is specific to each >> collector in order to provide a "debug" level of detail?" (Matt) >> >> Very good point. The verbose output will be as unified as possible, but >> with indeed GC-specific extensions not to lose that information. >> >> * "I guess you plan to provide a parser written in Java?" (Rainer) >> >> Java? We're HotSpot developers! We only work in C++, assembly, and awk! >> Just kidding... Yes, indeed in Java. >> >> * "so possibly Open Source with a nice license like Apache Software >> License 2" (Rainer) >> >> Maybe, and not up to me to decide. >> >> * "f00.00000001 might have been detected as old and copied to the remote >> host and during the same time GC decides to now reuse it... That's why >> I personally find externally organized pruning better. Another thing I >> often miss is the ability to combine size and time based rotation." (Rainer) >> >> The proposal never reuses log files. We'll never overwrite anything. >> Instead, we'll delete the oldest files as we create new ones. If we tell >> the users to prune the older log files themselves, I know what the first >> bug filed against the new policy will be. :-) Regarding rotating based >> on both size and time: most people care about size so I think that's >> what we'll do. If you want more advanced management of the logs you'll >> have to set N to infinity (at least we'll need a way to say "never >> delete older files") so that HotSpot doesn't delete any files and you'll >> be able to copy them and delete them yourself. >> >> But, seriously, this is excellent feedback. You guys are doing more wild >> stuff with our logs than I had imagined. :-) >> >> * "Will you start another discussion about the data contents of the >> file?" (Rainer) >> >> We'll do that separately, based most likely on a wiki. When we get to >> it. No promises though! >> >> * "For more debug detail per collector one could use PrintHeapAtGC" >> (Michael) >> >> Well, PrintHeapAtGC was supposed to be added for debugging purposes, >> i.e., to find out what the address range of each generation is. However, >> it has clearer information on how full each generation is which is why >> people use it today (it's very space inefficient though...). We are >> hoping to add that information to the standard GC log records to >> eliminate the need for PrintHeapAtGC. >> >> * "In our application we prefix _every_ "cyclic" log file with the >> config options used to start the app." (Jeff) >> >> Adding configuration / whatever information at the top of every log file >> fragment is an excellent suggestion. Thanks for bringing it up. >> >> * "How many digits in the sequence? Would that be configurable?" (Adam) >> >> 8 should be more enough (do you really see the need for more than 99m >> log fragments)? Actually, even 6 will probably be enough. And if we go >> over that, we won't cycle the numbers, we'll just expand the number field. >> >> * "IMHO it would be great if we could use %p also for" (Johann) >> >> I was going to say that this would start getting over the top. But I was >> not aware that you can do that with the fatal error log. I'll need to >> investigate that further. So, we'll leave this (and additional custom >> formatting in the GC log name) as a "maybe". :-) I'm not quite sure >> whether we'd want to use the same facility for the sequence numbers >> though, given that they'd be needed if we split the log and won't be >> needed if we don't. For those, I just vote to just add a suffix to the >> log file name when they are needed. >> >> Thanks again for all the good points, >> >> Tony, HotSpot GC Group >> >> On 5/6/2010 3:32 PM, Tony Printezis wrote: >> >>> Hi all, >>> >>> We would like your input on some changes to HotSpot's GC logging that >>> we have been discussing. We have been wanting to improve our GC >>> logging for some time. However we haven't had the resources to spend >>> on it. We don't know when we'll get to it, but we'd still like to get >>> some feedback on our plans. >>> >>> The changes fall into two categories. >>> >>> >>> A. Unification and improvement of -verbosegc / -XX:+PrintGCDetails >>> output. >>> >>> I strongly believe that maintaining two GC log formats is >>> counter-productive, especially given that the current -verbosegc >>> format is unhelpful in many ways (i.e., lacks a lot of helpful >>> information). So, we would like to unify the two into one, with maybe >>> -XX:+PrintGCDetails generating a superset of what -verbosegc would >>> generate (so that a parser for the -XX:+PrintGCDetails output will >>> also be able to parse the -verbosegc output). The new output will not >>> be what -XX:+PrintGCDetails generates today but something that can be >>> reliably parsed and it is also reasonably human-readable (so, no xml >>> and no space/tab-separated formats). Additionally, we're proposing to >>> enable -XX:+PrintGCTimeStamps by default (in fact, we'll probably >>> deprecate and ignore that option, I can't believe that users will >>> really not want a time stamp per GC log record). We'll leave >>> -XX:+PrintGCDateStamps to be optional though. >>> >>> Specific questions: >>> >>> - Is anyone really attached to the old -verbosegc output? >>> - Would anyone really hate having time stamps by default? >>> - I know that a lot of folks have their own parsers for our current GC >>> log formats. Would you be happy if we provided you with a (reliable!) >>> parser for the new format in Java that you can easily adapt? >>> >>> >>> B. Introducing "cyclic" GC logs. >>> >>> This is something that a lot of folks have asked for given that they >>> were concerned with the GC logs getting very large (a 1TB disk is $85 >>> these days, but anyway...). Given that each GC log record is of >>> variable size, we cannot easily cycle through the log using the same >>> file (I'd rather not have to overwrite existing records). Our current >>> proposal is for the user to specify a file number N and a size target >>> S for each file. For a given GC log -Xloggc:foo, HotSpot will generate >>> >>> foo.00000001 >>> foo.00000002 >>> foo.00000003 >>> etc. >>> >>> (we'll create a new file as soon as the size of the one we are writing >>> to exceeds S, so each file will be slightly larger than S but it will >>> be helpful not to split individual log records between two files) >>> >>> When we create a new file, if we have more than N files we'll delete >>> the oldest. So, in the above example, if N == 3, when we create >>> foo.00000004 we'll delete foo.00000001. >>> >>> Note that in the above scheme, the logs are not really "cyclic" but, >>> instead, we're pruning the oldest records every now and then, which >>> has the same effect. >>> >>> Another (related) request has been to maybe append the GC log file >>> name with the pid of the JVM that's generating it. Maybe we don't want >>> to do this by default. But, would people find it helpful if we provide >>> a new cmd line parameter to do that? So, for the above example and >>> assuming that the JVM's pid is 1234, the GC log file(s) will be either: >>> >>> foo.1234 >>> >>> or >>> >>> foo.1234.00000001 >>> foo.1234.00000002 >>> foo.1234.00000003 >>> etc. >>> >>> Specific questions: >>> >>> - Would people really hate it if HotSpot starts appending the GC log >>> file name with a (zero-padded) sequence number? Maybe if N == 1 (the >>> default), HotSpot will skip the sequence number and ignore S, i.e., >>> behave as it does today. >>> - To the people who have been asking for cyclic GC logs: is the >>> sequence number scheme above good enough? >>> >>> >>> Thanks in advance for your feedback, >>> >>> Tony, HotSpot GC Group >>> >>> >>> >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> >> > > > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From y.s.ramakrishna at oracle.com Mon May 10 23:15:47 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Mon, 10 May 2010 23:15:47 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6951188: CMS: move PromotionInfo into its own file Message-ID: <20100510231549.B43B2441DB@hg.openjdk.java.net> Changeset: a8127dc669ba Author: ysr Date: 2010-05-10 12:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a8127dc669ba 6951188: CMS: move PromotionInfo into its own file Summary: Moved PromotionInfo and friends into new files promotionInfo.{h,c}pp from their previous compactibleFreeListSpace.{h,c}pp home. Reviewed-by: apetrusenko ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp + src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp + src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep From yamauchi at google.com Mon May 10 23:50:27 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Mon, 10 May 2010 16:50:27 -0700 Subject: Free ratio based heap shrinking in the parallel collector In-Reply-To: <4BDF0E2C.7020809@oracle.com> References: <56E32EB8-AA26-477B-872F-6AD5C2104900@Sun.COM> <4BB4C3A4.40701@oracle.com> <4BD9F2E6.3090404@oracle.com> <4BDF0E2C.7020809@oracle.com> Message-ID: Jon, Thanks for your comments. My new revision is here ??http://cr.openjdk.java.net/~hiroshi/webrevs/heapshrink/ My comments are inlined below: > In parallelScavengeHeap.cpp > > In the UseParallelGC collector the initial size (init_size) can be > significantly larger than the minimum size.?? If you want to shrink down > the heap to minimize footprint, do you really want to limit by the > initial size instead of the minimum size? > > 1001 maximum_desired_capacity = MAX2(maximum_desired_capacity, init_size); > > Similarly here the amount of used data could be very small and > setting the floor at the initial size may not be what you > want. > > 1034 minimum_desired_capacity = MAX2(minimum_desired_capacity, init_size); I changed the code so that it uses the min size instead of the init size. > > In psYoungGen.cpp you guard output with PrintGC only.? In similar > cases this type of output is guarded with Verbose also.? Does this > output as is get printed in the middle of the usual > -verbosegc (also known as PrintGC) line? > > 1000 if (PrintGC) { > 1001 gclog_or_tty->print_cr(" Resizing young gen. expand_bytes=%d,%d", > 1002 eden_expand_bytes, survivor_expand_bytes); > 1003 gclog_or_tty->print("BEFORE: Young Gen: "); > 1004 gclog_or_tty->print("eden capacity : " SIZE_FORMAT ", ", > 1005 eden_space()->capacity_in_bytes()); > 1006 gclog_or_tty->print("eden used : " SIZE_FORMAT ", " , > 1007 eden_space()->used_in_bytes()); > 1008 gclog_or_tty->print("survivor capacity : " SIZE_FORMAT ", ", > 1009 from_space()->capacity_in_bytes()); > 1010 gclog_or_tty->print_cr("survivor used : " SIZE_FORMAT ", " , > 1011 from_space()->used_in_bytes()); > 1012 } I added Verbose to the guard. And yes, the output show up in the middle of PrintGC line. > > > In psOldGen.cpp you could try to expand up to max_gen_size > instead of returning? > > 501 void PSOldGen::try_to_expand_by(size_t expand_bytes) { > 502 if (expand_bytes < MinHeapDeltaBytes || > 503 capacity_in_bytes() + expand_bytes > max_gen_size()) { > 504 return; > > Additionally PSOldGen::expand() chooses to use MinHeapDeltaBytes > as the minimum expansion size (in the sense that sizes for expansion > are round up to MinHeapDeltaBytes).?? You would rather not expand > for less than MinHeapDeltaBytes??? I'll admit that there maybe some > inconsistencies in the way MinHeapDeltaBytes is used.? Just checking > that this is what you want to do. > > Again, seems to me that you want to shrink down to the minimum > generation size as opposed to the initial size. > > ?523 void PSOldGen::try_to_shrink_by(size_t shrink_bytes) { > ?524?? if (shrink_bytes < MinHeapDeltaBytes || > ?525?????? capacity_in_bytes() - shrink_bytes < init_gen_size()) { > ?526???? return; > ?527?? } Now I have: 502 if (capacity_in_bytes() + expand_bytes > max_gen_size()) { 503 expand_bytes = max_gen_size() - capacity_in_bytes(); 504 } and likewise for try_to_shrink_by(). 1. It allows the subsequent code (eg expand()) to round up the size < MinHeapDeltaBytes. 2. It rounds down the size that goes past the max/min gen size so that the heap is expanded/shrunk to the max/min. > > In globals.hpp.? We may want this feature implemented in other > collectors at some point - G1 comes to mind.? I'd drop the leading > PS on the flag so that it is ResizeByFreeRatioWithSystemGC. > > 3079?? product(bool, PSResizeByFreeRatioWithSystemGC, false,???????????????????? \ > 3080?????????? "Resize the heap by free ratio in System.gc() "?????????????????? \ > 3081?????????? "under UseParallelGC") > Done. Hiroshi From martin at attivio.com Tue May 11 14:13:41 2010 From: martin at attivio.com (Martin Serrano) Date: Tue, 11 May 2010 10:13:41 -0400 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: <4BE43C97.6000805@oracle.com> References: <4BE3194E.902@oracle.com> <4BE43C97.6000805@oracle.com> Message-ID: <9694A6C3D68A4249BD9E1A875B6BA81E105CCD27@bos0ex01.corp.attivio.com> Tony, Love the ideas. We start java via a wrapper process and we currently set the gc log file name using a timestamp. In upcoming releases we are planning on augmenting that with a meaningful application name. Specific comments on your response: > * "if you're going to roll the logs then I would prefer a meaningful > suffix rather than just a counter." > > A counter seems like a perfectly meaningful suffix to me. I would prefer to have a consistent suffix (like .log), in the filename. Perhaps you could support just the %d format for the counter in the generated log name. We'd also appreciate having startup information at the top of the gc log. Cheers, Martin -----Original Message----- From: hotspot-gc-use-bounces at openjdk.java.net [mailto:hotspot-gc-use-bounces at openjdk.java.net] On Behalf Of Tony Printezis Sent: Friday, May 07, 2010 12:15 PM To: hotspot-gc-use at openjdk.java.net Subject: Re: Feedback requested: HotSpot GC logging improvements Hi all, First, thank you for all the excellent feedback (which I see as mostly positive to the proposals). We are glad that people still care about the GC logs. Instead of replying to individual e-mails, I'll consolidate my replies here. * "I would say that PrintGCDateStamps should be the default" (several folks brought this up) From the point of view of analyzing logs to just look at the GC's behavior, we only need time stamps. And this is the reason why I'd like to see them turned on by default (too many times we got a log without time stamps for which we said "damn, if it had time stamps we'd get a better idea of what was happening"). So, they are the minimum we need to get a good picture of how the GC behaved. Date stamps will increase the size of the log (which still seems to be an issue for some people) and be helpful in fewer places (i.e., when comparing application and GC events; but we generally do not do that). So, you'll have to turn them on yourselves. :-) * "successive runs overwrite the previous log file" (several folks brought this up) Don't you think that adding the JVM's pid to the log file name would eliminate this problem? * "I'm not attached to the old format" (several folks mentioned this) Oh, good. I'll be quoting you when I'll be making a case to remove it. * "A serial-attached-scsi (aka SAS) disk at 10k rpm is a little bit more expensive than $85/TB" (Ryan) Point taken, but do you really need super duper 10k rpm disks to store GC log files. :-) * "if you're going to roll the logs then I would prefer a meaningful suffix rather than just a counter." A counter seems like a perfectly meaningful suffix to me. * "wouldn't you still need a verbose output that is specific to each collector in order to provide a "debug" level of detail?" (Matt) Very good point. The verbose output will be as unified as possible, but with indeed GC-specific extensions not to lose that information. * "I guess you plan to provide a parser written in Java?" (Rainer) Java? We're HotSpot developers! We only work in C++, assembly, and awk! Just kidding... Yes, indeed in Java. * "so possibly Open Source with a nice license like Apache Software License 2" (Rainer) Maybe, and not up to me to decide. * "f00.00000001 might have been detected as old and copied to the remote host and during the same time GC decides to now reuse it... That's why I personally find externally organized pruning better. Another thing I often miss is the ability to combine size and time based rotation." (Rainer) The proposal never reuses log files. We'll never overwrite anything. Instead, we'll delete the oldest files as we create new ones. If we tell the users to prune the older log files themselves, I know what the first bug filed against the new policy will be. :-) Regarding rotating based on both size and time: most people care about size so I think that's what we'll do. If you want more advanced management of the logs you'll have to set N to infinity (at least we'll need a way to say "never delete older files") so that HotSpot doesn't delete any files and you'll be able to copy them and delete them yourself. But, seriously, this is excellent feedback. You guys are doing more wild stuff with our logs than I had imagined. :-) * "Will you start another discussion about the data contents of the file?" (Rainer) We'll do that separately, based most likely on a wiki. When we get to it. No promises though! * "For more debug detail per collector one could use PrintHeapAtGC" (Michael) Well, PrintHeapAtGC was supposed to be added for debugging purposes, i.e., to find out what the address range of each generation is. However, it has clearer information on how full each generation is which is why people use it today (it's very space inefficient though...). We are hoping to add that information to the standard GC log records to eliminate the need for PrintHeapAtGC. * "In our application we prefix _every_ "cyclic" log file with the config options used to start the app." (Jeff) Adding configuration / whatever information at the top of every log file fragment is an excellent suggestion. Thanks for bringing it up. * "How many digits in the sequence? Would that be configurable?" (Adam) 8 should be more enough (do you really see the need for more than 99m log fragments)? Actually, even 6 will probably be enough. And if we go over that, we won't cycle the numbers, we'll just expand the number field. * "IMHO it would be great if we could use %p also for" (Johann) I was going to say that this would start getting over the top. But I was not aware that you can do that with the fatal error log. I'll need to investigate that further. So, we'll leave this (and additional custom formatting in the GC log name) as a "maybe". :-) I'm not quite sure whether we'd want to use the same facility for the sequence numbers though, given that they'd be needed if we split the log and won't be needed if we don't. For those, I just vote to just add a suffix to the log file name when they are needed. Thanks again for all the good points, Tony, HotSpot GC Group On 5/6/2010 3:32 PM, Tony Printezis wrote: > Hi all, > > We would like your input on some changes to HotSpot's GC logging that > we have been discussing. We have been wanting to improve our GC > logging for some time. However we haven't had the resources to spend > on it. We don't know when we'll get to it, but we'd still like to get > some feedback on our plans. > > The changes fall into two categories. > > > A. Unification and improvement of -verbosegc / -XX:+PrintGCDetails > output. > > I strongly believe that maintaining two GC log formats is > counter-productive, especially given that the current -verbosegc > format is unhelpful in many ways (i.e., lacks a lot of helpful > information). So, we would like to unify the two into one, with maybe > -XX:+PrintGCDetails generating a superset of what -verbosegc would > generate (so that a parser for the -XX:+PrintGCDetails output will > also be able to parse the -verbosegc output). The new output will not > be what -XX:+PrintGCDetails generates today but something that can be > reliably parsed and it is also reasonably human-readable (so, no xml > and no space/tab-separated formats). Additionally, we're proposing to > enable -XX:+PrintGCTimeStamps by default (in fact, we'll probably > deprecate and ignore that option, I can't believe that users will > really not want a time stamp per GC log record). We'll leave > -XX:+PrintGCDateStamps to be optional though. > > Specific questions: > > - Is anyone really attached to the old -verbosegc output? > - Would anyone really hate having time stamps by default? > - I know that a lot of folks have their own parsers for our current GC > log formats. Would you be happy if we provided you with a (reliable!) > parser for the new format in Java that you can easily adapt? > > > B. Introducing "cyclic" GC logs. > > This is something that a lot of folks have asked for given that they > were concerned with the GC logs getting very large (a 1TB disk is $85 > these days, but anyway...). Given that each GC log record is of > variable size, we cannot easily cycle through the log using the same > file (I'd rather not have to overwrite existing records). Our current > proposal is for the user to specify a file number N and a size target > S for each file. For a given GC log -Xloggc:foo, HotSpot will generate > > foo.00000001 > foo.00000002 > foo.00000003 > etc. > > (we'll create a new file as soon as the size of the one we are writing > to exceeds S, so each file will be slightly larger than S but it will > be helpful not to split individual log records between two files) > > When we create a new file, if we have more than N files we'll delete > the oldest. So, in the above example, if N == 3, when we create > foo.00000004 we'll delete foo.00000001. > > Note that in the above scheme, the logs are not really "cyclic" but, > instead, we're pruning the oldest records every now and then, which > has the same effect. > > Another (related) request has been to maybe append the GC log file > name with the pid of the JVM that's generating it. Maybe we don't want > to do this by default. But, would people find it helpful if we provide > a new cmd line parameter to do that? So, for the above example and > assuming that the JVM's pid is 1234, the GC log file(s) will be either: > > foo.1234 > > or > > foo.1234.00000001 > foo.1234.00000002 > foo.1234.00000003 > etc. > > Specific questions: > > - Would people really hate it if HotSpot starts appending the GC log > file name with a (zero-padded) sequence number? Maybe if N == 1 (the > default), HotSpot will skip the sequence number and ignore S, i.e., > behave as it does today. > - To the people who have been asking for cyclic GC logs: is the > sequence number scheme above good enough? > > > Thanks in advance for your feedback, > > Tony, HotSpot GC Group > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From tony.printezis at oracle.com Tue May 11 14:33:49 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 11 May 2010 10:33:49 -0400 Subject: Feedback requested: HotSpot GC logging improvements In-Reply-To: <9694A6C3D68A4249BD9E1A875B6BA81E105CCD27@bos0ex01.corp.attivio.com> References: <4BE3194E.902@oracle.com> <4BE43C97.6000805@oracle.com> <9694A6C3D68A4249BD9E1A875B6BA81E105CCD27@bos0ex01.corp.attivio.com> Message-ID: <4BE96ACD.2070805@oracle.com> Martin, Hi, thanks for the feedback. Martin Serrano wrote: > I would prefer to have a consistent suffix (like .log), in the filename. Perhaps you could support just the %d format for the counter in the generated log name. > Well, if you allow parameters in the log file name, like 'foo.%d.%n.log' then folks can give their one suffix. I don't think we want to start adding one... Tony _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From john.coomes at oracle.com Wed May 12 19:55:33 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 12 May 2010 19:55:33 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6951923: some uses of fatal1 were missed by 6888954 Message-ID: <20100512195535.86A2C44542@hg.openjdk.java.net> Changeset: 67d74f7a15d9 Author: jcoomes Date: 2010-05-12 10:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/67d74f7a15d9 6951923: some uses of fatal1 were missed by 6888954 Reviewed-by: jcoomes Contributed-by: Gary Benson ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp From y.s.ramakrishna at oracle.com Wed May 12 23:38:51 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Wed, 12 May 2010 16:38:51 -0700 Subject: Growing GC Young Gen Times In-Reply-To: References: Message-ID: <4BEB3C0B.6040804@oracle.com> Try the jvm from hs18 (jdk 7) and let us know what you see. Or wait for JDK 6u21 which (i think) is slated for sometime next month. Or get an hs17 JVM with the fix 6631166 via your Java support and give it a try. Also add -XX:+UseLargePages -XX:+AlwaysPreTouch and if you have enough cores try increasing yr ParallelGCThreads from your current setting of 4 (what was the default you got?). I have not looked at the log you sent, but can take a look when i get some time; but no promises, as i am drowned in other work at the moment. -- ramki On 05/12/10 15:19, Matt Fowles wrote: > All~ > > I have a large app that produces ~4g of garbage every 30 seconds and > am trying to reduce the size of gc outliers. About 99% of this data > is garbage, but almost anything that survives one collection survives > for an indeterminately long amount of time. We are currently using > the following VM and options: > > java version "1.6.0_20" > Java(TM) SE Runtime Environment (build 1.6.0_20-b02) > Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) > > -verbose:gc > -XX:+PrintGCTimeStamps > -XX:+PrintGCDetails > -XX:+PrintGCTaskTimeStamps > -XX:+PrintTenuringDistribution > -XX:+PrintCommandLineFlags > -XX:+PrintReferenceGC > -Xms32g -Xmx32g -Xmn4g > -XX:+UseParNewGC > -XX:ParallelGCThreads=4 > -XX:+UseConcMarkSweepGC > -XX:ParallelCMSThreads=4 > -XX:CMSInitiatingOccupancyFraction=60 > -XX:+UseCMSInitiatingOccupancyOnly > -XX:+CMSParallelRemarkEnabled > -XX:MaxGCPauseMillis=50 > -Xloggc:gc.log > > > As you can see from the GC log, we never actually reach the point > where the CMS kicks in (after app startup). But our young gens seem > to take increasingly long to collect as time goes by. > > The steady state of the app is reached around 956.392 into the log > with a collection that takes 0.106 seconds. Thereafter the survivor > space remains roughly constantly as filled and the amount promoted to > old gen also remains constant, but the collection times increase to > 2.855 seconds by the end of the 3.5 hour run. > > Has anyone seen this sort of behavior before? Are there more switches > that I should try running with? > > Obviously, I am working to profile the app and reduce the garbage load > in parallel. But if I still see this sort of problem, it is only a > question of how long must the app run before I see unacceptable > latency spikes. > > Matt > > > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From jon.masamitsu at oracle.com Thu May 13 15:52:58 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 13 May 2010 08:52:58 -0700 Subject: Free ratio based heap shrinking in the parallel collector In-Reply-To: References: <56E32EB8-AA26-477B-872F-6AD5C2104900@Sun.COM> <4BB4C3A4.40701@oracle.com> <4BD9F2E6.3090404@oracle.com> <4BDF0E2C.7020809@oracle.com> Message-ID: <4BEC205A.9080207@oracle.com> Hiroshi, Looks fine. I only looked at the files where you indicated a change in your mail below. If there is more for me to look at, please let me know which files. I'll get another one of the GC guys here to also review the changes. I've create a CR for this. 6952079: With UseParallelScavenge use MinHeapFreeRation/MaxHeapFreeRatio if UseAdaptiveSivePolicy is off. What testing have you done? I would expect that UseParallelGC with UseAdaptiveSizePolicy turned off to grow and shrink the generations in a way similar to UseSerialGC. Can you check that is the case? I think if you set SurvivorRatio explicitly the survivor spaces will be close. You might have to set InitialSurvivorRatio. If you set InitialTenuringThreshold and MaxTenuringThreshold to the same value, I would expect the promotion rate to be close. Promotion rates don't have to be the same but it would remove one variable from a comparison. If there are surprises let talk about them. Different isn't necessarily wrong. Jon On 05/10/10 16:50, Hiroshi Yamauchi wrote: > Jon, > > Thanks for your comments. My new revision is here > > http://cr.openjdk.java.net/~hiroshi/webrevs/heapshrink/ > > My comments are inlined below: > > >> In parallelScavengeHeap.cpp >> >> In the UseParallelGC collector the initial size (init_size) can be >> significantly larger than the minimum size. If you want to shrink down >> the heap to minimize footprint, do you really want to limit by the >> initial size instead of the minimum size? >> >> 1001 maximum_desired_capacity = MAX2(maximum_desired_capacity, init_size); >> >> Similarly here the amount of used data could be very small and >> setting the floor at the initial size may not be what you >> want. >> >> 1034 minimum_desired_capacity = MAX2(minimum_desired_capacity, init_size); >> > > I changed the code so that it uses the min size instead of the init size. > > >> In psYoungGen.cpp you guard output with PrintGC only. In similar >> cases this type of output is guarded with Verbose also. Does this >> output as is get printed in the middle of the usual >> -verbosegc (also known as PrintGC) line? >> >> 1000 if (PrintGC) { >> 1001 gclog_or_tty->print_cr(" Resizing young gen. expand_bytes=%d,%d", >> 1002 eden_expand_bytes, survivor_expand_bytes); >> 1003 gclog_or_tty->print("BEFORE: Young Gen: "); >> 1004 gclog_or_tty->print("eden capacity : " SIZE_FORMAT ", ", >> 1005 eden_space()->capacity_in_bytes()); >> 1006 gclog_or_tty->print("eden used : " SIZE_FORMAT ", " , >> 1007 eden_space()->used_in_bytes()); >> 1008 gclog_or_tty->print("survivor capacity : " SIZE_FORMAT ", ", >> 1009 from_space()->capacity_in_bytes()); >> 1010 gclog_or_tty->print_cr("survivor used : " SIZE_FORMAT ", " , >> 1011 from_space()->used_in_bytes()); >> 1012 } >> > > I added Verbose to the guard. And yes, the output show up in the > middle of PrintGC line. > > >> In psOldGen.cpp you could try to expand up to max_gen_size >> instead of returning? >> >> 501 void PSOldGen::try_to_expand_by(size_t expand_bytes) { >> 502 if (expand_bytes < MinHeapDeltaBytes || >> 503 capacity_in_bytes() + expand_bytes > max_gen_size()) { >> 504 return; >> >> Additionally PSOldGen::expand() chooses to use MinHeapDeltaBytes >> as the minimum expansion size (in the sense that sizes for expansion >> are round up to MinHeapDeltaBytes). You would rather not expand >> for less than MinHeapDeltaBytes? I'll admit that there maybe some >> inconsistencies in the way MinHeapDeltaBytes is used. Just checking >> that this is what you want to do. >> >> Again, seems to me that you want to shrink down to the minimum >> generation size as opposed to the initial size. >> >> 523 void PSOldGen::try_to_shrink_by(size_t shrink_bytes) { >> 524 if (shrink_bytes < MinHeapDeltaBytes || >> 525 capacity_in_bytes() - shrink_bytes < init_gen_size()) { >> 526 return; >> 527 } >> > > Now I have: > > 502 if (capacity_in_bytes() + expand_bytes > max_gen_size()) { > 503 expand_bytes = max_gen_size() - capacity_in_bytes(); > 504 } > > and likewise for try_to_shrink_by(). > > 1. It allows the subsequent code (eg expand()) to round up the size < > MinHeapDeltaBytes. > 2. It rounds down the size that goes past the max/min gen size so that > the heap is expanded/shrunk to the max/min. > > >> In globals.hpp. We may want this feature implemented in other >> collectors at some point - G1 comes to mind. I'd drop the leading >> PS on the flag so that it is ResizeByFreeRatioWithSystemGC. >> >> 3079 product(bool, PSResizeByFreeRatioWithSystemGC, false, \ >> 3080 "Resize the heap by free ratio in System.gc() " \ >> 3081 "under UseParallelGC") >> >> > > Done. > > Hiroshi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Thu May 13 16:23:18 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 13 May 2010 09:23:18 -0700 Subject: Growing GC Young Gen Times In-Reply-To: References: Message-ID: <4BEC2776.8010609@oracle.com> Matt, As Ramki indicated fragmentation might be an issue. As the fragmentation in the old generation increases, it takes longer to find space in the old generation into which to promote objects from the young generation. This is apparently not the problem that Wayne is having but you still might be hitting it. If you can connect jconsole to the VM and force a full GC, that would tell us if it's fragmentation. There might be a scaling issue with the UseParNewGC. If you can use -XX:-UseParNewGC (turning off the parallel young generation collection) with -XX:+UseConcMarkSweepGC the pauses will be longer but may be more stable. That's not the solution but just part of the investigation. You could try just -XX:+UseParNewGC without -XX:+UseConcMarkSweepGC and if you don't see the growing young generation pause, that would indicate something specific about promotion into the CMS generation. UseParallelGC is different from UseParNewGC in a number of ways and if you try UseParallelGC and still see the growing young generation pauses, I'd suspect something special about your application. If you can run these experiments hopefully they will tell us where to look next. Jon On 05/12/10 15:19, Matt Fowles wrote: > All~ > > I have a large app that produces ~4g of garbage every 30 seconds and > am trying to reduce the size of gc outliers. About 99% of this data > is garbage, but almost anything that survives one collection survives > for an indeterminately long amount of time. We are currently using > the following VM and options: > > java version "1.6.0_20" > Java(TM) SE Runtime Environment (build 1.6.0_20-b02) > Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) > > -verbose:gc > -XX:+PrintGCTimeStamps > -XX:+PrintGCDetails > -XX:+PrintGCTaskTimeStamps > -XX:+PrintTenuringDistribution > -XX:+PrintCommandLineFlags > -XX:+PrintReferenceGC > -Xms32g -Xmx32g -Xmn4g > -XX:+UseParNewGC > -XX:ParallelGCThreads=4 > -XX:+UseConcMarkSweepGC > -XX:ParallelCMSThreads=4 > -XX:CMSInitiatingOccupancyFraction=60 > -XX:+UseCMSInitiatingOccupancyOnly > -XX:+CMSParallelRemarkEnabled > -XX:MaxGCPauseMillis=50 > -Xloggc:gc.log > > > As you can see from the GC log, we never actually reach the point > where the CMS kicks in (after app startup). But our young gens seem > to take increasingly long to collect as time goes by. > > The steady state of the app is reached around 956.392 into the log > with a collection that takes 0.106 seconds. Thereafter the survivor > space remains roughly constantly as filled and the amount promoted to > old gen also remains constant, but the collection times increase to > 2.855 seconds by the end of the 3.5 hour run. > > Has anyone seen this sort of behavior before? Are there more switches > that I should try running with? > > Obviously, I am working to profile the app and reduce the garbage load > in parallel. But if I still see this sort of problem, it is only a > question of how long must the app run before I see unacceptable > latency spikes. > > Matt > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From y.s.ramakrishna at oracle.com Thu May 13 21:52:24 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Thu, 13 May 2010 14:52:24 -0700 Subject: Growing GC Young Gen Times In-Reply-To: References: <4BEC2776.8010609@oracle.com> Message-ID: <4BEC7498.6030405@oracle.com> On 05/13/10 10:50, Matt Fowles wrote: > Jon~ > > This may sound naive, but how can fragmentation be an issue if the old > gen has never been collected? I would think we are still in the space > where we can just bump the old gen alloc pointer... Matt, The old gen allocator may fragment the space. Allocation is not exactly "bump a pointer". -- ramki > > Matt > > On Thu, May 13, 2010 at 12:23 PM, Jon Masamitsu > wrote: >> Matt, >> >> As Ramki indicated fragmentation might be an issue. As the fragmentation >> in the old generation increases, it takes longer to find space in the old >> generation >> into which to promote objects from the young generation. This is apparently >> not >> the problem that Wayne is having but you still might be hitting it. If you >> can >> connect jconsole to the VM and force a full GC, that would tell us if it's >> fragmentation. >> >> There might be a scaling issue with the UseParNewGC. If you can use >> -XX:-UseParNewGC (turning off the parallel young >> generation collection) with -XX:+UseConcMarkSweepGC the pauses >> will be longer but may be more stable. That's not the solution but just >> part >> of the investigation. >> >> You could try just -XX:+UseParNewGC without -XX:+UseConcMarkSweepGC >> and if you don't see the growing young generation pause, that would indicate >> something specific about promotion into the CMS generation. >> >> UseParallelGC is different from UseParNewGC in a number of ways >> and if you try UseParallelGC and still see the growing young generation >> pauses, I'd suspect something special about your application. >> >> If you can run these experiments hopefully they will tell >> us where to look next. >> >> Jon >> >> >> On 05/12/10 15:19, Matt Fowles wrote: >> >> All~ >> >> I have a large app that produces ~4g of garbage every 30 seconds and >> am trying to reduce the size of gc outliers. About 99% of this data >> is garbage, but almost anything that survives one collection survives >> for an indeterminately long amount of time. We are currently using >> the following VM and options: >> >> java version "1.6.0_20" >> Java(TM) SE Runtime Environment (build 1.6.0_20-b02) >> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) >> >> -verbose:gc >> -XX:+PrintGCTimeStamps >> -XX:+PrintGCDetails >> -XX:+PrintGCTaskTimeStamps >> -XX:+PrintTenuringDistribution >> -XX:+PrintCommandLineFlags >> -XX:+PrintReferenceGC >> -Xms32g -Xmx32g -Xmn4g >> -XX:+UseParNewGC >> -XX:ParallelGCThreads=4 >> -XX:+UseConcMarkSweepGC >> -XX:ParallelCMSThreads=4 >> -XX:CMSInitiatingOccupancyFraction=60 >> -XX:+UseCMSInitiatingOccupancyOnly >> -XX:+CMSParallelRemarkEnabled >> -XX:MaxGCPauseMillis=50 >> -Xloggc:gc.log >> >> >> As you can see from the GC log, we never actually reach the point >> where the CMS kicks in (after app startup). But our young gens seem >> to take increasingly long to collect as time goes by. >> >> The steady state of the app is reached around 956.392 into the log >> with a collection that takes 0.106 seconds. Thereafter the survivor >> space remains roughly constantly as filled and the amount promoted to >> old gen also remains constant, but the collection times increase to >> 2.855 seconds by the end of the 3.5 hour run. >> >> Has anyone seen this sort of behavior before? Are there more switches >> that I should try running with? >> >> Obviously, I am working to profile the app and reduce the garbage load >> in parallel. But if I still see this sort of problem, it is only a >> question of how long must the app run before I see unacceptable >> latency spikes. >> >> Matt >> >> ________________________________ >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From jon.masamitsu at oracle.com Thu May 13 22:29:33 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 13 May 2010 15:29:33 -0700 Subject: Growing GC Young Gen Times In-Reply-To: <4BEC7498.6030405@oracle.com> References: <4BEC2776.8010609@oracle.com> <4BEC7498.6030405@oracle.com> Message-ID: <4BEC7D4D.2000905@oracle.com> Matt, To amplify on Ramki's comment, the allocations out of the old generation are always from a free list. During a young generation collection each GC thread will get its own local free lists from the old generation so that it can copy objects to the old generation without synchronizing with the other GC thread (most of the time). Objects from a GC thread's local free lists are pushed to the globals lists after the collection (as far as I recall). So there is some churn in the free lists. Jon On 05/13/10 14:52, Y. Srinivas Ramakrishna wrote: > On 05/13/10 10:50, Matt Fowles wrote: >> Jon~ >> >> This may sound naive, but how can fragmentation be an issue if the old >> gen has never been collected? I would think we are still in the space >> where we can just bump the old gen alloc pointer... > > Matt, The old gen allocator may fragment the space. Allocation is not > exactly "bump a pointer". > > -- ramki > >> >> Matt >> >> On Thu, May 13, 2010 at 12:23 PM, Jon Masamitsu >> wrote: >>> Matt, >>> >>> As Ramki indicated fragmentation might be an issue. As the >>> fragmentation >>> in the old generation increases, it takes longer to find space in >>> the old >>> generation >>> into which to promote objects from the young generation. This is >>> apparently >>> not >>> the problem that Wayne is having but you still might be hitting it. >>> If you >>> can >>> connect jconsole to the VM and force a full GC, that would tell us >>> if it's >>> fragmentation. >>> >>> There might be a scaling issue with the UseParNewGC. If you can use >>> -XX:-UseParNewGC (turning off the parallel young >>> generation collection) with -XX:+UseConcMarkSweepGC the pauses >>> will be longer but may be more stable. That's not the solution but >>> just >>> part >>> of the investigation. >>> >>> You could try just -XX:+UseParNewGC without -XX:+UseConcMarkSweepGC >>> and if you don't see the growing young generation pause, that would >>> indicate >>> something specific about promotion into the CMS generation. >>> >>> UseParallelGC is different from UseParNewGC in a number of ways >>> and if you try UseParallelGC and still see the growing young generation >>> pauses, I'd suspect something special about your application. >>> >>> If you can run these experiments hopefully they will tell >>> us where to look next. >>> >>> Jon >>> >>> >>> On 05/12/10 15:19, Matt Fowles wrote: >>> >>> All~ >>> >>> I have a large app that produces ~4g of garbage every 30 seconds and >>> am trying to reduce the size of gc outliers. About 99% of this data >>> is garbage, but almost anything that survives one collection survives >>> for an indeterminately long amount of time. We are currently using >>> the following VM and options: >>> >>> java version "1.6.0_20" >>> Java(TM) SE Runtime Environment (build 1.6.0_20-b02) >>> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) >>> >>> -verbose:gc >>> -XX:+PrintGCTimeStamps >>> -XX:+PrintGCDetails >>> -XX:+PrintGCTaskTimeStamps >>> -XX:+PrintTenuringDistribution >>> -XX:+PrintCommandLineFlags >>> -XX:+PrintReferenceGC >>> -Xms32g -Xmx32g -Xmn4g >>> -XX:+UseParNewGC >>> -XX:ParallelGCThreads=4 >>> -XX:+UseConcMarkSweepGC >>> -XX:ParallelCMSThreads=4 >>> -XX:CMSInitiatingOccupancyFraction=60 >>> -XX:+UseCMSInitiatingOccupancyOnly >>> -XX:+CMSParallelRemarkEnabled >>> -XX:MaxGCPauseMillis=50 >>> -Xloggc:gc.log >>> >>> >>> As you can see from the GC log, we never actually reach the point >>> where the CMS kicks in (after app startup). But our young gens seem >>> to take increasingly long to collect as time goes by. >>> >>> The steady state of the app is reached around 956.392 into the log >>> with a collection that takes 0.106 seconds. Thereafter the survivor >>> space remains roughly constantly as filled and the amount promoted to >>> old gen also remains constant, but the collection times increase to >>> 2.855 seconds by the end of the 3.5 hour run. >>> >>> Has anyone seen this sort of behavior before? Are there more switches >>> that I should try running with? >>> >>> Obviously, I am working to profile the app and reduce the garbage load >>> in parallel. But if I still see this sort of problem, it is only a >>> question of how long must the app run before I see unacceptable >>> latency spikes. >>> >>> Matt >>> >>> ________________________________ >>> _______________________________________________ >>> hotspot-gc-use mailing list >>> hotspot-gc-use at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From yamauchi at google.com Thu May 13 23:34:48 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Thu, 13 May 2010 16:34:48 -0700 Subject: Free ratio based heap shrinking in the parallel collector In-Reply-To: <4BEC205A.9080207@oracle.com> References: <4BB4C3A4.40701@oracle.com> <4BD9F2E6.3090404@oracle.com> <4BDF0E2C.7020809@oracle.com> <4BEC205A.9080207@oracle.com> Message-ID: On Thu, May 13, 2010 at 8:52 AM, Jon Masamitsu wrote: > Hiroshi, > > Looks fine.? I only looked at the files where you indicated a change in your > mail below.? If there is more for me to look at, please let me know which > files. I don't think there are changes that I haven't indicated. > I'll get another one of the GC guys here to also review > the changes. OK. > > I've create a CR for this. > > 6952079: With UseParallelScavenge use MinHeapFreeRation/MaxHeapFreeRatio if > UseAdaptiveSivePolicy is off. Thanks. I will update my webrev with the bug number. > What testing have you done?? I would expect that UseParallelGC with > UseAdaptiveSizePolicy turned off to grow and shrink the generations > in a way similar to UseSerialGC.? Can you check that is the case? My testing is with the use of System.gc() which is used by the main application behavior pattern that I had described. I checked the expansion of the heap via the free ratio worked with -UseAdaptiveSizePolicy and that the shrinkage worked with both +/-UseAdaptiveSizePolicy on System.gc() (all under UseParallelGC). I haven't compared it to UseSerialGC. > I think if you set SurvivorRatio explicitly the survivor spaces will > be close.? You might have to set InitialSurvivorRatio.?? If you > set InitialTenuringThreshold and MaxTenuringThreshold? to the > same value, I would expect the promotion rate to be close. > Promotion rates don't have to be the same but it would remove > one variable from a comparison.? If there are surprises let talk about > them.? Different isn't necessarily wrong. I assume by 'close' you mean between UseSerialGC and UseParallelGC with -UseAdaptiveSizePolicy. I need more elaboration. How would you do the testing described above (eg how/when to measure them and what to run)? Hiroshi > > Jon > > On 05/10/10 16:50, Hiroshi Yamauchi wrote: > > Jon, > > Thanks for your comments. My new revision is here > > ??http://cr.openjdk.java.net/~hiroshi/webrevs/heapshrink/ > > My comments are inlined below: > > > > In parallelScavengeHeap.cpp > > In the UseParallelGC collector the initial size (init_size) can be > significantly larger than the minimum size.?? If you want to shrink down > the heap to minimize footprint, do you really want to limit by the > initial size instead of the minimum size? > > 1001 maximum_desired_capacity = MAX2(maximum_desired_capacity, > init_size); > > Similarly here the amount of used data could be very small and > setting the floor at the initial size may not be what you > want. > > 1034 minimum_desired_capacity = MAX2(minimum_desired_capacity, > init_size); > > > I changed the code so that it uses the min size instead of the init size. > > > > In psYoungGen.cpp you guard output with PrintGC only.? In similar > cases this type of output is guarded with Verbose also.? Does this > output as is get printed in the middle of the usual > -verbosegc (also known as PrintGC) line? > > 1000 if (PrintGC) { > 1001 gclog_or_tty->print_cr(" Resizing young gen. expand_bytes=%d,%d", > 1002 eden_expand_bytes, survivor_expand_bytes); > 1003 gclog_or_tty->print("BEFORE: Young Gen: "); > 1004 gclog_or_tty->print("eden capacity : " SIZE_FORMAT ", ", > 1005 eden_space()->capacity_in_bytes()); > 1006 gclog_or_tty->print("eden used : " SIZE_FORMAT ", " , > 1007 eden_space()->used_in_bytes()); > 1008 gclog_or_tty->print("survivor capacity : " SIZE_FORMAT ", ", > 1009 from_space()->capacity_in_bytes()); > 1010 gclog_or_tty->print_cr("survivor used : " SIZE_FORMAT ", " , > 1011 from_space()->used_in_bytes()); > 1012 } > > > I added Verbose to the guard. And yes, the output show up in the > middle of PrintGC line. > > > > In psOldGen.cpp you could try to expand up to max_gen_size > instead of returning? > > 501 void PSOldGen::try_to_expand_by(size_t expand_bytes) { > 502 if (expand_bytes < MinHeapDeltaBytes || > 503 capacity_in_bytes() + expand_bytes > max_gen_size()) { > 504 return; > > Additionally PSOldGen::expand() chooses to use MinHeapDeltaBytes > as the minimum expansion size (in the sense that sizes for expansion > are round up to MinHeapDeltaBytes).?? You would rather not expand > for less than MinHeapDeltaBytes??? I'll admit that there maybe some > inconsistencies in the way MinHeapDeltaBytes is used.? Just checking > that this is what you want to do. > > Again, seems to me that you want to shrink down to the minimum > generation size as opposed to the initial size. > > ?523 void PSOldGen::try_to_shrink_by(size_t shrink_bytes) { > ?524?? if (shrink_bytes < MinHeapDeltaBytes || > ?525?????? capacity_in_bytes() - shrink_bytes < init_gen_size()) { > ?526???? return; > ?527?? } > > > Now I have: > > 502 if (capacity_in_bytes() + expand_bytes > max_gen_size()) { > 503 expand_bytes = max_gen_size() - capacity_in_bytes(); > 504 } > > and likewise for try_to_shrink_by(). > > 1. It allows the subsequent code (eg expand()) to round up the size < > MinHeapDeltaBytes. > 2. It rounds down the size that goes past the max/min gen size so that > the heap is expanded/shrunk to the max/min. > > > > In globals.hpp.? We may want this feature implemented in other > collectors at some point - G1 comes to mind.? I'd drop the leading > PS on the flag so that it is ResizeByFreeRatioWithSystemGC. > > 3079?? product(bool, PSResizeByFreeRatioWithSystemGC, > false,???????????????????? \ > 3080?????????? "Resize the heap by free ratio in System.gc() > "?????????????????? \ > 3081?????????? "under UseParallelGC") > > > > Done. > > Hiroshi > From jon.masamitsu at oracle.com Fri May 14 05:44:49 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 13 May 2010 22:44:49 -0700 Subject: Free ratio based heap shrinking in the parallel collector In-Reply-To: References: <4BB4C3A4.40701@oracle.com> <4BD9F2E6.3090404@oracle.com> <4BDF0E2C.7020809@oracle.com> <4BEC205A.9080207@oracle.com> Message-ID: <4BECE351.9020701@oracle.com> On 5/13/10 4:34 PM, Hiroshi Yamauchi wrote: > > I assume by 'close' you mean between UseSerialGC and UseParallelGC > with -UseAdaptiveSizePolicy. > > I need more elaboration. How would you do the testing described above > (eg how/when to measure them and what to run)? > > I would start by running some benchmarks with your your changes and with UseSerialGC and looking at the number of GC that are done and what the heap looks like at the end of the execution. When PrintGCDetails is set, the heap is printed on exit. GCOld would be a good benchmark to start with because it comes to steady state quickly and runs a specified amount of work. I would expect that the number of GC's would be within 10% of each other. I would also hope the generations to be within 20% of each other. If not we should look at the details to see why the sizes are not closer. Let's see how that goes before deciding what else we should do. GChisto is a good tool to compare the GC counts. There are also some scripts available (PrintGCStats) to do the same if you prefer. From john.coomes at oracle.com Fri May 14 06:15:43 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 06:15:43 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 32 new changesets Message-ID: <20100514061650.AD85D447F2@hg.openjdk.java.net> Changeset: e0a1a502e402 Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e0a1a502e402 Added tag jdk7-b90 for changeset 605c9707a766 ! .hgtags Changeset: 7b03170e1fcb Author: trims Date: 2010-04-29 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7b03170e1fcb Merge Changeset: 310cdbc35535 Author: trims Date: 2010-04-29 15:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/310cdbc35535 6948636: Bump the HS18 build number to 04 Summary: Update the HS18 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 03a8443caa4b Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/03a8443caa4b Added tag jdk7-b91 for changeset e0a1a502e402 ! .hgtags Changeset: e3fa0cc77f74 Author: trims Date: 2010-05-04 12:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e3fa0cc77f74 Merge Changeset: 3221d1887d30 Author: trims Date: 2010-05-04 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3221d1887d30 Added tag hs18-b03 for changeset 25f53b53aaa3 ! .hgtags Changeset: 731bcbe3c9c4 Author: trims Date: 2010-05-06 12:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/731bcbe3c9c4 6950438: Add 6u18 and 6u20 release values explicitly to jprt.properties file Summary: modify jprt.properties to allow JPRT to use 6u18 and 6u18 targets Reviewed-by: ohair ! make/jprt.properties Changeset: 5dabb4e73380 Author: trims Date: 2010-05-06 13:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5dabb4e73380 Merge Changeset: fd3de7134574 Author: mikejwre Date: 2010-05-06 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fd3de7134574 Added tag jdk7-b92 for changeset 3221d1887d30 ! .hgtags Changeset: 80ccc94456b2 Author: trims Date: 2010-05-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/80ccc94456b2 Merge Changeset: 359375cb7de6 Author: trims Date: 2010-05-07 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/359375cb7de6 Added tag hs18-b04 for changeset 310cdbc35535 ! .hgtags Changeset: e8e83be27dd7 Author: never Date: 2010-05-10 14:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e8e83be27dd7 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: 96d554193f72 Author: coleenp Date: 2010-04-19 18:58 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/96d554193f72 6944822: Fix for 6938627 exposes problem with hard-coded buffer sizes Summary: Make tmpdir buffer sizes MAX_PATH+1 Reviewed-by: dholmes, coleenp Contributed-by: andreas.kohn at fredhopper.com ! src/os/linux/vm/attachListener_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp Changeset: 77261afdc5f2 Author: coleenp Date: 2010-05-04 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/77261afdc5f2 6935118: UseCompressedOops modification in methodOopDesc::sort_methods() causes JCK timeout Summary: Add comparison functions for compressed oops to use bubblesort. Reviewed-by: never, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/oops/methodOop.cpp + test/runtime/6925573/SortMethodsTest.java Changeset: f43b5e9f7881 Author: kamg Date: 2010-05-05 09:28 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f43b5e9f7881 6949118: jvm.dll shows the company name as Sun Microsystems Summary: Changed to "Oracle Corporation" Reviewed-by: coleenp, dcubed ! make/hotspot_distro Changeset: 3fca8e9cd36a Author: dcubed Date: 2010-05-05 16:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3fca8e9cd36a Merge ! src/os/linux/vm/os_linux.cpp Changeset: 4ad4e0ee3779 Author: dcubed Date: 2010-05-10 13:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4ad4e0ee3779 Merge Changeset: 2ad074ba8456 Author: dcubed Date: 2010-05-11 17:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2ad074ba8456 Merge Changeset: c640000b7cc1 Author: twisti Date: 2010-04-29 06:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c640000b7cc1 6829193: JSR 292 needs to support SPARC Summary: There are unimplemented portions of the hotspot code for method handles and invokedynamic specific to SPARC. Reviewed-by: kvn, never, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: ae8f909e5fc7 Author: iveresov Date: 2010-04-29 17:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ae8f909e5fc7 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 is fixed Summary: Disable the use of pcmpestri until it can be guaranteed that the load doesn't cross in to the uncommited space. See 6942326. Reviewed-by: never, kvn ! src/share/vm/opto/library_call.cpp Changeset: 0c5b3cf3c1f5 Author: twisti Date: 2010-04-30 04:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0c5b3cf3c1f5 6939182: Zero JNI handles fix Summary: Zero will exit with an error when invoked with -Xcheck:jni. Reviewed-by: twisti, kamg Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/javaFrameAnchor_zero.hpp ! src/cpu/zero/vm/stack_zero.cpp ! src/cpu/zero/vm/stack_zero.hpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.hpp Changeset: 2338d41fbd81 Author: twisti Date: 2010-04-30 08:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2338d41fbd81 6943304: remove tagged stack interpreter Reviewed-by: coleenp, never, gbenson ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreterRT_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/interpreterRT_x86_64.cpp ! src/cpu/x86/vm/interpreter_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/interpreter_zero.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: cd5dbf694d45 Author: jrose Date: 2010-05-01 02:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/cd5dbf694d45 6939134: JSR 292 adjustments to method handle invocation Summary: split MethodHandle.invoke into invokeExact and invokeGeneric; also clean up JVM-to-Java interfaces Reviewed-by: twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 2ffde6cfe049 Author: jrose Date: 2010-05-01 21:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2ffde6cfe049 6939196: method handle signatures off the boot class path get linkage errors Summary: Adjust MethodType lookup logic to search off the BCP, but not to cache those results Reviewed-by: twisti ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp Changeset: 68d6683eaef7 Author: twisti Date: 2010-05-04 02:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/68d6683eaef7 6949423: remove tagged stack interpreter for Zero Summary: Missed Zero changes for 6943304. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/interpreter_zero.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp Changeset: d6e880569997 Author: twisti Date: 2010-05-05 05:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d6e880569997 6949830: 6939134 broke Zero Summary: The commit for 6939134 broke Zero. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/methodHandles_zero.cpp Changeset: 348346af6676 Author: twisti Date: 2010-05-06 02:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/348346af6676 6950178: Zero stack improvements Summary: Moves the logic for determining the size of the Zero stack into the ZeroStack class. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/stack_zero.cpp ! src/cpu/zero/vm/stack_zero.hpp ! src/cpu/zero/vm/stack_zero.inline.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/share/vm/includeDB_zero Changeset: 6cfbdb113e52 Author: twisti Date: 2010-05-07 04:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6cfbdb113e52 6950617: Zero/Shark interface updates Summary: Zero needs a couple of new methods to allow Shark to access the new frame anchor field. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.hpp ! src/cpu/zero/vm/javaFrameAnchor_zero.hpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.hpp Changeset: df736661d0c8 Author: jrose Date: 2010-05-11 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/df736661d0c8 Merge ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/signature.cpp Changeset: 22af4ce8dba1 Author: twisti Date: 2010-05-12 03:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/22af4ce8dba1 6951784: Zero deoptimizer changes Summary: The way Zero currently handles deoptimization can lead to methods being freed while they are still being executed. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/entry_zero.hpp Changeset: ef1a1d051971 Author: jrose Date: 2010-05-12 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ef1a1d051971 Merge ! src/share/vm/oops/methodOop.cpp Changeset: 8bfe9058ca46 Author: jcoomes Date: 2010-05-13 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/8bfe9058ca46 Merge ! src/share/vm/runtime/globals.hpp From y.s.ramakrishna at oracle.com Fri May 14 16:58:09 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Fri, 14 May 2010 09:58:09 -0700 Subject: Growing GC Young Gen Times In-Reply-To: References: Message-ID: <4BED8121.5000405@oracle.com> Hi Matt -- i am computing some metrics from yr log file and would like to know how many cpu's you have for the logs below? Also, as you noted, almost anything that survives a scavenge lives for a while. To reduce the overhead of unnecessary back-and-forth copying in the survivor spaces, just use MaxTenuringThreshold=1 (This suggestion was also made by several others in the thread, and is corroborated by your PrintTenuringDistribution data). Since you have farily large survivor spaces configured now, (at least large enough to fit 4 age cohorts, which will be down to 1 age cohort if you use MTT=1), i'd suggest making your surviror spaces smaller, may be down to about 64 MB from the current 420 MB each, and give the excess to your Eden space. Then use 6u21 when it comes out (or ask your Java support to send you a 6u21 for a beta test), or drop in a JVM from JDK 7 into your 6u20 installation, and run with that. If you still see rising pause times let me know or file a bug, and send us the log file and JVM options along with full platform information. I'll run some metrics from yr log file if you send me the info re platform above, and that may perhaps reveal a few more secrets. later. -- ramki On 05/12/10 15:19, Matt Fowles wrote: > All~ > > I have a large app that produces ~4g of garbage every 30 seconds and > am trying to reduce the size of gc outliers. About 99% of this data > is garbage, but almost anything that survives one collection survives > for an indeterminately long amount of time. We are currently using > the following VM and options: > > java version "1.6.0_20" > Java(TM) SE Runtime Environment (build 1.6.0_20-b02) > Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) > > -verbose:gc > -XX:+PrintGCTimeStamps > -XX:+PrintGCDetails > -XX:+PrintGCTaskTimeStamps > -XX:+PrintTenuringDistribution > -XX:+PrintCommandLineFlags > -XX:+PrintReferenceGC > -Xms32g -Xmx32g -Xmn4g > -XX:+UseParNewGC > -XX:ParallelGCThreads=4 > -XX:+UseConcMarkSweepGC > -XX:ParallelCMSThreads=4 > -XX:CMSInitiatingOccupancyFraction=60 > -XX:+UseCMSInitiatingOccupancyOnly > -XX:+CMSParallelRemarkEnabled > -XX:MaxGCPauseMillis=50 > -Xloggc:gc.log > > > As you can see from the GC log, we never actually reach the point > where the CMS kicks in (after app startup). But our young gens seem > to take increasingly long to collect as time goes by. > > The steady state of the app is reached around 956.392 into the log > with a collection that takes 0.106 seconds. Thereafter the survivor > space remains roughly constantly as filled and the amount promoted to > old gen also remains constant, but the collection times increase to > 2.855 seconds by the end of the 3.5 hour run. > > Has anyone seen this sort of behavior before? Are there more switches > that I should try running with? > > Obviously, I am working to profile the app and reduce the garbage load > in parallel. But if I still see this sort of problem, it is only a > question of how long must the app run before I see unacceptable > latency spikes. > > Matt > > > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From y.s.ramakrishna at oracle.com Fri May 14 17:23:38 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Fri, 14 May 2010 10:23:38 -0700 Subject: Growing GC Young Gen Times In-Reply-To: References: <4BED8121.5000405@oracle.com> Message-ID: <4BED871A.4010306@oracle.com> On 05/14/10 10:07, Matt Fowles wrote: > Ramki~ > > The machine has 4 cpus each of which have 4 cores. I will adjust the Great, thanks. I'd suggest make ParallelGCThreads=8. Also compare with -XX:-UseParNewGC. if it's the kind of fragmentation that we believe may be the cause here, you'd see larger gc times in the latter case but they would not increase as they do now. But that is conjecture at this point. > survivor spaces as you suggest. Previously I had been running with > MTT 0, but change it to 4 at the suggestion of others. MTT=0 can give very poor performance, as people said MTT=4 would definitely be better here than MTT=0. You should use MTT=1 here though. > > Running with the JDK7 version may take a bit of time, but I will > pursue that as well. All you should do is pull the libjvm.so that is in the JDK 7 installation (or bundle) and plonk it down into the appropriate directory of your existing JDK 6u20 installation. We just want to see the results with the latest JVM which includes a fix for 6631166. I attached a very rough plot of some metrics extracted from your log and this behaviour is definitely deserving of a bug, especially if it can be shown that it happens in the latest JVM. In the plot: red: scavenge durations dark blue: promoted data per scavenge pink: data in survivor space following scavenge light blue: live data in old gen As you can see the scavenge clearly correlates with the occupancy of the old gen (as Jon and others indicated). Did you try Jon's suggestion of doing a manual GC at that point via jconsole, and seeing if the upward trend of scavenges continues beyond that? Did you use -XX:+UseLargePages and -XX:+AlwaysPreTouch? Do you have an easily used test case that you can share with us via your support channels? If/when you do so, please copy me and send them a reference to this thread on this mailing list. later, with your new data. -- ramki > > Matt > > > > On Fri, May 14, 2010 at 12:58 PM, Y. Srinivas Ramakrishna > wrote: >> Hi Matt -- i am computing some metrics from yr log file >> and would like to know how many cpu's you have for the logs below? >> >> Also, as you noted, almost anything that survives a scavenge >> lives for a while. To reduce the overhead of unnecessary >> back-and-forth copying in the survivor spaces, just use >> MaxTenuringThreshold=1 (This suggestion was also made by >> several others in the thread, and is corroborated by your >> PrintTenuringDistribution data). Since you have farily large survivor >> spaces configured now, (at least large enough to fit 4 age cohorts, >> which will be down to 1 age cohort if you use MTT=1), i'd >> suggest making your surviror spaces smaller, may be down to >> about 64 MB from the current 420 MB each, and give the excess >> to your Eden space. >> >> Then use 6u21 when it comes out (or ask your Java support to >> send you a 6u21 for a beta test), or drop in a JVM from JDK 7 into >> your 6u20 installation, and run with that. If you still see >> rising pause times let me know or file a bug, and send us the >> log file and JVM options along with full platform information. >> >> I'll run some metrics from yr log file if you send me the info >> re platform above, and that may perhaps reveal a few more secrets. >> >> later. >> -- ramki >> >> On 05/12/10 15:19, Matt Fowles wrote: >>> All~ >>> >>> I have a large app that produces ~4g of garbage every 30 seconds and >>> am trying to reduce the size of gc outliers. About 99% of this data >>> is garbage, but almost anything that survives one collection survives >>> for an indeterminately long amount of time. We are currently using >>> the following VM and options: >>> >>> java version "1.6.0_20" >>> Java(TM) SE Runtime Environment (build 1.6.0_20-b02) >>> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) >>> >>> -verbose:gc >>> -XX:+PrintGCTimeStamps >>> -XX:+PrintGCDetails >>> -XX:+PrintGCTaskTimeStamps >>> -XX:+PrintTenuringDistribution >>> -XX:+PrintCommandLineFlags >>> -XX:+PrintReferenceGC >>> -Xms32g -Xmx32g -Xmn4g >>> -XX:+UseParNewGC >>> -XX:ParallelGCThreads=4 >>> -XX:+UseConcMarkSweepGC >>> -XX:ParallelCMSThreads=4 >>> -XX:CMSInitiatingOccupancyFraction=60 >>> -XX:+UseCMSInitiatingOccupancyOnly >>> -XX:+CMSParallelRemarkEnabled >>> -XX:MaxGCPauseMillis=50 >>> -Xloggc:gc.log >>> >>> >>> As you can see from the GC log, we never actually reach the point >>> where the CMS kicks in (after app startup). But our young gens seem >>> to take increasingly long to collect as time goes by. >>> >>> The steady state of the app is reached around 956.392 into the log >>> with a collection that takes 0.106 seconds. Thereafter the survivor >>> space remains roughly constantly as filled and the amount promoted to >>> old gen also remains constant, but the collection times increase to >>> 2.855 seconds by the end of the 3.5 hour run. >>> >>> Has anyone seen this sort of behavior before? Are there more switches >>> that I should try running with? >>> >>> Obviously, I am working to profile the app and reduce the garbage load >>> in parallel. But if I still see this sort of problem, it is only a >>> question of how long must the app run before I see unacceptable >>> latency spikes. >>> >>> Matt >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> hotspot-gc-use mailing list >>> hotspot-gc-use at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> -------------- next part -------------- A non-text attachment was scrubbed... Name: rough_plot.gif Type: image/gif Size: 16547 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From y.s.ramakrishna at oracle.com Fri May 14 17:36:23 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Fri, 14 May 2010 10:36:23 -0700 Subject: Growing GC Young Gen Times In-Reply-To: References: <4BEC2776.8010609@oracle.com> <4BEC7498.6030405@oracle.com> <4BEC7D4D.2000905@oracle.com> Message-ID: <4BED8A17.9090208@oracle.com> On 05/14/10 10:24, Matt Fowles wrote: > Jon~ > > That makes, sense but the fact is that the old gen *never* get > collected. So all the allocations happen from the giant empty space > at the end of the free list. I thought fragmentation only occurred > when the free lists are added to after freeing memory... As Jon indicated allocation is done from free lists of blocks that are pre-carved on demand to avoid contention while allocating. The old heuristics for how large to make those lists and the inventory to hold in those lists was not working well as you scaled the number of workers. Following 6631166 we believe it works better and causes both less contention and less fragmentation than it did before, because we do not hold unnecessary excess inventory of free blocks. The fragmentation in turn causes card-scanning to suffer adversely, besides the issues with loss of spatial locality also increasing cache misses and TLB misses. (The large page option might help mitigate the latter a bit, especially since you have such a large heap and our fragmented allocation may be exacerbating the TLB pressure.) -- ramki > > Matt > > On Thu, May 13, 2010 at 6:29 PM, Jon Masamitsu wrote: >> Matt, >> >> To amplify on Ramki's comment, the allocations out of the >> old generation are always from a free list. During a young >> generation collection each GC thread will get its own >> local free lists from the old generation so that it can >> copy objects to the old generation without synchronizing >> with the other GC thread (most of the time). Objects from >> a GC thread's local free lists are pushed to the globals lists >> after the collection (as far as I recall). So there is some >> churn in the free lists. >> >> Jon >> >> On 05/13/10 14:52, Y. Srinivas Ramakrishna wrote: >>> On 05/13/10 10:50, Matt Fowles wrote: >>>> Jon~ >>>> >>>> This may sound naive, but how can fragmentation be an issue if the old >>>> gen has never been collected? I would think we are still in the space >>>> where we can just bump the old gen alloc pointer... >>> Matt, The old gen allocator may fragment the space. Allocation is not >>> exactly "bump a pointer". >>> >>> -- ramki >>> >>>> Matt >>>> >>>> On Thu, May 13, 2010 at 12:23 PM, Jon Masamitsu >>>> wrote: >>>>> Matt, >>>>> >>>>> As Ramki indicated fragmentation might be an issue. As the >>>>> fragmentation >>>>> in the old generation increases, it takes longer to find space in the >>>>> old >>>>> generation >>>>> into which to promote objects from the young generation. This is >>>>> apparently >>>>> not >>>>> the problem that Wayne is having but you still might be hitting it. If >>>>> you >>>>> can >>>>> connect jconsole to the VM and force a full GC, that would tell us if >>>>> it's >>>>> fragmentation. >>>>> >>>>> There might be a scaling issue with the UseParNewGC. If you can use >>>>> -XX:-UseParNewGC (turning off the parallel young >>>>> generation collection) with -XX:+UseConcMarkSweepGC the pauses >>>>> will be longer but may be more stable. That's not the solution but just >>>>> part >>>>> of the investigation. >>>>> >>>>> You could try just -XX:+UseParNewGC without -XX:+UseConcMarkSweepGC >>>>> and if you don't see the growing young generation pause, that would >>>>> indicate >>>>> something specific about promotion into the CMS generation. >>>>> >>>>> UseParallelGC is different from UseParNewGC in a number of ways >>>>> and if you try UseParallelGC and still see the growing young generation >>>>> pauses, I'd suspect something special about your application. >>>>> >>>>> If you can run these experiments hopefully they will tell >>>>> us where to look next. >>>>> >>>>> Jon >>>>> >>>>> >>>>> On 05/12/10 15:19, Matt Fowles wrote: >>>>> >>>>> All~ >>>>> >>>>> I have a large app that produces ~4g of garbage every 30 seconds and >>>>> am trying to reduce the size of gc outliers. About 99% of this data >>>>> is garbage, but almost anything that survives one collection survives >>>>> for an indeterminately long amount of time. We are currently using >>>>> the following VM and options: >>>>> >>>>> java version "1.6.0_20" >>>>> Java(TM) SE Runtime Environment (build 1.6.0_20-b02) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) >>>>> >>>>> -verbose:gc >>>>> -XX:+PrintGCTimeStamps >>>>> -XX:+PrintGCDetails >>>>> -XX:+PrintGCTaskTimeStamps >>>>> -XX:+PrintTenuringDistribution >>>>> -XX:+PrintCommandLineFlags >>>>> -XX:+PrintReferenceGC >>>>> -Xms32g -Xmx32g -Xmn4g >>>>> -XX:+UseParNewGC >>>>> -XX:ParallelGCThreads=4 >>>>> -XX:+UseConcMarkSweepGC >>>>> -XX:ParallelCMSThreads=4 >>>>> -XX:CMSInitiatingOccupancyFraction=60 >>>>> -XX:+UseCMSInitiatingOccupancyOnly >>>>> -XX:+CMSParallelRemarkEnabled >>>>> -XX:MaxGCPauseMillis=50 >>>>> -Xloggc:gc.log >>>>> >>>>> >>>>> As you can see from the GC log, we never actually reach the point >>>>> where the CMS kicks in (after app startup). But our young gens seem >>>>> to take increasingly long to collect as time goes by. >>>>> >>>>> The steady state of the app is reached around 956.392 into the log >>>>> with a collection that takes 0.106 seconds. Thereafter the survivor >>>>> space remains roughly constantly as filled and the amount promoted to >>>>> old gen also remains constant, but the collection times increase to >>>>> 2.855 seconds by the end of the 3.5 hour run. >>>>> >>>>> Has anyone seen this sort of behavior before? Are there more switches >>>>> that I should try running with? >>>>> >>>>> Obviously, I am working to profile the app and reduce the garbage load >>>>> in parallel. But if I still see this sort of problem, it is only a >>>>> question of how long must the app run before I see unacceptable >>>>> latency spikes. >>>>> >>>>> Matt >>>>> >>>>> ________________________________ >>>>> _______________________________________________ >>>>> hotspot-gc-use mailing list >>>>> hotspot-gc-use at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>>> _______________________________________________ >>>> hotspot-gc-use mailing list >>>> hotspot-gc-use at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From jon.masamitsu at oracle.com Fri May 14 17:39:50 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 14 May 2010 10:39:50 -0700 Subject: Growing GC Young Gen Times In-Reply-To: References: <4BEC2776.8010609@oracle.com> <4BEC7498.6030405@oracle.com> <4BEC7D4D.2000905@oracle.com> Message-ID: <4BED8AE6.1020408@oracle.com> On 5/14/10 10:24 AM, Matt Fowles wrote: > Jon~ > > That makes, sense but the fact is that the old gen *never* get > collected. So all the allocations happen from the giant empty space > at the end of the free list. I thought fragmentation only occurred > when the free lists are added to after freeing memory... > Ok. You may be right. > Matt > > On Thu, May 13, 2010 at 6:29 PM, Jon Masamitsu wrote: > >> Matt, >> >> To amplify on Ramki's comment, the allocations out of the >> old generation are always from a free list. During a young >> generation collection each GC thread will get its own >> local free lists from the old generation so that it can >> copy objects to the old generation without synchronizing >> with the other GC thread (most of the time). Objects from >> a GC thread's local free lists are pushed to the globals lists >> after the collection (as far as I recall). So there is some >> churn in the free lists. >> >> Jon >> >> On 05/13/10 14:52, Y. Srinivas Ramakrishna wrote: >> >>> On 05/13/10 10:50, Matt Fowles wrote: >>> >>>> Jon~ >>>> >>>> This may sound naive, but how can fragmentation be an issue if the old >>>> gen has never been collected? I would think we are still in the space >>>> where we can just bump the old gen alloc pointer... >>>> >>> Matt, The old gen allocator may fragment the space. Allocation is not >>> exactly "bump a pointer". >>> >>> -- ramki >>> >>> >>>> Matt >>>> >>>> On Thu, May 13, 2010 at 12:23 PM, Jon Masamitsu >>>> wrote: >>>> >>>>> Matt, >>>>> >>>>> As Ramki indicated fragmentation might be an issue. As the >>>>> fragmentation >>>>> in the old generation increases, it takes longer to find space in the >>>>> old >>>>> generation >>>>> into which to promote objects from the young generation. This is >>>>> apparently >>>>> not >>>>> the problem that Wayne is having but you still might be hitting it. If >>>>> you >>>>> can >>>>> connect jconsole to the VM and force a full GC, that would tell us if >>>>> it's >>>>> fragmentation. >>>>> >>>>> There might be a scaling issue with the UseParNewGC. If you can use >>>>> -XX:-UseParNewGC (turning off the parallel young >>>>> generation collection) with -XX:+UseConcMarkSweepGC the pauses >>>>> will be longer but may be more stable. That's not the solution but just >>>>> part >>>>> of the investigation. >>>>> >>>>> You could try just -XX:+UseParNewGC without -XX:+UseConcMarkSweepGC >>>>> and if you don't see the growing young generation pause, that would >>>>> indicate >>>>> something specific about promotion into the CMS generation. >>>>> >>>>> UseParallelGC is different from UseParNewGC in a number of ways >>>>> and if you try UseParallelGC and still see the growing young generation >>>>> pauses, I'd suspect something special about your application. >>>>> >>>>> If you can run these experiments hopefully they will tell >>>>> us where to look next. >>>>> >>>>> Jon >>>>> >>>>> >>>>> On 05/12/10 15:19, Matt Fowles wrote: >>>>> >>>>> All~ >>>>> >>>>> I have a large app that produces ~4g of garbage every 30 seconds and >>>>> am trying to reduce the size of gc outliers. About 99% of this data >>>>> is garbage, but almost anything that survives one collection survives >>>>> for an indeterminately long amount of time. We are currently using >>>>> the following VM and options: >>>>> >>>>> java version "1.6.0_20" >>>>> Java(TM) SE Runtime Environment (build 1.6.0_20-b02) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) >>>>> >>>>> -verbose:gc >>>>> -XX:+PrintGCTimeStamps >>>>> -XX:+PrintGCDetails >>>>> -XX:+PrintGCTaskTimeStamps >>>>> -XX:+PrintTenuringDistribution >>>>> -XX:+PrintCommandLineFlags >>>>> -XX:+PrintReferenceGC >>>>> -Xms32g -Xmx32g -Xmn4g >>>>> -XX:+UseParNewGC >>>>> -XX:ParallelGCThreads=4 >>>>> -XX:+UseConcMarkSweepGC >>>>> -XX:ParallelCMSThreads=4 >>>>> -XX:CMSInitiatingOccupancyFraction=60 >>>>> -XX:+UseCMSInitiatingOccupancyOnly >>>>> -XX:+CMSParallelRemarkEnabled >>>>> -XX:MaxGCPauseMillis=50 >>>>> -Xloggc:gc.log >>>>> >>>>> >>>>> As you can see from the GC log, we never actually reach the point >>>>> where the CMS kicks in (after app startup). But our young gens seem >>>>> to take increasingly long to collect as time goes by. >>>>> >>>>> The steady state of the app is reached around 956.392 into the log >>>>> with a collection that takes 0.106 seconds. Thereafter the survivor >>>>> space remains roughly constantly as filled and the amount promoted to >>>>> old gen also remains constant, but the collection times increase to >>>>> 2.855 seconds by the end of the 3.5 hour run. >>>>> >>>>> Has anyone seen this sort of behavior before? Are there more switches >>>>> that I should try running with? >>>>> >>>>> Obviously, I am working to profile the app and reduce the garbage load >>>>> in parallel. But if I still see this sort of problem, it is only a >>>>> question of how long must the app run before I see unacceptable >>>>> latency spikes. >>>>> >>>>> Matt >>>>> >>>>> ________________________________ >>>>> _______________________________________________ >>>>> hotspot-gc-use mailing list >>>>> hotspot-gc-use at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>>>> >>>> _______________________________________________ >>>> hotspot-gc-use mailing list >>>> hotspot-gc-use at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>>> >>> >> _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From y.s.ramakrishna at oracle.com Fri May 14 17:44:25 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Fri, 14 May 2010 10:44:25 -0700 Subject: Growing GC Young Gen Times In-Reply-To: <4BED8A17.9090208@oracle.com> References: <4BEC2776.8010609@oracle.com> <4BEC7498.6030405@oracle.com> <4BEC7D4D.2000905@oracle.com> <4BED8A17.9090208@oracle.com> Message-ID: <4BED8BF9.7000803@oracle.com> On 05/14/10 10:36, Y. Srinivas Ramakrishna wrote: > On 05/14/10 10:24, Matt Fowles wrote: >> Jon~ >> >> That makes, sense but the fact is that the old gen *never* get >> collected. So all the allocations happen from the giant empty space >> at the end of the free list. I thought fragmentation only occurred >> when the free lists are added to after freeing memory... > > As Jon indicated allocation is done from free lists of blocks > that are pre-carved on demand to avoid contention while allocating. > The old heuristics for how large to make those lists and the > inventory to hold in those lists was not working well as you > scaled the number of workers. Following 6631166 we believe it > works better and causes both less contention and less > fragmentation than it did before, because we do not hold > unnecessary excess inventory of free blocks. To see what the fragmentation is, try -XX:PrintFLSStatistics=2. This will slow down your scavenge pauses (perhaps by quite a bit for your 26 GB heap), but you will get a report of the number of blocks on free lists and how fragmented the space is on that ccount (for some appropriate notion of fragmentation). Don't use that flag in production though :-) -- ramki > > The fragmentation in turn causes card-scanning to suffer > adversely, besides the issues with loss of spatial locality also > increasing cache misses and TLB misses. (The large page > option might help mitigate the latter a bit, especially > since you have such a large heap and our fragmented > allocation may be exacerbating the TLB pressure.) > > -- ramki > >> Matt >> >> On Thu, May 13, 2010 at 6:29 PM, Jon Masamitsu wrote: >>> Matt, >>> >>> To amplify on Ramki's comment, the allocations out of the >>> old generation are always from a free list. During a young >>> generation collection each GC thread will get its own >>> local free lists from the old generation so that it can >>> copy objects to the old generation without synchronizing >>> with the other GC thread (most of the time). Objects from >>> a GC thread's local free lists are pushed to the globals lists >>> after the collection (as far as I recall). So there is some >>> churn in the free lists. >>> >>> Jon >>> >>> On 05/13/10 14:52, Y. Srinivas Ramakrishna wrote: >>>> On 05/13/10 10:50, Matt Fowles wrote: >>>>> Jon~ >>>>> >>>>> This may sound naive, but how can fragmentation be an issue if the old >>>>> gen has never been collected? I would think we are still in the space >>>>> where we can just bump the old gen alloc pointer... >>>> Matt, The old gen allocator may fragment the space. Allocation is not >>>> exactly "bump a pointer". >>>> >>>> -- ramki >>>> >>>>> Matt >>>>> >>>>> On Thu, May 13, 2010 at 12:23 PM, Jon Masamitsu >>>>> wrote: >>>>>> Matt, >>>>>> >>>>>> As Ramki indicated fragmentation might be an issue. As the >>>>>> fragmentation >>>>>> in the old generation increases, it takes longer to find space in the >>>>>> old >>>>>> generation >>>>>> into which to promote objects from the young generation. This is >>>>>> apparently >>>>>> not >>>>>> the problem that Wayne is having but you still might be hitting it. If >>>>>> you >>>>>> can >>>>>> connect jconsole to the VM and force a full GC, that would tell us if >>>>>> it's >>>>>> fragmentation. >>>>>> >>>>>> There might be a scaling issue with the UseParNewGC. If you can use >>>>>> -XX:-UseParNewGC (turning off the parallel young >>>>>> generation collection) with -XX:+UseConcMarkSweepGC the pauses >>>>>> will be longer but may be more stable. That's not the solution but just >>>>>> part >>>>>> of the investigation. >>>>>> >>>>>> You could try just -XX:+UseParNewGC without -XX:+UseConcMarkSweepGC >>>>>> and if you don't see the growing young generation pause, that would >>>>>> indicate >>>>>> something specific about promotion into the CMS generation. >>>>>> >>>>>> UseParallelGC is different from UseParNewGC in a number of ways >>>>>> and if you try UseParallelGC and still see the growing young generation >>>>>> pauses, I'd suspect something special about your application. >>>>>> >>>>>> If you can run these experiments hopefully they will tell >>>>>> us where to look next. >>>>>> >>>>>> Jon >>>>>> >>>>>> >>>>>> On 05/12/10 15:19, Matt Fowles wrote: >>>>>> >>>>>> All~ >>>>>> >>>>>> I have a large app that produces ~4g of garbage every 30 seconds and >>>>>> am trying to reduce the size of gc outliers. About 99% of this data >>>>>> is garbage, but almost anything that survives one collection survives >>>>>> for an indeterminately long amount of time. We are currently using >>>>>> the following VM and options: >>>>>> >>>>>> java version "1.6.0_20" >>>>>> Java(TM) SE Runtime Environment (build 1.6.0_20-b02) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) >>>>>> >>>>>> -verbose:gc >>>>>> -XX:+PrintGCTimeStamps >>>>>> -XX:+PrintGCDetails >>>>>> -XX:+PrintGCTaskTimeStamps >>>>>> -XX:+PrintTenuringDistribution >>>>>> -XX:+PrintCommandLineFlags >>>>>> -XX:+PrintReferenceGC >>>>>> -Xms32g -Xmx32g -Xmn4g >>>>>> -XX:+UseParNewGC >>>>>> -XX:ParallelGCThreads=4 >>>>>> -XX:+UseConcMarkSweepGC >>>>>> -XX:ParallelCMSThreads=4 >>>>>> -XX:CMSInitiatingOccupancyFraction=60 >>>>>> -XX:+UseCMSInitiatingOccupancyOnly >>>>>> -XX:+CMSParallelRemarkEnabled >>>>>> -XX:MaxGCPauseMillis=50 >>>>>> -Xloggc:gc.log >>>>>> >>>>>> >>>>>> As you can see from the GC log, we never actually reach the point >>>>>> where the CMS kicks in (after app startup). But our young gens seem >>>>>> to take increasingly long to collect as time goes by. >>>>>> >>>>>> The steady state of the app is reached around 956.392 into the log >>>>>> with a collection that takes 0.106 seconds. Thereafter the survivor >>>>>> space remains roughly constantly as filled and the amount promoted to >>>>>> old gen also remains constant, but the collection times increase to >>>>>> 2.855 seconds by the end of the 3.5 hour run. >>>>>> >>>>>> Has anyone seen this sort of behavior before? Are there more switches >>>>>> that I should try running with? >>>>>> >>>>>> Obviously, I am working to profile the app and reduce the garbage load >>>>>> in parallel. But if I still see this sort of problem, it is only a >>>>>> question of how long must the app run before I see unacceptable >>>>>> latency spikes. >>>>>> >>>>>> Matt >>>>>> >>>>>> ________________________________ >>>>>> _______________________________________________ >>>>>> hotspot-gc-use mailing list >>>>>> hotspot-gc-use at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>>>> _______________________________________________ >>>>> hotspot-gc-use mailing list >>>>> hotspot-gc-use at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From john.coomes at oracle.com Fri May 14 18:58:00 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 18:58:00 +0000 Subject: hg: jdk7/hotspot-gc: 3 new changesets Message-ID: <20100514185800.88DFB44901@hg.openjdk.java.net> Changeset: aa4f995fb65e Author: prr Date: 2010-05-11 14:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/aa4f995fb65e 6931180: Migration to recent versions of MS Platform SDK Summary: Changes to enable building JDK7 with Microsoft Visual Studio 2010 Reviewed-by: ohair, art, ccheung, dcubed ! README-builds.html Changeset: 5fc102ff48f0 Author: mikejwre Date: 2010-05-12 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/5fc102ff48f0 Merge Changeset: ec423e5e725d Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/ec423e5e725d Added tag jdk7-b93 for changeset 5fc102ff48f0 ! .hgtags From john.coomes at oracle.com Fri May 14 18:58:04 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 18:58:04 +0000 Subject: hg: jdk7/hotspot-gc/corba: 3 new changesets Message-ID: <20100514185808.1A34244902@hg.openjdk.java.net> Changeset: ee2d8f1bef5b Author: prr Date: 2010-05-11 14:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/ee2d8f1bef5b 6931180: Migration to recent versions of MS Platform SDK Summary: Changes to enable building JDK7 with Microsoft Visual Studio 2010 Reviewed-by: ohair, art, ccheung, dcubed ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk Changeset: 9718d624864c Author: mikejwre Date: 2010-05-12 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/9718d624864c Merge Changeset: f2ff4938cecd Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/f2ff4938cecd Added tag jdk7-b93 for changeset 9718d624864c ! .hgtags From john.coomes at oracle.com Fri May 14 19:04:32 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 19:04:32 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b93 for changeset c725ca829c5a Message-ID: <20100514190433.0F61B4490D@hg.openjdk.java.net> Changeset: 2de307cd3b4e Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/2de307cd3b4e Added tag jdk7-b93 for changeset c725ca829c5a ! .hgtags From john.coomes at oracle.com Fri May 14 19:04:36 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 19:04:36 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b93 for changeset 797bef191975 Message-ID: <20100514190436.62E754490E@hg.openjdk.java.net> Changeset: 8515e093efd1 Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/8515e093efd1 Added tag jdk7-b93 for changeset 797bef191975 ! .hgtags From john.coomes at oracle.com Fri May 14 19:04:43 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 19:04:43 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 3 new changesets Message-ID: <20100514190540.DB4174490F@hg.openjdk.java.net> Changeset: 7bbb5f3b6eed Author: prr Date: 2010-05-11 14:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7bbb5f3b6eed 6931180: Migration to recent versions of MS Platform SDK 6944048: VS2010 build failure in make/com/sun/java/pack: missing unpack200.exe.manifest 6944015: VS2010 build failure in awt_TextArea.cpp: ambiguous call to abs() 6936319: JDK build fails in awt_DnDDS.cpp with Visual Studio 2008/Platform SDK 7 6944516: Windows L&F is broken in SwingSet2, when JDK is built with the recent Windows SDK Summary: Changes to enable building JDK7 with Microsoft Visual Studio 2010 Reviewed-by: ohair, art, ccheung, dcubed ! make/com/sun/java/pack/Makefile ! make/common/Defs-windows.gmk ! make/common/Modules.gmk ! make/common/Release.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk ! src/share/bin/main.c ! src/windows/bin/java_md.c ! src/windows/native/sun/jkernel/DownloadDialog.cpp ! src/windows/native/sun/jkernel/DownloadHelper.cpp ! src/windows/native/sun/jkernel/stdafx.h ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp Changeset: 219b84b9533a Author: mikejwre Date: 2010-05-12 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/219b84b9533a Merge Changeset: d352cd74ef71 Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d352cd74ef71 Added tag jdk7-b93 for changeset 219b84b9533a ! .hgtags From john.coomes at oracle.com Fri May 14 19:09:39 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 19:09:39 +0000 Subject: hg: jdk7/hotspot-gc/langtools: Added tag jdk7-b93 for changeset 683cd1f6bc4b Message-ID: <20100514190944.E5D5944910@hg.openjdk.java.net> Changeset: e224d437e84a Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/e224d437e84a Added tag jdk7-b93 for changeset 683cd1f6bc4b ! .hgtags From y.s.ramakrishna at oracle.com Fri May 14 19:32:45 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Fri, 14 May 2010 12:32:45 -0700 Subject: Growing GC Young Gen Times In-Reply-To: References: <4BEC2776.8010609@oracle.com> <4BEC7498.6030405@oracle.com> <4BEC7D4D.2000905@oracle.com> <4BED8A17.9090208@oracle.com> <4BED8BF9.7000803@oracle.com> Message-ID: <4BEDA55D.5030703@oracle.com> Matt -- Yes, comparative data for all these for 6u20 and jdk 7 would be great. Naturally, server 1 is most immediately useful for determining if 6631166 addresses this at all, but others would be useful too if it turns out it doesn't (i.e. if jdk 7's server 1 turns out to be no better than 6u20's -- at which point we should get this into the right channel -- open a bug, and a support case). thanks. -- ramki On 05/14/10 12:24, Matt Fowles wrote: > Ramki~ > > I am preparing the flags for the next 3 runs (which run in parallel) and > wanted to check a few things with you. I believe that each of these is > collecting a useful data point, > > Server 1 is running with 8 threads, reduced young gen, and MTT 1. > Server 2 is running with 8 threads, reduced young gen, and MTT 1, > ParNew, but NOT CMS. > Server 3 is running with 8 threads, reduced young gen, and MTT 1, > and PrintFLSStatistics. > > I can (additionally) run all of these tests on JDK7 (Java HotSpot(TM) > 64-Bit Server VM (build 17.0-b05, mixed mode)). > > Server 1: > -verbose:gc > -XX:+PrintGCTimeStamps > -XX:+PrintGCDetails > -XX:+PrintGCTaskTimeStamps > -XX:+PrintCommandLineFlags > > -Xms32g -Xmx32g -Xmn1g > -XX:+UseParNewGC > -XX:ParallelGCThreads=8 > -XX:+UseConcMarkSweepGC > -XX:ParallelCMSThreads=8 > -XX:MaxTenuringThreshold=1 > -XX:SurvivorRatio=14 > -XX:+CMSParallelRemarkEnabled > -Xloggc:gc1.log > -XX:+UseLargePages > -XX:+AlwaysPreTouch > > Server 2: > -verbose:gc > -XX:+PrintGCTimeStamps > -XX:+PrintGCDetails > -XX:+PrintGCTaskTimeStamps > -XX:+PrintCommandLineFlags > > -Xms32g -Xmx32g -Xmn1g > -XX:+UseParNewGC > -XX:ParallelGCThreads=8 > -XX:MaxTenuringThreshold=1 > -XX:SurvivorRatio=14 > -Xloggc:gc2.log > -XX:+UseLargePages > -XX:+AlwaysPreTouch > > > Server 3: > -verbose:gc > -XX:+PrintGCTimeStamps > -XX:+PrintGCDetails > -XX:+PrintGCTaskTimeStamps > -XX:+PrintCommandLineFlags > > -Xms32g -Xmx32g -Xmn1g > -XX:+UseParNewGC > -XX:ParallelGCThreads=8 > -XX:+UseConcMarkSweepGC > -XX:ParallelCMSThreads=8 > -XX:MaxTenuringThreshold=1 > -XX:SurvivorRatio=14 > -XX:+CMSParallelRemarkEnabled > -Xloggc:gc3.log > > -XX:PrintFLSStatistics=2 > -XX:+UseLargePages > -XX:+AlwaysPreTouch > > Matt > > On Fri, May 14, 2010 at 1:44 PM, Y. Srinivas Ramakrishna > > wrote: > > On 05/14/10 10:36, Y. Srinivas Ramakrishna wrote: > >> > >> On 05/14/10 10:24, Matt Fowles wrote: > >>> > >>> Jon~ > >>> > >>> That makes, sense but the fact is that the old gen *never* get > >>> collected. So all the allocations happen from the giant empty space > >>> at the end of the free list. I thought fragmentation only occurred > >>> when the free lists are added to after freeing memory... > >> > >> As Jon indicated allocation is done from free lists of blocks > >> that are pre-carved on demand to avoid contention while allocating. > >> The old heuristics for how large to make those lists and the > >> inventory to hold in those lists was not working well as you > >> scaled the number of workers. Following 6631166 we believe it > >> works better and causes both less contention and less > >> fragmentation than it did before, because we do not hold > >> unnecessary excess inventory of free blocks. > > > > To see what the fragmentation is, try -XX:PrintFLSStatistics=2. > > This will slow down your scavenge pauses (perhaps by quite a bit > > for your 26 GB heap), but you will get a report of the number of > > blocks on free lists and how fragmented the space is on that ccount > > (for some appropriate notion of fragmentation). Don't use that > > flag in production though :-) > > > > -- ramki > > > >> > >> The fragmentation in turn causes card-scanning to suffer > >> adversely, besides the issues with loss of spatial locality also > >> increasing cache misses and TLB misses. (The large page > >> option might help mitigate the latter a bit, especially > >> since you have such a large heap and our fragmented > >> allocation may be exacerbating the TLB pressure.) > >> > >> -- ramki > >> > >>> Matt > >>> > >>> On Thu, May 13, 2010 at 6:29 PM, Jon Masamitsu > > > >>> wrote: > >>>> > >>>> Matt, > >>>> > >>>> To amplify on Ramki's comment, the allocations out of the > >>>> old generation are always from a free list. During a young > >>>> generation collection each GC thread will get its own > >>>> local free lists from the old generation so that it can > >>>> copy objects to the old generation without synchronizing > >>>> with the other GC thread (most of the time). Objects from > >>>> a GC thread's local free lists are pushed to the globals lists > >>>> after the collection (as far as I recall). So there is some > >>>> churn in the free lists. > >>>> > >>>> Jon > >>>> > >>>> On 05/13/10 14:52, Y. Srinivas Ramakrishna wrote: > >>>>> > >>>>> On 05/13/10 10:50, Matt Fowles wrote: > >>>>>> > >>>>>> Jon~ > >>>>>> > >>>>>> This may sound naive, but how can fragmentation be an issue if > the old > >>>>>> gen has never been collected? I would think we are still in the > space > >>>>>> where we can just bump the old gen alloc pointer... > >>>>> > >>>>> Matt, The old gen allocator may fragment the space. Allocation is not > >>>>> exactly "bump a pointer". > >>>>> > >>>>> -- ramki > >>>>> > >>>>>> Matt > >>>>>> > >>>>>> On Thu, May 13, 2010 at 12:23 PM, Jon Masamitsu > >>>>>> > wrote: > >>>>>>> > >>>>>>> Matt, > >>>>>>> > >>>>>>> As Ramki indicated fragmentation might be an issue. As the > >>>>>>> fragmentation > >>>>>>> in the old generation increases, it takes longer to find space > in the > >>>>>>> old > >>>>>>> generation > >>>>>>> into which to promote objects from the young generation. This is > >>>>>>> apparently > >>>>>>> not > >>>>>>> the problem that Wayne is having but you still might be hitting it. > >>>>>>> If > >>>>>>> you > >>>>>>> can > >>>>>>> connect jconsole to the VM and force a full GC, that would tell > us if > >>>>>>> it's > >>>>>>> fragmentation. > >>>>>>> > >>>>>>> There might be a scaling issue with the UseParNewGC. If you > can use > >>>>>>> -XX:-UseParNewGC (turning off the parallel young > >>>>>>> generation collection) with -XX:+UseConcMarkSweepGC the pauses > >>>>>>> will be longer but may be more stable. That's not the solution but > >>>>>>> just > >>>>>>> part > >>>>>>> of the investigation. > >>>>>>> > >>>>>>> You could try just -XX:+UseParNewGC without -XX:+UseConcMarkSweepGC > >>>>>>> and if you don't see the growing young generation pause, that would > >>>>>>> indicate > >>>>>>> something specific about promotion into the CMS generation. > >>>>>>> > >>>>>>> UseParallelGC is different from UseParNewGC in a number of ways > >>>>>>> and if you try UseParallelGC and still see the growing young > >>>>>>> generation > >>>>>>> pauses, I'd suspect something special about your application. > >>>>>>> > >>>>>>> If you can run these experiments hopefully they will tell > >>>>>>> us where to look next. > >>>>>>> > >>>>>>> Jon > >>>>>>> > >>>>>>> > >>>>>>> On 05/12/10 15:19, Matt Fowles wrote: > >>>>>>> > >>>>>>> All~ > >>>>>>> > >>>>>>> I have a large app that produces ~4g of garbage every 30 > seconds and > >>>>>>> am trying to reduce the size of gc outliers. About 99% of this > data > >>>>>>> is garbage, but almost anything that survives one collection > survives > >>>>>>> for an indeterminately long amount of time. We are currently using > >>>>>>> the following VM and options: > >>>>>>> > >>>>>>> java version "1.6.0_20" > >>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_20-b02) > >>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) > >>>>>>> > >>>>>>> -verbose:gc > >>>>>>> -XX:+PrintGCTimeStamps > >>>>>>> -XX:+PrintGCDetails > >>>>>>> -XX:+PrintGCTaskTimeStamps > >>>>>>> -XX:+PrintTenuringDistribution > >>>>>>> -XX:+PrintCommandLineFlags > >>>>>>> -XX:+PrintReferenceGC > >>>>>>> -Xms32g -Xmx32g -Xmn4g > >>>>>>> -XX:+UseParNewGC > >>>>>>> -XX:ParallelGCThreads=4 > >>>>>>> -XX:+UseConcMarkSweepGC > >>>>>>> -XX:ParallelCMSThreads=4 > >>>>>>> -XX:CMSInitiatingOccupancyFraction=60 > >>>>>>> -XX:+UseCMSInitiatingOccupancyOnly > >>>>>>> -XX:+CMSParallelRemarkEnabled > >>>>>>> -XX:MaxGCPauseMillis=50 > >>>>>>> -Xloggc:gc.log > >>>>>>> > >>>>>>> > >>>>>>> As you can see from the GC log, we never actually reach the point > >>>>>>> where the CMS kicks in (after app startup). But our young gens > seem > >>>>>>> to take increasingly long to collect as time goes by. > >>>>>>> > >>>>>>> The steady state of the app is reached around 956.392 into the log > >>>>>>> with a collection that takes 0.106 seconds. Thereafter the > survivor > >>>>>>> space remains roughly constantly as filled and the amount > promoted to > >>>>>>> old gen also remains constant, but the collection times increase to > >>>>>>> 2.855 seconds by the end of the 3.5 hour run. > >>>>>>> > >>>>>>> Has anyone seen this sort of behavior before? Are there more > >>>>>>> switches > >>>>>>> that I should try running with? > >>>>>>> > >>>>>>> Obviously, I am working to profile the app and reduce the garbage > >>>>>>> load > >>>>>>> in parallel. But if I still see this sort of problem, it is only a > >>>>>>> question of how long must the app run before I see unacceptable > >>>>>>> latency spikes. > >>>>>>> > >>>>>>> Matt > >>>>>>> > >>>>>>> ________________________________ > >>>>>>> _______________________________________________ > >>>>>>> hotspot-gc-use mailing list > >>>>>>> hotspot-gc-use at openjdk.java.net > > >>>>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > >>>>>> > >>>>>> _______________________________________________ > >>>>>> hotspot-gc-use mailing list > >>>>>> hotspot-gc-use at openjdk.java.net > > >>>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > >> > >> _______________________________________________ > >> hotspot-gc-use mailing list > >> hotspot-gc-use at openjdk.java.net > >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > > > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From andrey.petrusenko at sun.com Fri May 14 22:27:42 2010 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Fri, 14 May 2010 22:27:42 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6921317: (partial) G1: assert(top() == bottom() || zfs == Allocated, "Region must be empty, or we must be setting it to Message-ID: <20100514222744.496A744957@hg.openjdk.java.net> Changeset: cc387008223e Author: apetrusenko Date: 2010-05-14 10:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/cc387008223e 6921317: (partial) G1: assert(top() == bottom() || zfs == Allocated,"Region must be empty, or we must be setting it to Summary: Extended the failing assertion with the new message format to get more data. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp From peter.schuller at infidyne.com Sat May 15 17:12:20 2010 From: peter.schuller at infidyne.com (Peter Schuller) Date: Sat, 15 May 2010 19:12:20 +0200 Subject: g1 not doing partial aggressively enough -> fallback to full gc In-Reply-To: References: Message-ID: > ? ?HTTPGCTEST_LOGGC=gc.log HTTPGCTEST_COLLECTOR=g1 ./run.sh I forgot to mention that JAVA_HOME must be set or the script will fail without a user-friendly error. -- / Peter Schuller _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From peter.schuller at infidyne.com Sat May 15 17:10:52 2010 From: peter.schuller at infidyne.com (Peter Schuller) Date: Sat, 15 May 2010 19:10:52 +0200 Subject: g1 not doing partial aggressively enough -> fallback to full gc Message-ID: Hello, I have another utterly unscientific (but I think interesting) variation of an older test. The behavior that is interesting in this case is that the heap grows until it hits the maximum heap size and falls back to a full GC in spite of there being high-payoff old regions. Based on on the heap size after the full GC, the live working set if roughly ~ 230 MB, and the maximum heap size is 4 GB. This means that during the GC:s right before the full GC:s, g1 is choosing to do young generation GC:s even though the average live ratio in the older regions should be roughly 5% (low-hanging fruit for partial collections). Links to the test, the GC log file and an executable .jar file for convenience, follows at the bottom of this E-Mail. A short description of roughly what the test is doing in my particular invocation and use of it: I have a loop running which repeatedly tells the httpgctest server to add 25000 "data items" to its in-memory set, followed by removing 0.1% of all data items (pseudo-randomly). The end-result is that of a steady-state of roughly 250000 data items that are aged pseudo-randomly (the removal of 0.1% is done by selecting a pseudo-randomly from the set). Thus, dead objects will be accumulated over time over all regions, though the data structure overhead of the set itself will tend to generate data that is shorter-lived on average (due to use of clojure's immutable data structures). Given this behavior, no individual region is likely to become completely empty, so they need to be evacuated in a partial collection (rather than as part of the 'cleanup' phase). The bulk of the data collected in the young generation is expected to be the immutable data structure's internal structure. There should be very little writing to older generations (again due to the use of clojure's immutable data structures). The JVM version is one built from a recently merged-from-main bsd-port: changeset: 206:12f0c051d819 tag: tip parent: 202:44ad17a6ffea parent: 205:b7b4797303cb user: Greg Lewis date: Sat May 08 10:53:55 2010 -0700 summary: Merge from main OpenJDK repository The JVM options used in the particular run that produced the log is (cut'n'paste from -XX:+PrintCommandLineFlags, but re-ordered for clarity): -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:GCPauseIntervalMillis=15 -XX:MaxGCPauseMillis=10 -XX:+G1ParallelRSetScanningEnabled -XX:+G1ParallelRSetUpdatingEnabled -XX:InitialHeapSize=52428800 -XX:MaxHeapSize=4294967296 -XX:ThreadStackSize=256 -XX:+PrintCommandLineFlags -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+TraceClassUnloading -XX:+CITime The log files should lots of young collections, and a very select few partial collections after marking phases. Typically along the lines of (excerpt, because the full log is very long): 46.219: [GC pause (young) 2553M->2550M(4096M), 0.0071520 secs] 46.234: [GC pause (young) 2555M->2551M(4096M), 0.0052560 secs] 46.250: [GC pause (young) 2559M->2554M(4096M), 0.0074780 secs] 46.281: [GC pause (young) 2559M->2555M(4096M), 0.0058670 secs] 46.306: [GC pause (young) 2569M->2555M(4096M), 0.0039900 secs] 46.326: [GC pause (young) 2569M->2556M(4096M), 0.0056980 secs] 46.339: [GC concurrent-count-end, 0.4546580] 46.339: [GC cleanup 2562M->2502M(4096M), 0.0702940 secs] 46.410: [GC concurrent-cleanup-start] 46.414: [GC concurrent-cleanup-end, 0.0041480] 46.431: [GC pause (young) 2515M->2497M(4096M), 0.0069320 secs] 46.444: [GC pause (partial) 2501M->2495M(4096M), 0.0056890 secs] 46.469: [GC pause (partial) 2499M->2493M(4096M), 0.0065570 secs] 46.486: [GC pause (partial) 2497M->2493M(4096M), 0.0058280 secs] 46.497: [GC pause (partial) 2496M->2493M(4096M), 0.0108240 secs] 46.525: [GC pause (young) (initial-mark) 2507M->2494M(4096M)46.529: [GC concurrent-mark-start] , 0.0044130 secs] 46.544: [GC pause (young) 2508M->2494M(4096M), 0.0053780 secs] 46.574: [GC pause (young) 2513M->2495M(4096M), 0.0058290 secs] 46.727: [GC pause (young) 2512M->2499M(4096M), 0.0122760 secs] 46.761: [GC pause (young) 2507M->2501M(4096M), 0.0121180 secs] 46.799: [GC pause (young) 2512M->2505M(4096M), 0.0116450 secs] 46.826: [GC pause (young) 2513M->2507M(4096M), 0.0098290 secs] 46.852: [GC pause (young) 2515M->2510M(4096M), 0.0111450 secs] 46.873: [GC pause (young) 2517M->2512M(4096M), 0.0095310 secs] 46.893: [GC pause (young) 2519M->2514M(4096M), 0.0113990 secs] 46.918: [GC pause (young) 2519M->2516M(4096M), 0.0092540 secs] At the very end we see the full GC and the resulting heap size: 74.777: [GC pause (young) 4090M->4074M(4096M), 0.0085890 secs] 74.796: [GC pause (young) 4082M->4075M(4096M), 0.0061880 secs] 74.833: [Full GC 4095M->227M(758M), 2.9635480 secs] 77.940: [GC pause (young) 253M->232M(758M), 0.0206140 secs] 77.970: [GC pause (young) 236M->233M(1426M), 0.0168640 secs] Close to this there are only young collections in sight. The effect is lessened by providing less strict pause time demands on g1 (I tested 250/300 instead of the 10/15 used in this case), but the behavior *does* remain. It just takes longer to kick in (given the same heap size). Test links/reproduction information: The test is the httpgctest (as of version 751d8374810a497cf26e48211183db5dd0a73185): http://github.com/scode/httpgctest A GC log produced with: HTTPGCTEST_LOGGC=gc.log HTTPGCTEST_COLLECTOR=g1 ./run.sh Can be found here: http://distfiles.scode.org/mlref/gctest/httpgctest-g1-fullgc-20100515/gc.log An executable .jar file (product of 'lein uberjar') is here: http://distfiles.scode.org/mlref/gctest/httpgctest-g1-fullgc-20100515/httpgctest-standalone.jar For running the executable .jar with the same options, the direct link to run.sh of the correct version is: http://github.com/scode/httpgctest/blob/751d8374810a497cf26e48211183db5dd0a73185/run.sh The input to the test once running, is the following little loop running concurrently: while [ 1 ] ; do curl 'http://localhost:9191/gendata?amount=25000' ; curl 'http://localhost:9191/dropdata?ratio=0.1' ; sleep 0.1 ; done -- / Peter Schuller _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From y.s.ramakrishna at oracle.com Mon May 17 09:50:52 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Mon, 17 May 2010 09:50:52 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6948539: CMS+UseCompressedOops: placement of cms_free bit interferes with promoted object link Message-ID: <20100517095101.23E0B44DFB@hg.openjdk.java.net> Changeset: a00b51b2dda4 Author: ysr Date: 2010-05-17 00:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a00b51b2dda4 6948539: CMS+UseCompressedOops: placement of cms_free bit interferes with promoted object link Summary: When using compressed oops, use compressed promoted pointers in b63:b31 of the mark word, so as not to interfere with the CMS "freeness bit" at b7. Updated mark-word layout documentation. Reviewed-by: minqi, poonam, jmasa, coleenp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp ! src/share/vm/oops/markOop.hpp From yamauchi at google.com Tue May 18 00:26:45 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Mon, 17 May 2010 17:26:45 -0700 Subject: Free ratio based heap shrinking in the parallel collector In-Reply-To: <4BECE351.9020701@oracle.com> References: <4BD9F2E6.3090404@oracle.com> <4BDF0E2C.7020809@oracle.com> <4BEC205A.9080207@oracle.com> <4BECE351.9020701@oracle.com> Message-ID: On Thu, May 13, 2010 at 10:44 PM, Jon Masamitsu wrote: > On 5/13/10 4:34 PM, Hiroshi Yamauchi wrote: >> >> I assume by 'close' you mean between UseSerialGC and UseParallelGC >> with -UseAdaptiveSizePolicy. >> >> I need more elaboration. How would you do the testing described above >> (eg how/when to measure them and what to run)? >> >> > > I would start by running some benchmarks with your your changes and with > UseSerialGC > and looking at the number of GC that are done and what the heap looks like > at > the end of the execution. ?When PrintGCDetails is set, the heap is printed > on exit. ? GCOld would be ?a good benchmark to start with because it comes > to > steady state quickly and runs a specified amount of work. ?I would expect > that > the number of GC's would be within 10% of each other. ? I would also hope > the generations to be within 20% of each other. ?If not we should look at > the details to see why the sizes are not closer. ? Let's see how that goes > before > deciding what else we should do. > > GChisto is a good tool to compare the GC counts. ?There are also some > scripts available (PrintGCStats) to do the same if you prefer. > > > Unfortunately, GCOld wasn't available for download. I instead used the eclipse benchmark from Dacapo (which seems to be the most GC intensive in the suite). The PrintGCStats script was available. I measured the following four configurations. 1. +UseSerialGC The serial collector with its (limited) support of resizing by free ratio. Only the old gen is resized by free ratio and shrinking is less aggressive (due to the 'shrink_factor' which damps the shrinkage down 40% of the straight-forward way) 2. +UseParallelGC-UseAdaptiveSizePolicy-1 This is as per the latest patch. 3. +UseParallelGC-UseAdaptiveSizePolicy-2 Same as 2 except that the free ratio on a minor collection is computed based on both young and old gens rather than just the young gen. This effectively temporarily reverses the last change we made. 4. +UseParallelGC+UseAdaptiveSizePolicy The parallel collector and (the default) UseAdaptiveSizePolicy. The following is the heap size stats at the end of the execution and the PrintGCStats output for each of the four configurations. (It's easiest to read in a fixed-width font.) The heap size parameters (Xmx and Xms) are unset. The common VM flags are -server -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails. Disclaimer: I have run each only once. 1. +UseSerialGC Heap def new generation total 19392K, used 4653K [0x70d90000, 0x72290000, 0x85c30000) eden space 17280K, 22% used [0x70d90000, 0x7115b458, 0x71e70000) from space 2112K, 36% used [0x72080000, 0x72140220, 0x72290000) to space 2112K, 0% used [0x71e70000, 0x71e70000, 0x72080000) tenured generation total 42880K, used 20727K [0x85c30000, 0x88610000, 0xaf990000) the space 42880K, 48% used [0x85c30000, 0x8706de88, 0x8706e000, 0x88610000) compacting perm gen total 16640K, used 16407K [0xaf990000, 0xb09d0000, 0xb3990000) the space 16640K, 98% used [0xaf990000, 0xb0995f08, 0xb0996000, 0xb09d0000) No shared spaces configured. what count total mean max stddev gen0(s) 183 0.602 0.00329 0.014 0.0019 gen0t(s) 183 0.000 0.00000 0.000 0.0000 gen1t(s) 4 0.000 0.00000 0.000 0.0000 GC(s) 187 0.000 0.00000 0.000 0.0000 alloc(MB) 183 3078.570 16.82279 16.875 0.1896 promo(MB) 183 97.285 0.53161 4.647 0.7827 alloc/elapsed_time = 3078.570 MB / 29.343 s = 104.917 MB/s alloc/tot_cpu_time = 3078.570 MB / 117.372 s = 26.229 MB/s alloc/mut_cpu_time = 3078.570 MB / 117.372 s = 26.229 MB/s promo/elapsed_time = 97.285 MB / 29.343 s = 3.315 MB/s promo/gc0_time = 97.285 MB / 0.000 s = 0.000 MB/s gc_seq_load = 0.000 s / 117.372 s = 0.000% gc_conc_load = 0.000 s / 117.372 s = 0.000% gc_tot_load = 0.000 s / 117.372 s = 0.000% 2. +UseParallelGC-UseAdaptiveSizePolicy-1 Heap PSYoungGen total 1600K, used 905K [0x9eb30000, 0x9fcf0000, 0xb39d0000) eden space 1536K, 56% used [0x9eb30000,0x9ec0a540,0x9ecb0000) from space 64K, 50% used [0x9fce0000,0x9fce8000,0x9fcf0000) to space 512K, 0% used [0x9fbf0000,0x9fbf0000,0x9fc70000) PSOldGen total 35456K, used 23449K [0x74dd0000, 0x77070000, 0x9eb30000) object space 35456K, 66% used [0x74dd0000,0x764b65c8,0x77070000) PSPermGen total 19968K, used 16423K [0x70dd0000, 0x72150000, 0x74dd0000) object space 19968K, 82% used [0x70dd0000,0x71dd9e70,0x72150000) what count total mean max stddev gen0(s) 2102 0.000 0.00000 0.000 0.0000 gen1t(s) 15 0.000 0.00000 0.000 0.0000 GC(s) 2117 0.000 0.00000 0.000 0.0000 alloc(MB) 2102 3156.040 1.50145 15.750 0.3145 promo(MB) 2102 338.998 0.16127 1.718 0.2520 alloc/elapsed_time = 3156.040 MB / 35.017 s = 90.129 MB/s alloc/tot_cpu_time = 3156.040 MB / 140.068 s = 22.532 MB/s alloc/mut_cpu_time = 3156.040 MB / 140.068 s = 22.532 MB/s promo/elapsed_time = 338.998 MB / 35.017 s = 9.681 MB/s promo/gc0_time = 338.998 MB / 0.000 s = 0.000 MB/s gc_seq_load = 0.000 s / 140.068 s = 0.000% gc_conc_load = 0.000 s / 140.068 s = 0.000% gc_tot_load = 0.000 s / 140.068 s = 0.000% 3. +UseParallelGC-UseAdaptiveSizePolicy-2 Heap PSYoungGen total 10176K, used 7135K [0x9eb00000, 0x9fcc0000, 0xb39a0000) eden space 10112K, 69% used [0x9eb00000,0x9f1e7c68,0x9f4e0000) from space 64K, 100% used [0x9fca0000,0x9fcb0000,0x9fcb0000) to space 64K, 0% used [0x9fcb0000,0x9fcb0000,0x9fcc0000) PSOldGen total 16640K, used 12978K [0x74da0000, 0x75de0000, 0x9eb00000) object space 16640K, 77% used [0x74da0000,0x75a4cbd8,0x75de0000) PSPermGen total 18688K, used 16431K [0x70da0000, 0x71fe0000, 0x74da0000) object space 18688K, 87% used [0x70da0000,0x71dabe60,0x71fe0000) what count total mean max stddev gen0(s) 341 0.000 0.00000 0.000 0.0000 gen1t(s) 18 0.000 0.00000 0.000 0.0000 GC(s) 359 0.000 0.00000 0.000 0.0000 alloc(MB) 341 3151.223 9.24112 17.625 2.6183 promo(MB) 341 170.810 0.50091 3.881 0.5584 alloc/elapsed_time = 3151.223 MB / 29.328 s = 107.448 MB/s alloc/tot_cpu_time = 3151.223 MB / 117.312 s = 26.862 MB/s alloc/mut_cpu_time = 3151.223 MB / 117.312 s = 26.862 MB/s promo/elapsed_time = 170.810 MB / 29.328 s = 5.824 MB/s promo/gc0_time = 170.810 MB / 0.000 s = 0.000 MB/s gc_seq_load = 0.000 s / 117.312 s = 0.000% gc_conc_load = 0.000 s / 117.312 s = 0.000% gc_tot_load = 0.000 s / 117.312 s = 0.000% 4. +UseParallelGC+UseAdaptiveSizePolicy Heap PSYoungGen total 288832K, used 47438K [0x9ea50000, 0xb27a0000, 0xb38f0000) eden space 282176K, 14% used [0x9ea50000,0xa1226bc8,0xafde0000) from space 6656K, 99% used [0xb1a60000,0xb20dd000,0xb20e0000) to space 6912K, 0% used [0xb20e0000,0xb20e0000,0xb27a0000) PSOldGen total 42880K, used 20044K [0x74cf0000, 0x776d0000, 0x9ea50000) object space 42880K, 46% used [0x74cf0000,0x760831e0,0x776d0000) PSPermGen total 34560K, used 16446K [0x70cf0000, 0x72eb0000, 0x74cf0000) object space 34560K, 47% used [0x70cf0000,0x71cffbf8,0x72eb0000) what count total mean max stddev gen0(s) 29 0.000 0.00000 0.000 0.0000 gen1t(s) 2 0.000 0.00000 0.000 0.0000 GC(s) 31 0.000 0.00000 0.000 0.0000 alloc(MB) 29 3122.054 107.65702 318.750 110.5556 promo(MB) 29 57.154 1.97084 6.962 2.2706 alloc/elapsed_time = 3122.054 MB / 28.569 s = 109.281 MB/s alloc/tot_cpu_time = 3122.054 MB / 114.276 s = 27.320 MB/s alloc/mut_cpu_time = 3122.054 MB / 114.276 s = 27.320 MB/s promo/elapsed_time = 57.154 MB / 28.569 s = 2.001 MB/s promo/gc0_time = 57.154 MB / 0.000 s = 0.000 MB/s gc_seq_load = 0.000 s / 114.276 s = 0.000% gc_conc_load = 0.000 s / 114.276 s = 0.000% gc_tot_load = 0.000 s / 114.276 s = 0.000% There may be some issue in parsing the GC times in the script since they are mostly zeros for some reason. Config 2 caused a lot more GCs to happen than config 1. This appears to be because the size of the young gen stayed mostly at ~2 MB compared to ~20 MB in config 1 due to the (more aggressive) shrinking. I can imagine that if the free ratio is solely based on the young gen, this could happen. Config 3 caused fewer GCs than config 2 (still about 2x config 1). But the elapsed time was on par with config 1. Yet, config 3 ended with the smallest heap size (~30 MB). Config 4 caused fewest GCs. It was the fastest (by a few %) but ended with the largest heap size (> 300 MB). Anyway, the results of config 2 and 3 are out of the ranges that Jon mentioned. Hiroshi From suncg03 at gmail.com Tue May 18 15:22:39 2010 From: suncg03 at gmail.com (ChenGuang Sun) Date: Tue, 18 May 2010 11:22:39 -0400 Subject: A minor bug in jdk7-b87 Message-ID: Hi, I'm reading the code and have noticed a minor typo in the function "CollectedHeap::pre_initialize()". I think it should be "#ifdef COMPILER2" instead of "#ifdef COMPLER2". I haven't checked whether it has been corrected in the latest revision. Thanks, Chen From y.s.ramakrishna at oracle.com Tue May 18 16:19:57 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Tue, 18 May 2010 09:19:57 -0700 Subject: A minor bug in jdk7-b87 In-Reply-To: <4BF2B67F.9050807@oracle.com> References: <4BF2B67F.9050807@oracle.com> Message-ID: <4BF2BE2D.6030205@oracle.com> 6953483 Typo related to ReduceInitialCardMarks Workaround for the case of CMS: -XX:-ReduceInitialCardMarks. No issue for other collectors (G1, which may otherwise have been vulnerable, has this optimization switched off). Thanks, ChenGuang, for bringing this to our attention. -- ramki Y. Srinivas Ramakrishna wrote: > Looks like I am responsible for that typo (which is still there). > I'll test and fix that issue. Thanks for the fix! > > -- ramki > > ChenGuang Sun wrote: >> Hi, >> >> I'm reading the code and have noticed a minor typo in the function >> "CollectedHeap::pre_initialize()". >> >> I think it should be "#ifdef COMPILER2" instead of "#ifdef >> COMPLER2". I haven't checked whether it has been corrected in the >> latest revision. >> >> Thanks, >> Chen > > From vladimir.kozlov at oracle.com Tue May 18 17:25:24 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 May 2010 10:25:24 -0700 Subject: A minor bug in jdk7-b87 In-Reply-To: <4BF2BE2D.6030205@oracle.com> References: <4BF2B67F.9050807@oracle.com> <4BF2BE2D.6030205@oracle.com> Message-ID: <4BF2CD84.7050608@oracle.com> The file also have LP64 instead of _LP64: src/share/vm/gc_interface/collectedHeap.cpp:#ifdef LP64 Vladimir Y. Srinivas Ramakrishna wrote: > 6953483 Typo related to ReduceInitialCardMarks > > Workaround for the case of CMS: -XX:-ReduceInitialCardMarks. > > No issue for other collectors (G1, which may otherwise have been > vulnerable, has this optimization switched off). > > Thanks, ChenGuang, for bringing this to our attention. > -- ramki > > Y. Srinivas Ramakrishna wrote: >> Looks like I am responsible for that typo (which is still there). >> I'll test and fix that issue. Thanks for the fix! >> >> -- ramki >> >> ChenGuang Sun wrote: >>> Hi, >>> >>> I'm reading the code and have noticed a minor typo in the function >>> "CollectedHeap::pre_initialize()". >>> >>> I think it should be "#ifdef COMPILER2" instead of "#ifdef >>> COMPLER2". I haven't checked whether it has been corrected in the >>> latest revision. >>> >>> Thanks, >>> Chen >> >> > From yamauchi at google.com Tue May 18 18:12:10 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 18 May 2010 11:12:10 -0700 Subject: PrintGCStats Message-ID: Hi, Does any have a version of the PrintGCStats script that works with the recent Hotspot builds and that we can share in the community? It appears that an old version of it is available here: http://java.sun.com/developer/technicalArticles/Programming/turbo/#PrintGCStats But it does not seem to be able to parse the output from a recent Hotspot correctly (eg gc times always show zero.) I think it's very convenient and almost a must to have a version that we can share and standardize on. Thanks, Hiroshi From adamh at basis.com Tue May 18 18:19:51 2010 From: adamh at basis.com (Adam Hawthorne) Date: Tue, 18 May 2010 14:19:51 -0400 Subject: PrintGCStats In-Reply-To: References: Message-ID: I hacked this one up a few months ago when I couldn't find one. You might want to review it, I don't guarantee it's accurate, and I don't know awk very well, but it seemed to be working when I last used it. Let me know if it doesn't come through (PrintGCStats.tgz) . Adam -- Adam Hawthorne Software Engineer BASIS International Ltd. www.basis.com +1.505.345.5232 Phone On Tue, May 18, 2010 at 14:12, Hiroshi Yamauchi wrote: > Hi, > > Does any have a version of the PrintGCStats script that works with the > recent Hotspot builds and that we can share in the community? > > It appears that an old version of it is available here: > > > http://java.sun.com/developer/technicalArticles/Programming/turbo/#PrintGCStats > > But it does not seem to be able to parse the output from a recent > Hotspot correctly (eg gc times always show zero.) > > I think it's very convenient and almost a must to have a version that > we can share and standardize on. > > Thanks, > Hiroshi > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PrintGCStats.tgz Type: application/x-gzip Size: 13188 bytes Desc: not available URL: From yamauchi at google.com Tue May 18 19:07:15 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 18 May 2010 12:07:15 -0700 Subject: PrintGCStats In-Reply-To: References: Message-ID: Hi Adam, Thanks for a quick response. I'll try to take a look at it at my next chance. Does anyone, who knows more about the script than I, feel like taking a look at it? Thanks, Hiroshi On Tue, May 18, 2010 at 11:19 AM, Adam Hawthorne wrote: > I hacked this one up a few months ago when I couldn't find one. ?You might > want to review it, I don't guarantee it's accurate, and I don't know awk > very well, but it seemed to be working when I last used it. > > Let me know if it doesn't come through (PrintGCStats.tgz) . > Adam > > -- > Adam Hawthorne > Software Engineer > BASIS International Ltd. > www.basis.com > +1.505.345.5232 Phone > > > On Tue, May 18, 2010 at 14:12, Hiroshi Yamauchi wrote: >> >> Hi, >> >> Does any have a version of the PrintGCStats script that works with the >> recent Hotspot builds and that we can share in the community? >> >> It appears that an old version of it is available here: >> >> >> ?http://java.sun.com/developer/technicalArticles/Programming/turbo/#PrintGCStats >> >> But it does not seem to be able to parse the output from a recent >> Hotspot correctly (eg gc times always show zero.) >> >> I think it's very convenient and almost a must to have a version that >> we can share and standardize on. >> >> Thanks, >> Hiroshi > > From y.s.ramakrishna at oracle.com Tue May 18 19:07:52 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Tue, 18 May 2010 12:07:52 -0700 Subject: A minor bug in jdk7-b87 In-Reply-To: <4BF2CD84.7050608@oracle.com> References: <4BF2B67F.9050807@oracle.com> <4BF2BE2D.6030205@oracle.com> <4BF2CD84.7050608@oracle.com> Message-ID: <4BF2E588.1020404@oracle.com> Vladimir Kozlov wrote: > The file also have LP64 instead of _LP64: > > src/share/vm/gc_interface/collectedHeap.cpp:#ifdef LP64 > Yes, that one is probably not fatal (as far as i can see because i think LP64 gets defined when building 64-bit and this has been around a lot longer than COMPLER2; i'll check), but we should fix that too... thanks Vladimir. -- ramki > Vladimir > > Y. Srinivas Ramakrishna wrote: >> 6953483 Typo related to ReduceInitialCardMarks >> >> Workaround for the case of CMS: -XX:-ReduceInitialCardMarks. >> >> No issue for other collectors (G1, which may otherwise have been >> vulnerable, has this optimization switched off). >> >> Thanks, ChenGuang, for bringing this to our attention. >> -- ramki >> >> Y. Srinivas Ramakrishna wrote: >>> Looks like I am responsible for that typo (which is still there). >>> I'll test and fix that issue. Thanks for the fix! >>> >>> -- ramki >>> >>> ChenGuang Sun wrote: >>>> Hi, >>>> >>>> I'm reading the code and have noticed a minor typo in the function >>>> "CollectedHeap::pre_initialize()". >>>> >>>> I think it should be "#ifdef COMPILER2" instead of "#ifdef >>>> COMPLER2". I haven't checked whether it has been corrected in the >>>> latest revision. >>>> >>>> Thanks, >>>> Chen >>> >>> >> From john.coomes at oracle.com Wed May 19 00:53:27 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 19 May 2010 00:53:27 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6951319: enable solaris builds using Sun Studio 12 update 1 Message-ID: <20100519005337.A7F6C44176@hg.openjdk.java.net> Changeset: fb1a39993f69 Author: jcoomes Date: 2010-05-18 11:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fb1a39993f69 6951319: enable solaris builds using Sun Studio 12 update 1 Reviewed-by: kamg, ysr, dholmes, johnc ! make/solaris/makefiles/amd64.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/i486.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/dtrace.hpp From y.s.ramakrishna at oracle.com Thu May 20 00:18:08 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Thu, 20 May 2010 00:18:08 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6953483: Typo related to ReduceInitialCardMarks leaves concurrent collectors vulnerable to heap corruption Message-ID: <20100520001811.2168644362@hg.openjdk.java.net> Changeset: 15190cbcabe9 Author: ysr Date: 2010-05-19 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/15190cbcabe9 6953483: Typo related to ReduceInitialCardMarks leaves concurrent collectors vulnerable to heap corruption Summary: Corrected mis-spelling of COMPILER2 in #ifdef, which could cause heap corruption in CMS due to precleaning when +ReduceInitialCardMarks. Thanks to ChenGuang Sun for bringing this typo to our attention. Reviewed-by: tonyp, jmasa, jcoomes, kvn ! src/share/vm/gc_interface/collectedHeap.cpp From y.s.ramakrishna at oracle.com Thu May 20 06:31:15 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Thu, 20 May 2010 06:31:15 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6953952: collectedHeap.cpp should use #ifdef _LP64 not LP64 Message-ID: <20100520063119.1F13B4437D@hg.openjdk.java.net> Changeset: 1634cec09505 Author: ysr Date: 2010-05-19 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1634cec09505 6953952: collectedHeap.cpp should use #ifdef _LP64 not LP64 Summary: Changed LP64 to _LP64 in collectedHeap.cpp. Reviewed-by: kvn, jcoomes ! src/share/vm/gc_interface/collectedHeap.cpp From kirk.pepperdine at gmail.com Wed May 26 19:58:57 2010 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Wed, 26 May 2010 15:58:57 -0400 Subject: gc log entry format Message-ID: Hi all, In build 1.6.0_17-b04-248-9M3125 I've been running into log entries that look like this. 41.597: [GC 41.597: [ParNew (promotion failed) Desired survivor size 1343488 bytes, new threshold 4 (max 4) - age 1: 744120 bytes, 744120 total - age 2: 529152 bytes, 1273272 total - age 3: 32392 bytes, 1305664 total : 17486K->17249K(18624K), 0.0021027 secs]41.599: [CMS41.600: [CMS-concurrent-abortable-preclean: 0.028/0.632 secs] [Times: user=1.00 sys=0.04, real=0.63 secs] (concurrent mode failure): 63809K->8087K(64768K), 0.0860671 secs] 81202K->8087K(83392K), [CMS Perm : 10707K->10707K(21248K)], 0.0883203 secs] [Times: user=0.09 sys=0.00, real=0.09 secs] Looks like ParNew is mixed with the invocation of the CMS instead of that record being on a new line. The format is consistent but not so nice to parse ;-) Regards, Kirk -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Wed May 26 20:34:11 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 26 May 2010 13:34:11 -0700 Subject: gc log entry format In-Reply-To: References: Message-ID: <4BFD85C3.6000706@oracle.com> I think you're seeing a mix of the ParNew collection experiencing a promotion failure and resulting in a full collection - this part 41.599: [CMS and at the same time a CMS concurrent phase starting 41.600: [CMS-concurrent-abortable-preclean: Yah, we hate it too. We're not doing any piecemeal fixing of the logging since we're trying to overhaul the whole thing. On 5/26/10 12:58 PM, Kirk Pepperdine wrote: > Hi all, > > In build 1.6.0_17-b04-248-9M3125 I've been running into log entries > that look like this. > > 41.597: [GC 41.597: [ParNew (promotion failed) > Desired survivor size 1343488 bytes, new threshold 4 (max 4) > - age 1: 744120 bytes, 744120 total > - age 2: 529152 bytes, 1273272 total > - age 3: 32392 bytes, 1305664 total > : 17486K->17249K(18624K), 0.0021027 secs]41.599: [CMS41.600: > [CMS-concurrent-abortable-preclean: 0.028/0.632 secs] [Times: > user=1.00 sys=0.04, real=0.63 secs] > (concurrent mode failure): 63809K->8087K(64768K), 0.0860671 secs] > 81202K->8087K(83392K), [CMS Perm : 10707K->10707K(21248K)], 0.0883203 > secs] [Times: user=0.09 sys=0.00, real=0.09 secs] > > Looks like ParNew is mixed with the invocation of the CMS instead of > that record being on a new line. The format is consistent but not so > nice to parse ;-) > > Regards, > Kirk From y.s.ramakrishna at oracle.com Wed May 26 20:41:02 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Wed, 26 May 2010 13:41:02 -0700 Subject: gc log entry format In-Reply-To: <4BFD85C3.6000706@oracle.com> References: <4BFD85C3.6000706@oracle.com> Message-ID: <4BFD875E.9050302@oracle.com> Jon Masamitsu wrote: > I think you're seeing a mix of the ParNew collection experiencing a > promotion failure and resulting in a full collection - this part > > 41.599: [CMS > > and at the same time a CMS concurrent phase starting > > 41.600: [CMS-concurrent-abortable-preclean: That's the concurrent phase _ending_. It turns out that because of historical reasons, we have to _end_ an ongoing concurrent phase before the foreground collection can take over and do a full gc as done here. So, yes, each concurrent mode failure will likely have such a report of the "interrupted" concurrent phase reporting its end before the foreground compacting collection occures. > > Yah, we hate it too. We're not doing any piecemeal fixing > of the logging since we're trying to overhaul the whole thing. > Right, and as we've remarked on occasion, our approach in the interim is to post-process the logs so as to separate out such interleaving so that our existing parsers can grok the data. Perhaps that approach can work for Kirk too in the interim... -- ramki > > > On 5/26/10 12:58 PM, Kirk Pepperdine wrote: >> Hi all, >> >> In build 1.6.0_17-b04-248-9M3125 I've been running into log entries >> that look like this. >> >> 41.597: [GC 41.597: [ParNew (promotion failed) >> Desired survivor size 1343488 bytes, new threshold 4 (max 4) >> - age 1: 744120 bytes, 744120 total >> - age 2: 529152 bytes, 1273272 total >> - age 3: 32392 bytes, 1305664 total >> : 17486K->17249K(18624K), 0.0021027 secs]41.599: [CMS41.600: >> [CMS-concurrent-abortable-preclean: 0.028/0.632 secs] [Times: >> user=1.00 sys=0.04, real=0.63 secs] >> (concurrent mode failure): 63809K->8087K(64768K), 0.0860671 secs] >> 81202K->8087K(83392K), [CMS Perm : 10707K->10707K(21248K)], 0.0883203 >> secs] [Times: user=0.09 sys=0.00, real=0.09 secs] >> >> Looks like ParNew is mixed with the invocation of the CMS instead of >> that record being on a new line. The format is consistent but not so >> nice to parse ;-) >> >> Regards, >> Kirk > From john.cuthbertson at sun.com Wed May 26 21:36:01 2010 From: john.cuthbertson at sun.com (john.cuthbertson at sun.com) Date: Wed, 26 May 2010 21:36:01 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6941378: G1: change default value of G1UseFixedWindowMMUTracker to true Message-ID: <20100526213610.532A846E2E@hg.openjdk.java.net> Changeset: f16f1d7893de Author: johnc Date: 2010-05-24 17:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f16f1d7893de 6941378: G1: change default value of G1UseFixedWindowMMUTracker to true Summary: Rather than changing the default value of the G1UseFixedWindowMMUTracker, the flag and associated guarantee have been removed. Reviewed-by: jcoomes, tonyp, ysr ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp From atulksh at hotmail.com Thu May 27 17:58:17 2010 From: atulksh at hotmail.com (atulksh) Date: Thu, 27 May 2010 10:58:17 -0700 (PDT) Subject: UseCompressedOops switch with more than 32gb heaps... Message-ID: <28697759.post@talk.nabble.com> Hi, We are currently running our application servers with 26Gb of heap and have the UseCompressedOops enabled for memory savings. We are intending to boost the memory on our servers more, in which event, we would be bumping the heap above 32Gb. I know that the UseCompressedOops switch works only if you have a heap of 32Gb or less. Is there anything in the Hotspot VM roadmap where there may be support of heaps larger than 32Gb, and still using the UseCompressedOops switch for memory optimization (32 bit object pointers within the heap)? Or is this question irrelevent - meaning there is no possibility to have such a support on the 64 bit machines? Thank you for your response in advance. Atul -- View this message in context: http://old.nabble.com/UseCompressedOops-switch-with-more-than-32gb-heaps...-tp28697759p28697759.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From vladimir.kozlov at oracle.com Thu May 27 18:03:00 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 May 2010 11:03:00 -0700 Subject: UseCompressedOops switch with more than 32gb heaps... In-Reply-To: <28697759.post@talk.nabble.com> References: <28697759.post@talk.nabble.com> Message-ID: <4BFEB3D4.6040000@oracle.com> I am currently working on this. You have to increase java objects alignment (from current 8 bytes) to be able to use compressed pointers (which are 32 bit) which large heaps. Thanks, Vladimir atulksh wrote: > Hi, > We are currently running our application servers with 26Gb of heap and have > the UseCompressedOops enabled for memory savings. We are intending to boost > the memory on our servers more, in which event, we would be bumping the heap > above 32Gb. I know that the UseCompressedOops switch works only if you have > a heap of 32Gb or less. > > Is there anything in the Hotspot VM roadmap where there may be support of > heaps larger than 32Gb, and still using the UseCompressedOops switch for > memory optimization (32 bit object pointers within the heap)? Or is this > question irrelevent - meaning there is no possibility to have such a support > on the 64 bit machines? > > Thank you for your response in advance. > > Atul From John.Coomes at oracle.com Thu May 27 18:07:01 2010 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 27 May 2010 11:07:01 -0700 Subject: review request (XXS): 6956472 vmerrors.sh uses ksh-specific syntax Message-ID: <19454.46277.708883.388646@oracle.com> Trivial, one-line change to remove ksh-specific syntax from vmerrors.sh. http://cr.openjdk.java.net/~jcoomes/6956472-vmerrors/ -John From vladimir.kozlov at oracle.com Thu May 27 18:06:37 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 May 2010 11:06:37 -0700 Subject: review request (XXS): 6956472 vmerrors.sh uses ksh-specific syntax In-Reply-To: <19454.46277.708883.388646@oracle.com> References: <19454.46277.708883.388646@oracle.com> Message-ID: <4BFEB4AD.5090900@oracle.com> Good. Vladimir John Coomes wrote: > Trivial, one-line change to remove ksh-specific syntax from vmerrors.sh. > > http://cr.openjdk.java.net/~jcoomes/6956472-vmerrors/ > > -John > From atulksh at hotmail.com Thu May 27 18:40:13 2010 From: atulksh at hotmail.com (atulksh) Date: Thu, 27 May 2010 11:40:13 -0700 (PDT) Subject: UseCompressedOops switch with more than 32gb heaps... In-Reply-To: <4BFEB3D4.6040000@oracle.com> References: <28697759.post@talk.nabble.com> <4BFEB3D4.6040000@oracle.com> Message-ID: <28698254.post@talk.nabble.com> Hi Vladimir, So what you are saying is, in a future Hotspot release, we will have the ability to specify a heap greater than 32Gb for a VM and still use the useCompressedOops switch. The VM will use compressed oops references, while still allowing the VM overall to address more than 32Gb of heap. What is the timeframe of such a feature (even if it is vague and not precise it is fine) are we looking at - is it coming soon (less than a year)? Thanks for your quick response. Atul Vladimir Kozlov-6 wrote: > > I am currently working on this. You have to increase java objects > alignment > (from current 8 bytes) to be able to use compressed pointers (which are 32 > bit) > which large heaps. > > Thanks, > Vladimir > > atulksh wrote: >> Hi, >> We are currently running our application servers with 26Gb of heap and >> have >> the UseCompressedOops enabled for memory savings. We are intending to >> boost >> the memory on our servers more, in which event, we would be bumping the >> heap >> above 32Gb. I know that the UseCompressedOops switch works only if you >> have >> a heap of 32Gb or less. >> >> Is there anything in the Hotspot VM roadmap where there may be support of >> heaps larger than 32Gb, and still using the UseCompressedOops switch for >> memory optimization (32 bit object pointers within the heap)? Or is this >> question irrelevent - meaning there is no possibility to have such a >> support >> on the 64 bit machines? >> >> Thank you for your response in advance. >> >> Atul > > -- View this message in context: http://old.nabble.com/UseCompressedOops-switch-with-more-than-32gb-heaps...-tp28697759p28698254.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From John.Coomes at oracle.com Thu May 27 18:48:17 2010 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 27 May 2010 11:48:17 -0700 Subject: review request (XXS): 6956472 vmerrors.sh uses ksh-specific syntax In-Reply-To: <4BFEB4AD.5090900@oracle.com> References: <19454.46277.708883.388646@oracle.com> <4BFEB4AD.5090900@oracle.com> Message-ID: <19454.48753.600617.947259@oracle.com> Vladimir Kozlov (vladimir.kozlov at oracle.com) wrote: > Good. Thank you. -John > John Coomes wrote: > > Trivial, one-line change to remove ksh-specific syntax from vmerrors.sh. > > > > http://cr.openjdk.java.net/~jcoomes/6956472-vmerrors/ > > > > -John > > From vladimir.kozlov at oracle.com Thu May 27 18:56:00 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 May 2010 11:56:00 -0700 Subject: UseCompressedOops switch with more than 32gb heaps... In-Reply-To: <28698254.post@talk.nabble.com> References: <28697759.post@talk.nabble.com> <4BFEB3D4.6040000@oracle.com> <28698254.post@talk.nabble.com> Message-ID: <4BFEC040.4040007@oracle.com> Very soon. Watch for next changes coming into hotspot (jdk7). I don't know when it will appear in the 6 update release. "6916623: Align object to 16 bytes to use Compressed Oops with java heap up to 64Gb" "6954029: Improve implicit null check generation with COOP" The first bug is closed so you may not see it but I will open it when I am done with changes. Vladimir atulksh wrote: > Hi Vladimir, > So what you are saying is, in a future Hotspot release, we will have the > ability to specify a heap greater than 32Gb for a VM and still use the > useCompressedOops switch. The VM will use compressed oops references, while > still allowing the VM overall to address more than 32Gb of heap. > > What is the timeframe of such a feature (even if it is vague and not precise > it is fine) are we looking at - is it coming soon (less than a year)? > > Thanks for your quick response. > > Atul > > > Vladimir Kozlov-6 wrote: >> I am currently working on this. You have to increase java objects >> alignment >> (from current 8 bytes) to be able to use compressed pointers (which are 32 >> bit) >> which large heaps. >> >> Thanks, >> Vladimir >> >> atulksh wrote: >>> Hi, >>> We are currently running our application servers with 26Gb of heap and >>> have >>> the UseCompressedOops enabled for memory savings. We are intending to >>> boost >>> the memory on our servers more, in which event, we would be bumping the >>> heap >>> above 32Gb. I know that the UseCompressedOops switch works only if you >>> have >>> a heap of 32Gb or less. >>> >>> Is there anything in the Hotspot VM roadmap where there may be support of >>> heaps larger than 32Gb, and still using the UseCompressedOops switch for >>> memory optimization (32 bit object pointers within the heap)? Or is this >>> question irrelevent - meaning there is no possibility to have such a >>> support >>> on the 64 bit machines? >>> >>> Thank you for your response in advance. >>> >>> Atul >> > From atulksh at hotmail.com Thu May 27 19:08:50 2010 From: atulksh at hotmail.com (atulksh) Date: Thu, 27 May 2010 12:08:50 -0700 (PDT) Subject: UseCompressedOops switch with more than 32gb heaps... In-Reply-To: <4BFEC040.4040007@oracle.com> References: <28697759.post@talk.nabble.com> <4BFEB3D4.6040000@oracle.com> <28698254.post@talk.nabble.com> <4BFEC040.4040007@oracle.com> Message-ID: <28698608.post@talk.nabble.com> This is great to know. Thank you so much for you quick responses. Atul Vladimir Kozlov-6 wrote: > > Very soon. Watch for next changes coming into hotspot (jdk7). > I don't know when it will appear in the 6 update release. > > "6916623: Align object to 16 bytes to use Compressed Oops with java heap > up to 64Gb" > "6954029: Improve implicit null check generation with COOP" > > The first bug is closed so you may not see it but I will open it when I am > done with changes. > > Vladimir > > atulksh wrote: >> Hi Vladimir, >> So what you are saying is, in a future Hotspot release, we will have the >> ability to specify a heap greater than 32Gb for a VM and still use the >> useCompressedOops switch. The VM will use compressed oops references, >> while >> still allowing the VM overall to address more than 32Gb of heap. >> >> What is the timeframe of such a feature (even if it is vague and not >> precise >> it is fine) are we looking at - is it coming soon (less than a year)? >> >> Thanks for your quick response. >> >> Atul >> >> >> Vladimir Kozlov-6 wrote: >>> I am currently working on this. You have to increase java objects >>> alignment >>> (from current 8 bytes) to be able to use compressed pointers (which are >>> 32 >>> bit) >>> which large heaps. >>> >>> Thanks, >>> Vladimir >>> >>> atulksh wrote: >>>> Hi, >>>> We are currently running our application servers with 26Gb of heap and >>>> have >>>> the UseCompressedOops enabled for memory savings. We are intending to >>>> boost >>>> the memory on our servers more, in which event, we would be bumping the >>>> heap >>>> above 32Gb. I know that the UseCompressedOops switch works only if you >>>> have >>>> a heap of 32Gb or less. >>>> >>>> Is there anything in the Hotspot VM roadmap where there may be support >>>> of >>>> heaps larger than 32Gb, and still using the UseCompressedOops switch >>>> for >>>> memory optimization (32 bit object pointers within the heap)? Or is >>>> this >>>> question irrelevent - meaning there is no possibility to have such a >>>> support >>>> on the 64 bit machines? >>>> >>>> Thank you for your response in advance. >>>> >>>> Atul >>> >> > > -- View this message in context: http://old.nabble.com/UseCompressedOops-switch-with-more-than-32gb-heaps...-tp28697759p28698608.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From atulksh at hotmail.com Thu May 27 19:14:40 2010 From: atulksh at hotmail.com (atulksh) Date: Thu, 27 May 2010 12:14:40 -0700 (PDT) Subject: UseCompressedOops switch with more than 32gb heaps... In-Reply-To: <4BFEC040.4040007@oracle.com> References: <28697759.post@talk.nabble.com> <4BFEB3D4.6040000@oracle.com> <28698254.post@talk.nabble.com> <4BFEC040.4040007@oracle.com> Message-ID: <28698669.post@talk.nabble.com> Hi Vladimir, I did not find the two bugs you mentioned in the Hotspot bug database. Are they only accessible to you internally and not exposed to the public world? I looked here. http://bugs.sun.com/bugdatabase/ Thanks, Atul Vladimir Kozlov-6 wrote: > > Very soon. Watch for next changes coming into hotspot (jdk7). > I don't know when it will appear in the 6 update release. > > "6916623: Align object to 16 bytes to use Compressed Oops with java heap > up to 64Gb" > "6954029: Improve implicit null check generation with COOP" > > The first bug is closed so you may not see it but I will open it when I am > done with changes. > > Vladimir > > atulksh wrote: >> Hi Vladimir, >> So what you are saying is, in a future Hotspot release, we will have the >> ability to specify a heap greater than 32Gb for a VM and still use the >> useCompressedOops switch. The VM will use compressed oops references, >> while >> still allowing the VM overall to address more than 32Gb of heap. >> >> What is the timeframe of such a feature (even if it is vague and not >> precise >> it is fine) are we looking at - is it coming soon (less than a year)? >> >> Thanks for your quick response. >> >> Atul >> >> >> Vladimir Kozlov-6 wrote: >>> I am currently working on this. You have to increase java objects >>> alignment >>> (from current 8 bytes) to be able to use compressed pointers (which are >>> 32 >>> bit) >>> which large heaps. >>> >>> Thanks, >>> Vladimir >>> >>> atulksh wrote: >>>> Hi, >>>> We are currently running our application servers with 26Gb of heap and >>>> have >>>> the UseCompressedOops enabled for memory savings. We are intending to >>>> boost >>>> the memory on our servers more, in which event, we would be bumping the >>>> heap >>>> above 32Gb. I know that the UseCompressedOops switch works only if you >>>> have >>>> a heap of 32Gb or less. >>>> >>>> Is there anything in the Hotspot VM roadmap where there may be support >>>> of >>>> heaps larger than 32Gb, and still using the UseCompressedOops switch >>>> for >>>> memory optimization (32 bit object pointers within the heap)? Or is >>>> this >>>> question irrelevent - meaning there is no possibility to have such a >>>> support >>>> on the 64 bit machines? >>>> >>>> Thank you for your response in advance. >>>> >>>> Atul >>> >> > > -- View this message in context: http://old.nabble.com/UseCompressedOops-switch-with-more-than-32gb-heaps...-tp28697759p28698669.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From vladimir.kozlov at oracle.com Thu May 27 20:30:52 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 May 2010 13:30:52 -0700 Subject: UseCompressedOops switch with more than 32gb heaps... In-Reply-To: <28698669.post@talk.nabble.com> References: <28697759.post@talk.nabble.com> <4BFEB3D4.6040000@oracle.com> <28698254.post@talk.nabble.com> <4BFEC040.4040007@oracle.com> <28698669.post@talk.nabble.com> Message-ID: <4BFED67C.7080706@oracle.com> I don't have answer on this question. I don't know why 6954029 is not exposed. Vladimir atulksh wrote: > Hi Vladimir, > I did not find the two bugs you mentioned in the Hotspot bug database. Are > they only accessible to you internally and not exposed to the public world? > > I looked here. > > http://bugs.sun.com/bugdatabase/ > > Thanks, > > Atul > > > Vladimir Kozlov-6 wrote: >> Very soon. Watch for next changes coming into hotspot (jdk7). >> I don't know when it will appear in the 6 update release. >> >> "6916623: Align object to 16 bytes to use Compressed Oops with java heap >> up to 64Gb" >> "6954029: Improve implicit null check generation with COOP" >> >> The first bug is closed so you may not see it but I will open it when I am >> done with changes. >> >> Vladimir >> >> atulksh wrote: >>> Hi Vladimir, >>> So what you are saying is, in a future Hotspot release, we will have the >>> ability to specify a heap greater than 32Gb for a VM and still use the >>> useCompressedOops switch. The VM will use compressed oops references, >>> while >>> still allowing the VM overall to address more than 32Gb of heap. >>> >>> What is the timeframe of such a feature (even if it is vague and not >>> precise >>> it is fine) are we looking at - is it coming soon (less than a year)? >>> >>> Thanks for your quick response. >>> >>> Atul >>> >>> >>> Vladimir Kozlov-6 wrote: >>>> I am currently working on this. You have to increase java objects >>>> alignment >>>> (from current 8 bytes) to be able to use compressed pointers (which are >>>> 32 >>>> bit) >>>> which large heaps. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> atulksh wrote: >>>>> Hi, >>>>> We are currently running our application servers with 26Gb of heap and >>>>> have >>>>> the UseCompressedOops enabled for memory savings. We are intending to >>>>> boost >>>>> the memory on our servers more, in which event, we would be bumping the >>>>> heap >>>>> above 32Gb. I know that the UseCompressedOops switch works only if you >>>>> have >>>>> a heap of 32Gb or less. >>>>> >>>>> Is there anything in the Hotspot VM roadmap where there may be support >>>>> of >>>>> heaps larger than 32Gb, and still using the UseCompressedOops switch >>>>> for >>>>> memory optimization (32 bit object pointers within the heap)? Or is >>>>> this >>>>> question irrelevent - meaning there is no possibility to have such a >>>>> support >>>>> on the 64 bit machines? >>>>> >>>>> Thank you for your response in advance. >>>>> >>>>> Atul >> > From john.coomes at oracle.com Fri May 28 09:23:02 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 May 2010 09:23:02 +0000 Subject: hg: jdk7/hotspot-gc: 3 new changesets Message-ID: <20100528092302.4D12146E65@hg.openjdk.java.net> Changeset: 412712f77af6 Author: ohair Date: 2010-05-25 15:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/412712f77af6 6943119: Rebrand source copyright notices Reviewed-by: darcy ! Makefile ! make/Defs-internal.gmk ! make/corba-rules.gmk ! make/deploy-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jaxp-rules.gmk ! make/jaxws-rules.gmk ! make/jdk-rules.gmk ! make/jprt.gmk ! make/jprt.properties ! make/langtools-rules.gmk ! make/sanity-rules.gmk ! make/sponsors-rules.gmk ! make/templates/bsd-header ! make/templates/gpl-cp-header ! test/Makefile Changeset: fd3663286e77 Author: ohair Date: 2010-05-26 10:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/fd3663286e77 Merge Changeset: cf71cb515116 Author: mikejwre Date: 2010-05-27 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/cf71cb515116 Added tag jdk7-b95 for changeset fd3663286e77 ! .hgtags From john.coomes at oracle.com Fri May 28 09:28:47 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 May 2010 09:28:47 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: 3 new changesets Message-ID: <20100528092847.BAE1D46E66@hg.openjdk.java.net> Changeset: 72d78db95fb1 Author: ohair Date: 2010-05-25 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/72d78db95fb1 6943119: Rebrand source copyright notices Reviewed-by: darcy ! build-defs.xml ! build-drop-template.xml ! build.properties ! build.xml ! jaxp.properties ! make/Makefile ! make/jprt.properties Changeset: 07050840f98c Author: ohair Date: 2010-05-26 10:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/07050840f98c Merge Changeset: 9510ed0e1c7a Author: mikejwre Date: 2010-05-27 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/9510ed0e1c7a Added tag jdk7-b95 for changeset 07050840f98c ! .hgtags From john.coomes at oracle.com Fri May 28 09:28:51 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 May 2010 09:28:51 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: 3 new changesets Message-ID: <20100528092851.8AD2B46E67@hg.openjdk.java.net> Changeset: 4ac192952d75 Author: ohair Date: 2010-05-25 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/4ac192952d75 6943119: Rebrand source copyright notices Reviewed-by: darcy ! build-defs.xml ! build-drop-template.xml ! build.properties ! build.xml ! jaxws.properties ! make/Makefile ! make/jprt.properties Changeset: ee06cfb113d5 Author: ohair Date: 2010-05-26 10:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/ee06cfb113d5 Merge Changeset: 208fd4451232 Author: mikejwre Date: 2010-05-27 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/208fd4451232 Added tag jdk7-b95 for changeset ee06cfb113d5 ! .hgtags From john.coomes at oracle.com Fri May 28 09:41:03 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 May 2010 09:41:03 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 3 new changesets Message-ID: <20100528094112.B7CC746E6A@hg.openjdk.java.net> Changeset: 9d9f26857129 Author: ohair Date: 2010-05-25 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/9d9f26857129 6943119: Rebrand source copyright notices Reviewed-by: darcy ! make/Makefile ! make/Makefile-classic ! make/build.properties ! make/build.xml ! make/jprt.properties ! make/netbeans/langtools/build.xml ! make/netbeans/langtools/nbproject/project.xml ! make/netbeans/langtools/nbproject/standard-context-menu-items.ent ! make/netbeans/langtools/nbproject/standard-ide-actions.ent ! make/test/HelloWorld.java ! make/test/bootstrap/javac.sh ! make/test/bootstrap/javadoc.sh ! make/test/bootstrap/javah.sh ! make/test/contents.sh ! make/test/lib/apt.sh ! make/test/lib/classes.sh ! make/test/lib/javac.sh ! make/test/lib/javadoc.sh ! make/test/lib/javah.sh ! make/test/lib/javap.sh ! make/test/lib/src.sh ! make/tools/CompileProperties/CompileProperties.java ! make/tools/CompileProperties/CompilePropertiesTask.java ! make/tools/GenStubs/GenStubs.java ! make/tools/SelectTool/SelectToolTask.java ! src/share/bin/launcher.sh-template ! src/share/classes/com/sun/javadoc/AnnotationDesc.java ! src/share/classes/com/sun/javadoc/AnnotationTypeDoc.java ! src/share/classes/com/sun/javadoc/AnnotationTypeElementDoc.java ! src/share/classes/com/sun/javadoc/AnnotationValue.java ! src/share/classes/com/sun/javadoc/ClassDoc.java ! src/share/classes/com/sun/javadoc/ConstructorDoc.java ! src/share/classes/com/sun/javadoc/Doc.java ! src/share/classes/com/sun/javadoc/DocErrorReporter.java ! src/share/classes/com/sun/javadoc/Doclet.java ! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java ! src/share/classes/com/sun/javadoc/FieldDoc.java ! src/share/classes/com/sun/javadoc/LanguageVersion.java ! src/share/classes/com/sun/javadoc/MemberDoc.java ! src/share/classes/com/sun/javadoc/MethodDoc.java ! src/share/classes/com/sun/javadoc/PackageDoc.java ! src/share/classes/com/sun/javadoc/ParamTag.java ! src/share/classes/com/sun/javadoc/Parameter.java ! src/share/classes/com/sun/javadoc/ParameterizedType.java ! src/share/classes/com/sun/javadoc/ProgramElementDoc.java ! src/share/classes/com/sun/javadoc/RootDoc.java ! src/share/classes/com/sun/javadoc/SeeTag.java ! src/share/classes/com/sun/javadoc/SerialFieldTag.java ! src/share/classes/com/sun/javadoc/SourcePosition.java ! src/share/classes/com/sun/javadoc/Tag.java ! src/share/classes/com/sun/javadoc/ThrowsTag.java ! src/share/classes/com/sun/javadoc/Type.java ! src/share/classes/com/sun/javadoc/TypeVariable.java ! src/share/classes/com/sun/javadoc/WildcardType.java ! src/share/classes/com/sun/javadoc/package.html ! src/share/classes/com/sun/mirror/apt/AnnotationProcessor.java ! src/share/classes/com/sun/mirror/apt/AnnotationProcessorEnvironment.java ! src/share/classes/com/sun/mirror/apt/AnnotationProcessorFactory.java ! src/share/classes/com/sun/mirror/apt/AnnotationProcessorListener.java ! src/share/classes/com/sun/mirror/apt/AnnotationProcessors.java ! src/share/classes/com/sun/mirror/apt/Filer.java ! src/share/classes/com/sun/mirror/apt/Messager.java ! src/share/classes/com/sun/mirror/apt/RoundCompleteEvent.java ! src/share/classes/com/sun/mirror/apt/RoundCompleteListener.java ! src/share/classes/com/sun/mirror/apt/RoundState.java ! src/share/classes/com/sun/mirror/apt/package-info.java ! src/share/classes/com/sun/mirror/declaration/AnnotationMirror.java ! src/share/classes/com/sun/mirror/declaration/AnnotationTypeDeclaration.java ! src/share/classes/com/sun/mirror/declaration/AnnotationTypeElementDeclaration.java ! src/share/classes/com/sun/mirror/declaration/AnnotationValue.java ! src/share/classes/com/sun/mirror/declaration/ClassDeclaration.java ! src/share/classes/com/sun/mirror/declaration/ConstructorDeclaration.java ! src/share/classes/com/sun/mirror/declaration/Declaration.java ! src/share/classes/com/sun/mirror/declaration/EnumConstantDeclaration.java ! src/share/classes/com/sun/mirror/declaration/EnumDeclaration.java ! src/share/classes/com/sun/mirror/declaration/ExecutableDeclaration.java ! src/share/classes/com/sun/mirror/declaration/FieldDeclaration.java ! src/share/classes/com/sun/mirror/declaration/InterfaceDeclaration.java ! src/share/classes/com/sun/mirror/declaration/MemberDeclaration.java ! src/share/classes/com/sun/mirror/declaration/MethodDeclaration.java ! src/share/classes/com/sun/mirror/declaration/Modifier.java ! src/share/classes/com/sun/mirror/declaration/PackageDeclaration.java ! src/share/classes/com/sun/mirror/declaration/ParameterDeclaration.java ! src/share/classes/com/sun/mirror/declaration/TypeDeclaration.java ! src/share/classes/com/sun/mirror/declaration/TypeParameterDeclaration.java ! src/share/classes/com/sun/mirror/declaration/package-info.java ! src/share/classes/com/sun/mirror/overview.html ! src/share/classes/com/sun/mirror/type/AnnotationType.java ! src/share/classes/com/sun/mirror/type/ArrayType.java ! src/share/classes/com/sun/mirror/type/ClassType.java ! src/share/classes/com/sun/mirror/type/DeclaredType.java ! src/share/classes/com/sun/mirror/type/EnumType.java ! src/share/classes/com/sun/mirror/type/InterfaceType.java ! src/share/classes/com/sun/mirror/type/MirroredTypeException.java ! src/share/classes/com/sun/mirror/type/MirroredTypesException.java ! src/share/classes/com/sun/mirror/type/PrimitiveType.java ! src/share/classes/com/sun/mirror/type/ReferenceType.java ! src/share/classes/com/sun/mirror/type/TypeMirror.java ! src/share/classes/com/sun/mirror/type/TypeVariable.java ! src/share/classes/com/sun/mirror/type/VoidType.java ! src/share/classes/com/sun/mirror/type/WildcardType.java ! src/share/classes/com/sun/mirror/type/package-info.java ! src/share/classes/com/sun/mirror/util/DeclarationFilter.java ! src/share/classes/com/sun/mirror/util/DeclarationScanner.java ! src/share/classes/com/sun/mirror/util/DeclarationVisitor.java ! src/share/classes/com/sun/mirror/util/DeclarationVisitors.java ! src/share/classes/com/sun/mirror/util/Declarations.java ! src/share/classes/com/sun/mirror/util/SimpleDeclarationVisitor.java ! src/share/classes/com/sun/mirror/util/SimpleTypeVisitor.java ! src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java ! src/share/classes/com/sun/mirror/util/SourcePosition.java ! src/share/classes/com/sun/mirror/util/TypeVisitor.java ! src/share/classes/com/sun/mirror/util/Types.java ! src/share/classes/com/sun/mirror/util/package-info.java ! src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/AnnotationTree.java ! src/share/classes/com/sun/source/tree/ArrayAccessTree.java ! src/share/classes/com/sun/source/tree/ArrayTypeTree.java ! src/share/classes/com/sun/source/tree/AssertTree.java ! src/share/classes/com/sun/source/tree/AssignmentTree.java ! src/share/classes/com/sun/source/tree/BinaryTree.java ! src/share/classes/com/sun/source/tree/BlockTree.java ! src/share/classes/com/sun/source/tree/BreakTree.java ! src/share/classes/com/sun/source/tree/CaseTree.java ! src/share/classes/com/sun/source/tree/CatchTree.java ! src/share/classes/com/sun/source/tree/ClassTree.java ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/CompoundAssignmentTree.java ! src/share/classes/com/sun/source/tree/ConditionalExpressionTree.java ! src/share/classes/com/sun/source/tree/ContinueTree.java ! src/share/classes/com/sun/source/tree/DoWhileLoopTree.java ! src/share/classes/com/sun/source/tree/EmptyStatementTree.java ! src/share/classes/com/sun/source/tree/EnhancedForLoopTree.java ! src/share/classes/com/sun/source/tree/ErroneousTree.java ! src/share/classes/com/sun/source/tree/ExpressionStatementTree.java ! src/share/classes/com/sun/source/tree/ExpressionTree.java ! src/share/classes/com/sun/source/tree/ForLoopTree.java ! src/share/classes/com/sun/source/tree/IdentifierTree.java ! src/share/classes/com/sun/source/tree/IfTree.java ! src/share/classes/com/sun/source/tree/ImportTree.java ! src/share/classes/com/sun/source/tree/InstanceOfTree.java ! src/share/classes/com/sun/source/tree/LabeledStatementTree.java ! src/share/classes/com/sun/source/tree/LineMap.java ! src/share/classes/com/sun/source/tree/LiteralTree.java ! src/share/classes/com/sun/source/tree/MemberSelectTree.java ! src/share/classes/com/sun/source/tree/MethodInvocationTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/ModifiersTree.java ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/tree/NewClassTree.java ! src/share/classes/com/sun/source/tree/ParameterizedTypeTree.java ! src/share/classes/com/sun/source/tree/ParenthesizedTree.java ! src/share/classes/com/sun/source/tree/PrimitiveTypeTree.java ! src/share/classes/com/sun/source/tree/ReturnTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/tree/StatementTree.java ! src/share/classes/com/sun/source/tree/SwitchTree.java ! src/share/classes/com/sun/source/tree/SynchronizedTree.java ! src/share/classes/com/sun/source/tree/ThrowTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/tree/TypeCastTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/tree/UnaryTree.java ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/tree/WhileLoopTree.java ! src/share/classes/com/sun/source/tree/WildcardTree.java ! src/share/classes/com/sun/source/tree/package-info.java ! src/share/classes/com/sun/source/util/AbstractTypeProcessor.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/SourcePositions.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TaskListener.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/source/util/TreePathScanner.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/source/util/package-info.java ! src/share/classes/com/sun/tools/apt/Main.java ! src/share/classes/com/sun/tools/apt/comp/AnnotationProcessingError.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/comp/BootstrapAPF.java ! src/share/classes/com/sun/tools/apt/comp/PrintAP.java ! src/share/classes/com/sun/tools/apt/comp/UsageMessageNeededException.java ! src/share/classes/com/sun/tools/apt/main/CommandLine.java ! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/apt/mirror/AptEnv.java ! src/share/classes/com/sun/tools/apt/mirror/apt/AnnotationProcessorEnvironmentImpl.java ! src/share/classes/com/sun/tools/apt/mirror/apt/FilerImpl.java ! src/share/classes/com/sun/tools/apt/mirror/apt/MessagerImpl.java ! src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java ! src/share/classes/com/sun/tools/apt/mirror/apt/RoundStateImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationMirrorImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeElementDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/ClassDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/ConstructorDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationMaker.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/EnumConstantDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/EnumDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/ExecutableDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/FieldDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/InterfaceDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/MemberDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/MethodDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/PackageDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/ParameterDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/TypeDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/TypeParameterDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/AnnotationTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/ArrayTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/ClassTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/DeclaredTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/EnumTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/InterfaceTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/PrimitiveTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeMaker.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/VoidTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/WildcardTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/util/DeclarationsImpl.java ! src/share/classes/com/sun/tools/apt/mirror/util/SourcePositionImpl.java ! src/share/classes/com/sun/tools/apt/mirror/util/TypesImpl.java ! src/share/classes/com/sun/tools/apt/resources/apt.properties ! src/share/classes/com/sun/tools/apt/resources/apt_ja.properties ! src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties ! src/share/classes/com/sun/tools/apt/util/Bark.java ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/classfile/Annotation.java ! src/share/classes/com/sun/tools/classfile/AnnotationDefault_attribute.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/AttributeException.java ! src/share/classes/com/sun/tools/classfile/Attributes.java ! src/share/classes/com/sun/tools/classfile/CharacterRangeTable_attribute.java ! src/share/classes/com/sun/tools/classfile/ClassFile.java ! src/share/classes/com/sun/tools/classfile/ClassReader.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/classfile/CompilationID_attribute.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/ConstantPoolException.java ! src/share/classes/com/sun/tools/classfile/ConstantValue_attribute.java ! src/share/classes/com/sun/tools/classfile/DefaultAttribute.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/classfile/Dependency.java ! src/share/classes/com/sun/tools/classfile/Deprecated_attribute.java ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/classfile/DescriptorException.java ! src/share/classes/com/sun/tools/classfile/EnclosingMethod_attribute.java ! src/share/classes/com/sun/tools/classfile/Exceptions_attribute.java ! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java ! src/share/classes/com/sun/tools/classfile/Field.java ! src/share/classes/com/sun/tools/classfile/InnerClasses_attribute.java ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/classfile/LineNumberTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LocalVariableTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LocalVariableTypeTable_attribute.java ! src/share/classes/com/sun/tools/classfile/Method.java ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/classfile/RuntimeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeInvisibleAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeInvisibleParameterAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeParameterAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeVisibleAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeVisibleParameterAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/Signature.java ! src/share/classes/com/sun/tools/classfile/Signature_attribute.java ! src/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java ! src/share/classes/com/sun/tools/classfile/SourceFile_attribute.java ! src/share/classes/com/sun/tools/classfile/SourceID_attribute.java ! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/share/classes/com/sun/tools/classfile/StackMap_attribute.java ! src/share/classes/com/sun/tools/classfile/Synthetic_attribute.java ! src/share/classes/com/sun/tools/classfile/Type.java ! src/share/classes/com/sun/tools/doclets/Taglet.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/StylesheetWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/package.html ! src/share/classes/com/sun/tools/doclets/formats/html/package.html ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeOptionalMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstructorWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/FieldWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MethodWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/NestedClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package.html ! src/share/classes/com/sun/tools/doclets/internal/toolkit/package.html ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseExecutableMemberTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseInlineTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DeprecatedTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DocRootTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritableTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LegacyTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/Taglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package.html ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/CommentedMethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/TaggedMethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/TextTag.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package.html ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package.html ! src/share/classes/com/sun/tools/doclets/package.html ! src/share/classes/com/sun/tools/doclets/standard/Standard.java ! src/share/classes/com/sun/tools/javac/Launcher.java ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/Server.java ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/Formattable.java ! src/share/classes/com/sun/tools/javac/api/JavacScope.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/api/Messages.java ! src/share/classes/com/sun/tools/javac/api/WrappingJavaFileManager.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/BoundKind.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/AttrContextEnv.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/Todo.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/RelativePath.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ByteCodes.java ! src/share/classes/com/sun/tools/javac/jvm/CRTFlags.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/jvm/UninitializedType.java ! src/share/classes/com/sun/tools/javac/main/CommandLine.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/JavacOption.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/model/FilteredMemberList.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/model/JavacSourcePosition.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java ! src/share/classes/com/sun/tools/javac/parser/EndPosParser.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/Parser.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/Token.java ! src/share/classes/com/sun/tools/javac/processing/AnnotationProcessingError.java ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/legacy.properties ! src/share/classes/com/sun/tools/javac/resources/version.properties-template ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/Abort.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/ByteBuffer.java ! src/share/classes/com/sun/tools/javac/util/ClientCodeException.java ! src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java ! src/share/classes/com/sun/tools/javac/util/Constants.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/Convert.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/FatalError.java ! src/share/classes/com/sun/tools/javac/util/ForwardingDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javac/util/Name.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! src/share/classes/com/sun/tools/javac/util/Pair.java ! src/share/classes/com/sun/tools/javac/util/Position.java ! src/share/classes/com/sun/tools/javac/util/PropagatedException.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/SharedNameTable.java ! src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java ! src/share/classes/com/sun/tools/javac/util/Warner.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Main.java ! src/share/classes/com/sun/tools/javadoc/MemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ModifierFilter.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/TagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javah/InternalError.java ! src/share/classes/com/sun/tools/javah/JNI.java ! src/share/classes/com/sun/tools/javah/JavahFileManager.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/JavahTool.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Main.java ! src/share/classes/com/sun/tools/javah/Mangle.java ! src/share/classes/com/sun/tools/javah/NativeHeaderTool.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/com/sun/tools/javah/Util.java ! src/share/classes/com/sun/tools/javah/resources/l10n.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/BasicWriter.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java ! src/share/classes/com/sun/tools/javap/Context.java ! src/share/classes/com/sun/tools/javap/DisassemblerTool.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java ! src/share/classes/com/sun/tools/javap/InternalError.java ! src/share/classes/com/sun/tools/javap/JavapFileManager.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/LocalVariableTableWriter.java ! src/share/classes/com/sun/tools/javap/LocalVariableTypeTableWriter.java ! src/share/classes/com/sun/tools/javap/Main.java ! src/share/classes/com/sun/tools/javap/Messages.java ! src/share/classes/com/sun/tools/javap/Options.java ! src/share/classes/com/sun/tools/javap/SourceWriter.java ! src/share/classes/com/sun/tools/javap/StackMapWriter.java ! src/share/classes/com/sun/tools/javap/TryBlockWriter.java ! src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! src/share/classes/com/sun/tools/javap/resources/version.properties-template ! src/share/classes/javax/annotation/processing/AbstractProcessor.java ! src/share/classes/javax/annotation/processing/Completion.java ! src/share/classes/javax/annotation/processing/Completions.java ! src/share/classes/javax/annotation/processing/Filer.java ! src/share/classes/javax/annotation/processing/FilerException.java ! src/share/classes/javax/annotation/processing/Messager.java ! src/share/classes/javax/annotation/processing/ProcessingEnvironment.java ! src/share/classes/javax/annotation/processing/Processor.java ! src/share/classes/javax/annotation/processing/RoundEnvironment.java ! src/share/classes/javax/annotation/processing/SupportedAnnotationTypes.java ! src/share/classes/javax/annotation/processing/SupportedOptions.java ! src/share/classes/javax/annotation/processing/SupportedSourceVersion.java ! src/share/classes/javax/annotation/processing/package-info.java ! src/share/classes/javax/lang/model/SourceVersion.java ! src/share/classes/javax/lang/model/UnknownEntityException.java ! src/share/classes/javax/lang/model/element/AnnotationMirror.java ! src/share/classes/javax/lang/model/element/AnnotationValue.java ! src/share/classes/javax/lang/model/element/AnnotationValueVisitor.java ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/ElementKind.java ! src/share/classes/javax/lang/model/element/ElementVisitor.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/element/Modifier.java ! src/share/classes/javax/lang/model/element/Name.java ! src/share/classes/javax/lang/model/element/NestingKind.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/Parameterizable.java ! src/share/classes/javax/lang/model/element/QualifiedNameable.java ! src/share/classes/javax/lang/model/element/TypeElement.java ! src/share/classes/javax/lang/model/element/TypeParameterElement.java ! src/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java ! src/share/classes/javax/lang/model/element/UnknownElementException.java ! src/share/classes/javax/lang/model/element/VariableElement.java ! src/share/classes/javax/lang/model/element/package-info.java ! src/share/classes/javax/lang/model/overview.html ! src/share/classes/javax/lang/model/package-info.java ! src/share/classes/javax/lang/model/type/ArrayType.java ! src/share/classes/javax/lang/model/type/DeclaredType.java ! src/share/classes/javax/lang/model/type/ErrorType.java ! src/share/classes/javax/lang/model/type/ExecutableType.java ! src/share/classes/javax/lang/model/type/MirroredTypeException.java ! src/share/classes/javax/lang/model/type/MirroredTypesException.java ! src/share/classes/javax/lang/model/type/NoType.java ! src/share/classes/javax/lang/model/type/NullType.java ! src/share/classes/javax/lang/model/type/PrimitiveType.java ! src/share/classes/javax/lang/model/type/ReferenceType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeMirror.java ! src/share/classes/javax/lang/model/type/TypeVariable.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/type/UnknownTypeException.java ! src/share/classes/javax/lang/model/type/WildcardType.java ! src/share/classes/javax/lang/model/type/package-info.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/ElementFilter.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java ! src/share/classes/javax/lang/model/util/Elements.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java ! src/share/classes/javax/lang/model/util/Types.java ! src/share/classes/javax/lang/model/util/package-info.java ! src/share/classes/javax/tools/Diagnostic.java ! src/share/classes/javax/tools/DiagnosticCollector.java ! src/share/classes/javax/tools/DiagnosticListener.java ! src/share/classes/javax/tools/FileObject.java ! src/share/classes/javax/tools/ForwardingFileObject.java ! src/share/classes/javax/tools/ForwardingJavaFileManager.java ! src/share/classes/javax/tools/ForwardingJavaFileObject.java ! src/share/classes/javax/tools/JavaCompiler.java ! src/share/classes/javax/tools/JavaFileManager.java ! src/share/classes/javax/tools/JavaFileObject.java ! src/share/classes/javax/tools/OptionChecker.java ! src/share/classes/javax/tools/SimpleJavaFileObject.java ! src/share/classes/javax/tools/StandardJavaFileManager.java ! src/share/classes/javax/tools/StandardLocation.java ! src/share/classes/javax/tools/Tool.java ! src/share/classes/javax/tools/ToolProvider.java ! src/share/classes/javax/tools/package-info.java ! src/share/sample/javac/processing/src/CheckNamesProcessor.java ! test/com/sun/javadoc/5093723/DocumentedClass.java ! test/com/sun/javadoc/5093723/T5093723.java ! test/com/sun/javadoc/5093723/UndocumentedClass.java ! test/com/sun/javadoc/AccessAsciiArt/AccessAsciiArt.java ! test/com/sun/javadoc/AccessAsciiArt/p1/C.java ! test/com/sun/javadoc/AccessAsciiArt/p1/I.java ! test/com/sun/javadoc/AccessAsciiArt/p1/SC.java ! test/com/sun/javadoc/AccessAsciiArt/p1/SI.java ! test/com/sun/javadoc/AccessAsciiArt/p1/subpkg/SSC.java ! test/com/sun/javadoc/AccessFrameTitle/AccessFrameTitle.java ! test/com/sun/javadoc/AccessFrameTitle/p1/C1.java ! test/com/sun/javadoc/AccessFrameTitle/p2/C2.java ! test/com/sun/javadoc/AccessH1/AccessH1.java ! test/com/sun/javadoc/AccessH1/p1/C.java ! test/com/sun/javadoc/AccessH1/p2/C2.java ! test/com/sun/javadoc/AccessSkipNav/AccessSkipNav.java ! test/com/sun/javadoc/AccessSkipNav/p1/C1.java ! test/com/sun/javadoc/AccessSkipNav/p2/C2.java ! test/com/sun/javadoc/AccessSummary/AccessSummary.java ! test/com/sun/javadoc/AccessSummary/p1/C1.java ! test/com/sun/javadoc/AccessSummary/p2/C2.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/AuthorDD/p1/C1.java ! test/com/sun/javadoc/DocRootSlash/DocRootSlash.java ! test/com/sun/javadoc/DocRootSlash/p1/C1.java ! test/com/sun/javadoc/DocRootSlash/p2/C2.java ! test/com/sun/javadoc/JavascriptWinTitle/JavascriptWinTitle.java ! test/com/sun/javadoc/JavascriptWinTitle/p1/C.java ! test/com/sun/javadoc/JavascriptWinTitle/p2/C2.java ! test/com/sun/javadoc/MetaTag/MetaTag.java ! test/com/sun/javadoc/MetaTag/p1/C1.java ! test/com/sun/javadoc/MetaTag/p2/C2.java ! test/com/sun/javadoc/PackagesHeader/PackagesHeader.java ! test/com/sun/javadoc/PackagesHeader/p1/C1.java ! test/com/sun/javadoc/PackagesHeader/p2/C2.java ! test/com/sun/javadoc/ValidHtml/ValidHtml.java ! test/com/sun/javadoc/ValidHtml/p1/C.java ! test/com/sun/javadoc/ValidHtml/p2/C2.java ! test/com/sun/javadoc/VersionNumber/VersionNumber.java ! test/com/sun/javadoc/VersionNumber/p1/C.java ! test/com/sun/javadoc/WindowTitles/WindowTitles.java ! test/com/sun/javadoc/WindowTitles/p1/C1.java ! test/com/sun/javadoc/WindowTitles/p2/C2.java ! test/com/sun/javadoc/_template/Template.java ! test/com/sun/javadoc/_template/TemplateComplete.java ! test/com/sun/javadoc/constantValues/A.java ! test/com/sun/javadoc/constantValues/TestConstantValues.java ! test/com/sun/javadoc/constantValues/TestConstantValues2.java ! test/com/sun/javadoc/constantValues/TestConstantValuesDriver.java ! test/com/sun/javadoc/dupThrowsTags/TestDupThrowsTags.java ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testAbsLinkPath/TestAbsLinkPath.java ! test/com/sun/javadoc/testAbsLinkPath/pkg1/C1.java ! test/com/sun/javadoc/testAbsLinkPath/pkg2/C2.java ! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java ! test/com/sun/javadoc/testAnnotationTypes/pkg/AnnotationType.java ! test/com/sun/javadoc/testBackSlashInLink/TestBackSlashInLink.java ! test/com/sun/javadoc/testBadPackageFileInJar/TestBadPackageFileInJar.java ! test/com/sun/javadoc/testBadPackageFileInJar/pkg/C.java ! test/com/sun/javadoc/testBadSourceFile/C1.java ! test/com/sun/javadoc/testBadSourceFile/C2.java ! test/com/sun/javadoc/testBadSourceFile/TestBadSourceFile.java ! test/com/sun/javadoc/testBaseClass/Bar.java ! test/com/sun/javadoc/testBaseClass/BaseClass.java ! test/com/sun/javadoc/testBaseClass/TestBaseClass.java ! test/com/sun/javadoc/testBaseClass/baz/Foo.java ! test/com/sun/javadoc/testBreakIterator/TestBreakIterator.java ! test/com/sun/javadoc/testBreakIterator/pkg/BreakIteratorTest.java ! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java ! test/com/sun/javadoc/testCRLineSeparator/pkg/MyClass.java ! test/com/sun/javadoc/testClassCrossReferences/C.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testClassTree/TestClassTree.java ! test/com/sun/javadoc/testClassTree/pkg/AnnotationType.java ! test/com/sun/javadoc/testClassTree/pkg/ChildClass.java ! test/com/sun/javadoc/testClassTree/pkg/Coin.java ! test/com/sun/javadoc/testClassTree/pkg/ParentClass.java ! test/com/sun/javadoc/testCmndLineClass/C5.java ! test/com/sun/javadoc/testCmndLineClass/TestCmndLineClass.java ! test/com/sun/javadoc/testCmndLineClass/pkg1/C1.java ! test/com/sun/javadoc/testCmndLineClass/pkg1/C2.java ! test/com/sun/javadoc/testCmndLineClass/pkg2/C3.java ! test/com/sun/javadoc/testCmndLineClass/pkg2/C4.java ! test/com/sun/javadoc/testConstantValuesPage/TestConstantValuesPage.java ! test/com/sun/javadoc/testConstructorIndent/C.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testDeprecatedDocs/pkg/DeprecatedClassByAnnotation.java ! test/com/sun/javadoc/testDeprecatedDocs/pkg/TestAnnotationType.java ! test/com/sun/javadoc/testDeprecatedDocs/pkg/TestClass.java ! test/com/sun/javadoc/testDeprecatedDocs/pkg/TestEnum.java ! test/com/sun/javadoc/testDeprecatedDocs/pkg/TestError.java ! test/com/sun/javadoc/testDeprecatedDocs/pkg/TestException.java ! test/com/sun/javadoc/testDeprecatedDocs/pkg/TestInterface.java ! test/com/sun/javadoc/testDocErrorReporter/TestDocErrorReporter.java ! test/com/sun/javadoc/testDocFileDir/TestDocFileDir.java ! test/com/sun/javadoc/testDocFileDir/pkg/C.java ! test/com/sun/javadoc/testDocRootInlineTag/TestDocRootInlineTag.java ! test/com/sun/javadoc/testDocRootInlineTag/TestDocRootTag.java ! test/com/sun/javadoc/testDocRootInlineTag/pkg/C.java ! test/com/sun/javadoc/testDupParamWarn/TestDupParamWarn.java ! test/com/sun/javadoc/testDupParamWarn/pkg/Bar.java ! test/com/sun/javadoc/testDupParamWarn/pkg/Foo.java ! test/com/sun/javadoc/testEmptyClass/TestEmptyClass.java ! test/com/sun/javadoc/testEmptyClass/src/Empty.java ! test/com/sun/javadoc/testEnclosingClass/TestEnclosingClass.java ! test/com/sun/javadoc/testEnclosingClass/pkg/MyClass.java ! test/com/sun/javadoc/testEncoding/EncodeTest.java ! test/com/sun/javadoc/testEncoding/TestEncoding.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testExternalOverridenMethod/pkg/XReader.java ! test/com/sun/javadoc/testGroupOption/TestGroupOption.java ! test/com/sun/javadoc/testGroupOption/pkg1/C.java ! test/com/sun/javadoc/testGroupOption/pkg2/C.java ! test/com/sun/javadoc/testGroupOption/pkg3/C.java ! test/com/sun/javadoc/testHeadings/TestHeadings.java ! test/com/sun/javadoc/testHeadings/pkg1/C1.java ! test/com/sun/javadoc/testHeadings/pkg2/C2.java ! test/com/sun/javadoc/testHelpOption/TestHelpOption.java ! test/com/sun/javadoc/testHiddenMembers/TestHiddenMembers.java ! test/com/sun/javadoc/testHiddenMembers/pkg/BaseClass.java ! test/com/sun/javadoc/testHiddenMembers/pkg/SubClass.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHref/pkg/C1.java ! test/com/sun/javadoc/testHref/pkg/C2.java ! test/com/sun/javadoc/testHref/pkg/C3.java ! test/com/sun/javadoc/testHref/pkg/C4.java ! test/com/sun/javadoc/testHrefInDocComment/TestHrefInDocComment.java ! test/com/sun/javadoc/testHrefInDocComment/pkg/I1.java ! test/com/sun/javadoc/testHrefInDocComment/pkg/I2.java ! test/com/sun/javadoc/testHtmlComments/C.java ! test/com/sun/javadoc/testHtmlComments/TestHtmlComments.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C1.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C2.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C3.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C4.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C5.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/package-info.java ! test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java ! test/com/sun/javadoc/testHtmlStrongTag/pkg1/C1.java ! test/com/sun/javadoc/testHtmlStrongTag/pkg2/C2.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java ! test/com/sun/javadoc/testHtmlTableTags/pkg1/C1.java ! test/com/sun/javadoc/testHtmlTableTags/pkg1/I1.java ! test/com/sun/javadoc/testHtmlTableTags/pkg1/package-info.java ! test/com/sun/javadoc/testHtmlTableTags/pkg2/C2.java ! test/com/sun/javadoc/testHtmlTableTags/pkg2/C3.java ! test/com/sun/javadoc/testHtmlTableTags/pkg2/C4.java ! test/com/sun/javadoc/testHtmlTableTags/pkg2/package-info.java ! test/com/sun/javadoc/testHtmlTag/TestHtmlTag.java ! test/com/sun/javadoc/testHtmlTag/pkg1/C1.java ! test/com/sun/javadoc/testHtmlTag/pkg2/C2.java ! test/com/sun/javadoc/testIndex/NoPackage.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testIndex/pkg/AnnotationType.java ! test/com/sun/javadoc/testIndex/pkg/C.java ! test/com/sun/javadoc/testIndex/pkg/Coin.java ! test/com/sun/javadoc/testIndex/pkg/Interface.java ! test/com/sun/javadoc/testInlineLinkLabel/TestInlineLinkLabel.java ! test/com/sun/javadoc/testInlineLinkLabel/pkg/C1.java ! test/com/sun/javadoc/testInlineLinkLabel/pkg/C2.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testInterface/pkg/Child.java ! test/com/sun/javadoc/testInterface/pkg/Interface.java ! test/com/sun/javadoc/testInterface/pkg/Parent.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java ! test/com/sun/javadoc/testJavascript/pkg/C.java ! test/com/sun/javadoc/testLeadingSpaces/LeadingSpaces.java ! test/com/sun/javadoc/testLegacyTaglet/C.java ! test/com/sun/javadoc/testLegacyTaglet/TestLegacyTaglet.java ! test/com/sun/javadoc/testLegacyTaglet/ToDoTaglet.java ! test/com/sun/javadoc/testLegacyTaglet/UnderlineTaglet.java ! test/com/sun/javadoc/testLinkOption/TestBadLinkOption.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testLinkOption/TestNewLineInLink.java ! test/com/sun/javadoc/testLinkOption/java/lang/StringBuilderChild.java ! test/com/sun/javadoc/testLinkOption/pkg/C.java ! test/com/sun/javadoc/testLinkOption/pkg2/C2.java ! test/com/sun/javadoc/testLinkOption/testNewLineInLink/C.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testLinkTaglet/checkPkg/A.java ! test/com/sun/javadoc/testLinkTaglet/checkPkg/B.java ! test/com/sun/javadoc/testLinkTaglet/pkg/C.java ! test/com/sun/javadoc/testLinkToSerialForm/TestLinkToSerialForm.java ! test/com/sun/javadoc/testLinkToSerialForm/pkg/C.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberInheritence/diamond/A.java ! test/com/sun/javadoc/testMemberInheritence/diamond/B.java ! test/com/sun/javadoc/testMemberInheritence/diamond/C.java ! test/com/sun/javadoc/testMemberInheritence/diamond/X.java ! test/com/sun/javadoc/testMemberInheritence/diamond/Z.java ! test/com/sun/javadoc/testMemberInheritence/inheritDist/A.java ! test/com/sun/javadoc/testMemberInheritence/inheritDist/B.java ! test/com/sun/javadoc/testMemberInheritence/inheritDist/C.java ! test/com/sun/javadoc/testMemberInheritence/pkg/BaseClass.java ! test/com/sun/javadoc/testMemberInheritence/pkg/BaseInterface.java ! test/com/sun/javadoc/testMemberInheritence/pkg/SubClass.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testMemberSummary/pkg/PrivateParent.java ! test/com/sun/javadoc/testMemberSummary/pkg/PublicChild.java ! test/com/sun/javadoc/testMemberSummary/pkg2/A.java ! test/com/sun/javadoc/testModifier/Interface.java ! test/com/sun/javadoc/testModifier/ModifierAbstract.java ! test/com/sun/javadoc/testModifier/Test.java ! test/com/sun/javadoc/testModifier/TestModifier.java ! test/com/sun/javadoc/testNavagation/TestNavagation.java ! test/com/sun/javadoc/testNavagation/pkg/A.java ! test/com/sun/javadoc/testNavagation/pkg/C.java ! test/com/sun/javadoc/testNavagation/pkg/E.java ! test/com/sun/javadoc/testNavagation/pkg/I.java ! test/com/sun/javadoc/testNestedInlineTag/TestNestedInlineTag.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/BoldTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/GreenTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/UnderlineTaglet.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/AnnotationType.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/AnnotationTypeUndocumented.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/AnnotationTypeUsage.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/Coin.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/MultiTypeParameters.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/SubInterface.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/SuperInterface.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/TypeParameterSubClass.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/TypeParameterSuperClass.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/TypeParameters.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/VarArgs.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/Wildcards.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg/package-info.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg1/A.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg1/B.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg2/ClassUseTest1.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg2/ClassUseTest2.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg2/ClassUseTest3.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg2/Foo.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg2/Foo2.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg2/Foo3.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg2/Foo4.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg2/ParamTest.java ! test/com/sun/javadoc/testNewLanguageFeatures/pkg2/ParamTest2.java ! test/com/sun/javadoc/testNoPackagesFile/C.java ! test/com/sun/javadoc/testNoPackagesFile/TestNoPackagesFile.java ! test/com/sun/javadoc/testNotifications/TestNotifications.java ! test/com/sun/javadoc/testNotifications/pkg/C.java ! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testOverridenMethods/pkg1/BaseClass.java ! test/com/sun/javadoc/testOverridenMethods/pkg1/SubClass.java ! test/com/sun/javadoc/testOverridenMethods/pkg2/SubClass.java ! test/com/sun/javadoc/testOverridenMethods/pkg3/I0.java ! test/com/sun/javadoc/testOverridenMethods/pkg3/I1.java ! test/com/sun/javadoc/testOverridenMethods/pkg3/I2.java ! test/com/sun/javadoc/testOverridenMethods/pkg3/I3.java ! test/com/sun/javadoc/testOverridenMethods/pkg3/I4.java ! test/com/sun/javadoc/testPackagePage/TestPackagePage.java ! test/com/sun/javadoc/testPackagePage/com/pkg/C.java ! test/com/sun/javadoc/testPackagePage/pkg2/C.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testParamTaglet/pkg/C.java ! test/com/sun/javadoc/testParamTaglet/pkg/Parent.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testPrivateClasses/pkg/PrivateInterface.java ! test/com/sun/javadoc/testPrivateClasses/pkg/PrivateParent.java ! test/com/sun/javadoc/testPrivateClasses/pkg/PublicChild.java ! test/com/sun/javadoc/testPrivateClasses/pkg/PublicInterface.java ! test/com/sun/javadoc/testPrivateClasses/pkg2/C.java ! test/com/sun/javadoc/testPrivateClasses/pkg2/I.java ! test/com/sun/javadoc/testRecurseSubPackages/TestRecurseSubPackages.java ! test/com/sun/javadoc/testRecurseSubPackages/pkg1/C1.java ! test/com/sun/javadoc/testRecurseSubPackages/pkg1/C2.java ! test/com/sun/javadoc/testRecurseSubPackages/pkg1/pkg2/C3.java ! test/com/sun/javadoc/testRecurseSubPackages/pkg1/pkg2/C4.java ! test/com/sun/javadoc/testRecurseSubPackages/pkg1/pkg2/packageToExclude/DummyClass.java ! test/com/sun/javadoc/testRecurseSubPackages/pkg1/pkg2/pkg3/C5.java ! test/com/sun/javadoc/testRecurseSubPackages/pkg1/pkg2/pkg3/C6.java ! test/com/sun/javadoc/testRelativeLinks/TestRelativeLinks.java ! test/com/sun/javadoc/testRelativeLinks/pkg/C.java ! test/com/sun/javadoc/testRelativeLinks/pkg2/Foo.java ! test/com/sun/javadoc/testReturnTag/TestReturnTag.java ! test/com/sun/javadoc/testSerialVersionUID/C.java ! test/com/sun/javadoc/testSerialVersionUID/TestSerialVersionUID.java ! test/com/sun/javadoc/testSerializedForm/TestSerializedForm.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/pkg1/C1.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/pkg1/C2.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/pkg1/C3.java ! test/com/sun/javadoc/testSimpleTag/C.java ! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java ! test/com/sun/javadoc/testSimpleTagExclude/DummyClass.java ! test/com/sun/javadoc/testSimpleTagExclude/TestSimpleTagExclude.java ! test/com/sun/javadoc/testSourceTab/DoubleTab/C.java ! test/com/sun/javadoc/testSourceTab/SingleTab/C.java ! test/com/sun/javadoc/testSourceTab/TestSourceTab.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java ! test/com/sun/javadoc/testStylesheet/pkg/A.java ! test/com/sun/javadoc/testSummaryHeading/C.java ! test/com/sun/javadoc/testSummaryHeading/TestSummaryHeading.java ! test/com/sun/javadoc/testSuperclassInSerialForm/TestSuperClassInSerialForm.java ! test/com/sun/javadoc/testSuperclassInSerialForm/pkg/SubClass.java ! test/com/sun/javadoc/testSuperclassInSerialForm/pkg/SuperClass.java ! test/com/sun/javadoc/testSupplementary/TestSupplementary.java ! test/com/sun/javadoc/testTagHolderMethod/TestTagHolderMethod.java ! test/com/sun/javadoc/testTagHolderMethod/pkg/C.java ! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java ! test/com/sun/javadoc/testTagInheritence/firstSentence/A.java ! test/com/sun/javadoc/testTagInheritence/firstSentence/B.java ! test/com/sun/javadoc/testTagInheritence/firstSentence2/A.java ! test/com/sun/javadoc/testTagInheritence/firstSentence2/B.java ! test/com/sun/javadoc/testTagInheritence/firstSentence2/C.java ! test/com/sun/javadoc/testTagInheritence/pkg/TestAbstractClass.java ! test/com/sun/javadoc/testTagInheritence/pkg/TestInterface.java ! test/com/sun/javadoc/testTagInheritence/pkg/TestInterfaceForAbstractClass.java ! test/com/sun/javadoc/testTagInheritence/pkg/TestSuperSuperClass.java ! test/com/sun/javadoc/testTagInheritence/pkg/TestSuperSuperInterface.java ! test/com/sun/javadoc/testTagInheritence/pkg/TestTagInheritence.java ! test/com/sun/javadoc/testTagMisuse/TestTagMisuse.java ! test/com/sun/javadoc/testTaglets/C.java ! test/com/sun/javadoc/testTaglets/Child.java ! test/com/sun/javadoc/testTaglets/Parent.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java ! test/com/sun/javadoc/testThrowsHead/C.java ! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java ! test/com/sun/javadoc/testThrowsInheritence/C.java ! test/com/sun/javadoc/testThrowsInheritence/Foo.java ! test/com/sun/javadoc/testThrowsInheritence/I.java ! test/com/sun/javadoc/testThrowsInheritence/Iface.java ! test/com/sun/javadoc/testThrowsInheritence/TestThrowsTagInheritence.java ! test/com/sun/javadoc/testThrowsTag/TestThrowsTag.java ! test/com/sun/javadoc/testThrowsTag/pkg/C.java ! test/com/sun/javadoc/testThrowsTag/pkg/P.java ! test/com/sun/javadoc/testThrowsTag/pkg/T1.java ! test/com/sun/javadoc/testThrowsTag/pkg/T2.java ! test/com/sun/javadoc/testThrowsTag/pkg/T3.java ! test/com/sun/javadoc/testThrowsTag/pkg/T4.java ! test/com/sun/javadoc/testThrowsTag/pkg/T5.java ! test/com/sun/javadoc/testThrowsTag/pkg/T6.java ! test/com/sun/javadoc/testThrowsTag/pkg/T7.java ! test/com/sun/javadoc/testThrowsTag/pkg/T8.java ! test/com/sun/javadoc/testTitleInHref/TestTitleInHref.java ! test/com/sun/javadoc/testTitleInHref/pkg/Class.java ! test/com/sun/javadoc/testTitleInHref/pkg/Interface.java ! test/com/sun/javadoc/testTitleInHref/pkg/Links.java ! test/com/sun/javadoc/testTopOption/TestTopOption.java ! test/com/sun/javadoc/testTopOption/pkg/AnnotationType.java ! test/com/sun/javadoc/testTopOption/pkg/Cl.java ! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java ! test/com/sun/javadoc/testTypeParams/pkg/C.java ! test/com/sun/javadoc/testTypeParams/pkg/Parent.java ! test/com/sun/javadoc/testUnnamedPackage/BadSource.java ! test/com/sun/javadoc/testUnnamedPackage/C.java ! test/com/sun/javadoc/testUnnamedPackage/TestUnnamedPackage.java ! test/com/sun/javadoc/testUseOption/TestUseOption.java ! test/com/sun/javadoc/testUseOption/pkg1/C1.java ! test/com/sun/javadoc/testUseOption/pkg1/C2.java ! test/com/sun/javadoc/testUseOption/pkg1/C4.java ! test/com/sun/javadoc/testUseOption/pkg1/C5.java ! test/com/sun/javadoc/testUseOption/pkg1/C6.java ! test/com/sun/javadoc/testUseOption/pkg1/C7.java ! test/com/sun/javadoc/testUseOption/pkg1/C8.java ! test/com/sun/javadoc/testUseOption/pkg1/UsedClass.java ! test/com/sun/javadoc/testUseOption/pkg2/C3.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java ! test/com/sun/javadoc/testValueTag/pkg1/Class1.java ! test/com/sun/javadoc/testValueTag/pkg1/Class2.java ! test/com/sun/javadoc/testValueTag/pkg1/CustomTagUsage.java ! test/com/sun/javadoc/testValueTag/pkg2/Class3.java ! test/com/sun/javadoc/testWarnBadParamNames/C.java ! test/com/sun/javadoc/testWarnBadParamNames/TestWarnBadParamNames.java ! test/com/sun/javadoc/testWarnings/TestWarnings.java ! test/jprt.config ! test/tools/apt/Basics/Aggregate.java ! test/tools/apt/Basics/ClassAnnotations.java ! test/tools/apt/Basics/FreshnessApf.java ! test/tools/apt/Basics/GenClass.java ! test/tools/apt/Basics/Indirect.java ! test/tools/apt/Basics/Lacuna.java ! test/tools/apt/Basics/MethodAnnotations.java ! test/tools/apt/Basics/Milk.java ! test/tools/apt/Basics/MisMatch.java ! test/tools/apt/Basics/Misc.java ! test/tools/apt/Basics/MyMarker.java ! test/tools/apt/Basics/MySimple.java ! test/tools/apt/Basics/NestedClassAnnotations.java ! test/tools/apt/Basics/NullAPF.java ! test/tools/apt/Basics/ParameterAnnotations.java ! test/tools/apt/Basics/StaticFieldAnnotations.java ! test/tools/apt/Basics/StaticMethodAnnotations.java ! test/tools/apt/Basics/TestGetPackageApf.java ! test/tools/apt/Basics/TestGetTypeDeclarationApf.java ! test/tools/apt/Basics/annot/AnnotMarker.java ! test/tools/apt/Basics/annot/AnnotShangri_la.java ! test/tools/apt/Basics/annot/AnnotSimple.java ! test/tools/apt/Basics/annot/annot2/AnnotMarker2.java ! test/tools/apt/Basics/annot/annot2/AnnotSimple2.java ! test/tools/apt/Basics/apt.sh ! test/tools/apt/Basics/foo/bar/Baz.java ! test/tools/apt/Basics/foo/bar/Quux.java ! test/tools/apt/Basics/p1/p2.java ! test/tools/apt/Basics/p1/p2/C1.java ! test/tools/apt/Basics/print.sh ! test/tools/apt/Compile/ClassDeclApf.java ! test/tools/apt/Compile/ClassDeclApf2.java ! test/tools/apt/Compile/Dummy1.java ! test/tools/apt/Compile/ErrorAPF.java ! test/tools/apt/Compile/Round1Apf.java ! test/tools/apt/Compile/Round2Apf.java ! test/tools/apt/Compile/Round3Apf.java ! test/tools/apt/Compile/Round4Apf.java ! test/tools/apt/Compile/Rounds.java ! test/tools/apt/Compile/StaticApf.java ! test/tools/apt/Compile/WarnAPF.java ! test/tools/apt/Compile/WrappedStaticApf.java ! test/tools/apt/Compile/compile.sh ! test/tools/apt/Compile/src/AhOneClass.java ! test/tools/apt/Compile/src/AndAhTwoClass.java ! test/tools/apt/Compile/src/Round1Class.java ! test/tools/apt/Discovery/Dee.java ! test/tools/apt/Discovery/Dum.java ! test/tools/apt/Discovery/Empty.java ! test/tools/apt/Discovery/PhantomTouch.java ! test/tools/apt/Discovery/PhantomUpdate.java ! test/tools/apt/Discovery/Touch.java ! test/tools/apt/Discovery/discovery.sh ! test/tools/apt/Misc/Marked.java ! test/tools/apt/Misc/Marker.java ! test/tools/apt/Misc/Misc.java ! test/tools/apt/Misc/misc.sh ! test/tools/apt/Options/Marked.java ! test/tools/apt/Options/Marker.java ! test/tools/apt/Options/OptionChecker.java ! test/tools/apt/Options/options.sh ! test/tools/apt/Scanners/Counter.java ! test/tools/apt/Scanners/MemberOrderApf.java ! test/tools/apt/Scanners/Order.java ! test/tools/apt/Scanners/Scanner.java ! test/tools/apt/Scanners/TestEnum.java ! test/tools/apt/Scanners/VisitOrder.java ! test/tools/apt/Scanners/scanner.sh ! test/tools/apt/lib/Ignore.java ! test/tools/apt/lib/Test.java ! test/tools/apt/lib/TestProcessor.java ! test/tools/apt/lib/TestProcessorFactory.java ! test/tools/apt/lib/Tester.java ! test/tools/apt/mirror/declaration/AnnoMirror.java ! test/tools/apt/mirror/declaration/AnnoTypeDecl.java ! test/tools/apt/mirror/declaration/AnnoTypeElemDecl.java ! test/tools/apt/mirror/declaration/AnnoVal.java ! test/tools/apt/mirror/declaration/ClassDecl.java ! test/tools/apt/mirror/declaration/ConstExpr.java ! test/tools/apt/mirror/declaration/ConstructorDecl.java ! test/tools/apt/mirror/declaration/EnumDecl.java ! test/tools/apt/mirror/declaration/FieldDecl.java ! test/tools/apt/mirror/declaration/GetAnno.java ! test/tools/apt/mirror/declaration/InterfaceDecl.java ! test/tools/apt/mirror/declaration/MethodDecl.java ! test/tools/apt/mirror/declaration/PackageDecl.java ! test/tools/apt/mirror/declaration/ParameterDecl.java ! test/tools/apt/mirror/declaration/pkg1/AClass.java ! test/tools/apt/mirror/declaration/pkg1/AnAnnoType.java ! test/tools/apt/mirror/declaration/pkg1/AnEnum.java ! test/tools/apt/mirror/declaration/pkg1/AnInterface.java ! test/tools/apt/mirror/declaration/pkg1/package-info.java ! test/tools/apt/mirror/declaration/pkg1/pkg2/AnInterface.java ! test/tools/apt/mirror/declaration/pkg1/pkg2/package.html ! test/tools/apt/mirror/type/AnnoTyp.java ! test/tools/apt/mirror/type/ArrayTyp.java ! test/tools/apt/mirror/type/ClassTyp.java ! test/tools/apt/mirror/type/EnumTyp.java ! test/tools/apt/mirror/type/InterfaceTyp.java ! test/tools/apt/mirror/type/PrimitiveTyp.java ! test/tools/apt/mirror/type/TypeVar.java ! test/tools/apt/mirror/type/WildcardTyp.java ! test/tools/apt/mirror/util/Overrides.java ! test/tools/apt/mirror/util/TypeCreation.java ! test/tools/apt/verifyVariables.sh ! test/tools/javac/4241573/T4241573.java ! test/tools/javac/4846262/Test.sh ! test/tools/javac/4980495/static/p1/A1.java ! test/tools/javac/4980495/static/p2/A2.java ! test/tools/javac/4980495/std/p1/A1.java ! test/tools/javac/4980495/std/p2/A2.java ! test/tools/javac/5005368.java ! test/tools/javac/5045412/Bar.java ! test/tools/javac/5045412/Foo.java ! test/tools/javac/6199662/Tree.java ! test/tools/javac/6199662/TreeInfo.java ! test/tools/javac/6199662/TreeScanner.java ! test/tools/javac/6257443/T6257443.java ! test/tools/javac/6257443/package-info.java ! test/tools/javac/6302184/T6302184.java ! test/tools/javac/6302184/T6302184.sh ! test/tools/javac/6304921/TestLog.java ! test/tools/javac/6330997/T1.java ! test/tools/javac/6330997/T2.java ! test/tools/javac/6330997/T6330997.java ! test/tools/javac/6341866/A.java ! test/tools/javac/6341866/Anno.java ! test/tools/javac/6341866/B.java ! test/tools/javac/6341866/T6341866.java ! test/tools/javac/6342411/T6342411.java ! test/tools/javac/6342411/a/Base.java ! test/tools/javac/6342411/a/Pub.java ! test/tools/javac/6390045/T6390045a.java ! test/tools/javac/6390045/T6390045b.java ! test/tools/javac/6394683/A.java ! test/tools/javac/6394683/B.java ! test/tools/javac/6394683/T6394683.java ! test/tools/javac/6400383/T6400383.java ! test/tools/javac/6400872/A.java ! test/tools/javac/6400872/B.java ! test/tools/javac/6400872/C.java ! test/tools/javac/6400872/T6400872.java ! test/tools/javac/6402516/A.java ! test/tools/javac/6402516/CheckClass.java ! test/tools/javac/6402516/CheckIsAccessible.java ! test/tools/javac/6402516/CheckLocalElements.java ! test/tools/javac/6402516/CheckMethod.java ! test/tools/javac/6402516/Checker.java ! test/tools/javac/6402516/TestClass.java ! test/tools/javac/6402516/TestIsAccessible.java ! test/tools/javac/6402516/TestLocalElements.java ! test/tools/javac/6402516/TestMethod.java ! test/tools/javac/6403424/A.java ! test/tools/javac/6403424/B.java ! test/tools/javac/6403424/T6403424.java ! test/tools/javac/6410653/T6410653.java ! test/tools/javac/6440583/A.java ! test/tools/javac/6440583/T6440583.java ! test/tools/javac/6457284/T6457284.java ! test/tools/javac/6464451/BigFinally.java ! test/tools/javac/6464451/DeepNestedFinally.java ! test/tools/javac/6464451/ManyExitsInTry.java ! test/tools/javac/6508981/TestInferBinaryName.java ! test/tools/javac/6508981/p/A.java ! test/tools/javac/6521805/T6521805b.java ! test/tools/javac/6521805/T6521805c.java ! test/tools/javac/6521805/T6521805e.java ! test/tools/javac/6627362/T6627362.java ! test/tools/javac/6627362/x/E.java ! test/tools/javac/6627362/x/Object.java ! test/tools/javac/6668794/badClass/A.java ! test/tools/javac/6668794/badClass/Test.java ! test/tools/javac/6668794/badSource/p/A.java ! test/tools/javac/6734819/T6734819a.java ! test/tools/javac/6734819/T6734819b.java ! test/tools/javac/6835430/A.java ! test/tools/javac/6835430/T6835430.java ! test/tools/javac/6889255/T6889255.java ! test/tools/javac/6902720/E1.java ! test/tools/javac/6902720/E2.java ! test/tools/javac/6902720/Test.java ! test/tools/javac/AbstractOverride.java ! test/tools/javac/AccessMethods/AccessMethodsLHS.java ! test/tools/javac/AccessMethods/BitwiseAssignment.java ! test/tools/javac/AccessMethods/ChainedAssignment.java ! test/tools/javac/AccessMethods/ConstructorAccess.java ! test/tools/javac/AccessMethods/InternalHandshake.java ! test/tools/javac/AccessMethods/LateAddition.java ! test/tools/javac/AccessMethods/UplevelPrivateConstants.java ! test/tools/javac/AddReferenceThis.java ! test/tools/javac/Ambig3.java ! test/tools/javac/AnonClsInIntf.java ! test/tools/javac/AnonInnerException_1.java ! test/tools/javac/AnonInnerException_2.java ! test/tools/javac/AnonInnerException_3.java ! test/tools/javac/AnonStaticMember_1.java ! test/tools/javac/AnonStaticMember_2.java ! test/tools/javac/AnonStaticMember_3.java ! test/tools/javac/AnonymousConstructorExceptions.java ! test/tools/javac/AnonymousNull.java ! test/tools/javac/AnonymousProtect/AnonymousProtect.java ! test/tools/javac/AnonymousProtect/P1/priv.java ! test/tools/javac/AnonymousProtect/P1/pub.java ! test/tools/javac/AnonymousProtect/P1/pubExposePriv.java ! test/tools/javac/AnonymousProtect/P2/usePub.java ! test/tools/javac/AnonymousType.java ! test/tools/javac/ArrayCast.java ! test/tools/javac/ArrayCloneCodeGen.java ! test/tools/javac/BadAnnotation.java ! test/tools/javac/BadBreak.java ! test/tools/javac/BadCovar.java ! test/tools/javac/BadHexConstant.java ! test/tools/javac/BadOptimization/DeadCode1.java ! test/tools/javac/BadOptimization/DeadCode2.java ! test/tools/javac/BadOptimization/DeadCode3.java ! test/tools/javac/BadOptimization/DeadCode4.java ! test/tools/javac/BadOptimization/DeadCode5.java ! test/tools/javac/BadOptimization/DeadCode6.java ! test/tools/javac/BadOptimization/Switch1.java ! test/tools/javac/BadOptimization/Switch2.java ! test/tools/javac/BoolArray.java ! test/tools/javac/BoundClassError.java ! test/tools/javac/BreakAcrossClass.java ! test/tools/javac/Capture.java ! test/tools/javac/CaptureInSubtype.java ! test/tools/javac/CascadedInnerNewInstance.java ! test/tools/javac/CastInterface2Array.java ! test/tools/javac/ClassCycle/ClassCycle1a.java ! test/tools/javac/ClassCycle/ClassCycle1b.java ! test/tools/javac/ClassCycle/ClassCycle2a.java ! test/tools/javac/ClassCycle/ClassCycle2b.java ! test/tools/javac/ClassCycle/ClassCycle3a.java ! test/tools/javac/ClassCycle/ClassCycle3b.java ! test/tools/javac/ClassFileModifiers/ClassModifiers.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java ! test/tools/javac/ClassIsAbstract.java ! test/tools/javac/ClassLit.java ! test/tools/javac/ClassLiterals/ClassLiteralHelperContext.java ! test/tools/javac/ClassLiterals/InitializeOuter.java ! test/tools/javac/ClassLiterals/InitializeTarget.java ! test/tools/javac/ClassLiterals/InnerClassLiterals.java ! test/tools/javac/ClassLiterals/LiteralInterfaceImpl.java ! test/tools/javac/ClassLiterals/LiteralInterface_1.java ! test/tools/javac/ClassLiterals/LiteralInterface_2.java ! test/tools/javac/ClassLiterals/LiteralInterface_3.java ! test/tools/javac/ClassLiterals/evalinit/ClassLiteralEvalInit.java ! test/tools/javac/ClassLiterals/evalinit/java/lang/Integer.java ! test/tools/javac/ClassLiterals/p1/C.java ! test/tools/javac/ClassLiterals/p1/SuperClass.java ! test/tools/javac/ClassModifiers/InterfaceAndInnerClsCtor.java ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ClassPathTest/ClassPathTest1.java ! test/tools/javac/ClassPathTest/ClassPathTest2.java ! test/tools/javac/ClassPathTest/ClassPathTest3.java ! test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java ! test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java ! test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java ! test/tools/javac/ClassToTypeParm.java ! test/tools/javac/CloneableProblem.java ! test/tools/javac/Closure1.java ! test/tools/javac/Closure2.java ! test/tools/javac/Closure3.java ! test/tools/javac/Closure4.java ! test/tools/javac/Closure5.java ! test/tools/javac/Closure6.java ! test/tools/javac/CompoundBox.java ! test/tools/javac/ConditionalArgTypes_1.java ! test/tools/javac/ConditionalArgTypes_2.java ! test/tools/javac/ConditionalClass.java ! test/tools/javac/ConditionalInline.java ! test/tools/javac/ConditionalWithVoid.java ! test/tools/javac/ConstBoolAppend.java ! test/tools/javac/ConstCharAppend.java ! test/tools/javac/ConstantValues/ConstValInit.java ! test/tools/javac/ConstantValues/ConstValInlining.java ! test/tools/javac/ConstantValues/test_ff1.java ! test/tools/javac/ConstantValues/test_ff2.java ! test/tools/javac/CyclicInheritance2.java ! test/tools/javac/CyclicInheritance4.java ! test/tools/javac/CyclicInheritance6/Main.java ! test/tools/javac/CyclicInheritance6/p1/A.java ! test/tools/javac/CyclicInheritance6/p1/B.java ! test/tools/javac/CyclicInheritance6/p1/C.java ! test/tools/javac/CyclicScoping/CyclicScoping_1.java ! test/tools/javac/CyclicScoping/CyclicScoping_2.java ! test/tools/javac/DeadInnerClass.java ! test/tools/javac/DeclarationStatementInline.java ! test/tools/javac/DeepStringConcat.java ! test/tools/javac/DefiniteAssignment/ConstantInfiniteWhile.java ! test/tools/javac/DefiniteAssignment/DABlock.java ! test/tools/javac/DefiniteAssignment/DALoop1.java ! test/tools/javac/DefiniteAssignment/DASwitch.java ! test/tools/javac/DefiniteAssignment/DUAssert.java ! test/tools/javac/DefiniteAssignment/DUBeforeDefined1.java ! test/tools/javac/DefiniteAssignment/DUBeforeDefined2.java ! test/tools/javac/DefiniteAssignment/DUParam1.java ! test/tools/javac/DefiniteAssignment/DUParam2.java ! test/tools/javac/DefiniteAssignment/DUSwitch.java ! test/tools/javac/DefiniteAssignment/DUSwitch2.java ! test/tools/javac/DefiniteAssignment/DUTry.java ! test/tools/javac/DefiniteAssignment/DefAssignAfterIf_1.java ! test/tools/javac/DefiniteAssignment/DefAssignAfterIf_2.java ! test/tools/javac/DefiniteAssignment/DefAssignAfterThis_1.java ! test/tools/javac/DefiniteAssignment/DefAssignAfterThis_2.java ! test/tools/javac/DefiniteAssignment/DefAssignAfterTry1.java ! test/tools/javac/DefiniteAssignment/DefAssignAfterTry2.java ! test/tools/javac/DefiniteAssignment/DefAssignAfterTry3.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_1.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_10.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_11.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_12.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_13.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_14.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_15.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_16.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_2.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_3.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_4.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_5.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_6.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_7.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_8.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignBoolean_9.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignCond.java ! test/tools/javac/DefiniteAssignment/DefAssignBoolean/DefAssignConstantBoolean.java ! test/tools/javac/DefiniteAssignment/DefAssignNestedArg.java ! test/tools/javac/DefiniteAssignment/T4704365.java ! test/tools/javac/DefiniteAssignment/T4717164.java ! test/tools/javac/DefiniteAssignment/T4717165.java ! test/tools/javac/DefiniteAssignment/T4718134.java ! test/tools/javac/DefiniteAssignment/T4718142.java ! test/tools/javac/DefiniteAssignment/T4718142a.java ! test/tools/javac/DefiniteAssignment/T4718708.java ! test/tools/javac/DefiniteAssignment/T4720379.java ! test/tools/javac/DefiniteAssignment/T4720751.java ! test/tools/javac/DefiniteAssignment/T4721062a.java ! test/tools/javac/DefiniteAssignment/T4721062b.java ! test/tools/javac/DefiniteAssignment/T4721076.java ! test/tools/javac/DefiniteAssignment/T4721998.java ! test/tools/javac/DefiniteAssignment/T4725725.java ! test/tools/javac/DefiniteAssignment/ThrowBeforeTryFinally.java ! test/tools/javac/DefiniteAssignment/UncaughtException.java ! test/tools/javac/DepParam.java ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/DivByZero.java ! test/tools/javac/DuplicateClass.java ! test/tools/javac/DuplicateClass2.java ! test/tools/javac/DuplicateImport.java ! test/tools/javac/EOI.java ! test/tools/javac/EarlyAssert.java ! test/tools/javac/EarlyAssertWrapper.java ! test/tools/javac/EmptyArray.java ! test/tools/javac/EmptyBreak.java ! test/tools/javac/EmptyDocComments.java ! test/tools/javac/EmptySwitch.java ! test/tools/javac/EnclosingAccessCheck.java ! test/tools/javac/Enum1.java ! test/tools/javac/ExceptionalFinally.java ! test/tools/javac/ExceptionalFinally2.java ! test/tools/javac/ExprQualifiedType.java ! test/tools/javac/ExtDirs/ExtDirTest_1.java ! test/tools/javac/ExtDirs/ExtDirTest_2.java ! test/tools/javac/ExtDirs/ExtDirTest_3.java ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/ExtendsAccess/p/ExtendsAccess.java ! test/tools/javac/ExtendsScope.java ! test/tools/javac/ExtraneousEquals.java ! test/tools/javac/FaultySignature.java ! test/tools/javac/FinalInitializer.java ! test/tools/javac/FinalInitializer_2.java ! test/tools/javac/FinalIntConcatenation.java ! test/tools/javac/FinalThisReference.java ! test/tools/javac/FinallyWarn.java ! test/tools/javac/FlatnameClash.java ! test/tools/javac/FlatnameClash2.java ! test/tools/javac/FloatingPointChanges/Test.java ! test/tools/javac/FoldConditional.java ! test/tools/javac/ForwardReference/ForwardReference_2.java ! test/tools/javac/ForwardReference/ForwardReference_4.java ! test/tools/javac/ForwardReference/ForwardReference_5.java ! test/tools/javac/ForwardReference/T6676362a.java ! test/tools/javac/ForwardReference/T6676362b.java ! test/tools/javac/ForwardReference/UseBeforeDeclaration.java ! test/tools/javac/GoodCovar.java ! test/tools/javac/HexFloatLiterals.java ! test/tools/javac/HexThree.java ! test/tools/javac/HiddenAbstractMethod/one/Parent.java ! test/tools/javac/HiddenAbstractMethod/two/Child.java ! test/tools/javac/IllDefinedOrderOfInit.java ! test/tools/javac/IllegallyOptimizedException.java ! test/tools/javac/ImplicitToString.java ! test/tools/javac/ImportCycle/Dummy.java ! test/tools/javac/ImportCycle/foo/Bottom.java ! test/tools/javac/ImportCycle/foo/Bottom2.java ! test/tools/javac/ImportCycle/foo/Middle.java ! test/tools/javac/ImportCycle/foo/Middle2.java ! test/tools/javac/ImportCycle/foo/Top.java ! test/tools/javac/ImportCycle/foo/Top2.java ! test/tools/javac/ImportPackagePrivateInner/Dummy.java ! test/tools/javac/ImportPackagePrivateInner/foo/Accessee.java ! test/tools/javac/ImportPackagePrivateInner/foo/Accessor.java ! test/tools/javac/ImportUnnamed/Dummy.java ! test/tools/javac/ImportUnnamed/foo/A.java ! test/tools/javac/InconsistentInheritedSignature.java ! test/tools/javac/InconsistentStack.java ! test/tools/javac/Increment.java ! test/tools/javac/InheritedPrivateImpl.java ! test/tools/javac/InitializerCompletion_1.java ! test/tools/javac/InitializerCompletion_2.java ! test/tools/javac/InitializerCompletion_3.java ! test/tools/javac/InitializerCompletion_4.java ! test/tools/javac/InnerClassesAttribute/Test.java ! test/tools/javac/InnerMemberRegression.java ! test/tools/javac/InnerMethSig.java ! test/tools/javac/InnerNamedConstant_1.java ! test/tools/javac/InnerTruth.java ! test/tools/javac/InstanceInitException_1.java ! test/tools/javac/InstanceInitException_2.java ! test/tools/javac/InterfaceAssert.java ! test/tools/javac/InterfaceFieldParsing_1.java ! test/tools/javac/InterfaceInInner.java ! test/tools/javac/InterfaceObjectIncompatibility.java ! test/tools/javac/InterfaceObjectInheritance.java ! test/tools/javac/InterfaceOverrideCheck.java ! test/tools/javac/InterfaceOverrideFinal.java ! test/tools/javac/InterfaceOverrideObject.java ! test/tools/javac/InvalidIntfCast.java ! test/tools/javac/JsrRet.java ! test/tools/javac/LabelHiding_1.java ! test/tools/javac/LabeledDeclaration.java ! test/tools/javac/LocalClasses_1.java ! test/tools/javac/ManyMembers2.java ! test/tools/javac/MemberTypeInheritance.java ! test/tools/javac/MissingInclude.java ! test/tools/javac/MissingInclude.sh ! test/tools/javac/NameClash/One.java ! test/tools/javac/NameClash/a/One.java ! test/tools/javac/NameClash/b/One.java ! test/tools/javac/NameCollision2.java ! test/tools/javac/NestedDuplicateLabels.java ! test/tools/javac/NestedFinallyReturn.java ! test/tools/javac/NewGeneric.java ! test/tools/javac/NoClass.java ! test/tools/javac/NoNoClassDefFoundErrorError.java ! test/tools/javac/NonAmbiguousField/one/Parent.java ! test/tools/javac/NonAmbiguousField/one/Parent2.java ! test/tools/javac/NonAmbiguousField/two/Child.java ! test/tools/javac/NonAmbiguousField/two/Child2.java ! test/tools/javac/NonStaticFieldExpr4c.java ! test/tools/javac/NonStaticFieldExpr4d.java ! test/tools/javac/NonStaticFinalVar.java ! test/tools/javac/Null2DArray.java ! test/tools/javac/NullQualifiedNew.java ! test/tools/javac/NullQualifiedNew2.java ! test/tools/javac/NullQualifiedSuper1.java ! test/tools/javac/NullQualifiedSuper2.java ! test/tools/javac/NullStaticQualifier.java ! test/tools/javac/Object1.java ! test/tools/javac/Object2.java ! test/tools/javac/ObjectIncompatibleInterface.java ! test/tools/javac/ObjectMethodRefFromInterface.java ! test/tools/javac/OuterParameter_1.java ! test/tools/javac/OverrideChecks/6400189/T6400189c.java ! test/tools/javac/OverrideChecks/6400189/T6400189d.java ! test/tools/javac/OverrideChecks/6738538/T6738538a.java ! test/tools/javac/OverrideChecks/6738538/T6738538b.java ! test/tools/javac/OverrideChecks/InconsistentReturn.java ! test/tools/javac/OverrideChecks/InterfaceImplements.java ! test/tools/javac/OverrideChecks/InterfaceOverride.java ! test/tools/javac/OverrideChecks/Private.java ! test/tools/javac/OverrideChecks/StaticOverride.java ! test/tools/javac/OverrideChecks/T4720356a.java ! test/tools/javac/OverrideChecks/T4720356b.java ! test/tools/javac/OverrideChecks/T4720359a.java ! test/tools/javac/OverrideChecks/T4720359b.java ! test/tools/javac/OverrideChecks/T4721069.java ! test/tools/javac/OverrideChecks/T6326485.java ! test/tools/javac/OverrideChecks/T6399361.java ! test/tools/javac/OverrideChecks/ThrowsConflict.java ! test/tools/javac/PackageClassAmbiguity/Bad.java ! test/tools/javac/PackageClassAmbiguity/util.java ! test/tools/javac/PackageClassClash/PackageClassClash.java ! test/tools/javac/Parens1.java ! test/tools/javac/Parens2.java ! test/tools/javac/Parens3.java ! test/tools/javac/Parens4.java ! test/tools/javac/ParseConditional.java ! test/tools/javac/Paths/6638501/HelloLib/test/HelloImpl.java ! test/tools/javac/Paths/6638501/JarFromManifestFailure.java ! test/tools/javac/Paths/6638501/WsCompileExample.java ! test/tools/javac/Paths/6638501/test/SayHello.java ! test/tools/javac/Paths/6638501/test1/SayHelloToo.java ! test/tools/javac/Paths/Class-Path.sh ! test/tools/javac/Paths/CompileClose.java ! test/tools/javac/Paths/Diagnostics.sh ! test/tools/javac/Paths/Help.sh ! test/tools/javac/Paths/MineField.sh ! test/tools/javac/Paths/SameJVM.java ! test/tools/javac/Paths/Util.sh ! test/tools/javac/Paths/wcMineField.sh ! test/tools/javac/PrivateLocalConstructor.java ! test/tools/javac/PrivateUplevelConstant.java ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java ! test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java ! test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java ! test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_4.java ! test/tools/javac/QualifiedAccess/pack1/P1.java ! test/tools/javac/QualifiedAccess/pack1/P2.java ! test/tools/javac/QualifiedConstant.java ! test/tools/javac/QualifiedNew.java ! test/tools/javac/QualifiedNewScope.java ! test/tools/javac/QualifiedOuterThis.java ! test/tools/javac/QualifiedOuterThis2.java ! test/tools/javac/QualifiedThisAndSuper_1.java ! test/tools/javac/QualifiedThisAndSuper_2.java ! test/tools/javac/QualifiedThisAndSuper_3.java ! test/tools/javac/QualifiedThisExactMatch.java ! test/tools/javac/RawCrash.java ! test/tools/javac/ReturnAfterIfThenElse.java ! test/tools/javac/SerialWarn.java ! test/tools/javac/ShiftExpressionTest.java ! test/tools/javac/Source5.java ! test/tools/javac/StandaloneQualifiedSuper.java ! test/tools/javac/StaticBlockScope.java ! test/tools/javac/StoreClass.java ! test/tools/javac/StrictAbstract.java ! test/tools/javac/StringAppendAccessMethodOnLHS.java ! test/tools/javac/StringConversion.java ! test/tools/javac/StringConversion2.java ! test/tools/javac/StringsInSwitch/OneCaseSwitches.java ! test/tools/javac/StringsInSwitch/StringSwitches.java ! test/tools/javac/SuperField.java ! test/tools/javac/SuperMeth.java ! test/tools/javac/SuperMethodResolve.java ! test/tools/javac/SuperNew.java ! test/tools/javac/SuperNew2.java ! test/tools/javac/SuperNew3.java ! test/tools/javac/SuperNew4.java ! test/tools/javac/SuperclassConstructorException.java ! test/tools/javac/SwitchFence.java ! test/tools/javac/SwitchScope.java ! test/tools/javac/SynthName1.java ! test/tools/javac/SynthName2.java ! test/tools/javac/T4848619/T4848619a.java ! test/tools/javac/T4848619/T4848619b.java ! test/tools/javac/T4994049/DeprecatedNOT.java ! test/tools/javac/T4994049/DeprecatedYES.java ! test/tools/javac/T5090006/T5090006.java ! test/tools/javac/T5090006/compiler.sh ! test/tools/javac/T5092545.java ! test/tools/javac/T5105890.java ! test/tools/javac/T6180021/AbstractSub.java ! test/tools/javac/T6180021/Sub.java ! test/tools/javac/T6180021/Super.java ! test/tools/javac/T6231246/T6231246.java ! test/tools/javac/T6232928.java ! test/tools/javac/T6232928/package-info.java ! test/tools/javac/T6234077.java ! test/tools/javac/T6238612.java ! test/tools/javac/T6265400.java ! test/tools/javac/T6266772.java ! test/tools/javac/T6294589.java ! test/tools/javac/T6304128.java ! test/tools/javac/T6306967.java ! test/tools/javac/T6326754.java ! test/tools/javac/T6341023.java ! test/tools/javac/T6351767.java ! test/tools/javac/T6356217/T6356217.java ! test/tools/javac/T6358024.java ! test/tools/javac/T6358166.java ! test/tools/javac/T6358168.java ! test/tools/javac/T6361619.java ! test/tools/javac/T6366196.java ! test/tools/javac/T6370653.java ! test/tools/javac/T6379327.java ! test/tools/javac/T6395974.java ! test/tools/javac/T6397044.java ! test/tools/javac/T6397286.java ! test/tools/javac/T6403466.java ! test/tools/javac/T6404756.java ! test/tools/javac/T6405099.java ! test/tools/javac/T6407066.java ! test/tools/javac/T6407257.java ! test/tools/javac/T6410706.java ! test/tools/javac/T6411379.java ! test/tools/javac/T6413876.java ! test/tools/javac/T6423583.java ! test/tools/javac/T6435291/T6435291.java ! test/tools/javac/T6472751.java ! test/tools/javac/T6534287.java ! test/tools/javac/T6557865.java ! test/tools/javac/T6558476.java ! test/tools/javac/T6595666.java ! test/tools/javac/T6625520.java ! test/tools/javac/T6654037.java ! test/tools/javac/T6663588.java ! test/tools/javac/T6665791.java ! test/tools/javac/T6668802.java ! test/tools/javac/T6705935.java ! test/tools/javac/T6725036.java ! test/tools/javac/T6759996.java ! test/tools/javac/T6794959.java ! test/tools/javac/T6855236.java ! test/tools/javac/T6873849.java ! test/tools/javac/T6881645.java ! test/tools/javac/T6942649.java ! test/tools/javac/ThrowNull.java ! test/tools/javac/ThrowsIntersection_1.java ! test/tools/javac/ThrowsIntersection_2.java ! test/tools/javac/ThrowsIntersection_3.java ! test/tools/javac/ThrowsIntersection_4.java ! test/tools/javac/TryInInstanceInit.java ! test/tools/javac/UncaughtOverflow.java ! test/tools/javac/UncaughtOverflow2.java ! test/tools/javac/UnreachableVar.java ! test/tools/javac/UnterminatedLineComment.java ! test/tools/javac/UplevelFromAnonInSuperCall.java ! test/tools/javac/UseEnum.java ! test/tools/javac/VarDeclarationWithAssignment.java ! test/tools/javac/Verify.java ! test/tools/javac/VerifyDA.java ! test/tools/javac/VersionOpt.java ! test/tools/javac/VoidArray.java ! test/tools/javac/abstract/T1.java ! test/tools/javac/abstract/T2.java ! test/tools/javac/abstract/T3.java ! test/tools/javac/abstract/T4717181a.java ! test/tools/javac/abstract/T4717181b.java ! test/tools/javac/abstract/U1.java ! test/tools/javac/abstract/U2.java ! test/tools/javac/abstract/U3.java ! test/tools/javac/accessVirtualInner/Main.java ! test/tools/javac/accessVirtualInner/a/A.java ! test/tools/javac/accessVirtualInner/b/B.java ! test/tools/javac/accessVirtualInner/c/C.java ! test/tools/javac/annotations/6214965/CompilerAnnotationTest.java ! test/tools/javac/annotations/6214965/CompilerAnnotationTest2.java ! test/tools/javac/annotations/6214965/CompilerAnnotationTest2bad.java ! test/tools/javac/annotations/6214965/T6214965.java ! test/tools/javac/annotations/6359949/T6359949.java ! test/tools/javac/annotations/6359949/T6359949a.java ! test/tools/javac/annotations/6365854/T6365854.java ! test/tools/javac/annotations/6365854/TestAnnotation.java ! test/tools/javac/annotations/6365854/TestCore.java ! test/tools/javac/annotations/6365854/evolve/TestAnnotation.java ! test/tools/javac/annotations/default/A.java ! test/tools/javac/annotations/default/B.java ! test/tools/javac/annotations/default/C.java ! test/tools/javac/annotations/default/Derr.java ! test/tools/javac/annotations/default/Eerr.java ! test/tools/javac/annotations/neg/AnnComma.java ! test/tools/javac/annotations/neg/ArrayLit.java ! test/tools/javac/annotations/neg/Constant.java ! test/tools/javac/annotations/neg/Cycle1.java ! test/tools/javac/annotations/neg/Cycle2.java ! test/tools/javac/annotations/neg/Cycle3.java ! test/tools/javac/annotations/neg/Dep.java ! test/tools/javac/annotations/neg/Dup.java ! test/tools/javac/annotations/neg/DupTarget.java ! test/tools/javac/annotations/neg/MemberOver.java ! test/tools/javac/annotations/neg/MixedSource.java ! test/tools/javac/annotations/neg/NoAnnotationMethods.java ! test/tools/javac/annotations/neg/NoClone.java ! test/tools/javac/annotations/neg/NoObjectMethods.java ! test/tools/javac/annotations/neg/ObjectMembers.java ! test/tools/javac/annotations/neg/OverrideNo.java ! test/tools/javac/annotations/neg/Package.java ! test/tools/javac/annotations/neg/Recovery.java ! test/tools/javac/annotations/neg/Recovery1.java ! test/tools/javac/annotations/neg/Scope.java ! test/tools/javac/annotations/neg/Syntax1.java ! test/tools/javac/annotations/neg/WrongTarget.java ! test/tools/javac/annotations/neg/WrongTarget2.java ! test/tools/javac/annotations/neg/WrongValue.java ! test/tools/javac/annotations/neg/Z1.java ! test/tools/javac/annotations/neg/Z10.java ! test/tools/javac/annotations/neg/Z11.java ! test/tools/javac/annotations/neg/Z12.java ! test/tools/javac/annotations/neg/Z13.java ! test/tools/javac/annotations/neg/Z14.java ! test/tools/javac/annotations/neg/Z15.java ! test/tools/javac/annotations/neg/Z16.java ! test/tools/javac/annotations/neg/Z2.java ! test/tools/javac/annotations/neg/Z3.java ! test/tools/javac/annotations/neg/Z4.java ! test/tools/javac/annotations/neg/Z5.java ! test/tools/javac/annotations/neg/Z8.java ! test/tools/javac/annotations/neg/Z9.java ! test/tools/javac/annotations/pos/AnnotationMethods.java ! test/tools/javac/annotations/pos/AnnoteElideBraces.java ! test/tools/javac/annotations/pos/ClassA.java ! test/tools/javac/annotations/pos/ClassB.java ! test/tools/javac/annotations/pos/Dep.java ! test/tools/javac/annotations/pos/Enum1.java ! test/tools/javac/annotations/pos/Local.java ! test/tools/javac/annotations/pos/Members.java ! test/tools/javac/annotations/pos/NType.java ! test/tools/javac/annotations/pos/OverrideCheck.java ! test/tools/javac/annotations/pos/OverrideOK.java ! test/tools/javac/annotations/pos/Parameter.java ! test/tools/javac/annotations/pos/Primitives.java ! test/tools/javac/annotations/pos/RightTarget.java ! test/tools/javac/annotations/pos/TrailingComma.java ! test/tools/javac/annotations/pos/Z1.java ! test/tools/javac/annotations/pos/Z2.java ! test/tools/javac/annotations/pos/Z3.java ! test/tools/javac/annotations/pos/Z4.java ! test/tools/javac/annotations/pos/package-info.java ! test/tools/javac/api/6400303/T6400303.java ! test/tools/javac/api/6400303/Test1.java ! test/tools/javac/api/6400303/Test2.java ! test/tools/javac/api/6406133/T6406133.java ! test/tools/javac/api/6410643/T6410643.java ! test/tools/javac/api/6411310/T6411310.java ! test/tools/javac/api/6411310/Test.java ! test/tools/javac/api/6411333/T6411333.java ! test/tools/javac/api/6412656/T6412656.java ! test/tools/javac/api/6415780/T6415780.java ! test/tools/javac/api/6418694/T6418694.java ! test/tools/javac/api/6420409/T6420409.java ! test/tools/javac/api/6420464/T6420464.java ! test/tools/javac/api/6421111/T6421111.java ! test/tools/javac/api/6421756/T6421756.java ! test/tools/javac/api/6422215/T6422215.java ! test/tools/javac/api/6422327/T6422327.java ! test/tools/javac/api/6423003/T6423003.java ! test/tools/javac/api/6431257/T6431257.java ! test/tools/javac/api/6431257/package-info.java ! test/tools/javac/api/6431435/A.java ! test/tools/javac/api/6431435/T6431435.java ! test/tools/javac/api/6431435/p/B.java ! test/tools/javac/api/6437349/T6437349.java ! test/tools/javac/api/6437999/T6437999.java ! test/tools/javac/api/6437999/Utf8.java ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/6440528/T6440528.java ! test/tools/javac/api/6440528/package-info.java ! test/tools/javac/api/6452876/T6452876.java ! test/tools/javac/api/6468404/T6468404.java ! test/tools/javac/api/6471599/Main.java ! test/tools/javac/api/6557752/T6557752.java ! test/tools/javac/api/6608214/T6608214.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/api/6733837/T6733837.java ! test/tools/javac/api/6852595/T6852595.java ! test/tools/javac/api/Sibling.java ! test/tools/javac/api/T6257235.java ! test/tools/javac/api/T6258271.java ! test/tools/javac/api/T6265137.java ! test/tools/javac/api/T6265137a.java ! test/tools/javac/api/T6306137.java ! test/tools/javac/api/T6345974.java ! test/tools/javac/api/T6357331.java ! test/tools/javac/api/T6358786.java ! test/tools/javac/api/T6358955.java ! test/tools/javac/api/T6392782.java ! test/tools/javac/api/T6395981.java ! test/tools/javac/api/T6397104.java ! test/tools/javac/api/T6400205.java ! test/tools/javac/api/T6400207.java ! test/tools/javac/api/T6407011.java ! test/tools/javac/api/T6412669.java ! test/tools/javac/api/T6431879.java ! test/tools/javac/api/T6483788.java ! test/tools/javac/api/T6501502.java ! test/tools/javac/api/T6838467.java ! test/tools/javac/api/T6877206.java ! test/tools/javac/api/TestEvalExpression.java ! test/tools/javac/api/TestGetTree.java ! test/tools/javac/api/TestJavacTask.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/api/TestOperators.java ! test/tools/javac/api/TestResolveError.java ! test/tools/javac/api/TestResolveIdent.java ! test/tools/javac/api/TestTreePath.java ! test/tools/javac/api/TestTrees.java ! test/tools/javac/api/evalexpr/ByteArrayClassLoader.java ! test/tools/javac/api/evalexpr/CompileFromString.java ! test/tools/javac/api/evalexpr/MemoryFileManager.java ! test/tools/javac/api/guide/Test.java ! test/tools/javac/api/guide/TestMe.java ! test/tools/javac/api/lib/ToolTester.java ! test/tools/javac/apt.sh ! test/tools/javac/assert/Attach.java ! test/tools/javac/assert/DU1.java ! test/tools/javac/assert/DU2.java ! test/tools/javac/binaryCompat/T1.java ! test/tools/javac/binaryCompat/T2.java ! test/tools/javac/binaryCompat/T3.java ! test/tools/javac/boxing/BoxedForeach.java ! test/tools/javac/boxing/Boxing1.java ! test/tools/javac/boxing/Boxing2.java ! test/tools/javac/boxing/Boxing4.java ! test/tools/javac/boxing/BoxingCaching.java ! test/tools/javac/boxing/NoBoxingBool.java ! test/tools/javac/boxing/NoBoxingByte.java ! test/tools/javac/boxing/NoBoxingChar.java ! test/tools/javac/boxing/NoBoxingDouble.java ! test/tools/javac/boxing/NoBoxingFloat.java ! test/tools/javac/boxing/NoBoxingInt.java ! test/tools/javac/boxing/NoBoxingLong.java ! test/tools/javac/boxing/NoBoxingShort.java ! test/tools/javac/boxing/T5082929.java ! test/tools/javac/boxing/T6348760.java ! test/tools/javac/boxing/T6369051.java ! test/tools/javac/boxing/T6614974.java ! test/tools/javac/boxing/T6816548.java ! test/tools/javac/capture/Capture1.java ! test/tools/javac/capture/Capture2.java ! test/tools/javac/capture/Capture3.java ! test/tools/javac/capture/Capture5.java ! test/tools/javac/capture/Martin.java ! test/tools/javac/capture/T6594284.java ! test/tools/javac/cast/4916620/T4916620.java ! test/tools/javac/cast/5034609/T5034609.java ! test/tools/javac/cast/5043020/T5043020.java ! test/tools/javac/cast/5064736/T5064736.java ! test/tools/javac/cast/5065215/T5065215.java ! test/tools/javac/cast/6211853/T6211853.java ! test/tools/javac/cast/6219964/T6219964.java ! test/tools/javac/cast/6256789/T6256789.java ! test/tools/javac/cast/6286112/T6286112.java ! test/tools/javac/cast/6295056/T6295056.java ! test/tools/javac/cast/6302214/T6302214.java ! test/tools/javac/cast/6302214/T6302214a.java ! test/tools/javac/cast/6302956/T6302956.java ! test/tools/javac/cast/6358534/T6358534.java ! test/tools/javac/cast/6467183/T6467183b.java ! test/tools/javac/cast/6548436/T6548436a.java ! test/tools/javac/cast/6548436/T6548436b.java ! test/tools/javac/cast/6548436/T6548436c.java ! test/tools/javac/cast/6548436/T6548436d.java ! test/tools/javac/cast/6558559/T6558559a.java ! test/tools/javac/cast/6558559/T6558559b.java ! test/tools/javac/cast/6586091/T6586091.java ! test/tools/javac/cast/BoxedArray.java ! test/tools/javac/cast/forum/T654170.java ! test/tools/javac/code/ArrayClone.java ! test/tools/javac/completion/C.java ! test/tools/javac/conditional/6500343/T6500343a.java ! test/tools/javac/conditional/6500343/T6500343b.java ! test/tools/javac/conditional/Conditional.java ! test/tools/javac/constDebug/ConstDebug.java ! test/tools/javac/constDebug/ConstDebug.sh ! test/tools/javac/crossPackageImpl/CrossPackageImplA.java ! test/tools/javac/crossPackageImpl/CrossPackageImplB.java ! test/tools/javac/danglingDep/DepX.java ! test/tools/javac/danglingDep/NoDepX.java ! test/tools/javac/danglingDep/RefX.java ! test/tools/javac/danglingDep/Test1.java ! test/tools/javac/depDocComment/DeprecatedDocComment2.java ! test/tools/javac/depOverrides/annotation/B3.java ! test/tools/javac/depOverrides/annotation/I.java ! test/tools/javac/depOverrides/annotation/P.java ! test/tools/javac/depOverrides/annotation/Test1.java ! test/tools/javac/depOverrides/annotation/Test2.java ! test/tools/javac/depOverrides/doccomment/B3.java ! test/tools/javac/depOverrides/doccomment/I.java ! test/tools/javac/depOverrides/doccomment/P.java ! test/tools/javac/depOverrides/doccomment/Test1.java ! test/tools/javac/depOverrides/doccomment/Test2.java ! test/tools/javac/enum/6350057/T6350057.java ! test/tools/javac/enum/6350057/TestEnum.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/enum/AbstractEmptyEnum.java ! test/tools/javac/enum/AbstractEnum1.java ! test/tools/javac/enum/DA1.java ! test/tools/javac/enum/DA2.java ! test/tools/javac/enum/DA3.java ! test/tools/javac/enum/Def.java ! test/tools/javac/enum/Enum1.java ! test/tools/javac/enum/Enum2.java ! test/tools/javac/enum/Enum3.java ! test/tools/javac/enum/EnumImplicitPrivateConstructor.java ! test/tools/javac/enum/EnumInit.java ! test/tools/javac/enum/EnumPrivateConstructor.java ! test/tools/javac/enum/EnumProtectedConstructor.java ! test/tools/javac/enum/EnumPublicConstructor.java ! test/tools/javac/enum/EnumSwitch1.java ! test/tools/javac/enum/EnumSwitch2.java ! test/tools/javac/enum/EnumSwitch3.java ! test/tools/javac/enum/EnumSwitch4.java ! test/tools/javac/enum/ExplicitlyAbstractEnum1.java ! test/tools/javac/enum/ExplicitlyAbstractEnum2.java ! test/tools/javac/enum/ExplicitlyFinalEnum1.java ! test/tools/javac/enum/ExplicitlyFinalEnum2.java ! test/tools/javac/enum/FauxEnum1.java ! test/tools/javac/enum/FauxEnum2.java ! test/tools/javac/enum/FauxEnum3.java ! test/tools/javac/enum/FauxSpecialEnum1.java ! test/tools/javac/enum/FauxSpecialEnum2.java ! test/tools/javac/enum/LocalEnum.java ! test/tools/javac/enum/NestedEnum.java ! test/tools/javac/enum/NoFinal.java ! test/tools/javac/enum/NoFinal2.java ! test/tools/javac/enum/NoFinal3.java ! test/tools/javac/enum/NoFinal4.java ! test/tools/javac/enum/NoFinal5.java ! test/tools/javac/enum/OkFinal.java ! test/tools/javac/enum/SynthValues.java ! test/tools/javac/enum/T5075242.java ! test/tools/javac/enum/T5081785.java ! test/tools/javac/enum/T5081785a.java ! test/tools/javac/enum/T5081785b.java ! test/tools/javac/enum/T5081785c.java ! test/tools/javac/enum/T6509042.java ! test/tools/javac/enum/T6675483.java ! test/tools/javac/enum/T6724345.java ! test/tools/javac/enum/TrailingComma.java ! test/tools/javac/enum/UserValue.java ! test/tools/javac/enum/ValueOf.java ! test/tools/javac/enum/enumSwitch/Color2.java ! test/tools/javac/enum/enumSwitch/EnumSwitch.java ! test/tools/javac/enum/forwardRef/TestEnum1.java ! test/tools/javac/enum/forwardRef/TestEnum2.java ! test/tools/javac/enum/forwardRef/TestEnum3.java ! test/tools/javac/enum/forwardRef/TestEnum4.java ! test/tools/javac/enum/forwardRef/TestEnum5.java ! test/tools/javac/enum/forwardRef/TestEnum6.java ! test/tools/javac/expression/NullAppend.java ! test/tools/javac/expression/NullAppend2.java ! test/tools/javac/falseCycle/FalseCycle.java ! test/tools/javac/falseCycle/FalseCycleBase.java ! test/tools/javac/fatalErrors/NoJavaLang.java ! test/tools/javac/fatalErrors/NoJavaLang.sh ! test/tools/javac/foreach/Foreach.java ! test/tools/javac/foreach/GenericIterator.java ! test/tools/javac/foreach/IntersectIterator.java ! test/tools/javac/foreach/ListOfListTest.java ! test/tools/javac/foreach/SpecIterable.java ! test/tools/javac/foreach/StaticBlock.java ! test/tools/javac/foreach/SuperfluousAbstract.java ! test/tools/javac/foreach/T6500701.java ! test/tools/javac/foreach/T6682380.java ! test/tools/javac/generics/5066774/T5066774.java ! test/tools/javac/generics/5086027/T5086027.java ! test/tools/javac/generics/5086027/T5086027pos.java ! test/tools/javac/generics/6182950/T6182950c.java ! test/tools/javac/generics/6192945/Method.java ! test/tools/javac/generics/6192945/MethodNeg.java ! test/tools/javac/generics/6192945/Neg.java ! test/tools/javac/generics/6192945/Neg2.java ! test/tools/javac/generics/6192945/Neg3.java ! test/tools/javac/generics/6192945/T6192945.java ! test/tools/javac/generics/6207386/Test.java ! test/tools/javac/generics/6213818/T6213818.java ! test/tools/javac/generics/6218229/T6218229.java ! test/tools/javac/generics/6227936/Orig.java ! test/tools/javac/generics/6227936/T6227936.java ! test/tools/javac/generics/6245699/T6245699.java ! test/tools/javac/generics/6245699/T6245699a.java ! test/tools/javac/generics/6245699/T6245699b.java ! test/tools/javac/generics/6245699/T6245699c.java ! test/tools/javac/generics/6268476/T6268476.java ! test/tools/javac/generics/6292765/T6292765.java ! test/tools/javac/generics/6294779/T6294779a.java ! test/tools/javac/generics/6294779/T6294779b.java ! test/tools/javac/generics/6294779/T6294779c.java ! test/tools/javac/generics/6332204/T6332204.java ! test/tools/javac/generics/6332204/T6346876.java ! test/tools/javac/generics/6356636/T6356636.java ! test/tools/javac/generics/6356636/a/AbstractFoo.java ! test/tools/javac/generics/6356636/a/Bar.java ! test/tools/javac/generics/6372782/AbstractElement.java ! test/tools/javac/generics/6372782/AbstractPlanarVector.java ! test/tools/javac/generics/6372782/AbstractVector.java ! test/tools/javac/generics/6372782/AdditionDefined.java ! test/tools/javac/generics/6372782/AdditiveClosure.java ! test/tools/javac/generics/6372782/Element.java ! test/tools/javac/generics/6372782/MultiplicationDefined.java ! test/tools/javac/generics/6372782/PlainForm.java ! test/tools/javac/generics/6372782/PlainPlanarVector.java ! test/tools/javac/generics/6372782/PlanarVector.java ! test/tools/javac/generics/6372782/PlanarVectorVariable.java ! test/tools/javac/generics/6372782/Ring.java ! test/tools/javac/generics/6372782/Scalar.java ! test/tools/javac/generics/6372782/State.java ! test/tools/javac/generics/6372782/T6372782.java ! test/tools/javac/generics/6372782/Value.java ! test/tools/javac/generics/6372782/VariableForm.java ! test/tools/javac/generics/6372782/Vector.java ! test/tools/javac/generics/6413682/T6413682.java ! test/tools/javac/generics/6413682/TestPos.java ! test/tools/javac/generics/6487370/T6487370.java ! test/tools/javac/generics/6495506/A.java ! test/tools/javac/generics/6495506/T6495506.java ! test/tools/javac/generics/6531075/T6531075.java ! test/tools/javac/generics/6531090/T6531090a.java ! test/tools/javac/generics/6531090/T6531090b.java ! test/tools/javac/generics/6729401/T6729401.java ! test/tools/javac/generics/ArrayClone.java ! test/tools/javac/generics/ArrayTypearg.java ! test/tools/javac/generics/BridgeClash.java ! test/tools/javac/generics/BridgeOrder.java ! test/tools/javac/generics/BridgeRestype.java ! test/tools/javac/generics/CastCrash.java ! test/tools/javac/generics/Casting.java ! test/tools/javac/generics/Casting2.java ! test/tools/javac/generics/Casting3.java ! test/tools/javac/generics/Casting4.java ! test/tools/javac/generics/Casting5.java ! test/tools/javac/generics/CatchTyparam.java ! test/tools/javac/generics/Conditional.java ! test/tools/javac/generics/Covar2.java ! test/tools/javac/generics/Covar3.java ! test/tools/javac/generics/Covar4.java ! test/tools/javac/generics/Crash01.java ! test/tools/javac/generics/Crash02.java ! test/tools/javac/generics/CyclicInheritance3.java ! test/tools/javac/generics/CyclicInheritance5.java ! test/tools/javac/generics/ErasureClashCrash.java ! test/tools/javac/generics/ExtendedRaw1.java ! test/tools/javac/generics/ExtendedRaw2.java ! test/tools/javac/generics/ExtendedRaw3.java ! test/tools/javac/generics/ExtendedRaw4.java ! test/tools/javac/generics/FinalBridge.java ! test/tools/javac/generics/GenLit1.java ! test/tools/javac/generics/GenLit2.java ! test/tools/javac/generics/GenericAnonCtor.java ! test/tools/javac/generics/GenericMerge.java ! test/tools/javac/generics/GenericOverride.java ! test/tools/javac/generics/GenericThrowable.java ! test/tools/javac/generics/GetClass.java ! test/tools/javac/generics/GetClass2.java ! test/tools/javac/generics/InheritanceConflict.java ! test/tools/javac/generics/InheritanceConflict2.java ! test/tools/javac/generics/InheritanceConflict3.java ! test/tools/javac/generics/InnerInterface1.java ! test/tools/javac/generics/InnerInterface2.java ! test/tools/javac/generics/InstanceOf1.java ! test/tools/javac/generics/InstanceOf2.java ! test/tools/javac/generics/InstanceOf3.java ! test/tools/javac/generics/InterfaceCast1.java ! test/tools/javac/generics/LoadOrder.java ! test/tools/javac/generics/MissingBridge.java ! test/tools/javac/generics/MissingCast.java ! test/tools/javac/generics/Multibound1.java ! test/tools/javac/generics/MultipleInheritance.java ! test/tools/javac/generics/NameOrder.java ! test/tools/javac/generics/Nonlinear.java ! test/tools/javac/generics/ParametricException.java ! test/tools/javac/generics/ParenVerify.java ! test/tools/javac/generics/PermuteBound.java ! test/tools/javac/generics/PrimitiveClass.java ! test/tools/javac/generics/PrimitiveVariant.java ! test/tools/javac/generics/RawClient.java ! test/tools/javac/generics/RefEqual.java ! test/tools/javac/generics/RelaxedArrays.java ! test/tools/javac/generics/ReverseOrder.java ! test/tools/javac/generics/SelfImplement.java ! test/tools/javac/generics/SilentUnchecked.java ! test/tools/javac/generics/SuperTypeargs.java ! test/tools/javac/generics/T4661029.java ! test/tools/javac/generics/T4683314.java ! test/tools/javac/generics/T4684378.java ! test/tools/javac/generics/T4695348.java ! test/tools/javac/generics/T4695415.java ! test/tools/javac/generics/T4695847.java ! test/tools/javac/generics/T4711570.java ! test/tools/javac/generics/T4711572.java ! test/tools/javac/generics/T4711694.java ! test/tools/javac/generics/T4738171.java ! test/tools/javac/generics/T4739399.java ! test/tools/javac/generics/T4757416.java ! test/tools/javac/generics/T4784207a.java ! test/tools/javac/generics/T4784207b.java ! test/tools/javac/generics/T4784219.java ! test/tools/javac/generics/T5011073.java ! test/tools/javac/generics/T5094318.java ! test/tools/javac/generics/T6391995.java ! test/tools/javac/generics/T6481655.java ! test/tools/javac/generics/T6507024.java ! test/tools/javac/generics/T6557954.java ! test/tools/javac/generics/T6657499.java ! test/tools/javac/generics/T6660289.java ! test/tools/javac/generics/T6751514.java ! test/tools/javac/generics/T6869075.java ! test/tools/javac/generics/TyparamLit.java ! test/tools/javac/generics/TyparamStaticScope.java ! test/tools/javac/generics/TyparamStaticScope2.java ! test/tools/javac/generics/UncheckedArray.java ! test/tools/javac/generics/UncheckedConstructor.java ! test/tools/javac/generics/UncheckedCovariance.java ! test/tools/javac/generics/UnsoundInference.java ! test/tools/javac/generics/Varargs.java ! test/tools/javac/generics/Varargs2.java ! test/tools/javac/generics/WrongNew.java ! test/tools/javac/generics/abstract/T4717181c.java ! test/tools/javac/generics/bridge1/A.java ! test/tools/javac/generics/bridge1/C.java ! test/tools/javac/generics/bridge1/D.java ! test/tools/javac/generics/bridge1/E.java ! test/tools/javac/generics/classreader/HArrayMethod.java ! test/tools/javac/generics/classreader/HMember.java ! test/tools/javac/generics/classreader/HMethod.java ! test/tools/javac/generics/classreader/HMethodImpl.java ! test/tools/javac/generics/compat/CovariantCompat1.java ! test/tools/javac/generics/compat/CovariantCompat2.java ! test/tools/javac/generics/compat/OverrideBridge1.java ! test/tools/javac/generics/compat/OverrideBridge2.java ! test/tools/javac/generics/compat/OverrideBridge3.java ! test/tools/javac/generics/compat/VisibleBridge.java ! test/tools/javac/generics/diamond/pos/Pos01.java ! test/tools/javac/generics/diamond/pos/Pos02.java ! test/tools/javac/generics/diamond/pos/Pos03.java ! test/tools/javac/generics/diamond/pos/Pos04.java ! test/tools/javac/generics/diamond/pos/Pos05.java ! test/tools/javac/generics/forwardSeparateBound/ForwardSeparateBound1.java ! test/tools/javac/generics/forwardSeparateBound/ForwardSeparateBound2.java ! test/tools/javac/generics/genericAbstract/A.java ! test/tools/javac/generics/genericAbstract/B.java ! test/tools/javac/generics/inference/4941882/T4941882.java ! test/tools/javac/generics/inference/4942040/T4942040.java ! test/tools/javac/generics/inference/4954546/T4954546.java ! test/tools/javac/generics/inference/4972073/T4972073.java ! test/tools/javac/generics/inference/4972073/T4972073a.java ! test/tools/javac/generics/inference/4972073/T4972073b.java ! test/tools/javac/generics/inference/5003431/T5003431.java ! test/tools/javac/generics/inference/5021635/T5021635.java ! test/tools/javac/generics/inference/5021635/T6299211.java ! test/tools/javac/generics/inference/5034571/T5034571.java ! test/tools/javac/generics/inference/5042462/T5042462.java ! test/tools/javac/generics/inference/5044646/T5044646.java ! test/tools/javac/generics/inference/5044646/p1/A1.java ! test/tools/javac/generics/inference/5044646/p1/B.java ! test/tools/javac/generics/inference/5044646/p1/C.java ! test/tools/javac/generics/inference/5044646/p2/A2.java ! test/tools/javac/generics/inference/5049523/T5049523.java ! test/tools/javac/generics/inference/5070671/T5070671.java ! test/tools/javac/generics/inference/5073060/GenericsAndPackages.java ! test/tools/javac/generics/inference/5073060/Neg.java ! test/tools/javac/generics/inference/5073060/NegHelper.java ! test/tools/javac/generics/inference/5073060/T5073060.java ! test/tools/javac/generics/inference/5073060/T5073060a.java ! test/tools/javac/generics/inference/5080917/T5080917.java ! test/tools/javac/generics/inference/5081782/Neg.java ! test/tools/javac/generics/inference/5081782/Pos.java ! test/tools/javac/generics/inference/6215213/T6215213.java ! test/tools/javac/generics/inference/6222762/T6222762.java ! test/tools/javac/generics/inference/6240565/T6240565.java ! test/tools/javac/generics/inference/6273455/T6273455.java ! test/tools/javac/generics/inference/6278587/T6278587.java ! test/tools/javac/generics/inference/6278587/T6278587Neg.java ! test/tools/javac/generics/inference/6302954/T6456971.java ! test/tools/javac/generics/inference/6302954/T6476073.java ! test/tools/javac/generics/inference/6302954/X.java ! test/tools/javac/generics/inference/6356673/T6365166.java ! test/tools/javac/generics/inference/6356673/Test.java ! test/tools/javac/generics/inference/6359106/Orig.java ! test/tools/javac/generics/inference/6359106/T6359106.java ! test/tools/javac/generics/inference/6365166/NewTest.java ! test/tools/javac/generics/inference/6468384/T6468384.java ! test/tools/javac/generics/inference/6569789/T6569789.java ! test/tools/javac/generics/inference/6650759/T6650759a.java ! test/tools/javac/generics/inference/6650759/T6650759b.java ! test/tools/javac/generics/inference/6650759/T6650759c.java ! test/tools/javac/generics/inference/6650759/T6650759d.java ! test/tools/javac/generics/inference/6650759/T6650759e.java ! test/tools/javac/generics/inference/6650759/T6650759f.java ! test/tools/javac/generics/inference/6650759/T6650759g.java ! test/tools/javac/generics/inference/6650759/T6650759h.java ! test/tools/javac/generics/inference/6650759/T6650759i.java ! test/tools/javac/generics/inference/6650759/T6650759j.java ! test/tools/javac/generics/inference/6650759/T6650759k.java ! test/tools/javac/generics/inference/6650759/T6650759l.java ! test/tools/javac/generics/inference/6650759/T6650759m.java ! test/tools/javac/generics/inference/T6835428.java ! test/tools/javac/generics/odersky/BadTest.java ! test/tools/javac/generics/odersky/BadTest2.java ! test/tools/javac/generics/odersky/BadTest3.java ! test/tools/javac/generics/odersky/BadTest4.java ! test/tools/javac/generics/odersky/Cell.java ! test/tools/javac/generics/odersky/List.java ! test/tools/javac/generics/odersky/Test.java ! test/tools/javac/generics/odersky/Test2.java ! test/tools/javac/generics/odersky/Test3.java ! test/tools/javac/generics/odersky/Test4.java ! test/tools/javac/generics/parametricException/J.java ! test/tools/javac/generics/parametricException/K.java ! test/tools/javac/generics/rare/Rare1.java ! test/tools/javac/generics/rare/Rare10.java ! test/tools/javac/generics/rare/Rare11.java ! test/tools/javac/generics/rare/Rare2.java ! test/tools/javac/generics/rare/Rare3.java ! test/tools/javac/generics/rare/Rare4.java ! test/tools/javac/generics/rare/Rare5.java ! test/tools/javac/generics/rare/Rare6.java ! test/tools/javac/generics/rare/Rare7.java ! test/tools/javac/generics/rare/Rare8.java ! test/tools/javac/generics/rare/Rare9.java ! test/tools/javac/generics/rawOverride/AttributeSet.java ! test/tools/javac/generics/rawOverride/Fail1.java ! test/tools/javac/generics/rawOverride/T6178365.java ! test/tools/javac/generics/rawOverride/T6846972.java ! test/tools/javac/generics/rawOverride/Warn1.java ! test/tools/javac/generics/rawOverride/Warn2.java ! test/tools/javac/generics/rawSeparate/CharScanner.java ! test/tools/javac/generics/rawSeparate/Hashtable.java ! test/tools/javac/generics/rawSeparate/RetroLexer.java ! test/tools/javac/generics/syntax/6318240/Bar.java ! test/tools/javac/generics/syntax/6318240/BarNeg1.java ! test/tools/javac/generics/syntax/6318240/BarNeg1a.java ! test/tools/javac/generics/syntax/6318240/BarNeg2.java ! test/tools/javac/generics/syntax/6318240/BarNeg2a.java ! test/tools/javac/generics/syntax/6318240/Foo.java ! test/tools/javac/generics/typeargs/Basic.java ! test/tools/javac/generics/typeargs/Metharg1.java ! test/tools/javac/generics/typeargs/Metharg2.java ! test/tools/javac/generics/typeargs/Newarg1.java ! test/tools/javac/generics/typeargs/Newarg2.java ! test/tools/javac/generics/typeargs/Superarg1.java ! test/tools/javac/generics/typeargs/Superarg2.java ! test/tools/javac/generics/typeargs/ThisArg.java ! test/tools/javac/generics/typevars/4856983/T4856983.java ! test/tools/javac/generics/typevars/4856983/T4856983a.java ! test/tools/javac/generics/typevars/4856983/T4856983b.java ! test/tools/javac/generics/typevars/5060485/Compatibility.java ! test/tools/javac/generics/typevars/5060485/Method.java ! test/tools/javac/generics/typevars/5060485/Neg1.java ! test/tools/javac/generics/typevars/5060485/Neg2.java ! test/tools/javac/generics/typevars/5060485/Pos.java ! test/tools/javac/generics/typevars/5060485/T5060485.java ! test/tools/javac/generics/typevars/5061359/Base.java ! test/tools/javac/generics/typevars/5061359/Intf.java ! test/tools/javac/generics/typevars/5061359/T5061359.java ! test/tools/javac/generics/typevars/5061359/T5061359a.java ! test/tools/javac/generics/typevars/5061359/T5061359b.java ! test/tools/javac/generics/typevars/6182630/T6182630.java ! test/tools/javac/generics/typevars/6182630/T6182630a.java ! test/tools/javac/generics/typevars/6182630/T6182630b.java ! test/tools/javac/generics/typevars/6182630/T6182630c.java ! test/tools/javac/generics/typevars/6182630/T6182630d.java ! test/tools/javac/generics/typevars/6182630/T6182630e.java ! test/tools/javac/generics/typevars/6182630/T6182630f.java ! test/tools/javac/generics/typevars/6199146/T6199146.java ! test/tools/javac/generics/typevars/6486430/T6486430.java ! test/tools/javac/generics/typevars/6486430/T6486430a.java ! test/tools/javac/generics/typevars/6569404/T6569404a.java ! test/tools/javac/generics/typevars/6569404/T6569404c.java ! test/tools/javac/generics/wildcards/6320612/T6320612.java ! test/tools/javac/generics/wildcards/6330931/T6330931.java ! test/tools/javac/generics/wildcards/6437894/A.java ! test/tools/javac/generics/wildcards/6437894/B.java ! test/tools/javac/generics/wildcards/6651719/T6651719a.java ! test/tools/javac/generics/wildcards/6762569/T6762569a.java ! test/tools/javac/generics/wildcards/6762569/T6762569b.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes1.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes2.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes3.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes4.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes5.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes6.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes7.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes8.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes9.java ! test/tools/javac/generics/wildcards/AssignmentSameType1.java ! test/tools/javac/generics/wildcards/AssignmentSameType2.java ! test/tools/javac/generics/wildcards/AssignmentSameType3.java ! test/tools/javac/generics/wildcards/AssignmentSameType4.java ! test/tools/javac/generics/wildcards/AssignmentSameType5.java ! test/tools/javac/generics/wildcards/AssignmentSameType6.java ! test/tools/javac/generics/wildcards/AssignmentSameType7.java ! test/tools/javac/generics/wildcards/AssignmentSameType8.java ! test/tools/javac/generics/wildcards/BoundBug.java ! test/tools/javac/generics/wildcards/ContraArg.java ! test/tools/javac/generics/wildcards/T5097548.java ! test/tools/javac/generics/wildcards/T5097548b.java ! test/tools/javac/generics/wildcards/T6450290.java ! test/tools/javac/generics/wildcards/T6732484.java ! test/tools/javac/generics/wildcards/UnboundArray.java ! test/tools/javac/generics/wildcards/neg/AmbiguousCast.java ! test/tools/javac/generics/wildcards/neg/Capture.java ! test/tools/javac/generics/wildcards/neg/CastFail1.java ! test/tools/javac/generics/wildcards/neg/CastFail10.java ! test/tools/javac/generics/wildcards/neg/CastFail11.java ! test/tools/javac/generics/wildcards/neg/CastFail12.java ! test/tools/javac/generics/wildcards/neg/CastFail13.java ! test/tools/javac/generics/wildcards/neg/CastFail14.java ! test/tools/javac/generics/wildcards/neg/CastFail15.java ! test/tools/javac/generics/wildcards/neg/CastFail16.java ! test/tools/javac/generics/wildcards/neg/CastFail17.java ! test/tools/javac/generics/wildcards/neg/CastFail18.java ! test/tools/javac/generics/wildcards/neg/CastFail19.java ! test/tools/javac/generics/wildcards/neg/CastFail2.java ! test/tools/javac/generics/wildcards/neg/CastFail20.java ! test/tools/javac/generics/wildcards/neg/CastFail21.java ! test/tools/javac/generics/wildcards/neg/CastFail3.java ! test/tools/javac/generics/wildcards/neg/CastFail4.java ! test/tools/javac/generics/wildcards/neg/CastFail5.java ! test/tools/javac/generics/wildcards/neg/CastFail6.java ! test/tools/javac/generics/wildcards/neg/CastFail7.java ! test/tools/javac/generics/wildcards/neg/CastFail8.java ! test/tools/javac/generics/wildcards/neg/CastFail9.java ! test/tools/javac/generics/wildcards/neg/CastWarn10.java ! test/tools/javac/generics/wildcards/neg/CastWarn11.java ! test/tools/javac/generics/wildcards/neg/CastWarn12.java ! test/tools/javac/generics/wildcards/neg/CastWarn13.java ! test/tools/javac/generics/wildcards/neg/CastWarn14.java ! test/tools/javac/generics/wildcards/neg/CastWarn2.java ! test/tools/javac/generics/wildcards/neg/CastWarn3.java ! test/tools/javac/generics/wildcards/neg/CastWarn4.java ! test/tools/javac/generics/wildcards/neg/CastWarn5.java ! test/tools/javac/generics/wildcards/neg/CastWarn6.java ! test/tools/javac/generics/wildcards/neg/CastWarn7.java ! test/tools/javac/generics/wildcards/neg/CastWarn8.java ! test/tools/javac/generics/wildcards/neg/CastWarn9.java ! test/tools/javac/generics/wildcards/neg/ParamCast.java ! test/tools/javac/generics/wildcards/neg/Readonly.java ! test/tools/javac/generics/wildcards/neg/Unbounded.java ! test/tools/javac/generics/wildcards/pos/AmbiguousCast2.java ! test/tools/javac/generics/wildcards/pos/BoundsCollision.java ! test/tools/javac/generics/wildcards/pos/Capture.java ! test/tools/javac/generics/wildcards/pos/CastTest.java ! test/tools/javac/generics/wildcards/pos/InstanceOf.java ! test/tools/javac/generics/wildcards/pos/ParamCast.java ! test/tools/javac/generics/wildcards/pos/RvalConversion.java ! test/tools/javac/generics/wildcards/pos/UncheckedCast1.java ! test/tools/javac/implicitThis/NewBeforeOuterConstructed.java ! test/tools/javac/implicitThis/NewBeforeOuterConstructed2.java ! test/tools/javac/implicitThis/NewBeforeOuterConstructed3.java ! test/tools/javac/implicitThis/WhichImplicitThis1.java ! test/tools/javac/implicitThis/WhichImplicitThis10.java ! test/tools/javac/implicitThis/WhichImplicitThis11.java ! test/tools/javac/implicitThis/WhichImplicitThis2.java ! test/tools/javac/implicitThis/WhichImplicitThis3.java ! test/tools/javac/implicitThis/WhichImplicitThis4.java ! test/tools/javac/implicitThis/WhichImplicitThis5.java ! test/tools/javac/implicitThis/WhichImplicitThis6.java ! test/tools/javac/implicitThis/WhichImplicitThis7.java ! test/tools/javac/implicitThis/WhichImplicitThis9.java ! test/tools/javac/importChecks/ImportCanonical1.java ! test/tools/javac/importChecks/ImportCanonical2.java ! test/tools/javac/importChecks/ImportIsFullyQualified.java ! test/tools/javac/importChecks/ImportOfOwnClass.java ! test/tools/javac/importChecks/InvalidImportsNoClasses.java ! test/tools/javac/importContext/anonPackage/Foo.java ! test/tools/javac/importContext/anonPackage/bar/Baz.java ! test/tools/javac/importContext/namedPackage/Dummy.java ! test/tools/javac/importContext/namedPackage/bar/Baz.java ! test/tools/javac/importContext/namedPackage/foo/Foo.java ! test/tools/javac/importscope/A.java ! test/tools/javac/importscope/B.java ! test/tools/javac/incompatibleNoninherited/A.java ! test/tools/javac/incompatibleNoninherited/B.java ! test/tools/javac/inheritAccess/PvtMbrsNotInherit1.java ! test/tools/javac/inheritedAccess/MethodReferenceQualification_1.java ! test/tools/javac/inheritedAccess/P1/priv.java ! test/tools/javac/inheritedAccess/P1/pub.java ! test/tools/javac/innerClassFile/Driver.sh ! test/tools/javac/innerClassFile/x/B.java ! test/tools/javac/innerClassFile/x/C.java ! test/tools/javac/innerClassFile/y/Main.java ! test/tools/javac/innerClassFile/y/R1.java ! test/tools/javac/innerClassFile/y/R2.java ! test/tools/javac/innerClassFile/y/R3.java ! test/tools/javac/javazip/A.java ! test/tools/javac/javazip/Test.sh ! test/tools/javac/javazip/bad/B.java ! test/tools/javac/javazip/good/B.java ! test/tools/javac/jvm/6397652/T6397652.java ! test/tools/javac/jvm/6397652/com/test/Test.java ! test/tools/javac/limits/ArrayDims1.java ! test/tools/javac/limits/ArrayDims2.java ! test/tools/javac/limits/ArrayDims3.java ! test/tools/javac/limits/ArrayDims4.java ! test/tools/javac/limits/ArrayDims5.java ! test/tools/javac/limits/CodeSize.java ! test/tools/javac/limits/FinallyNesting.java ! test/tools/javac/limits/LongName.java ! test/tools/javac/limits/NumArgs1.java ! test/tools/javac/limits/NumArgs2.java ! test/tools/javac/limits/NumArgs3.java ! test/tools/javac/limits/NumArgs4.java ! test/tools/javac/limits/PoolSize1.java ! test/tools/javac/limits/PoolSize2.java ! test/tools/javac/limits/StringLength.java ! test/tools/javac/links/T.java ! test/tools/javac/links/b/B.java ! test/tools/javac/links/links.sh ! test/tools/javac/lint/Deprecation.java ! test/tools/javac/lint/FallThrough.java ! test/tools/javac/lint/Unchecked.java ! test/tools/javac/literals/BinaryLiterals.java ! test/tools/javac/literals/UnderscoreLiterals.java ! test/tools/javac/mandatoryWarnings/deprecated/Test.java ! test/tools/javac/mandatoryWarnings/unchecked/Test.java ! test/tools/javac/meth/InvokeDyn.java ! test/tools/javac/meth/InvokeMH.java ! test/tools/javac/meth/MakeNegTests.sh ! test/tools/javac/miranda/4686148/AbstractTest.java ! test/tools/javac/miranda/4686148/ConcreteTest.java ! test/tools/javac/miranda/4686148/Test.java ! test/tools/javac/miranda/4686811/Tryit.java ! test/tools/javac/miranda/4686811/p1/A.java ! test/tools/javac/miranda/4686811/p1/C.java ! test/tools/javac/miranda/4686811/p2/B.java ! test/tools/javac/miranda/4711056/T1.java ! test/tools/javac/miranda/4711056/T2.java ! test/tools/javac/miranda/4711056/T3.java ! test/tools/javac/miranda/4711056/T4.java ! test/tools/javac/miranda/T4279316a.java ! test/tools/javac/miranda/T4279316b.java ! test/tools/javac/miranda/T4279316c.java ! test/tools/javac/miranda/T4279316d.java ! test/tools/javac/miranda/T4528315.java ! test/tools/javac/miranda/T4711325.java ! test/tools/javac/missingClass/A.java ! test/tools/javac/missingClass/B.java ! test/tools/javac/mixedTarget/CompatibleAbstracts1.java ! test/tools/javac/mixedTarget/CompatibleAbstracts2.java ! test/tools/javac/mixedTarget/CompatibleAbstracts3.java ! test/tools/javac/mixedTarget/CompatibleAbstracts4.java ! test/tools/javac/mixedTarget/CompatibleAbstracts5.java ! test/tools/javac/mixedTarget/ExtendCovariant1.java ! test/tools/javac/mixedTarget/ExtendCovariant2.java ! test/tools/javac/multicatch/Pos01.java ! test/tools/javac/multicatch/Pos02.java ! test/tools/javac/multicatch/Pos03.java ! test/tools/javac/multicatch/Pos04.java ! test/tools/javac/multicatch/Pos05.java ! test/tools/javac/nested/4903103/T4903103.java ! test/tools/javac/nested/5009484/X.java ! test/tools/javac/nested/5009484/Y.java ! test/tools/javac/newlines/Newlines.sh ! test/tools/javac/nio/compileTest/CompileTest.java ! test/tools/javac/nio/compileTest/HelloPathWorld.java ! test/tools/javac/overload/T4494762.java ! test/tools/javac/overload/T4723909.java ! test/tools/javac/overload/T4743490.java ! test/tools/javac/overload/T5090220.java ! test/tools/javac/overload/T6776289.java ! test/tools/javac/overrridecrash/A.java ! test/tools/javac/overrridecrash/B.java ! test/tools/javac/p1/AS.java ! test/tools/javac/p1/BS.java ! test/tools/javac/p1/CS.java ! test/tools/javac/packone/Mediator.java ! test/tools/javac/packone/Secret.java ! test/tools/javac/policy/test1/A.java ! test/tools/javac/policy/test1/D.java ! test/tools/javac/policy/test1/Test1a.java ! test/tools/javac/policy/test1/Test1b.java ! test/tools/javac/policy/test2/A.java ! test/tools/javac/policy/test2/B.java ! test/tools/javac/policy/test2/Test.java ! test/tools/javac/policy/test3/Test.java ! test/tools/javac/positions/T6402077.java ! test/tools/javac/positions/T6404194.java ! test/tools/javac/processing/6348193/T6348193.java ! test/tools/javac/processing/6348499/A.java ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/6350124/HelloWorldAP.java ! test/tools/javac/processing/6350124/Marked.java ! test/tools/javac/processing/6350124/Marker.java ! test/tools/javac/processing/6350124/T6350124.java ! test/tools/javac/processing/6359313/Foo.java ! test/tools/javac/processing/6359313/T6359313.java ! test/tools/javac/processing/6359313/package-info.java ! test/tools/javac/processing/6365040/ProcBar.java ! test/tools/javac/processing/6365040/ProcFoo.java ! test/tools/javac/processing/6365040/T6365040.java ! test/tools/javac/processing/6378728/T6378728.java ! test/tools/javac/processing/6413690/T6413690.java ! test/tools/javac/processing/6413690/TestMe.java ! test/tools/javac/processing/6413690/src/Super.java ! test/tools/javac/processing/6414633/A.java ! test/tools/javac/processing/6414633/T6414633.java ! test/tools/javac/processing/6430209/T6430209.java ! test/tools/javac/processing/6430209/b6341534.java ! test/tools/javac/processing/6430209/test0.java ! test/tools/javac/processing/6430209/test1.java ! test/tools/javac/processing/6499119/ClassProcessor.java ! test/tools/javac/processing/6499119/package-info.java ! test/tools/javac/processing/6511613/DummyProcessor.java ! test/tools/javac/processing/6511613/clss41701.java ! test/tools/javac/processing/6512707/T6512707.java ! test/tools/javac/processing/6512707/TestAnnotation.java ! test/tools/javac/processing/6512707/TestEnum.java ! test/tools/javac/processing/6634138/Dummy.java ! test/tools/javac/processing/6634138/ExerciseDependency.java ! test/tools/javac/processing/6634138/T6634138.java ! test/tools/javac/processing/T6439826.java ! test/tools/javac/processing/T6920317.java ! test/tools/javac/processing/Xprint.java ! test/tools/javac/processing/completion/TestCompletions.java ! test/tools/javac/processing/environment/HelloWorld.java ! test/tools/javac/processing/environment/TestSourceVersion.java ! test/tools/javac/processing/environment/round/AnnotatedElementInfo.java ! test/tools/javac/processing/environment/round/BuriedAnnotations.java ! test/tools/javac/processing/environment/round/C1.java ! test/tools/javac/processing/environment/round/C2.java ! test/tools/javac/processing/environment/round/Foo.java ! test/tools/javac/processing/environment/round/InheritedAnnotation.java ! test/tools/javac/processing/environment/round/Part1.java ! test/tools/javac/processing/environment/round/Part2.java ! test/tools/javac/processing/environment/round/SurfaceAnnotations.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/tools/javac/processing/errors/Foo.java ! test/tools/javac/processing/errors/TestFatalityOfParseErrors.java ! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java ! test/tools/javac/processing/errors/TestReturnCode.java ! test/tools/javac/processing/filer/TestFilerConstraints.java ! test/tools/javac/processing/filer/TestGetResource.java ! test/tools/javac/processing/filer/TestPackageInfo.java ! test/tools/javac/processing/filer/foo/Foo.java ! test/tools/javac/processing/filer/foo/bar/FuBar.java ! test/tools/javac/processing/filer/foo/bar/package-info.java ! test/tools/javac/processing/messager/MessagerBasics.java ! test/tools/javac/processing/model/6194785/T6194785.java ! test/tools/javac/processing/model/6194785/T6194785a.java ! test/tools/javac/processing/model/6341534/T6341534.java ! test/tools/javac/processing/model/6341534/dir/Foo.java ! test/tools/javac/processing/model/6341534/dir/package-info.java ! test/tools/javac/processing/model/TestExceptions.java ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/processing/model/element/TestAnonSourceNames.java ! test/tools/javac/processing/model/element/TestElement.java ! test/tools/javac/processing/model/element/TestNames.java ! test/tools/javac/processing/model/element/TestPackageElement.java ! test/tools/javac/processing/model/element/TypeParamBounds.java ! test/tools/javac/processing/model/testgetallmembers/Main.java ! test/tools/javac/processing/model/type/MirroredTypeEx/NpeTest.java ! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/type/TestTypeKind.java ! test/tools/javac/processing/model/util/BinaryName.java ! test/tools/javac/processing/model/util/GetTypeElemBadArg.java ! test/tools/javac/processing/model/util/NoSupers.java ! test/tools/javac/processing/model/util/OverridesSpecEx.java ! test/tools/javac/processing/model/util/Superless.java ! test/tools/javac/processing/model/util/TypesBadArg.java ! test/tools/javac/processing/model/util/deprecation/Dep1.java ! test/tools/javac/processing/model/util/deprecation/ExpectedDeprecation.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/tools/javac/processing/model/util/directSupersOfErr/C1.java ! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java ! test/tools/javac/processing/model/util/elements/Foo.java ! test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java ! test/tools/javac/processing/model/util/elements/TestGetPackageOf.java ! test/tools/javac/processing/model/util/elements/VacuousEnum.java ! test/tools/javac/processing/model/util/filter/ExpectedElementCounts.java ! test/tools/javac/processing/model/util/filter/Foo1.java ! test/tools/javac/processing/model/util/filter/TestIterables.java ! test/tools/javac/processing/warnings/HelloWorld.java ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/tools/javac/proprietary/WarnClass.java ! test/tools/javac/proprietary/WarnImport.java ! test/tools/javac/proprietary/WarnMethod.java ! test/tools/javac/proprietary/WarnStaticImport.java ! test/tools/javac/proprietary/WarnVariable.java ! test/tools/javac/proprietary/WarnWildcard.java ! test/tools/javac/protectedAccess/ProtectedAccess_1.java ! test/tools/javac/protectedAccess/ProtectedAccess_2.java ! test/tools/javac/protectedAccess/ProtectedAccess_3.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess1.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess5/Main.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess5/z1/Z1.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess5/z2/Z2.java ! test/tools/javac/protectedAccess/p/SuperClass.java ! test/tools/javac/protectedAccess/pkg/SuperClass.java ! test/tools/javac/protectedInner/AnonInnerClass.java ! test/tools/javac/protectedInner/InnerClass.java ! test/tools/javac/protectedInner/Outerclass.java ! test/tools/javac/protectedInner/mypackage/Superclass.java ! test/tools/javac/protectedInner/pkg1/Base.java ! test/tools/javac/protectedInner/pkg2/Sub.java ! test/tools/javac/quid/MakeNegTests.sh ! test/tools/javac/quid/QuotedIdent.java ! test/tools/javac/quid/QuotedIdent2.java ! test/tools/javac/rawDiags/Note.java ! test/tools/javac/scope/6225935/Bar.java ! test/tools/javac/scope/6225935/Baz.java ! test/tools/javac/scope/6225935/Estatico4.java ! test/tools/javac/scope/6225935/StaticImportAccess.java ! test/tools/javac/scope/6225935/T6214959.java ! test/tools/javac/scope/6225935/T6225935.java ! test/tools/javac/scope/6225935/T6381787.java ! test/tools/javac/scope/6225935/Test.java ! test/tools/javac/scope/6225935/a/Ambiguous.java ! test/tools/javac/scope/6225935/a/Named.java ! test/tools/javac/scope/6225935/a/Private.java ! test/tools/javac/scope/6225935/a/Star.java ! test/tools/javac/scope/6392998/T6392998.java ! test/tools/javac/sourcePath/SourcePath.java ! test/tools/javac/sourcePath/SourcePathA.java ! test/tools/javac/sourcePath2/SourcePath2.java ! test/tools/javac/sourcePath2/p/SourcePath2A.java ! test/tools/javac/stackmap/T4955930.java ! test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/stackmap/UninitThis.java ! test/tools/javac/staticImport/6665223/T6665223.java ! test/tools/javac/staticImport/6665223/pkg/A.java ! test/tools/javac/staticImport/6665223/pkg/B.java ! test/tools/javac/staticImport/6695838/T6695838.java ! test/tools/javac/staticImport/6695838/a/Foo.java ! test/tools/javac/staticImport/6695838/a/FooInterface.java ! test/tools/javac/staticImport/Ambig1.java ! test/tools/javac/staticImport/ImportInherit.java ! test/tools/javac/staticImport/ImportPrivate.java ! test/tools/javac/staticImport/PrivateStaticImport.java ! test/tools/javac/staticImport/Shadow.java ! test/tools/javac/staticImport/StaticImport.java ! test/tools/javac/staticImport/StaticImport2.java ! test/tools/javac/staticQualifiedNew/StaticQualifiedNew.java ! test/tools/javac/staticQualifiedNew/p2/X.java ! test/tools/javac/synthesize/Boolean.java ! test/tools/javac/synthesize/Byte.java ! test/tools/javac/synthesize/Character.java ! test/tools/javac/synthesize/Cloneable.java ! test/tools/javac/synthesize/Integer.java ! test/tools/javac/synthesize/Long.java ! test/tools/javac/synthesize/Main.java ! test/tools/javac/synthesize/Number.java ! test/tools/javac/synthesize/Object.java ! test/tools/javac/synthesize/Serializable.java ! test/tools/javac/synthesize/Short.java ! test/tools/javac/synthesize/Test.java ! test/tools/javac/synthesize/Void.java ! test/tools/javac/tree/T6923080.java ! test/tools/javac/tree/TestAnnotatedAnonClass.java ! test/tools/javac/tree/TreePosTest.java ! test/tools/javac/tree/TreeScannerTest.java ! test/tools/javac/treeannotests/AnnoTreeTests.java ! test/tools/javac/treeannotests/DA.java ! test/tools/javac/treeannotests/TA.java ! test/tools/javac/treeannotests/Test.java ! test/tools/javac/treeannotests/TestProcessor.java ! test/tools/javac/typeAnnotations/InnerClass.java ! test/tools/javac/typeAnnotations/MultipleTargets.java ! test/tools/javac/typeAnnotations/TypeParameterTarget.java ! test/tools/javac/typeAnnotations/TypeUseTarget.java ! test/tools/javac/typeAnnotations/attribution/Scopes.java ! test/tools/javac/typeAnnotations/classfile/DeadCode.java ! test/tools/javac/typeAnnotations/failures/OldArray.java ! test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java ! test/tools/javac/typeAnnotations/newlocations/BasicTest.java ! test/tools/javac/typeAnnotations/newlocations/ClassExtends.java ! test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java ! test/tools/javac/typeAnnotations/newlocations/ClassParameters.java ! test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java ! test/tools/javac/typeAnnotations/newlocations/Expressions.java ! test/tools/javac/typeAnnotations/newlocations/Fields.java ! test/tools/javac/typeAnnotations/newlocations/LocalVariables.java ! test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java ! test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java ! test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java ! test/tools/javac/typeAnnotations/newlocations/Parameters.java ! test/tools/javac/typeAnnotations/newlocations/Receivers.java ! test/tools/javac/typeAnnotations/newlocations/Throws.java ! test/tools/javac/typeAnnotations/newlocations/TypeCasts.java ! test/tools/javac/typeAnnotations/newlocations/TypeParameters.java ! test/tools/javac/typeAnnotations/newlocations/Wildcards.java ! test/tools/javac/unicode/FirstChar.java ! test/tools/javac/unicode/FirstChar2.java ! test/tools/javac/unicode/NonasciiDigit.java ! test/tools/javac/unicode/NonasciiDigit2.java ! test/tools/javac/unicode/SubChar.java ! test/tools/javac/unicode/SupplementaryJavaID1.java ! test/tools/javac/unicode/SupplementaryJavaID2.java ! test/tools/javac/unicode/SupplementaryJavaID3.java ! test/tools/javac/unicode/SupplementaryJavaID4.java ! test/tools/javac/unicode/SupplementaryJavaID5.java ! test/tools/javac/unicode/SupplementaryJavaID6.java ! test/tools/javac/unicode/SupplementaryJavaID6.sh ! test/tools/javac/unicode/TripleQuote.java ! test/tools/javac/unicode/UnicodeAtEOL.java ! test/tools/javac/unicode/UnicodeCommentDelimiter.java ! test/tools/javac/unicode/UnicodeUnicode.java ! test/tools/javac/unicode/Unmappable.java ! test/tools/javac/unit/T6198196.java ! test/tools/javac/unit/util/convert/EnclosingCandidates.java ! test/tools/javac/unit/util/list/AbstractList.java ! test/tools/javac/unit/util/list/FromArray.java ! test/tools/javac/util/filemanager/TestName.java ! test/tools/javac/util/list/TList.java ! test/tools/javac/varargs/6730476/T6730476a.java ! test/tools/javac/varargs/6730476/T6730476b.java ! test/tools/javac/varargs/Anon.java ! test/tools/javac/varargs/BadSyntax2.java ! test/tools/javac/varargs/T6746184.java ! test/tools/javac/varargs/Varargs1.java ! test/tools/javac/varargs/VarargsOverride.java ! test/tools/javac/varargs/Warn1.java ! test/tools/javac/varargs/Warn2.java ! test/tools/javac/varargs/warning/Warn1.java ! test/tools/javac/varargs/warning/Warn2.java ! test/tools/javac/varargs/warning/Warn3.java ! test/tools/javac/versions/CheckClassFileVersion.java ! test/tools/javac/versions/check.sh ! test/tools/javac/warnings/DepAnn.java ! test/tools/javac/warnings/Finally.java ! test/tools/javac/warnings/Serial.java ! test/tools/javac/warnings/T6763518.java ! test/tools/javadoc/6176978/T6176978.java ! test/tools/javadoc/6176978/X.java ! test/tools/javadoc/BooleanConst.java ! test/tools/javadoc/BreakIteratorWarning.java ! test/tools/javadoc/FlagsTooEarly.java ! test/tools/javadoc/InlineTagsWithBraces.java ! test/tools/javadoc/LangVers.java ! test/tools/javadoc/MethodLinks.java ! test/tools/javadoc/NoStar.java ! test/tools/javadoc/T4994049/FileWithTabs.java ! test/tools/javadoc/T4994049/T4994049.java ! test/tools/javadoc/XWerror.java ! test/tools/javadoc/annotations/annotateMethodsFields/Main.java ! test/tools/javadoc/annotations/annotateMethodsFields/pkg1/A.java ! test/tools/javadoc/annotations/annotateMethodsFields/pkg1/B.java ! test/tools/javadoc/annotations/annotateMethodsFields/pkg1/E.java ! test/tools/javadoc/annotations/annotatePackage/Main.java ! test/tools/javadoc/annotations/annotatePackage/pkg1/A.java ! test/tools/javadoc/annotations/annotatePackage/pkg1/package-info.java ! test/tools/javadoc/annotations/annotatePackage/pkg2/B.java ! test/tools/javadoc/annotations/annotateParams/Main.java ! test/tools/javadoc/annotations/annotateParams/pkg1/A.java ! test/tools/javadoc/annotations/annotateParams/pkg1/C.java ! test/tools/javadoc/annotations/badVals/Main.java ! test/tools/javadoc/annotations/badVals/pkg1/A.java ! test/tools/javadoc/annotations/defaults/Main.java ! test/tools/javadoc/annotations/defaults/pkg1/A.java ! test/tools/javadoc/annotations/defaults/pkg1/B.java ! test/tools/javadoc/annotations/elementTypes/Main.java ! test/tools/javadoc/annotations/elementTypes/pkg1/A.java ! test/tools/javadoc/annotations/elementTypes/pkg1/B.java ! test/tools/javadoc/annotations/missing/Main.java ! test/tools/javadoc/annotations/missing/somepackage/MissingAnnotationClass.java ! test/tools/javadoc/annotations/shortcuts/Main.java ! test/tools/javadoc/annotations/shortcuts/pkg1/A.java ! test/tools/javadoc/annotations/shortcuts/pkg1/Array.java ! test/tools/javadoc/annotations/shortcuts/pkg1/Marker.java ! test/tools/javadoc/annotations/shortcuts/pkg1/Value.java ! test/tools/javadoc/badSuper/BadSuper.java ! test/tools/javadoc/badSuper/p/A.java ! test/tools/javadoc/badSuper/p/B.java ! test/tools/javadoc/completionFailure/CompletionFailure.java ! test/tools/javadoc/completionFailure/pkg/A.java ! test/tools/javadoc/completionFailure/pkg/B.java ! test/tools/javadoc/dupOk/DupOk.java ! test/tools/javadoc/dupOk/sp1/p/A.java ! test/tools/javadoc/dupOk/sp2/p/A.java ! test/tools/javadoc/dupOk/sp2/p/B.java ! test/tools/javadoc/enum/docComments/Main.java ! test/tools/javadoc/enum/docComments/pkg1/Operation.java ! test/tools/javadoc/enum/enumType/Main.java ! test/tools/javadoc/enum/enumType/pkg1/QuotablePerson.java ! test/tools/javadoc/generics/genericClass/Main.java ! test/tools/javadoc/generics/genericClass/pkg1/A.java ! test/tools/javadoc/generics/genericInnerAndOuter/Main.java ! test/tools/javadoc/generics/genericInnerAndOuter/pkg1/O.java ! test/tools/javadoc/generics/genericInnerAndOuter/pkg1/X.java ! test/tools/javadoc/generics/genericInterface/Main.java ! test/tools/javadoc/generics/genericInterface/pkg1/A.java ! test/tools/javadoc/generics/genericMethod/Main.java ! test/tools/javadoc/generics/genericMethod/pkg1/A.java ! test/tools/javadoc/generics/genericSuper/Main.java ! test/tools/javadoc/generics/genericSuper/pkg1/A.java ! test/tools/javadoc/generics/supertypes/Main.java ! test/tools/javadoc/generics/supertypes/pkg1/A.java ! test/tools/javadoc/generics/supertypes/pkg1/B.java ! test/tools/javadoc/generics/throwsGeneric/Main.java ! test/tools/javadoc/generics/throwsGeneric/pkg1/A.java ! test/tools/javadoc/generics/tparamCycle/Main.java ! test/tools/javadoc/generics/tparamCycle/pkg1/LikeEnum.java ! test/tools/javadoc/generics/tparamTagOnMethod/Main.java ! test/tools/javadoc/generics/tparamTagOnMethod/pkg1/A.java ! test/tools/javadoc/generics/tparamTagOnType/Main.java ! test/tools/javadoc/generics/tparamTagOnType/pkg1/A.java ! test/tools/javadoc/generics/wildcards/Main.java ! test/tools/javadoc/generics/wildcards/pkg1/A.java ! test/tools/javadoc/imports/I.java ! test/tools/javadoc/imports/MissingImport.java ! test/tools/javadoc/lib/Tester.java ! test/tools/javadoc/nestedClass/NestedClass.java ! test/tools/javadoc/nestedClass/NestedClassB.java ! test/tools/javadoc/outputRedirect/Test.java ! test/tools/javadoc/outputRedirect/p/OutputRedirect.java ! test/tools/javadoc/sourceOnly/Test.java ! test/tools/javadoc/sourceOnly/p/SourceOnly.java ! test/tools/javadoc/sourceOption/SourceOption.java ! test/tools/javadoc/sourceOption/p/A.java ! test/tools/javadoc/subpackageIgnore/SubpackageIgnore.java ! test/tools/javadoc/subpackageIgnore/pkg1/not-subpkg/SomeJavaFile.java ! test/tools/javadoc/varArgs/Main.java ! test/tools/javadoc/varArgs/pkg1/A.java ! test/tools/javah/6257087/foo.java ! test/tools/javah/6257087/foo.sh ! test/tools/javah/6572945/T6572945.java ! test/tools/javah/6572945/TestClass1.java ! test/tools/javah/6572945/TestClass2.java ! test/tools/javah/6572945/TestClass3.java ! test/tools/javah/ConstMacroTest.sh ! test/tools/javah/MissingParamClassException.java ! test/tools/javah/MissingParamClassTest.sh ! test/tools/javah/ParamClassTest.java ! test/tools/javah/ReadOldClass.sh ! test/tools/javah/SubClassConsts.java ! test/tools/javah/SuperClassConsts.java ! test/tools/javah/T5070898.java ! test/tools/javah/T6893943.java ! test/tools/javah/compareTest/CompareTest.java ! test/tools/javah/compareTest/CompareTest.sh ! test/tools/javah/compareTest/FindNativeFiles.java ! test/tools/javap/4111861/T4111861.java ! test/tools/javap/4870651/T4870651.java ! test/tools/javap/4870651/Test.java ! test/tools/javap/6937244/T6937244.java ! test/tools/javap/6937244/T6937244A.java ! test/tools/javap/ExtPath.java ! test/tools/javap/NotPackagePrivateInterface.java ! test/tools/javap/PublicInterfaceTest.sh ! test/tools/javap/T4075403.java ! test/tools/javap/T4459541.java ! test/tools/javap/T4501660.java ! test/tools/javap/T4501661.java ! test/tools/javap/T4777949.java ! test/tools/javap/T4876942.java ! test/tools/javap/T4880663.java ! test/tools/javap/T4880672.java ! test/tools/javap/T4884240.java ! test/tools/javap/T4975569.java ! test/tools/javap/T6271787.java ! test/tools/javap/T6474890.java ! test/tools/javap/T6587786.java ! test/tools/javap/T6622216.java ! test/tools/javap/T6622232.java ! test/tools/javap/T6622260.java ! test/tools/javap/T6715251.java ! test/tools/javap/T6715753.java ! test/tools/javap/T6715767.java ! test/tools/javap/T6716452.java ! test/tools/javap/T6729471.java ! test/tools/javap/T6824493.java ! test/tools/javap/T6863746.java ! test/tools/javap/T6866657.java ! test/tools/javap/T6868539.java ! test/tools/javap/T6879371.java ! test/tools/javap/classfile/6888367/T6888367.java ! test/tools/javap/classfile/T6887895.java ! test/tools/javap/classfile/deps/GetDeps.java ! test/tools/javap/classfile/deps/T6907575.java ! test/tools/javap/classfile/deps/p/C1.java ! test/tools/javap/pathsep.sh ! test/tools/javap/stackmap/T6271292.java ! test/tools/javap/stackmap/T6271292.sh ! test/tools/javap/typeAnnotations/ArrayClassLiterals.java ! test/tools/javap/typeAnnotations/ArrayClassLiterals2.java ! test/tools/javap/typeAnnotations/ClassLiterals.java ! test/tools/javap/typeAnnotations/JSR175Annotations.java ! test/tools/javap/typeAnnotations/NewArray.java ! test/tools/javap/typeAnnotations/Presence.java ! test/tools/javap/typeAnnotations/PresenceInner.java ! test/tools/javap/typeAnnotations/T6855990.java ! test/tools/javap/typeAnnotations/Visibility.java Changeset: 752bb790fc2d Author: ohair Date: 2010-05-26 10:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/752bb790fc2d Merge Changeset: 637c646c6412 Author: mikejwre Date: 2010-05-27 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/637c646c6412 Added tag jdk7-b95 for changeset 752bb790fc2d ! .hgtags From john.coomes at oracle.com Sat May 29 08:13:07 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 29 May 2010 08:13:07 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6956472: test/runtime/6888954/vmerrors.sh uses ksh-specific syntax Message-ID: <20100529081316.712A346E98@hg.openjdk.java.net> Changeset: 5b77884bd4b7 Author: jcoomes Date: 2010-05-27 13:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5b77884bd4b7 6956472: test/runtime/6888954/vmerrors.sh uses ksh-specific syntax Reviewed-by: jmelvin, kvn ! test/runtime/6888954/vmerrors.sh From linuxhippy at gmail.com Sat May 29 17:09:54 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 29 May 2010 19:09:54 +0200 Subject: UseCompressedOops switch with more than 32gb heaps... In-Reply-To: <28698669.post@talk.nabble.com> References: <28697759.post@talk.nabble.com> <4BFEB3D4.6040000@oracle.com> <28698254.post@talk.nabble.com> <4BFEC040.4040007@oracle.com> <28698669.post@talk.nabble.com> Message-ID: Hi, > I did not find the two bugs you mentioned in the Hotspot bug database. Are > they only accessible to you internally and not exposed to the public world? > > I looked here. > > http://bugs.sun.com/bugdatabase/ There've been some strange things been going on with the public bug database, most recent bugs don't seem to be public visible. Probably some takeover related descisions, however I hope thats not the case .... - Clemens