From Antonios.Printezis at sun.com Mon Nov 3 08:10:01 2008 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Mon, 03 Nov 2008 11:10:01 -0500 Subject: Modifying the JVM to have a more deterministic garbage collection model In-Reply-To: <9198d5d0810311229s38e61e42r4f7ec28e89540268@mail.gmail.com> References: <9198d5d0810311229s38e61e42r4f7ec28e89540268@mail.gmail.com> Message-ID: <490F2259.7070105@sun.com> Hi there, How long will you have to do this and how familiar are you with modifying JVMs? I don't mean to put you off, but implementing an RC GC in HotSpot is not a trivial project. Not only you will have to implement the memory management part (maybe the CMS old gen will be a good start for this, given that it doesn't compact like all other GCs and RC typically requires a non-moving space), but also you will have to modify the JVM / interpreter / JIT to change the barriers to maintain the reference counts. Modifying the JIT will be tricky (C1, the client JIT, will be easier; C2, the server JIT, will be much harded). So, maybe, you could do this by turning off the JIT and run interpreter-only. Look at the oop_store* methods in oop.hpp to see how to change the barriers in the JVM (but I think you'll still need to modify the interpreter). Good luck. :-) Tony mirza2m at gmail.com wrote: > Hi, > For my class project I want to modify the JVM to have a more > deterministic garbage collection model. I will take a reference > counting approach to accomplish this. More specifically I will use a > variation of the algorithm described here > > http://www.jucs.org/jucs_13_6/cyclic_reference_counting_with/jucs_13_6_0830_0838_lins.pdf > > > In order to do this I need to store reference count or multiple > reference counts for each object. I will also need to update these > counts when a reference is added or removed. I need some help on > figuring out what would be the best way to do this? Can this be done > by tweaking or replacing some parts of the jvm or would I have to do > an over haul of the whole jvm (I hope that is not the case :) ) I have > looked at some of the source code at src/share/vm/{memory, > gc-interface, gc-implementation} but seems like this only handles > garbage collection it self, I also wanted to know where I would put > hooks to update refrence counts and what would be the best place to > store the reference counts, with in the object itself or somewhere > else. Any suggestion on software engineering aspect of this project > would also be very helpful. > > > Thank you -- ---------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS BUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | ---------------------------------------------------------------------- e-mail client: Thunderbird (Solaris) From twisti at complang.tuwien.ac.at Tue Nov 4 03:45:51 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Tue, 04 Nov 2008 12:45:51 +0100 Subject: Modifying the JVM to have a more deterministic garbage collection model In-Reply-To: <490F2259.7070105@sun.com> References: <9198d5d0810311229s38e61e42r4f7ec28e89540268@mail.gmail.com> <490F2259.7070105@sun.com> Message-ID: <1225799151.1112.58.camel@localhost> On Mon, 2008-11-03 at 11:10 -0500, Tony Printezis wrote: > Hi there, > > How long will you have to do this and how familiar are you with > modifying JVMs? I don't mean to put you off, but implementing an RC GC > in HotSpot is not a trivial project. Not only you will have to implement > the memory management part (maybe the CMS old gen will be a good start > for this, given that it doesn't compact like all other GCs and RC > typically requires a non-moving space), but also you will have to modify > the JVM / interpreter / JIT to change the barriers to maintain the > reference counts. Modifying the JIT will be tricky (C1, the client JIT, > will be easier; C2, the server JIT, will be much harded). So, maybe, you > could do this by turning off the JIT and run interpreter-only. Look at > the oop_store* methods in oop.hpp to see how to change the barriers in > the JVM (but I think you'll still need to modify the interpreter). My advice would be to use a simpler JVM than HotSpot. You should probably have a look at JamVM[1]. You could also try CACAO[2] or Kaffe[3], but I think JamVM will be the easiest one. [1] http://jamvm.sourceforge.net/ [2] http://www.cacaovm.org/ [3] http://www.kaffe.org/ - Christian From Y.S.Ramakrishna at Sun.COM Tue Nov 4 14:49:56 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Tue, 04 Nov 2008 14:49:56 -0800 Subject: Where have the Full GCs gone? In-Reply-To: <0E7AF2AC-F167-41AB-9780-873DBF58DACD@apple.com> References: <0E7AF2AC-F167-41AB-9780-873DBF58DACD@apple.com> Message-ID: Hi Moazam -- With the CMS collector, look for GC lines tagged with the string "CMS". Those indicate CMS collection activity. Please refer to the GC tuning guide (under "low pause collector," for sample output. There may also be full stop-world collections because of, for example, promotion failure, which may not be explicitly called out as a scavenge bails to a full collection. In those cases, look for the string "fail". In more recent JVM's in addition to the "gc invocations" count (which you see in yr +PrintHeapAtGC output below), you will also see "full = ..." counts which will tell you the number of major cycles that happened. If you have jstat on OS X, then jstat -gc would also give you FGC and FGCT which are respectively the number of and time spent in major gc cycles (these counters however are if i recall correctly somewhat misleading in the case of CMS). -- ramki ----- Original Message ----- From: Moazam Raja Date: Tuesday, November 4, 2008 2:41 pm Subject: Where have the Full GCs gone? To: hotspot-gc-use at openjdk.java.net > Hi all, I'm running a test and recording GC information on a Tomcat > application and have noticed that even after a few days, there are no > > 'Full GC' markers. Am I reading the log incorrectly, or are the Full > > GCs getting logged elsewhere? > > I'm using Java 1.5.0_13 on OS X with the following flags, > > -Xms=2048m -Xmx=2048m > -server -XX:+UseConcMarkSweepGC > -Xloggc:/var/tmp/GC.log > -verbose:gc > -XX:+PrintGCDetails > -XX:+PrintHeapAtGC > -XX:+PrintClassHistogram > -XX:+PrintGCApplicationConcurrentTime > > > A sample of the output from my GC log: > > > Application time: 1.4105823 seconds > 82558.187: [GC {Heap before gc invocations=111716: > par new generation total 21184K, used 21120K [0x0000000107270000, > > 0x0000000108730000, 0x0000000108730000) > eden space 21120K, 100% used [0x0000000107270000, > 0x0000000108710000, 0x0000000108710000) > from space 64K, 0% used [0x0000000108710000, 0x0000000108710000, > > 0x0000000108720000) > to space 64K, 0% used [0x0000000108720000, 0x0000000108720000, > > 0x0000000108730000) > concurrent mark-sweep generation total 20950272K, used 5483440K > [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > concurrent-mark-sweep perm gen total 39296K, used 23575K > [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > 82558.187: [ParNew: 21120K->0K(21184K), 0.0669633 secs] 5504560K- > >5487545K(20971456K)Heap after gc invocations=111717: > par new generation total 21184K, used 0K [0x0000000107270000, > 0x0000000108730000, 0x0000000108730000) > eden space 21120K, 0% used [0x0000000107270000, > 0x0000000107270000, 0x0000000108710000) > from space 64K, 0% used [0x0000000108720000, 0x0000000108720000, > > 0x0000000108730000) > to space 64K, 0% used [0x0000000108710000, 0x0000000108710000, > > 0x0000000108720000) > concurrent mark-sweep generation total 20950272K, used 5487545K > [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > concurrent-mark-sweep perm gen total 39296K, used 23575K > [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > } > , 0.0672098 secs] > > Application time: 0.4661567 seconds > 82558.721: [GC {Heap before gc invocations=111717: > par new generation total 21184K, used 21120K [0x0000000107270000, > > 0x0000000108730000, 0x0000000108730000) > eden space 21120K, 100% used [0x0000000107270000, > 0x0000000108710000, 0x0000000108710000) > from space 64K, 0% used [0x0000000108720000, 0x0000000108720000, > > 0x0000000108730000) > to space 64K, 0% used [0x0000000108710000, 0x0000000108710000, > > 0x0000000108720000) > concurrent mark-sweep generation total 20950272K, used 5487545K > [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > concurrent-mark-sweep perm gen total 39296K, used 23575K > [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > 82558.721: [ParNew: 21120K->0K(21184K), 0.0591967 secs] 5508665K- > >5491650K(20971456K)Heap after gc invocations=111718: > par new generation total 21184K, used 0K [0x0000000107270000, > 0x0000000108730000, 0x0000000108730000) > eden space 21120K, 0% used [0x0000000107270000, > 0x0000000107270000, 0x0000000108710000) > from space 64K, 0% used [0x0000000108710000, 0x0000000108710000, > > 0x0000000108720000) > to space 64K, 0% used [0x0000000108720000, 0x0000000108720000, > > 0x0000000108730000) > concurrent mark-sweep generation total 20950272K, used 5491650K > [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > concurrent-mark-sweep perm gen total 39296K, used 23575K > [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > } > , 0.0594283 secs] > > Application time: 0.0590593 seconds > 82558.840: [GC {Heap before gc invocations=111718: > par new generation total 21184K, used 21120K [0x0000000107270000, > > 0x0000000108730000, 0x0000000108730000) > eden space 21120K, 100% used [0x0000000107270000, > 0x0000000108710000, 0x0000000108710000) > from space 64K, 0% used [0x0000000108710000, 0x0000000108710000, > > 0x0000000108720000) > to space 64K, 0% used [0x0000000108720000, 0x0000000108720000, > > 0x0000000108730000) > concurrent mark-sweep generation total 20950272K, used 5491650K > [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > concurrent-mark-sweep perm gen total 39296K, used 23575K > [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > 82558.840: [ParNew: 21120K->0K(21184K), 0.0589090 secs] 5512770K- > >5496450K(20971456K)Heap after gc invocations=111719: > par new generation total 21184K, used 0K [0x0000000107270000, > 0x0000000108730000, 0x0000000108730000) > eden space 21120K, 0% used [0x0000000107270000, > 0x0000000107270000, 0x0000000108710000) > from space 64K, 0% used [0x0000000108720000, 0x0000000108720000, > > 0x0000000108730000) > to space 64K, 0% used [0x0000000108710000, 0x0000000108710000, > > 0x0000000108720000) > concurrent mark-sweep generation total 20950272K, used 5496450K > [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > concurrent-mark-sweep perm gen total 39296K, used 23575K > [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > } > , 0.0592058 secs] > > > -Moazam > > _______________________________________________ > 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 Sun.COM Tue Nov 4 15:45:25 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Tue, 04 Nov 2008 15:45:25 -0800 Subject: Where have the Full GCs gone? In-Reply-To: <6323F0D0-3FD0-4FB0-BF63-BF73546DE338@apple.com> References: <0E7AF2AC-F167-41AB-9780-873DBF58DACD@apple.com> <6323F0D0-3FD0-4FB0-BF63-BF73546DE338@apple.com> Message-ID: There's gchisto, a link to which was recently sent out on this list by Tony. Here's the link again:- https://gchisto.dev.java.net/ Google should give you a few other useful links, including some examples and user experiences. BTW, I am not sure if gchisto in its current form will accept gc logs that have PrintHeapAtGC information. You'll need to elide that information, or update GCHisto's parser to do so. Although jconsole does not have some of these capabilities, it has a subset and can be used to monitor a running jvm, so you should check it out to see if it suits your purposes. Finally, there's VisualVM ( https://visualvm.dev.java.net/ ) which might also have a suitable plugin, i am not sure though. (Then there's VisualGC, which I heard was going to be available as a plugin for VisualVM.) -- ramki ----- Original Message ----- From: Moazam Raja Date: Tuesday, November 4, 2008 3:26 pm Subject: Re: Where have the Full GCs gone? To: hotspot-gc-use at openjdk.java.net > Ramki, thanks! > > Do you know if there is a tool which I can feed this GC log into and > > get some graphs? > > -Moazam > > On Nov 4, 2008, at 2:49 PM, Y Srinivas Ramakrishna wrote: > > > Hi Moazam -- > > > > With the CMS collector, look for GC lines tagged with the > > string "CMS". Those indicate CMS collection activity. > > Please refer to the GC tuning guide (under "low pause collector," > > for sample output. > > > > There may also be full stop-world collections because of, > > for example, promotion failure, which may not be explicitly called > > out as a scavenge bails to a full collection. In those cases, > > look for the string "fail". > > > > In more recent JVM's in addition to the "gc invocations" count > > (which you see in yr +PrintHeapAtGC output below), you will also > > see "full = ..." counts which will tell you the number of major > > cycles that happened. > > > > If you have jstat on OS X, then jstat -gc would also give you > > FGC and FGCT which are respectively the number of and time spent > > in major gc cycles (these counters however are if i recall correctly > > somewhat misleading in the case of CMS). > > > > -- ramki > > > > ----- Original Message ----- > > From: Moazam Raja > > Date: Tuesday, November 4, 2008 2:41 pm > > Subject: Where have the Full GCs gone? > > To: hotspot-gc-use at openjdk.java.net > > > > > >> Hi all, I'm running a test and recording GC information on a Tomcat > >> application and have noticed that even after a few days, there are > no > >> > >> 'Full GC' markers. Am I reading the log incorrectly, or are the Full > >> > >> GCs getting logged elsewhere? > >> > >> I'm using Java 1.5.0_13 on OS X with the following flags, > >> > >> -Xms=2048m -Xmx=2048m > >> -server -XX:+UseConcMarkSweepGC > >> -Xloggc:/var/tmp/GC.log > >> -verbose:gc > >> -XX:+PrintGCDetails > >> -XX:+PrintHeapAtGC > >> -XX:+PrintClassHistogram > >> -XX:+PrintGCApplicationConcurrentTime > >> > >> > >> A sample of the output from my GC log: > >> > >> > >> Application time: 1.4105823 seconds > >> 82558.187: [GC {Heap before gc invocations=111716: > >> par new generation total 21184K, used 21120K [0x0000000107270000, > >> > >> 0x0000000108730000, 0x0000000108730000) > >> eden space 21120K, 100% used [0x0000000107270000, > >> 0x0000000108710000, 0x0000000108710000) > >> from space 64K, 0% used [0x0000000108710000, 0x0000000108710000, > >> > >> 0x0000000108720000) > >> to space 64K, 0% used [0x0000000108720000, 0x0000000108720000, > >> > >> 0x0000000108730000) > >> concurrent mark-sweep generation total 20950272K, used 5483440K > >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > >> concurrent-mark-sweep perm gen total 39296K, used 23575K > >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > >> 82558.187: [ParNew: 21120K->0K(21184K), 0.0669633 secs] 5504560K- > >>> 5487545K(20971456K)Heap after gc invocations=111717: > >> par new generation total 21184K, used 0K [0x0000000107270000, > >> 0x0000000108730000, 0x0000000108730000) > >> eden space 21120K, 0% used [0x0000000107270000, > >> 0x0000000107270000, 0x0000000108710000) > >> from space 64K, 0% used [0x0000000108720000, 0x0000000108720000, > >> > >> 0x0000000108730000) > >> to space 64K, 0% used [0x0000000108710000, 0x0000000108710000, > >> > >> 0x0000000108720000) > >> concurrent mark-sweep generation total 20950272K, used 5487545K > >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > >> concurrent-mark-sweep perm gen total 39296K, used 23575K > >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > >> } > >> , 0.0672098 secs] > >> > >> Application time: 0.4661567 seconds > >> 82558.721: [GC {Heap before gc invocations=111717: > >> par new generation total 21184K, used 21120K [0x0000000107270000, > >> > >> 0x0000000108730000, 0x0000000108730000) > >> eden space 21120K, 100% used [0x0000000107270000, > >> 0x0000000108710000, 0x0000000108710000) > >> from space 64K, 0% used [0x0000000108720000, 0x0000000108720000, > >> > >> 0x0000000108730000) > >> to space 64K, 0% used [0x0000000108710000, 0x0000000108710000, > >> > >> 0x0000000108720000) > >> concurrent mark-sweep generation total 20950272K, used 5487545K > >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > >> concurrent-mark-sweep perm gen total 39296K, used 23575K > >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > >> 82558.721: [ParNew: 21120K->0K(21184K), 0.0591967 secs] 5508665K- > >>> 5491650K(20971456K)Heap after gc invocations=111718: > >> par new generation total 21184K, used 0K [0x0000000107270000, > >> 0x0000000108730000, 0x0000000108730000) > >> eden space 21120K, 0% used [0x0000000107270000, > >> 0x0000000107270000, 0x0000000108710000) > >> from space 64K, 0% used [0x0000000108710000, 0x0000000108710000, > >> > >> 0x0000000108720000) > >> to space 64K, 0% used [0x0000000108720000, 0x0000000108720000, > >> > >> 0x0000000108730000) > >> concurrent mark-sweep generation total 20950272K, used 5491650K > >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > >> concurrent-mark-sweep perm gen total 39296K, used 23575K > >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > >> } > >> , 0.0594283 secs] > >> > >> Application time: 0.0590593 seconds > >> 82558.840: [GC {Heap before gc invocations=111718: > >> par new generation total 21184K, used 21120K [0x0000000107270000, > >> > >> 0x0000000108730000, 0x0000000108730000) > >> eden space 21120K, 100% used [0x0000000107270000, > >> 0x0000000108710000, 0x0000000108710000) > >> from space 64K, 0% used [0x0000000108710000, 0x0000000108710000, > >> > >> 0x0000000108720000) > >> to space 64K, 0% used [0x0000000108720000, 0x0000000108720000, > >> > >> 0x0000000108730000) > >> concurrent mark-sweep generation total 20950272K, used 5491650K > >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > >> concurrent-mark-sweep perm gen total 39296K, used 23575K > >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > >> 82558.840: [ParNew: 21120K->0K(21184K), 0.0589090 secs] 5512770K- > >>> 5496450K(20971456K)Heap after gc invocations=111719: > >> par new generation total 21184K, used 0K [0x0000000107270000, > >> 0x0000000108730000, 0x0000000108730000) > >> eden space 21120K, 0% used [0x0000000107270000, > >> 0x0000000107270000, 0x0000000108710000) > >> from space 64K, 0% used [0x0000000108720000, 0x0000000108720000, > >> > >> 0x0000000108730000) > >> to space 64K, 0% used [0x0000000108710000, 0x0000000108710000, > >> > >> 0x0000000108720000) > >> concurrent mark-sweep generation total 20950272K, used 5496450K > >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > >> concurrent-mark-sweep perm gen total 39296K, used 23575K > >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > >> } > >> , 0.0592058 secs] > >> > >> > >> -Moazam > >> > >> _______________________________________________ > >> 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 Peter.Kessler at Sun.COM Tue Nov 4 16:52:20 2008 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Tue, 04 Nov 2008 16:52:20 -0800 Subject: Where have the Full GCs gone? In-Reply-To: <0E7AF2AC-F167-41AB-9780-873DBF58DACD@apple.com> References: <0E7AF2AC-F167-41AB-9780-873DBF58DACD@apple.com> Message-ID: <4910EE44.7060704@Sun.COM> Moazam Raja wrote: > Hi all, I'm running a test and recording GC information on a Tomcat > application and have noticed that even after a few days, there are no > 'Full GC' markers. Am I reading the log incorrectly, or are the Full > GCs getting logged elsewhere? > > I'm using Java 1.5.0_13 on OS X with the following flags, > > -Xms=2048m -Xmx=2048m > -server -XX:+UseConcMarkSweepGC > -Xloggc:/var/tmp/GC.log > -verbose:gc > -XX:+PrintGCDetails > -XX:+PrintHeapAtGC > -XX:+PrintClassHistogram > -XX:+PrintGCApplicationConcurrentTime > > > A sample of the output from my GC log: > > > Application time: 1.4105823 seconds > 82558.187: [GC {Heap before gc invocations=111716: > par new generation total 21184K, used 21120K [0x0000000107270000, 0x0000000108730000, 0x0000000108730000) > eden space 21120K, 100% used [0x0000000107270000, 0x0000000108710000, 0x0000000108710000) > from space 64K, 0% used [0x0000000108710000, 0x0000000108710000, 0x0000000108720000) > to space 64K, 0% used [0x0000000108720000, 0x0000000108720000, 0x0000000108730000) > concurrent mark-sweep generation total 20950272K, used 5483440K [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > concurrent-mark-sweep perm gen total 39296K, used 23575K [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > 82558.187: [ParNew: 21120K->0K(21184K), 0.0669633 secs] 5504560K->5487545K(20971456K)Heap after gc invocations=111717: > par new generation total 21184K, used 0K [0x0000000107270000, 0x0000000108730000, 0x0000000108730000) > eden space 21120K, 0% used [0x0000000107270000, 0x0000000107270000, 0x0000000108710000) > from space 64K, 0% used [0x0000000108720000, 0x0000000108720000, 0x0000000108730000) > to space 64K, 0% used [0x0000000108710000, 0x0000000108710000, 0x0000000108720000) > concurrent mark-sweep generation total 20950272K, used 5487545K [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) > concurrent-mark-sweep perm gen total 39296K, used 23575K [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) > } > , 0.0672098 secs] > ... I don't think those are the command line arguments for the GC log you show. It looks from the PrintHeapAtGG output that your heap is 20GB, not the 2GB shown on the command line. 20MB in the "par new" generation, and the reast of the 20GB in the CMS generation. It looks like you are using just over 5GB of CMS space, which would explain why you haven't seen an old generation collection yet. ... peter _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Peter.Kessler at Sun.COM Tue Nov 4 17:38:01 2008 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Tue, 04 Nov 2008 17:38:01 -0800 Subject: Where have the Full GCs gone? In-Reply-To: <242C68AA-B22F-4C78-9866-60FE648C80BC@apple.com> References: <0E7AF2AC-F167-41AB-9780-873DBF58DACD@apple.com> <4910EE44.7060704@Sun.COM> <242C68AA-B22F-4C78-9866-60FE648C80BC@apple.com> Message-ID: <4910F8F9.90702@Sun.COM> You can *reserve* more virtual memory than you have physical memory. You just won't be happy when you exceed the amount of physical memory you have. How much physical memory do you have? If it's, say 8GB, you might not be to the point of paging, so things will look fine. But I suspect that at some point your application time and your GC times will rise as you need to page the heap to follow references. Usually that's a pretty steep cliff. This is Apple's port of JDK-1.5.0_13, right? I can't imagine that they changed the output format. ... peter Moazam Raja wrote: > Peter, this must be a bug in the GC output as I know for sure I don't > have the memory to run a 20GB heap. > > Instead of 20950272K, it must mean 20950272K*b*. > > This is on Java 1.5.0 on OS X Leopard. > > java version "1.5.0_13" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237) > Java HotSpot(TM) Server VM (build 1.5.0_13-119, mixed mode) > > > -Moazam > > On Nov 4, 2008, at 4:52 PM, Peter B. Kessler wrote: > >> Moazam Raja wrote: >>> Hi all, I'm running a test and recording GC information on a Tomcat >>> application and have noticed that even after a few days, there are >>> no 'Full GC' markers. Am I reading the log incorrectly, or are the >>> Full GCs getting logged elsewhere? >>> I'm using Java 1.5.0_13 on OS X with the following flags, >>> -Xms=2048m -Xmx=2048m >>> -server -XX:+UseConcMarkSweepGC >>> -Xloggc:/var/tmp/GC.log >>> -verbose:gc >>> -XX:+PrintGCDetails >>> -XX:+PrintHeapAtGC >>> -XX:+PrintClassHistogram >>> -XX:+PrintGCApplicationConcurrentTime >>> A sample of the output from my GC log: >>> Application time: 1.4105823 seconds >>> 82558.187: [GC {Heap before gc invocations=111716: >>> par new generation total 21184K, used 21120K [0x0000000107270000, 0x0000000108730000, 0x0000000108730000) >>> eden space 21120K, 100% used [0x0000000107270000, 0x0000000108710000, 0x0000000108710000) >>> from space 64K, 0% used [0x0000000108710000, 0x0000000108710000, 0x0000000108720000) >>> to space 64K, 0% used [0x0000000108720000, 0x0000000108720000, 0x0000000108730000) >>> concurrent mark-sweep generation total 20950272K, used 5483440K [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) >>> concurrent-mark-sweep perm gen total 39296K, used 23575K [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) >>> 82558.187: [ParNew: 21120K->0K(21184K), 0.0669633 secs] 5504560K->5487545K(20971456K)Heap after gc invocations=111717: >>> par new generation total 21184K, used 0K [0x0000000107270000, 0x0000000108730000, 0x0000000108730000) >>> eden space 21120K, 0% used [0x0000000107270000, 0x0000000107270000, 0x0000000108710000) >>> from space 64K, 0% used [0x0000000108720000, 0x0000000108720000, 0x0000000108730000) >>> to space 64K, 0% used [0x0000000108710000, 0x0000000108710000, 0x0000000108720000) >>> concurrent mark-sweep generation total 20950272K, used 5487545K [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) >>> concurrent-mark-sweep perm gen total 39296K, used 23575K [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) >>> } >>> , 0.0672098 secs] >>> ... >> >> I don't think those are the command line arguments for the GC log you >> show. It looks from the PrintHeapAtGG output that your heap is 20GB, >> not the 2GB shown on the command line. 20MB in the "par new" >> generation, and the reast of the 20GB in the CMS generation. >> >> It looks like you are using just over 5GB of CMS space, which would >> explain why you haven't seen an old generation collection yet. >> >> ... peter > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From moazam at apple.com Tue Nov 4 15:26:14 2008 From: moazam at apple.com (Moazam Raja) Date: Tue, 4 Nov 2008 15:26:14 -0800 Subject: Where have the Full GCs gone? In-Reply-To: References: <0E7AF2AC-F167-41AB-9780-873DBF58DACD@apple.com> Message-ID: <6323F0D0-3FD0-4FB0-BF63-BF73546DE338@apple.com> Ramki, thanks! Do you know if there is a tool which I can feed this GC log into and get some graphs? -Moazam On Nov 4, 2008, at 2:49 PM, Y Srinivas Ramakrishna wrote: > Hi Moazam -- > > With the CMS collector, look for GC lines tagged with the > string "CMS". Those indicate CMS collection activity. > Please refer to the GC tuning guide (under "low pause collector," > for sample output. > > There may also be full stop-world collections because of, > for example, promotion failure, which may not be explicitly called > out as a scavenge bails to a full collection. In those cases, > look for the string "fail". > > In more recent JVM's in addition to the "gc invocations" count > (which you see in yr +PrintHeapAtGC output below), you will also > see "full = ..." counts which will tell you the number of major > cycles that happened. > > If you have jstat on OS X, then jstat -gc would also give you > FGC and FGCT which are respectively the number of and time spent > in major gc cycles (these counters however are if i recall correctly > somewhat misleading in the case of CMS). > > -- ramki > > ----- Original Message ----- > From: Moazam Raja > Date: Tuesday, November 4, 2008 2:41 pm > Subject: Where have the Full GCs gone? > To: hotspot-gc-use at openjdk.java.net > > >> Hi all, I'm running a test and recording GC information on a Tomcat >> application and have noticed that even after a few days, there are no >> >> 'Full GC' markers. Am I reading the log incorrectly, or are the Full >> >> GCs getting logged elsewhere? >> >> I'm using Java 1.5.0_13 on OS X with the following flags, >> >> -Xms=2048m -Xmx=2048m >> -server -XX:+UseConcMarkSweepGC >> -Xloggc:/var/tmp/GC.log >> -verbose:gc >> -XX:+PrintGCDetails >> -XX:+PrintHeapAtGC >> -XX:+PrintClassHistogram >> -XX:+PrintGCApplicationConcurrentTime >> >> >> A sample of the output from my GC log: >> >> >> Application time: 1.4105823 seconds >> 82558.187: [GC {Heap before gc invocations=111716: >> par new generation total 21184K, used 21120K [0x0000000107270000, >> >> 0x0000000108730000, 0x0000000108730000) >> eden space 21120K, 100% used [0x0000000107270000, >> 0x0000000108710000, 0x0000000108710000) >> from space 64K, 0% used [0x0000000108710000, 0x0000000108710000, >> >> 0x0000000108720000) >> to space 64K, 0% used [0x0000000108720000, 0x0000000108720000, >> >> 0x0000000108730000) >> concurrent mark-sweep generation total 20950272K, used 5483440K >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) >> concurrent-mark-sweep perm gen total 39296K, used 23575K >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) >> 82558.187: [ParNew: 21120K->0K(21184K), 0.0669633 secs] 5504560K- >>> 5487545K(20971456K)Heap after gc invocations=111717: >> par new generation total 21184K, used 0K [0x0000000107270000, >> 0x0000000108730000, 0x0000000108730000) >> eden space 21120K, 0% used [0x0000000107270000, >> 0x0000000107270000, 0x0000000108710000) >> from space 64K, 0% used [0x0000000108720000, 0x0000000108720000, >> >> 0x0000000108730000) >> to space 64K, 0% used [0x0000000108710000, 0x0000000108710000, >> >> 0x0000000108720000) >> concurrent mark-sweep generation total 20950272K, used 5487545K >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) >> concurrent-mark-sweep perm gen total 39296K, used 23575K >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) >> } >> , 0.0672098 secs] >> >> Application time: 0.4661567 seconds >> 82558.721: [GC {Heap before gc invocations=111717: >> par new generation total 21184K, used 21120K [0x0000000107270000, >> >> 0x0000000108730000, 0x0000000108730000) >> eden space 21120K, 100% used [0x0000000107270000, >> 0x0000000108710000, 0x0000000108710000) >> from space 64K, 0% used [0x0000000108720000, 0x0000000108720000, >> >> 0x0000000108730000) >> to space 64K, 0% used [0x0000000108710000, 0x0000000108710000, >> >> 0x0000000108720000) >> concurrent mark-sweep generation total 20950272K, used 5487545K >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) >> concurrent-mark-sweep perm gen total 39296K, used 23575K >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) >> 82558.721: [ParNew: 21120K->0K(21184K), 0.0591967 secs] 5508665K- >>> 5491650K(20971456K)Heap after gc invocations=111718: >> par new generation total 21184K, used 0K [0x0000000107270000, >> 0x0000000108730000, 0x0000000108730000) >> eden space 21120K, 0% used [0x0000000107270000, >> 0x0000000107270000, 0x0000000108710000) >> from space 64K, 0% used [0x0000000108710000, 0x0000000108710000, >> >> 0x0000000108720000) >> to space 64K, 0% used [0x0000000108720000, 0x0000000108720000, >> >> 0x0000000108730000) >> concurrent mark-sweep generation total 20950272K, used 5491650K >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) >> concurrent-mark-sweep perm gen total 39296K, used 23575K >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) >> } >> , 0.0594283 secs] >> >> Application time: 0.0590593 seconds >> 82558.840: [GC {Heap before gc invocations=111718: >> par new generation total 21184K, used 21120K [0x0000000107270000, >> >> 0x0000000108730000, 0x0000000108730000) >> eden space 21120K, 100% used [0x0000000107270000, >> 0x0000000108710000, 0x0000000108710000) >> from space 64K, 0% used [0x0000000108710000, 0x0000000108710000, >> >> 0x0000000108720000) >> to space 64K, 0% used [0x0000000108720000, 0x0000000108720000, >> >> 0x0000000108730000) >> concurrent mark-sweep generation total 20950272K, used 5491650K >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) >> concurrent-mark-sweep perm gen total 39296K, used 23575K >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) >> 82558.840: [ParNew: 21120K->0K(21184K), 0.0589090 secs] 5512770K- >>> 5496450K(20971456K)Heap after gc invocations=111719: >> par new generation total 21184K, used 0K [0x0000000107270000, >> 0x0000000108730000, 0x0000000108730000) >> eden space 21120K, 0% used [0x0000000107270000, >> 0x0000000107270000, 0x0000000108710000) >> from space 64K, 0% used [0x0000000108720000, 0x0000000108720000, >> >> 0x0000000108730000) >> to space 64K, 0% used [0x0000000108710000, 0x0000000108710000, >> >> 0x0000000108720000) >> concurrent mark-sweep generation total 20950272K, used 5496450K >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) >> concurrent-mark-sweep perm gen total 39296K, used 23575K >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) >> } >> , 0.0592058 secs] >> >> >> -Moazam >> >> _______________________________________________ >> 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 moazam at apple.com Tue Nov 4 17:04:10 2008 From: moazam at apple.com (Moazam Raja) Date: Tue, 4 Nov 2008 17:04:10 -0800 Subject: Where have the Full GCs gone? In-Reply-To: <4910EE44.7060704@Sun.COM> References: <0E7AF2AC-F167-41AB-9780-873DBF58DACD@apple.com> <4910EE44.7060704@Sun.COM> Message-ID: <242C68AA-B22F-4C78-9866-60FE648C80BC@apple.com> Peter, this must be a bug in the GC output as I know for sure I don't have the memory to run a 20GB heap. Instead of 20950272K, it must mean 20950272Kb. This is on Java 1.5.0 on OS X Leopard. java version "1.5.0_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13- b05-237) Java HotSpot(TM) Server VM (build 1.5.0_13-119, mixed mode) -Moazam On Nov 4, 2008, at 4:52 PM, Peter B. Kessler wrote: > Moazam Raja wrote: >> Hi all, I'm running a test and recording GC information on a >> Tomcat application and have noticed that even after a few days, >> there are no 'Full GC' markers. Am I reading the log incorrectly, >> or are the Full GCs getting logged elsewhere? >> I'm using Java 1.5.0_13 on OS X with the following flags, >> -Xms=2048m -Xmx=2048m >> -server -XX:+UseConcMarkSweepGC >> -Xloggc:/var/tmp/GC.log >> -verbose:gc >> -XX:+PrintGCDetails >> -XX:+PrintHeapAtGC >> -XX:+PrintClassHistogram >> -XX:+PrintGCApplicationConcurrentTime >> A sample of the output from my GC log: >> Application time: 1.4105823 seconds >> 82558.187: [GC {Heap before gc invocations=111716: >> par new generation total 21184K, used 21120K >> [0x0000000107270000, 0x0000000108730000, 0x0000000108730000) >> eden space 21120K, 100% used [0x0000000107270000, >> 0x0000000108710000, 0x0000000108710000) >> from space 64K, 0% used [0x0000000108710000, >> 0x0000000108710000, 0x0000000108720000) >> to space 64K, 0% used [0x0000000108720000, >> 0x0000000108720000, 0x0000000108730000) >> concurrent mark-sweep generation total 20950272K, used 5483440K >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) >> concurrent-mark-sweep perm gen total 39296K, used 23575K >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) >> 82558.187: [ParNew: 21120K->0K(21184K), 0.0669633 secs] 5504560K- >> >5487545K(20971456K)Heap after gc invocations=111717: >> par new generation total 21184K, used 0K [0x0000000107270000, >> 0x0000000108730000, 0x0000000108730000) >> eden space 21120K, 0% used [0x0000000107270000, >> 0x0000000107270000, 0x0000000108710000) >> from space 64K, 0% used [0x0000000108720000, >> 0x0000000108720000, 0x0000000108730000) >> to space 64K, 0% used [0x0000000108710000, >> 0x0000000108710000, 0x0000000108720000) >> concurrent mark-sweep generation total 20950272K, used 5487545K >> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) >> concurrent-mark-sweep perm gen total 39296K, used 23575K >> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) >> } >> , 0.0672098 secs] >> ... > > I don't think those are the command line arguments for the GC log > you show. It looks from the PrintHeapAtGG output that your heap is > 20GB, not the 2GB shown on the command line. 20MB in the "par new" > generation, and the reast of the 20GB in the CMS generation. > > It looks like you are using just over 5GB of CMS space, which would > explain why you haven't seen an old generation collection yet. > > ... peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20081104/bfaa8a15/attachment.html -------------- 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 moazam at apple.com Tue Nov 4 17:36:32 2008 From: moazam at apple.com (Moazam Raja) Date: Tue, 4 Nov 2008 17:36:32 -0800 Subject: Where have the Full GCs gone? In-Reply-To: References: <0E7AF2AC-F167-41AB-9780-873DBF58DACD@apple.com> <4910EE44.7060704@Sun.COM> <242C68AA-B22F-4C78-9866-60FE648C80BC@apple.com> Message-ID: Peter, you were right, once again. :) Indeed, the heap is set to 20GB. Not what I had expected! Thanks! -Moazam > ----- Original Message ----- > From: Moazam Raja > Date: Tuesday, November 4, 2008 5:04 pm > Subject: Re: Where have the Full GCs gone? > To: "Peter B. Kessler" > Cc: hotspot-gc-use at openjdk.java.net > > >> Peter, this must be a bug in the GC output as I know for sure I don't >> >> have the memory to run a 20GB heap. >> >> Instead of 20950272K, it must mean 20950272Kb. >> >> This is on Java 1.5.0 on OS X Leopard. >> >> java version "1.5.0_13" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13- >> b05-237) >> Java HotSpot(TM) Server VM (build 1.5.0_13-119, mixed mode) >> >> >> -Moazam >> >> On Nov 4, 2008, at 4:52 PM, Peter B. Kessler wrote: >> >>> Moazam Raja wrote: >>>> Hi all, I'm running a test and recording GC information on a >>>> Tomcat application and have noticed that even after a few days, >>>> there are no 'Full GC' markers. Am I reading the log incorrectly, >> >>>> or are the Full GCs getting logged elsewhere? >>>> I'm using Java 1.5.0_13 on OS X with the following flags, >>>> -Xms=2048m -Xmx=2048m >>>> -server -XX:+UseConcMarkSweepGC >>>> -Xloggc:/var/tmp/GC.log >>>> -verbose:gc >>>> -XX:+PrintGCDetails >>>> -XX:+PrintHeapAtGC >>>> -XX:+PrintClassHistogram >>>> -XX:+PrintGCApplicationConcurrentTime >>>> A sample of the output from my GC log: >>>> Application time: 1.4105823 seconds >>>> 82558.187: [GC {Heap before gc invocations=111716: >>>> par new generation total 21184K, used 21120K >>>> [0x0000000107270000, 0x0000000108730000, 0x0000000108730000) >>>> eden space 21120K, 100% used [0x0000000107270000, >>>> 0x0000000108710000, 0x0000000108710000) >>>> from space 64K, 0% used [0x0000000108710000, >>>> 0x0000000108710000, 0x0000000108720000) >>>> to space 64K, 0% used [0x0000000108720000, >>>> 0x0000000108720000, 0x0000000108730000) >>>> concurrent mark-sweep generation total 20950272K, used 5483440K >>>> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) >>>> concurrent-mark-sweep perm gen total 39296K, used 23575K >>>> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) >>>> 82558.187: [ParNew: 21120K->0K(21184K), 0.0669633 secs] 5504560K- >>>>> 5487545K(20971456K)Heap after gc invocations=111717: >>>> par new generation total 21184K, used 0K [0x0000000107270000, >>>> 0x0000000108730000, 0x0000000108730000) >>>> eden space 21120K, 0% used [0x0000000107270000, >>>> 0x0000000107270000, 0x0000000108710000) >>>> from space 64K, 0% used [0x0000000108720000, >>>> 0x0000000108720000, 0x0000000108730000) >>>> to space 64K, 0% used [0x0000000108710000, >>>> 0x0000000108710000, 0x0000000108720000) >>>> concurrent mark-sweep generation total 20950272K, used 5487545K >>>> [0x0000000108730000, 0x0000000607270000, 0x0000000607270000) >>>> concurrent-mark-sweep perm gen total 39296K, used 23575K >>>> [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000) >>>> } >>>> , 0.0672098 secs] >>>> ... >>> >>> I don't think those are the command line arguments for the GC log >>> you show. It looks from the PrintHeapAtGG output that your heap is >> >>> 20GB, not the 2GB shown on the command line. 20MB in the "par new" >> >>> generation, and the reast of the 20GB in the CMS generation. >>> >>> It looks like you are using just over 5GB of CMS space, which would >> >>> explain why you haven't seen an old generation collection yet. >>> >>> ... peter >> >> _______________________________________________ >> 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 Antonios.Printezis at sun.com Tue Nov 4 21:49:46 2008 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Wed, 05 Nov 2008 00:49:46 -0500 Subject: Where have the Full GCs gone? In-Reply-To: References: <0E7AF2AC-F167-41AB-9780-873DBF58DACD@apple.com> <6323F0D0-3FD0-4FB0-BF63-BF73546DE338@apple.com> Message-ID: <491133FA.8010304@sun.com> Y Srinivas Ramakrishna wrote: > BTW, I am not sure if gchisto in its current form will > accept gc logs that have PrintHeapAtGC information. You'll > need to elide that information, or update GCHisto's parser > to do so. > Ramki, Yes, I believe the GChisto parser does currently have trouble reading GC logs with PrintHeapAtGC information... Tony -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) _______________________________________________ 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 sun.com Wed Nov 5 10:13:58 2008 From: John.Coomes at sun.com (John Coomes) Date: Wed, 5 Nov 2008 10:13:58 -0800 Subject: review request (M) - 6578152: fill_region_with_object Message-ID: <18705.57958.192973.973703@sun.com> 6578152: fill_region_with_object has usability and safety issues http://webrev.invokedynamic.info/jcoomes/6578152-fill/ Touches 25 files, but many are trivial changes. Thanks for any comments. -John From Keith.McGuigan at Sun.COM Wed Nov 5 09:08:48 2008 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Wed, 05 Nov 2008 12:08:48 -0500 Subject: 6423256: marking stacks should use a chunked data structure In-Reply-To: <4911D04A.8060900@gmail.com> References: <4911D04A.8060900@gmail.com> Message-ID: <4911D320.5060503@sun.com> Hi Scott - I'm forwarding this to the hotspot-gc-dev mailing list. If anyone is working on it, they'll be on that list (maybe this one too, but just in case). -- - Keith Scott Marlow wrote: > Is anyone working on this bug yet? From the bug report > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423256, it sounds > like someone started the work already. I would like to help with the > issue (either testing a proposed fix or submitting one). > > The bug report contains this text: > > " > The marking stack used by MarkSweep currently uses a GrowableArray. > That's overkill, since we only use the marking stack as a stack. In > contrast, GrowableArray implements an array, so when it expands, it > reallocs and copies the whole array to a new, larger, piece of > contiguous memory. Since the marking stack is often large, this often > requires a large contiguous chunk of memory, which can be difficult to > acquire. Since GrowableArray grows by doubling, on average 25% of the > array will be empty. When the marking stack is large, this can be a > substantial waste of space. > > Instead, the stack could be implemented as a chained series of small > regions. This could allow us to balance the storage for the chain > pointers against the increment of growth, to use an appropriate amount > of space in modest chunks. > Posted Date : 2006-05-08 23:47:21.0 > " > > > Scott > From John.Coomes at sun.com Wed Nov 5 15:36:36 2008 From: John.Coomes at sun.com (John Coomes) Date: Wed, 5 Nov 2008 15:36:36 -0800 Subject: 6423256: marking stacks should use a chunked data structure In-Reply-To: <4911D04A.8060900@gmail.com> References: <4911D04A.8060900@gmail.com> Message-ID: <18706.11780.232560.191946@sun.com> Scott Marlow (scott.marlow.opensource at gmail.com) wrote: > Is anyone working on this bug yet? From the bug report > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423256, it sounds > like someone started the work already. I would like to help with the > issue (either testing a proposed fix or submitting one). Hi Scott, Glad you want to help! One of our (former) colleagues implemented growable stacks just before he moved on to another group at Sun. I'm now the guardian of his changes. I haven't looked at it in detail, but I believe the code is complete and has had some testing. Certainly more would be in order. I'll post a webrev in a day or two. If you're willing you can review it and/or take the patch, build it and do some testing. -John > The bug report contains this text: > > " > The marking stack used by MarkSweep currently uses a GrowableArray. > That's overkill, since we only use the marking stack as a stack. In > contrast, GrowableArray implements an array, so when it expands, it > reallocs and copies the whole array to a new, larger, piece of > contiguous memory. Since the marking stack is often large, this often > requires a large contiguous chunk of memory, which can be difficult to > acquire. Since GrowableArray grows by doubling, on average 25% of the > array will be empty. When the marking stack is large, this can be a > substantial waste of space. > > Instead, the stack could be implemented as a chained series of small regions. This could allow us to balance the storage for the chain pointers against the increment of growth, to use an appropriate amount of space in modest chunks. > Posted Date : 2006-05-08 23:47:21.0 > " > > > Scott > From john.coomes at sun.com Fri Nov 7 14:51:12 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Nov 2008 22:51:12 +0000 Subject: hg: jdk7/hotspot-gc: Added tag jdk7-b39 for changeset ab523b49de1f Message-ID: <20081107225112.69F6EDFFB@hg.openjdk.java.net> Changeset: 44be42de6693 Author: xdono Date: 2008-11-06 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/44be42de6693 Added tag jdk7-b39 for changeset ab523b49de1f ! .hgtags From john.coomes at sun.com Fri Nov 7 14:52:45 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Nov 2008 22:52:45 +0000 Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b39 for changeset 55078b6661e2 Message-ID: <20081107225246.8C797E000@hg.openjdk.java.net> Changeset: 184e21992f47 Author: xdono Date: 2008-11-06 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/184e21992f47 Added tag jdk7-b39 for changeset 55078b6661e2 ! .hgtags From john.coomes at sun.com Fri Nov 7 14:55:43 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Nov 2008 22:55:43 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b39 for changeset 831b80be6cea Message-ID: <20081107225546.2D03ED005@hg.openjdk.java.net> Changeset: 54946f466e2c Author: xdono Date: 2008-11-06 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/54946f466e2c Added tag jdk7-b39 for changeset 831b80be6cea ! .hgtags From john.coomes at sun.com Fri Nov 7 14:57:22 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Nov 2008 22:57:22 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b39 for changeset 077bc9b1b035 Message-ID: <20081107225725.16258D00A@hg.openjdk.java.net> Changeset: 70a6ac6dd737 Author: xdono Date: 2008-11-06 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/70a6ac6dd737 Added tag jdk7-b39 for changeset 077bc9b1b035 ! .hgtags From john.coomes at sun.com Fri Nov 7 14:59:45 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Nov 2008 22:59:45 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 14 new changesets Message-ID: <20081107230348.724F2D010@hg.openjdk.java.net> Changeset: 86799e45c230 Author: emcmanus Date: 2008-10-08 18:38 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/86799e45c230 6757225: MXBean: Incorrect type names for parametrized types, dealing with arrays Reviewed-by: sjiang ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanIntrospector.java ! src/share/classes/javax/management/event/EventClient.java ! src/share/classes/javax/management/event/FetchingEventRelay.java ! src/share/classes/javax/management/monitor/Monitor.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java + test/javax/management/mxbean/TypeNameTest.java Changeset: 6a76dcaf15e3 Author: dfuchs Date: 2008-10-09 14:10 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6a76dcaf15e3 6332953: JMX agent should bind to loopback address when starting the local connector server Reviewed-by: emcmanus ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java + src/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java ! src/share/lib/management/management.properties Changeset: f50f9b0d18a8 Author: dfuchs Date: 2008-10-10 10:58 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f50f9b0d18a8 6758165: ConnectorBootstrap.DefaultValues should have a default value for USE_LOCAL_ONLY Reviewed-by: alanb, emcmanus ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java Changeset: 214ebdcf7252 Author: sherman Date: 2008-10-13 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/214ebdcf7252 5025260: Register methods should throw ClosedChannelException instead of NPE Summary: update the spec and implementation to throw ClosedSelectorException Reviewed-by: alanb ! src/share/classes/java/nio/channels/SelectableChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java + test/java/nio/channels/Selector/CloseThenRegister.java Changeset: 5eab86fc2ea8 Author: tbell Date: 2008-10-17 16:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5eab86fc2ea8 Merge Changeset: 486b917ed417 Author: mullan Date: 2008-10-07 13:41 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/486b917ed417 6752764: PIT B37: CertPath/CertPathValidatorTest/KeyParamsInheritanceTest failed Summary: fix regression introduced by 6465942 Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/BasicChecker.java Changeset: 3c234822b837 Author: mullan Date: 2008-10-07 13:48 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3c234822b837 Merge - src/share/classes/com/sun/jmx/interceptor/MBeanServerSupport.java - src/share/classes/java/nio/channels/package.html - src/share/classes/org/jcp/xml/dsig/internal/package.html - src/share/classes/sun/nio/ch/OptionAdaptor.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h - src/solaris/javavm/include/typedefs_md.h - src/windows/javavm/include/typedefs_md.h Changeset: 8b2d7e577d4a Author: mullan Date: 2008-10-07 14:44 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8b2d7e577d4a Merge Changeset: 3f051f3ba5bb Author: weijun Date: 2008-10-17 13:02 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3f051f3ba5bb 6706974: Add krb5 test infrastructure Reviewed-by: valeriep + test/sun/security/krb5/auto/Action.java + test/sun/security/krb5/auto/BasicKrb5Test.java + test/sun/security/krb5/auto/CleanState.java + test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/CrossRealm.java + test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/KerberosHashEqualsTest.java + test/sun/security/krb5/auto/OneKDC.java + test/sun/security/krb5/auto/basic.sh Changeset: 064e6a087f77 Author: wetmore Date: 2008-10-17 00:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/064e6a087f77 Merge Changeset: 0bf6c9c6fdc5 Author: weijun Date: 2008-10-20 10:32 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0bf6c9c6fdc5 6761072: new krb5 tests fail on multiple platforms Reviewed-by: xuelei ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OneKDC.java Changeset: 7df3f9183f67 Author: wetmore Date: 2008-10-20 01:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7df3f9183f67 Merge Changeset: 4e51997582ef Author: tbell Date: 2008-10-23 21:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4e51997582ef Merge Changeset: 2914c04c8644 Author: xdono Date: 2008-11-06 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2914c04c8644 Added tag jdk7-b39 for changeset 4e51997582ef ! .hgtags From john.coomes at sun.com Fri Nov 7 15:09:07 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Nov 2008 23:09:07 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 22 new changesets Message-ID: <20081107230942.E1954D017@hg.openjdk.java.net> Changeset: a54ef8459576 Author: jjg Date: 2008-10-07 15:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/a54ef8459576 6749967: regression tests for apt should be same-vm friendly Reviewed-by: darcy ! 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/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 Changeset: c0372d1097c0 Author: mcimadamore Date: 2008-10-09 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/c0372d1097c0 6751514: Unary post-increment with type variables crash javac during lowering Summary: Lower.abstractRval should take into account parenthesized expressions Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/generics/T6751514.java Changeset: 8c098cf64ab5 Author: mcimadamore Date: 2008-10-09 16:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/8c098cf64ab5 6738538: javac crashes when using a type parameter as a covariant method return type Summary: Capture conversion should be applied when acccessing a member of an intersection type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/OverrideChecks/6738538/T6738538a.java + test/tools/javac/OverrideChecks/6738538/T6738538b.java Changeset: ac6ce899d007 Author: mcimadamore Date: 2008-10-09 16:04 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/ac6ce899d007 6724345: incorrect method resolution for enum classes entered as source files Summary: Enum's abstract methods shouldn't be skipped during method resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/enum/T6724345.java Changeset: 8eafba4f61be Author: mcimadamore Date: 2008-10-09 16:07 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/8eafba4f61be 6406133: JCDiagnostic.getMessage ignores locale argument Summary: Compiler API should take into account locale settings Reviewed-by: jjg ! src/share/classes/com/sun/tools/apt/util/Bark.java ! src/share/classes/com/sun/tools/javac/api/Formattable.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/Messages.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/parser/Token.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.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/Log.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! test/tools/javac/6457284/T6457284.java + test/tools/javac/api/6406133/Erroneous.java + test/tools/javac/api/6406133/T6406133.java Changeset: e4eaddca54b7 Author: mcimadamore Date: 2008-10-09 16:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/e4eaddca54b7 6731573: diagnostic output should optionally include source line Summary: Added an -XD option to optionally prints out source lines in error messages Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java + test/tools/javac/api/6731573/Erroneous.java + test/tools/javac/api/6731573/T6731573.java Changeset: d766e40e49d6 Author: mcimadamore Date: 2008-10-09 16:21 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/d766e40e49d6 6586091: javac crashes with StackOverflowError Summary: Types.adapt should avoid infinite loops by exploiting a local cache Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/6586091/T6586091.java Changeset: e03459165ec4 Author: mcimadamore Date: 2008-10-14 17:05 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/e03459165ec4 6759143: com.sun.tools.javac.util.Messages is obsolete and should be removed Summary: push for 6406133 should have removed com.sun.tools.javac.util.Messages Reviewed-by: jjg - src/share/classes/com/sun/tools/javac/util/Messages.java Changeset: 22c4c1143a3a Author: jjg Date: 2008-10-15 08:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/22c4c1143a3a 6748541: javadoc should be reusable Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/lib/JavadocTester.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/T4994049.java ! test/tools/javadoc/XWerror.java ! test/tools/javadoc/completionFailure/CompletionFailure.java ! test/tools/javadoc/dupOk/DupOk.java ! test/tools/javadoc/imports/MissingImport.java ! test/tools/javadoc/lib/Tester.java ! test/tools/javadoc/nestedClass/NestedClass.java ! test/tools/javadoc/sourceOnly/p/SourceOnly.java ! test/tools/javadoc/sourceOption/SourceOption.java ! test/tools/javadoc/subpackageIgnore/SubpackageIgnore.java Changeset: 83ffdd1a6294 Author: mcimadamore Date: 2008-10-15 17:23 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/83ffdd1a6294 6759682: APT: compiler message file broken after refactoring of com.sun.tools.javac.util.Message Summary: JavacMessages should refresh its own bundle cache when a new resource bundle is added by APT Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java Changeset: e1332c04f6b6 Author: jjg Date: 2008-10-15 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/e1332c04f6b6 6759795: test/tools/apt/Basic/print.sh may fail depending on jtreg options Reviewed-by: darcy ! test/tools/apt/Basics/print.sh Changeset: 4feda9f0dbe7 Author: jjg Date: 2008-10-15 13:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/4feda9f0dbe7 6759796: test/tools/javac/6348193/T6348193.java fails if there are empty entries on the bootclasspath Reviewed-by: darcy ! test/tools/javac/processing/6348193/T6348193.java Changeset: 173162d6eb1d Author: jjg Date: 2008-10-16 07:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/173162d6eb1d 6759775: RegularFileObject.inferBinaryName gives bad result on empty path Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java Changeset: 2c1ef6ec9413 Author: jjg Date: 2008-10-16 07:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/2c1ef6ec9413 6759810: bad regression test causes source file to be deleted Reviewed-by: mcimadamore ! test/tools/javac/links/T.java ! test/tools/javac/links/links.sh Changeset: 6fcc8de719f5 Author: mcimadamore Date: 2008-10-16 18:07 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/6fcc8de719f5 6760226: test/tools/javap/T6622260.java fails with specific locale settings Summary: Changed the regression test in order to make it more robust w.r.t. to locale settings Reviewed-by: jjg ! test/tools/javap/T6622260.java Changeset: 402183e8d6e1 Author: jjg Date: 2008-10-16 16:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/402183e8d6e1 6760500: test com/sun/javadoc/testSupplementary/TestSupplementary.java is not same-VM safe Reviewed-by: darcy ! test/com/sun/javadoc/testSupplementary/TestSupplementary.java Changeset: eca4bf37b66e Author: jjg Date: 2008-10-17 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/eca4bf37b66e 6760805: empty element on bootclasspath breaks test/tools/apt/Compile/compile.sh Reviewed-by: darcy ! test/tools/apt/Compile/compile.sh Changeset: 2eec479619d8 Author: jjg Date: 2008-10-17 16:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/2eec479619d8 6760930: empty element on bootclasspath breaks test/tools/apt/Discovery/discovery.sh Reviewed-by: darcy ! test/tools/apt/Discovery/discovery.sh Changeset: acc41893695b Author: tbell Date: 2008-10-17 16:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/acc41893695b Merge - src/share/classes/com/sun/tools/javac/util/Messages.java Changeset: 8ae974495e73 Author: jjg Date: 2008-10-20 13:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/8ae974495e73 6759996: ignore empty entries on paths Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/Paths.java + test/tools/javac/T6759996.java Changeset: 3fb51e47622b Author: tbell Date: 2008-10-23 21:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/3fb51e47622b Merge Changeset: 968ca53217a1 Author: xdono Date: 2008-11-06 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/968ca53217a1 Added tag jdk7-b39 for changeset 3fb51e47622b ! .hgtags From igor.veresov at sun.com Fri Nov 7 18:47:51 2008 From: igor.veresov at sun.com (igor.veresov at sun.com) Date: Sat, 08 Nov 2008 02:47:51 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 5 new changesets Message-ID: <20081108024804.7E7F0D082@hg.openjdk.java.net> Changeset: 69e855d955f5 Author: xdono Date: 2008-10-23 10:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/69e855d955f5 Added tag jdk7-b38 for changeset d9bc824aa078 ! .hgtags Changeset: 7c99a4bb76a1 Author: trims Date: 2008-10-29 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7c99a4bb76a1 Merge Changeset: 49ca90d77f34 Author: trims Date: 2008-10-29 19:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/49ca90d77f34 Merge Changeset: c7ec737733a6 Author: kamg Date: 2008-10-30 15:48 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c7ec737733a6 6756528: Bytecodes::special_length_at reads past end of code buffer Summary: Add end-of-buffer indicator for paths used by the verifier Reviewed-by: acorn, coleenp ! src/share/vm/interpreter/bytecodeStream.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp Changeset: 348be627a148 Author: xlu Date: 2008-10-31 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/348be627a148 Merge From scott.marlow.opensource at gmail.com Fri Nov 7 20:34:52 2008 From: scott.marlow.opensource at gmail.com (Scott Marlow) Date: Fri, 07 Nov 2008 23:34:52 -0500 Subject: 6423256: marking stacks should use a chunked data structure In-Reply-To: <18706.11780.232560.191946@sun.com> References: <4911D04A.8060900@gmail.com> <18706.11780.232560.191946@sun.com> Message-ID: <491516EC.6040905@gmail.com> John Coomes wrote: > Scott Marlow (scott.marlow.opensource at gmail.com) wrote: > >> Is anyone working on this bug yet? From the bug report >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423256, it sounds >> like someone started the work already. I would like to help with the >> issue (either testing a proposed fix or submitting one). >> > > Hi Scott, > > Glad you want to help! One of our (former) colleagues implemented > growable stacks just before he moved on to another group at Sun. I'm > now the guardian of his changes. I haven't looked at it in detail, > but I believe the code is complete and has had some testing. > Certainly more would be in order. > > I'll post a webrev in a day or two. If you're willing you can review > it and/or take the patch, build it and do some testing. > > -John > John, I just got the build to work successfully on my Windows machine (with some help from build-dev at openjdk.java.net). I should be able to review the change and apply the patch (for testing) when your ready. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20081107/b87a5d0a/attachment.html From john.coomes at sun.com Wed Nov 12 03:09:33 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 12 Nov 2008 11:09:33 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6765804: GC "dead ratios" should be unsigned Message-ID: <20081112110938.E87ACD28D@hg.openjdk.java.net> Changeset: 122d10c82f3f Author: jcoomes Date: 2008-10-29 06:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/122d10c82f3f 6765804: GC "dead ratios" should be unsigned Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/runtime/globals.hpp From john.coomes at sun.com Wed Nov 12 05:40:16 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 12 Nov 2008 13:40:16 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 2 new changesets Message-ID: <20081112134023.30295D298@hg.openjdk.java.net> Changeset: 03f4fdd1b6af Author: jcoomes Date: 2008-11-11 22:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/03f4fdd1b6af 6718879: cannot build on solaris nevada Reviewed-by: xlu ! src/os/solaris/vm/os_solaris.cpp Changeset: 96c6da8f095c Author: jcoomes Date: 2008-11-07 12:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/96c6da8f095c 6769128: failure to run generateJvmOffsets is ignored Reviewed-by: xlu ! make/solaris/makefiles/dtrace.make From John.Coomes at sun.com Wed Nov 12 16:26:15 2008 From: John.Coomes at sun.com (John Coomes) Date: Wed, 12 Nov 2008 16:26:15 -0800 Subject: 6423256: marking stacks should use a chunked data structure In-Reply-To: <18706.11780.232560.191946@sun.com> References: <4911D04A.8060900@gmail.com> <18706.11780.232560.191946@sun.com> Message-ID: <18715.29735.540039.433458@sun.com> John Coomes (John.Coomes at sun.com) wrote: > Scott Marlow (scott.marlow.opensource at gmail.com) wrote: > > Is anyone working on this bug yet? From the bug report > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423256, it sounds > > like someone started the work already. I would like to help with the > > issue (either testing a proposed fix or submitting one). > > Hi Scott, > > Glad you want to help! One of our (former) colleagues implemented > growable stacks just before he moved on to another group at Sun. I'm > now the guardian of his changes. I haven't looked at it in detail, > but I believe the code is complete and has had some testing. > Certainly more would be in order. > > I'll post a webrev in a day or two. If you're willing you can review > it and/or take the patch, build it and do some testing. I guess really I meant a week or two :-(. Sorry, I've been out sick. Anyway, I put a webrev here: http://webrev.invokedynamic.info/jcoomes/6423256-stack/ I'd consider these preliminary since I haven't tested the changes after syncing them up, other than to do a few builds (it compiles cleanly on solaris). -John > > The bug report contains this text: > > > > " > > The marking stack used by MarkSweep currently uses a GrowableArray. > > That's overkill, since we only use the marking stack as a stack. In > > contrast, GrowableArray implements an array, so when it expands, it > > reallocs and copies the whole array to a new, larger, piece of > > contiguous memory. Since the marking stack is often large, this often > > requires a large contiguous chunk of memory, which can be difficult to > > acquire. Since GrowableArray grows by doubling, on average 25% of the > > array will be empty. When the marking stack is large, this can be a > > substantial waste of space. > > > > Instead, the stack could be implemented as a chained series of small regions. This could allow us to balance the storage for the chain pointers against the increment of growth, to use an appropriate amount of space in modest chunks. > > Posted Date : 2006-05-08 23:47:21.0 > > " > > > > > > Scott > > From Y.S.Ramakrishna at Sun.COM Fri Nov 14 02:09:15 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Fri, 14 Nov 2008 02:09:15 -0800 Subject: request for review (small): 6749695 Message-ID: 6749695 CMS: SIGEGV thrown on CMSCleanOnEnter optimization http://bugs.sun.com/view_bug.do?bug_id=6749695 (modulo a bugs.sun.com bug that causes "object" to appear as "customer") webrev: http://webrev.invokedynamic.info/ysr/6749695/ The problem, as described in the bug report, was that we were clearing too many cards, namely those prior to the "finger", which would not be scanned after the clearing of the MUT card, thus compromising correctness. The fix is to clear only the portion after the start of the object. Note that this optimization triggers only when the marking phase finds objects that straddle (or start at) page boundaries, limiting its efficacy somewhat. Testing: jprt with -XX:-UseParNewGC; no test case provided Thanks for your reviews. -- ramki From Y.S.Ramakrishna at Sun.COM Fri Nov 14 12:03:29 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Fri, 14 Nov 2008 12:03:29 -0800 Subject: request for review (medium): 6722113 Message-ID: 6722113 CMS: Incorrect overflow handling during precleaning of Reference lists http://bugs.sun.com/view_bug.do?bug_id=6722113 webrev: http://webrev.invokedynamic.info/ysr/6722113/ One problem was that we had reused a CMS reference processing closure to do concurrent precleaning of the discovered reference list, but had not extended it to deal correctly with marking stack overflow that might occur during a concurrent phase. The fix is to do so in the usual way for CMS, by redirtying the MUT-card containing the overflown object, taking care to deal with reference array objects appropriately. A further problem was that the marking done during the precleaning pass was not updating the discovered list lengths correctly because of the interleaved manner in which discovery and preclean-processing proceed in this case. This could lead to issues during the rebalancing of the per-thread discovered lists when doing reference processing multi-threaded. Adjusted related comments. (Note that this is the first case where we are explicitly doing reference processing without disabling discovery, I'd like to call this out explicitly for reviewers to pay special attention to. This will require looking at the reference processing code in detail, not just the portions that changed in the webrev. Note that this will need to change if concurrent precleaning were ever to become parallel/multi-threaded.) Testing: jprt, refworkload, with and without +ParallelRefProcEnabled Thanks for your reviews. -- ramki From Jon.Masamitsu at Sun.COM Fri Nov 14 14:58:12 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Fri, 14 Nov 2008 14:58:12 -0800 Subject: Openjdk hotspot build 14.0-b06 hard coded bug found. In-Reply-To: <2fcb552b0811141412s5cb90c90od356f80b381fcbb5@mail.gmail.com> References: <2fcb552b0811141412s5cb90c90od356f80b381fcbb5@mail.gmail.com> Message-ID: <491E0284.4000500@sun.com> Tony Guan wrote On 11/14/08 14:12,: >Hi there, > >I think I've found a little bug in the parallel gc codes. Will >somebody take a look at it? >Firstly, after a full gc, there maybe the need to adjust the boundary >between young and old generation. >and here in psMarkSweep.cpp, we >use: heap->resize_old_gen(size_policy->calculated_old_free_size_in_bytes()); > >Then this methods will in turn call: > gens()->adjust_boundary_for_old_gen_needs(desired_free_space); > >in this function, we compare the desired_free_space with the current >free space, and then calls request_old_gen_expansion: > if (old_gen()->free_in_bytes() < desired_free_space) { > MutexLocker x(ExpandHeap_lock); > request_old_gen_expansion(desired_free_space); >but in request_old_gen_expansion the desired_free_space is immediately >treated as expand_in_bytes. And in this implementation, the actual > > Yes, you're right that this looks like a bug. Also something that doesn't look right here is the use of calculated_old_free_size_in_bytes(). It looks like it is adding room for 1 addtional young gen collection. Perhaps not a bad idea but I don't recall now why it is used instead of the straight promo_size(). >change in bytes is computed like this: > size_t change_in_bytes = MIN3(young_gen_available, > old_gen_available, > align_size_up_(expand_in_bytes, alignment)); >and then: > virtual_spaces()->adjust_boundary_up(change_in_bytes) > >So in the end, we have old_gen()->free_in_bytes()+=desired_free_space >and the final "desired_free_space" is more than needed. > >And after the boundary is moved up (too high), the >_old_gen->resize(desired_free_space) > >will compute the new space size as: > size_t new_size = used_in_bytes() + desired_free_space; > >Thus it will shrink the old gen space smaller. So we have part the >space sacrificed by the young generation out of the old gen usage. And >the size of this wasted memory is (desired_free_space- prevoiusly free >space of old_gen). > > Yup, we've moved the boundary farther than we really wanted to. Are you able to file a bug report for this? Did you want to fix it? > > _______________________________________________ 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 Sun.COM Fri Nov 14 16:53:46 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Fri, 14 Nov 2008 16:53:46 -0800 Subject: Openjdk hotspot build 14.0-b06 hard coded bug found. In-Reply-To: <2fcb552b0811141600l19a65775ma9a083971cd57553@mail.gmail.com> References: <2fcb552b0811141412s5cb90c90od356f80b381fcbb5@mail.gmail.com> <491E0284.4000500@sun.com> <2fcb552b0811141600l19a65775ma9a083971cd57553@mail.gmail.com> Message-ID: <491E1D9A.2040208@sun.com> Inline replies Tony Guan wrote On 11/14/08 16:00,: >On Fri, Nov 14, 2008 at 4:58 PM, Jon Masamitsu wrote: > > >>Tony Guan wrote On 11/14/08 14:12,: >> >> >> >>>Hi there, >>> >>>I think I've found a little bug in the parallel gc codes. Will >>>somebody take a look at it? >>>Firstly, after a full gc, there maybe the need to adjust the boundary >>>between young and old generation. >>>and here in psMarkSweep.cpp, we >>>use: heap->resize_old_gen(size_policy->calculated_old_free_size_in_bytes()); >>> >>>Then this methods will in turn call: >>> gens()->adjust_boundary_for_old_gen_needs(desired_free_space); >>> >>>in this function, we compare the desired_free_space with the current >>>free space, and then calls request_old_gen_expansion: >>> if (old_gen()->free_in_bytes() < desired_free_space) { >>> MutexLocker x(ExpandHeap_lock); >>> request_old_gen_expansion(desired_free_space); >>>but in request_old_gen_expansion the desired_free_space is immediately >>>treated as expand_in_bytes. And in this implementation, the actual >>> >>> >>> >>> >>Yes, you're right that this looks like a bug. >> >>Also something that doesn't look right here is the use of >>calculated_old_free_size_in_bytes(). It looks like it is adding >>room for 1 addtional young gen collection. Perhaps not a >>bad idea but I don't recall now why it is used instead of the >>straight promo_size(). >> >> >In my opinion, adding room for 1 additional young gen collection is >OK, because in adjustable parallel gc, by doing this, we can reduce >the chance of doing full gc for next time. And that's why it's called >desired_free_space. (just a guess) > > I think it's odd because "desire_free_size" should have any such additional space built into it. "desired_free_size" is set in a method that purports to calculate the correct amount of free space for the old generation yet the use of calculated_old_free_size_in_bytes() bumps that up just a bit. Probably doesn't hurt but it's a policy decision that should be embedded in the calculation of "desired_free_size". > > > >> >> >>>change in bytes is computed like this: >>>size_t change_in_bytes = MIN3(young_gen_available, >>> old_gen_available, >>> align_size_up_(expand_in_bytes, alignment)); >>>and then: >>>virtual_spaces()->adjust_boundary_up(change_in_bytes) >>> >>>So in the end, we have old_gen()->free_in_bytes()+=desired_free_space >>>and the final "desired_free_space" is more than needed. >>> >>>And after the boundary is moved up (too high), the >>>_old_gen->resize(desired_free_space) >>> >>>will compute the new space size as: >>>size_t new_size = used_in_bytes() + desired_free_space; >>> >>>Thus it will shrink the old gen space smaller. So we have part the >>>space sacrificed by the young generation out of the old gen usage. And >>>the size of this wasted memory is (desired_free_space- prevoiusly free >>>space of old_gen). >>> >>> >>> >>> >>Yup, we've moved the boundary farther than we >>really wanted to. >> >>Are you able to file a bug report for this? Did you want >>to fix it? >> >> > >Is there any format should I follow to report the bug? > > In the description section if you just included the info you put in your mail, that would be fine. You can even cut-and-paste you mail into it. >In fact it's simple to fix it. just change >in >void AdjoiningGenerations::adjust_boundary_for_old_gen_needs() >the following change will solve it: > >-request_old_gen_expansion(desired_free_space); >+request_old_gen_expansion(desired_free_space-old_gen()->free_in_bytes()); > > > Yes, it's a straight forward change and so is a nice one if you want to try you hand at a contribution. > > > >>> >>> >> >> _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From igor.veresov at sun.com Fri Nov 14 19:09:12 2008 From: igor.veresov at sun.com (igor.veresov at sun.com) Date: Sat, 15 Nov 2008 03:09:12 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6770608: G1: Mutator thread can flush barrier and satb queues during safepoint; ... Message-ID: <20081115030917.06D3ED4AB@hg.openjdk.java.net> Changeset: da9cb4e97a5f Author: iveresov Date: 2008-11-14 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/da9cb4e97a5f 6770608: G1: Mutator thread can flush barrier and satb queues during safepoint 6660573: G1: BigApps Failure : guarantee(satb_mq_set.completed_buffers_num() == 0,"invariant") Summary: When exiting a mutator thread is removed from the thread list before it has a chance to flush its SATB and barrier queues. If GC happens at this moment the objects that are refererred from these queues can be moved, which will case a crash. The fix is simply to flush the buffers before removing a thread from the list. Reviewed-by: jcoomes, tonyp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp From guanxiaohua at gmail.com Fri Nov 14 22:49:36 2008 From: guanxiaohua at gmail.com (Tony Guan) Date: Sat, 15 Nov 2008 00:49:36 -0600 Subject: Openjdk hotspot build 14.0-b06 hard coded bug found. In-Reply-To: <491E1D9A.2040208@sun.com> References: <2fcb552b0811141412s5cb90c90od356f80b381fcbb5@mail.gmail.com> <491E0284.4000500@sun.com> <2fcb552b0811141600l19a65775ma9a083971cd57553@mail.gmail.com> <491E1D9A.2040208@sun.com> Message-ID: <2fcb552b0811142249m6da521cdsbc16a1a05fad0234@mail.gmail.com> Hi Jon, I've filed a bug report for it. The Review ID is 1390360. And I am not sure about the calculated_old_free_size_in_bytes() part, so I didn't included your comments. I can look further into the code in the coming days. Thanks! Tony On Fri, Nov 14, 2008 at 6:53 PM, Jon Masamitsu wrote: > Inline replies > > Tony Guan wrote On 11/14/08 16:00,: > >>On Fri, Nov 14, 2008 at 4:58 PM, Jon Masamitsu wrote: >> >> >>>Tony Guan wrote On 11/14/08 14:12,: >>> >>> >>> >>>>Hi there, >>>> >>>>I think I've found a little bug in the parallel gc codes. Will >>>>somebody take a look at it? >>>>Firstly, after a full gc, there maybe the need to adjust the boundary >>>>between young and old generation. >>>>and here in psMarkSweep.cpp, we >>>>use: heap->resize_old_gen(size_policy->calculated_old_free_size_in_bytes()); >>>> >>>>Then this methods will in turn call: >>>> gens()->adjust_boundary_for_old_gen_needs(desired_free_space); >>>> >>>>in this function, we compare the desired_free_space with the current >>>>free space, and then calls request_old_gen_expansion: >>>> if (old_gen()->free_in_bytes() < desired_free_space) { >>>> MutexLocker x(ExpandHeap_lock); >>>> request_old_gen_expansion(desired_free_space); >>>>but in request_old_gen_expansion the desired_free_space is immediately >>>>treated as expand_in_bytes. And in this implementation, the actual >>>> >>>> >>>> >>>> >>>Yes, you're right that this looks like a bug. >>> >>>Also something that doesn't look right here is the use of >>>calculated_old_free_size_in_bytes(). It looks like it is adding >>>room for 1 addtional young gen collection. Perhaps not a >>>bad idea but I don't recall now why it is used instead of the >>>straight promo_size(). >>> >>> >>In my opinion, adding room for 1 additional young gen collection is >>OK, because in adjustable parallel gc, by doing this, we can reduce >>the chance of doing full gc for next time. And that's why it's called >>desired_free_space. (just a guess) >> >> > > I think it's odd because "desire_free_size" should have any such > additional space built into it. "desired_free_size" is set in a > method that purports to calculate the correct amount of free > space for the old generation yet the use of > calculated_old_free_size_in_bytes() bumps that up just a bit. > Probably doesn't hurt but it's a policy decision that should > be embedded in the calculation of "desired_free_size". > >> >> >> >>> >>> >>>>change in bytes is computed like this: >>>>size_t change_in_bytes = MIN3(young_gen_available, >>>> old_gen_available, >>>> align_size_up_(expand_in_bytes, alignment)); >>>>and then: >>>>virtual_spaces()->adjust_boundary_up(change_in_bytes) >>>> >>>>So in the end, we have old_gen()->free_in_bytes()+=desired_free_space >>>>and the final "desired_free_space" is more than needed. >>>> >>>>And after the boundary is moved up (too high), the >>>>_old_gen->resize(desired_free_space) >>>> >>>>will compute the new space size as: >>>>size_t new_size = used_in_bytes() + desired_free_space; >>>> >>>>Thus it will shrink the old gen space smaller. So we have part the >>>>space sacrificed by the young generation out of the old gen usage. And >>>>the size of this wasted memory is (desired_free_space- prevoiusly free >>>>space of old_gen). >>>> >>>> >>>> >>>> >>>Yup, we've moved the boundary farther than we >>>really wanted to. >>> >>>Are you able to file a bug report for this? Did you want >>>to fix it? >>> >>> >> >>Is there any format should I follow to report the bug? >> >> > In the description section if you just included the info you > put in your mail, that would be fine. You can > even cut-and-paste you mail into it. > >>In fact it's simple to fix it. just change >>in >>void AdjoiningGenerations::adjust_boundary_for_old_gen_needs() >>the following change will solve it: >> >>-request_old_gen_expansion(desired_free_space); >>+request_old_gen_expansion(desired_free_space-old_gen()->free_in_bytes()); >> >> >> > > Yes, it's a straight forward change and so is a nice one if you > want to try you hand at a contribution. > >> >> >> >>>> >>>> >>> >>> > > _______________________________________________ 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 Sun.COM Mon Nov 17 05:53:56 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 17 Nov 2008 05:53:56 -0800 Subject: Openjdk hotspot build 14.0-b06 hard coded bug found. In-Reply-To: <2fcb552b0811142249m6da521cdsbc16a1a05fad0234@mail.gmail.com> References: <2fcb552b0811141412s5cb90c90od356f80b381fcbb5@mail.gmail.com> <491E0284.4000500@sun.com> <2fcb552b0811141600l19a65775ma9a083971cd57553@mail.gmail.com> <491E1D9A.2040208@sun.com> <2fcb552b0811142249m6da521cdsbc16a1a05fad0234@mail.gmail.com> Message-ID: <49217774.4070601@sun.com> Tony, Have you signed a Sun contributor agreement? http://www.sun.com/software/opensource/contributor_agreement.jsp Jon Tony Guan wrote On 11/14/08 22:49,: >Hi Jon, > >I've filed a bug report for it. The Review ID is 1390360. >And I am not sure about the calculated_old_free_size_in_bytes() part, >so I didn't included your comments. I can look further into the code >in the coming days. > >Thanks! > >Tony > >On Fri, Nov 14, 2008 at 6:53 PM, Jon Masamitsu wrote: > > >>Inline replies >> >>Tony Guan wrote On 11/14/08 16:00,: >> >> >> >>>On Fri, Nov 14, 2008 at 4:58 PM, Jon Masamitsu wrote: >>> >>> >>> >>> >>>>Tony Guan wrote On 11/14/08 14:12,: >>>> >>>> >>>> >>>> >>>> >>>>>Hi there, >>>>> >>>>>I think I've found a little bug in the parallel gc codes. Will >>>>>somebody take a look at it? >>>>>Firstly, after a full gc, there maybe the need to adjust the boundary >>>>>between young and old generation. >>>>>and here in psMarkSweep.cpp, we >>>>>use: heap->resize_old_gen(size_policy->calculated_old_free_size_in_bytes()); >>>>> >>>>>Then this methods will in turn call: >>>>> gens()->adjust_boundary_for_old_gen_needs(desired_free_space); >>>>> >>>>>in this function, we compare the desired_free_space with the current >>>>>free space, and then calls request_old_gen_expansion: >>>>> if (old_gen()->free_in_bytes() < desired_free_space) { >>>>> MutexLocker x(ExpandHeap_lock); >>>>> request_old_gen_expansion(desired_free_space); >>>>>but in request_old_gen_expansion the desired_free_space is immediately >>>>>treated as expand_in_bytes. And in this implementation, the actual >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Yes, you're right that this looks like a bug. >>>> >>>>Also something that doesn't look right here is the use of >>>>calculated_old_free_size_in_bytes(). It looks like it is adding >>>>room for 1 addtional young gen collection. Perhaps not a >>>>bad idea but I don't recall now why it is used instead of the >>>>straight promo_size(). >>>> >>>> >>>> >>>> >>>In my opinion, adding room for 1 additional young gen collection is >>>OK, because in adjustable parallel gc, by doing this, we can reduce >>>the chance of doing full gc for next time. And that's why it's called >>>desired_free_space. (just a guess) >>> >>> >>> >>> >>I think it's odd because "desire_free_size" should have any such >>additional space built into it. "desired_free_size" is set in a >>method that purports to calculate the correct amount of free >>space for the old generation yet the use of >>calculated_old_free_size_in_bytes() bumps that up just a bit. >>Probably doesn't hurt but it's a policy decision that should >>be embedded in the calculation of "desired_free_size". >> >> >> >>> >>> >>> >>>> >>>> >>>>>change in bytes is computed like this: >>>>>size_t change_in_bytes = MIN3(young_gen_available, >>>>> old_gen_available, >>>>> align_size_up_(expand_in_bytes, alignment)); >>>>>and then: >>>>>virtual_spaces()->adjust_boundary_up(change_in_bytes) >>>>> >>>>>So in the end, we have old_gen()->free_in_bytes()+=desired_free_space >>>>>and the final "desired_free_space" is more than needed. >>>>> >>>>>And after the boundary is moved up (too high), the >>>>>_old_gen->resize(desired_free_space) >>>>> >>>>>will compute the new space size as: >>>>>size_t new_size = used_in_bytes() + desired_free_space; >>>>> >>>>>Thus it will shrink the old gen space smaller. So we have part the >>>>>space sacrificed by the young generation out of the old gen usage. And >>>>>the size of this wasted memory is (desired_free_space- prevoiusly free >>>>>space of old_gen). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Yup, we've moved the boundary farther than we >>>>really wanted to. >>>> >>>>Are you able to file a bug report for this? Did you want >>>>to fix it? >>>> >>>> >>>> >>>> >>>Is there any format should I follow to report the bug? >>> >>> >>> >>> >>In the description section if you just included the info you >>put in your mail, that would be fine. You can >>even cut-and-paste you mail into it. >> >> >> >>>In fact it's simple to fix it. just change >>>in >>>void AdjoiningGenerations::adjust_boundary_for_old_gen_needs() >>>the following change will solve it: >>> >>>-request_old_gen_expansion(desired_free_space); >>>+request_old_gen_expansion(desired_free_space-old_gen()->free_in_bytes()); >>> >>> >>> >>> >>> >>Yes, it's a straight forward change and so is a nice one if you >>want to try you hand at a contribution. >> >> >> >>> >>> >>> >>>>> >>>>> >>>> >>>> >> >> _______________________________________________ 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 Sun.COM Mon Nov 17 11:34:49 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Mon, 17 Nov 2008 11:34:49 -0800 Subject: Request for review (medium): 6684579 Message-ID: 6684579 SoftReference processing can be made more efficient bug: http://bugs.sun.com/view_bug.do?bug_id=6684579 webrev: http://webrev.invokedynamic.info/ysr/6684579/ It turns out that, at least for current soft reference clearing policies where the soft-ref master clock is advanced only at each major GC, we can decide accurately (always for stop-world collectors, and for all current clearing policies also for concurrent collectors) whether a soft reference should not be cleared at the point at which the reference object is first discovered. This moves at least some of the load from the final reference processing phase into the marking phase (concurrent marking phase for the concurrent collectors) making for shorter GC pauses on account of processing SoftReference objects. For the specific, albeit somewhat extreme, case of this customer using the CMS collector the improvement was quite dramatic, going from 26 seconds to about 120 ms. In most cases, the performance improvement will be more modest depending on the size and population of soft references in the heap. Although the number of lines and files touched is rather large, the changes are wide and shallow, rather than deep, and mainly involve a change in the interface presented by some of the ReferenceProcessor methods to allow for the use of a soft ref policy object in the ReferenceProcessor object, rather than being a parameter to the processing methods. Thanks for your reviews. -- ramki From jon.masamitsu at sun.com Tue Nov 18 18:13:37 2008 From: jon.masamitsu at sun.com (jon.masamitsu at sun.com) Date: Wed, 19 Nov 2008 02:13:37 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6771742: Remove duplicate files from G1 merge Message-ID: <20081119021343.2B5B6D68C@hg.openjdk.java.net> Changeset: 8fa025608ec6 Author: jmasa Date: 2008-11-18 14:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/8fa025608ec6 6771742: Remove duplicate files from G1 merge Summary: Remove duplicate files and add includeDB_gc_g1 file in windows Makefile Reviewed-by: jcoomes, ysr ! make/windows/projectfiles/common/Makefile - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp From John.Coomes at sun.com Wed Nov 19 17:58:02 2008 From: John.Coomes at sun.com (John Coomes) Date: Wed, 19 Nov 2008 17:58:02 -0800 Subject: request for review (medium): 6722113 In-Reply-To: References: Message-ID: <18724.50218.760144.965731@sun.com> Y Srinivas Ramakrishna (Y.S.Ramakrishna at Sun.COM) wrote: > > 6722113 CMS: Incorrect overflow handling during precleaning of Reference lists > > http://bugs.sun.com/view_bug.do?bug_id=6722113 > > webrev: http://webrev.invokedynamic.info/ysr/6722113/ > ... Looks good to me. One nit: instead of adding a friend decl to CMSKeepAliveClosure, I think it'd be better to add a public accessor for the _concurrent_precleaning boolean and have CMSDrainMarkingStackClosure use that. -John From Y.S.Ramakrishna at Sun.COM Wed Nov 19 18:03:15 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Wed, 19 Nov 2008 18:03:15 -0800 Subject: request for review (medium): 6722113 In-Reply-To: <18724.50218.760144.965731@sun.com> References: <18724.50218.760144.965731@sun.com> Message-ID: Will fix that. Thanks for your review, John! (Thanks also to Andrey for his earlier review, sent separately!) -- ramki ----- Original Message ----- From: John Coomes Date: Wednesday, November 19, 2008 5:58 pm Subject: Re: request for review (medium): 6722113 To: Y Srinivas Ramakrishna Cc: hotspot-gc-dev at openjdk.java.net > Y Srinivas Ramakrishna (Y.S.Ramakrishna at Sun.COM) wrote: > > > > 6722113 CMS: Incorrect overflow handling during precleaning of > Reference lists > > > > http://bugs.sun.com/view_bug.do?bug_id=6722113 > > > > webrev: http://webrev.invokedynamic.info/ysr/6722113/ > > ... > > Looks good to me. One nit: instead of adding a friend decl to > CMSKeepAliveClosure, I think it'd be better to add a public accessor > for the _concurrent_precleaning boolean and have > CMSDrainMarkingStackClosure use that. > > -John > From igor.veresov at sun.com Wed Nov 19 22:16:32 2008 From: igor.veresov at sun.com (igor.veresov at sun.com) Date: Thu, 20 Nov 2008 06:16:32 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 24 new changesets Message-ID: <20081120061718.04D49D7D9@hg.openjdk.java.net> Changeset: 4d9884b01ba6 Author: never Date: 2008-10-28 09:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4d9884b01ba6 6754519: don't emit flag fixup for NaN when condition being tested doesn't need it Reviewed-by: kvn, rasbold ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/reg_split.cpp Changeset: b6cfd754403d Author: never Date: 2008-10-28 18:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b6cfd754403d 6649622: HotSpot Biased locking needs tuning on latest CPUs Reviewed-by: rasbold, kvn, kamg ! src/share/vm/runtime/arguments.cpp Changeset: f4fe12e429a4 Author: never Date: 2008-10-30 17:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f4fe12e429a4 6764622: IdealGraphVisualizer fixes Reviewed-by: rasbold, jrose ! src/share/tools/IdealGraphVisualizer/Bytecodes/src/com/sun/hotspot/igv/bytecodes/BytecodeViewTopComponent.java ! src/share/tools/IdealGraphVisualizer/ControlFlow/src/com/sun/hotspot/igv/controlflow/ControlFlowScene.java ! src/share/tools/IdealGraphVisualizer/ControlFlow/src/com/sun/hotspot/igv/controlflow/ControlFlowTopComponent.java ! src/share/tools/IdealGraphVisualizer/Coordinator/src/com/sun/hotspot/igv/coordinator/FolderNode.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/GraphDocument.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/Group.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/InputGraph.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/InputMethod.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/InputNode.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/Properties.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/Property.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/Parser.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/Printer.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/XMLParser.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/XMLWriter.java ! src/share/tools/IdealGraphVisualizer/Difference/src/com/sun/hotspot/igv/difference/Difference.java ! src/share/tools/IdealGraphVisualizer/Filter/manifest.mf ! src/share/tools/IdealGraphVisualizer/Filter/src/com/sun/hotspot/igv/filter/CustomFilter.java ! src/share/tools/IdealGraphVisualizer/Filter/src/com/sun/hotspot/igv/filter/SplitFilter.java ! src/share/tools/IdealGraphVisualizer/Graph/src/com/sun/hotspot/igv/graph/Diagram.java ! src/share/tools/IdealGraphVisualizer/Graph/src/com/sun/hotspot/igv/graph/Figure.java ! src/share/tools/IdealGraphVisualizer/HierarchicalLayout/src/com/sun/hotspot/igv/hierarchicallayout/Graph.java ! src/share/tools/IdealGraphVisualizer/HierarchicalLayout/src/com/sun/hotspot/igv/hierarchicallayout/HierarchicalClusterLayoutManager.java ! src/share/tools/IdealGraphVisualizer/Layout/src/com/sun/hotspot/igv/layout/LayoutGraph.java ! src/share/tools/IdealGraphVisualizer/README ! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/PropertiesSheet.java ! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/RangeSliderModel.java ! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/DiagramScene.java ! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/DiagramViewModel.java ! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/FindPanel.java ! src/share/tools/IdealGraphVisualizer/nbproject/platform.properties ! src/share/tools/IdealGraphVisualizer/nbproject/project.properties ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/frame.cpp Changeset: 72c5366e5d86 Author: rasbold Date: 2008-11-06 14:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/72c5366e5d86 6743900: frequency based block layout Summary: post-register allocation pass that drives block layout by edge frequencies Reviewed-by: never, kvn ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp Changeset: 0bf25c4807f9 Author: never Date: 2008-11-06 20:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0bf25c4807f9 6761594: framesize rounding code rounds using wrong units leading to slightly oversized frames Reviewed-by: rasbold, kvn ! src/share/vm/opto/chaitin.cpp Changeset: a1980da045cc Author: kvn Date: 2008-11-07 09:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a1980da045cc 6462850: generate biased locking code in C2 ideal graph Summary: Inline biased locking code in C2 ideal graph during macro nodes expansion Reviewed-by: never ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 577f3a2e0662 Author: never Date: 2008-11-07 13:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/577f3a2e0662 Merge Changeset: 05db98ed59ba Author: coleenp Date: 2008-11-07 11:03 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/05db98ed59ba 6760773: UseCompressedOops is broken with UseParNewGC Summary: sparc code for gen_subtype_check was doing an ld for a compressed oop with the sign bit set so not comparing, leading to a ClassCastException. Reviewed-by: phh, never, acorn, kvn, xlu ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp Changeset: 909cfd030fab Author: kamg Date: 2008-11-12 11:23 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/909cfd030fab Merge Changeset: 42ca4002efc2 Author: xdono Date: 2008-11-06 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/42ca4002efc2 Added tag jdk7-b39 for changeset 49ca90d77f34 ! .hgtags Changeset: 7704802ec1ce Author: trims Date: 2008-11-14 19:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7704802ec1ce Merge Changeset: 81a0cbe3b284 Author: trims Date: 2008-11-14 19:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/81a0cbe3b284 6771977: Bump HS14 build number to 07 Summary: Update the Hotspot build number to 07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3c07cda72b7d Author: tbell Date: 2008-11-11 22:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3c07cda72b7d 6764892: VS2008 changes required to compile hotspot sources Summary: Minor changes required to build using the Visual Studio 2008 compiler Reviewed-by: kvn, ohair ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/sa.make ! src/cpu/x86/vm/register_definitions_x86.cpp Changeset: 334969144810 Author: never Date: 2008-11-11 23:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/334969144810 6758445: loop heads that are exception entry points can crash during count_edges/mark_loops Reviewed-by: kvn, jrose ! src/share/vm/c1/c1_IR.cpp Changeset: 364141474b40 Author: never Date: 2008-11-12 05:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/364141474b40 Merge Changeset: 4d20a3aaf1ab Author: kvn Date: 2008-11-12 11:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4d20a3aaf1ab 6769748: Fix solaris makefiles for the case when "CC -V" produces several lines Summary: Fix solaris makefiles for 5.10 compilers Reviewed-by: jcoomes ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/i486.make ! make/solaris/makefiles/jvmg.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/sparc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/sparcv9.make ! make/solaris/makefiles/vm.make Changeset: a45484ea312d Author: jrose Date: 2008-11-12 22:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a45484ea312d 6653858: dynamic languages need to be able to load anonymous classes Summary: low-level privileged sun.misc.Unsafe.defineAnonymousClass Reviewed-by: kvn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/includeDB_gc_parallel ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 275a3b7ff0d6 Author: jrose Date: 2008-11-12 23:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/275a3b7ff0d6 6770949: minor tweaks before 6655638 Summary: minor cleanups & tuning of array.hpp, debug.cpp, growableArray.hpp, hashtable.cpp Reviewed-by: kvn ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.cpp Changeset: c1345e85f901 Author: kvn Date: 2008-11-13 14:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c1345e85f901 6767659: Conversion from i486 to x86 missed some entries in makefiles Summary: Fixed missed entries. Reviewed-by: never ! make/linux/makefiles/top.make ! make/solaris/makefiles/amd64.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/i486.make ! make/solaris/makefiles/sparc.make ! make/solaris/makefiles/top.make ! src/share/vm/adlc/archDesc.cpp Changeset: de78b80cedec Author: kvn Date: 2008-11-18 12:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/de78b80cedec 6772413: code cleanup Summary: Removed lines in adm64.make with interpret.o and moved few constant strings from header files. Reviewed-by: never ! make/solaris/makefiles/amd64.make ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/perfMemory.hpp Changeset: b1d6a3e95810 Author: kvn Date: 2008-11-18 12:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b1d6a3e95810 6766316: assert(!nocreate,"Cannot build a phi for a block already parsed.") Summary: Don't use the invariant local information if there are irreducible loops. Reviewed-by: never ! src/share/vm/opto/parse.hpp Changeset: 87559db65269 Author: kvn Date: 2008-11-18 14:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/87559db65269 6773078: UseCompressedOops: assert(kid == 0L || s->_leaf->in(0) == 0L,"internal operands have no control") Summary: Don't set the control edge of a klass load node. Reviewed-by: never ! src/share/vm/opto/macro.cpp Changeset: 491a904952f2 Author: kvn Date: 2008-11-19 09:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/491a904952f2 Merge Changeset: b5e603f2e024 Author: iveresov Date: 2008-11-19 14:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b5e603f2e024 Merge ! make/solaris/makefiles/dtrace.make - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp ! src/share/vm/runtime/globals.hpp From y.s.ramakrishna at sun.com Thu Nov 20 15:23:39 2008 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Thu, 20 Nov 2008 23:23:39 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6722113: CMS: Incorrect overflow handling during precleaning of Reference lists Message-ID: <20081120232341.E1C4AD82E@hg.openjdk.java.net> Changeset: 00b023ae2d78 Author: ysr Date: 2008-11-20 12:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/00b023ae2d78 6722113: CMS: Incorrect overflow handling during precleaning of Reference lists Summary: When we encounter marking stack overflow during precleaning of Reference lists, we were using the overflow list mechanism, which can cause problems on account of mutating the mark word of the header because of conflicts with mutator accesses and updates of that field. Instead we should use the usual mechanism for overflow handling in concurrent phases, namely dirtying of the card on which the overflowed object lies. Since precleaning effectively does a form of discovered list processing, albeit with discovery enabled, we needed to adjust some code to be correct in the face of interleaved processing and discovery. Reviewed-by: apetrusenko, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/runtime/globals.hpp From y.s.ramakrishna at sun.com Thu Nov 20 19:47:53 2008 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Fri, 21 Nov 2008 03:47:53 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6684579: SoftReference processing can be made more efficient Message-ID: <20081121034755.959C3D876@hg.openjdk.java.net> Changeset: c96030fff130 Author: ysr Date: 2008-11-20 16:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c96030fff130 6684579: SoftReference processing can be made more efficient Summary: For current soft-ref clearing policies, we can decide at marking time if a soft-reference will definitely not be cleared, postponing the decision of whether it will definitely be cleared to the final reference processing phase. This can be especially beneficial in the case of concurrent collectors where the marking is usually concurrent but reference processing is usually not. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/includeDB_core ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/utilities/macros.hpp From Jon.Masamitsu at Sun.COM Fri Nov 21 08:13:53 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Fri, 21 Nov 2008 08:13:53 -0800 Subject: See Par New GC 2 time slower on Sun T5220 than on Sun V440 In-Reply-To: References: Message-ID: <4926DE41.9040309@sun.com> Just FYI on this mail. We made a guess that the GC time was being dominated by Reference processing. They are using jdk5 and in ParNewGC in jdk5 Reference processing is done serially. Josh was able to make a change in the application to reduce that number of SoftReferences and the problem went away. Josh Wo wrote On 11/18/08 16:49,: >Hi Ramakrishna/Jon, > >I am with www.hotwire.com. I logged a Sun JDK case with Case # 66145049 as when we upgrade our Sun Fire v440 machine (4 cpu) with Sun SPARC-Enterprise-T5220 (showing 64 cpus using prstat) machine. During the load test, we saw our GC become more than 2 times slower than the old machine and see about 10% lower in the throughput. We have kept JVM setting the same but only increase the thread count of Weblogic (10mp1) work manager. > >I am wondering if you have any insight on why this is happening and if there are known issues/workaround. Any advice will be helpful. I have attached the GC output in the zip file. > >nohup-Nov10-11h09-wlviewstart-sjsp01.out is the v440 old machine, where GC is much better >nohup-Nov18-10h11-wlviewstart-sjsp03.out is the T5220 new machine, which is much more powerful but GC appears to be bad and we got worse throughput. > >Here is the java command line used on both machine >Java command line > >-Xms2410m -server -XX:ThreadStackSize=256 -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintClassHistogram -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+HandlePromotionFailure -XX:CMSInitiatingOccupancyFraction=68 -XX:+UseCMSInitiatingOccupancyOnly -Dsun.net.spi.nameservice.provider.1="dns,sun" -Dsun.net.spi.nameservice.nameservers=172.28.2.220,172.26.2.220 -Dsun.net.spi.nameservice.domain=stg.hotwire.com -XX:CMSMarkStackSize=32M -XX:CodeCacheMinimumFreeSpace=2M -XX:ReservedCodeCacheSize=64M -Xmx2410m -XX:NewSize=512M -XX:MaxNewSize=512M -XX:MaxTenuringThreshold=6 -XX:SurvivorRatio=5 -XX:TargetSurvivorRatio=80 -XX:MaxPermSize=256M -XX:-DisableExplicitGC -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger -Dhotwire.db.creds=/opt/p4/phoenix/10.11/deploy/stage/hw.db.creds -Dtangosol.coherence.mode=prod -Djava.endorsed.dirs=/opt/p4/3rdparty/apache/xalan/2.7.0hw -XX:CMSMaxAbortablePrecleanTime=1 -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -Djava.awt.headless=true -Dweblogic.client.socket.ConnectTimeout=5 -Dtangosol.coherence.distributed.localstorage=false -Dtangosol.coherence.cacheconfig=/opt/p4/phoenix/10.11/deploy/coherence-cache-config.xml -Dtangosol.coherence.log=jdk -Dtangosol.coherence.log.level=5 -Djavax.xml.transform.TransformerFactory=org.apache.xalan.xsltc.trax.TransformerFactoryImpl -Dweblogic.http.session.maxConcurrentRequest=5 -Dweblogic.management.server=http://swc01:7004 -Dcom.sun.management.jmxremote.port=8004 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dtangosol.coherence.management.remote=true -Dweblogic.Name=wlview1 -Dtangosol.coherence.member=wlview1 -Dweblogic.Domain=phoenix -Dweblogic.RootDirectory=/opt/p4/phoenix/10.11/deploy/stage/weblogic -Dwls.home=/opt/p4/3rdparty/bea/weblogic/10.0mp1/server -Dbea.home=/opt/p4/3rdparty/bea/weblogic/10.0mp1 -Dweblogic.connector.ConnectionPoolProfilingEnabled=false -Dcom.bea.wlw.netui.disableInstrumentation=true -D_Offline_FileDataArchive=true > >Thanks, >Josh > > > > > From y.s.ramakrishna at sun.com Mon Nov 24 12:46:35 2008 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Mon, 24 Nov 2008 20:46:35 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6774607: SIGSEGV or (!is_null(v), "oop value can never be zero") assertion when running with CMS and COOPs Message-ID: <20081124204638.5C7A4DAED@hg.openjdk.java.net> Changeset: df4305d4c1a1 Author: ysr Date: 2008-11-24 09:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/df4305d4c1a1 6774607: SIGSEGV or (!is_null(v),"oop value can never be zero") assertion when running with CMS and COOPs Summary: Use the more permissive set_klass_or_null() and klass_or_null() interfaces in ParNew's workqueue overflow code that manipulates the klass-word. Reviewed-by: coleenp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/oops/oop.inline.hpp From john.coomes at sun.com Mon Nov 24 15:35:22 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 24 Nov 2008 23:35:22 +0000 Subject: hg: jdk7/hotspot-gc: Added tag jdk7-b40 for changeset 44be42de6693 Message-ID: <20081124233522.239AFDB4A@hg.openjdk.java.net> Changeset: 8c34e4abcb43 Author: xdono Date: 2008-11-20 11:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/8c34e4abcb43 Added tag jdk7-b40 for changeset 44be42de6693 ! .hgtags From john.coomes at sun.com Mon Nov 24 15:39:09 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 24 Nov 2008 23:39:09 +0000 Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b40 for changeset 184e21992f47 Message-ID: <20081124233910.95220DB4F@hg.openjdk.java.net> Changeset: c90eeda9594e Author: xdono Date: 2008-11-20 11:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/c90eeda9594e Added tag jdk7-b40 for changeset 184e21992f47 ! .hgtags From john.coomes at sun.com Mon Nov 24 15:47:18 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 24 Nov 2008 23:47:18 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b40 for changeset 54946f466e2c Message-ID: <20081124234719.DC867DB54@hg.openjdk.java.net> Changeset: 0758bd3e2852 Author: xdono Date: 2008-11-20 11:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/0758bd3e2852 Added tag jdk7-b40 for changeset 54946f466e2c ! .hgtags From john.coomes at sun.com Mon Nov 24 15:50:56 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 24 Nov 2008 23:50:56 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b40 for changeset 70a6ac6dd737 Message-ID: <20081124235058.5C28FDB59@hg.openjdk.java.net> Changeset: a8379d24aa03 Author: xdono Date: 2008-11-20 11:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/a8379d24aa03 Added tag jdk7-b40 for changeset 70a6ac6dd737 ! .hgtags From john.coomes at sun.com Mon Nov 24 15:54:28 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 24 Nov 2008 23:54:28 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 12 new changesets Message-ID: <20081124235649.406F9DB5E@hg.openjdk.java.net> Changeset: 64da1f751c0f Author: martin Date: 2008-10-24 20:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/64da1f751c0f 6761678: (ann) SecurityException in AnnotationInvocationHandler.getMemberMethods Summary: Move call to getDeclaredMethods inside doPrivileged Reviewed-by: darcy, mullan Contributed-by: jjb at google.com ! src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java + test/java/lang/annotation/ParameterAnnotations.java Changeset: 1a324821b463 Author: tbell Date: 2008-10-24 20:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1a324821b463 Merge Changeset: 76ecb928e83a Author: emcmanus Date: 2008-10-27 14:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/76ecb928e83a 6763639: Remove "rawtypes" warnings from JMX code Reviewed-by: dfuchs ! make/netbeans/jmx/build.xml ! src/share/classes/com/sun/jmx/event/LeaseManager.java ! src/share/classes/com/sun/jmx/event/LeaseRenewer.java ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanIntrospector.java ! src/share/classes/com/sun/jmx/mbeanserver/ObjectInputStreamWithLoader.java ! src/share/classes/com/sun/jmx/mbeanserver/SecureClassLoaderRepository.java ! src/share/classes/com/sun/jmx/mbeanserver/Util.java ! src/share/classes/com/sun/jmx/mbeanserver/WeakIdentityHashMap.java ! src/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/internal/ProxyInputStream.java ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/internal/Unmarshal.java ! src/share/classes/com/sun/jmx/remote/security/FileLoginModule.java ! src/share/classes/com/sun/jmx/remote/security/JMXPluggableAuthenticator.java ! src/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java ! src/share/classes/com/sun/jmx/remote/util/ClassLoaderWithRepository.java ! src/share/classes/com/sun/jmx/remote/util/ClassLogger.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/com/sun/jmx/remote/util/EventClientConnection.java ! src/share/classes/com/sun/jmx/remote/util/OrderClassLoaders.java ! src/share/classes/javax/management/AttributeList.java ! src/share/classes/javax/management/DefaultLoaderRepository.java ! src/share/classes/javax/management/JMRuntimeException.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanInfo.java ! src/share/classes/javax/management/MBeanOperationInfo.java ! src/share/classes/javax/management/MBeanServerFactory.java ! src/share/classes/javax/management/MBeanServerInvocationHandler.java ! src/share/classes/javax/management/StandardMBean.java ! src/share/classes/javax/management/event/EventClientDelegate.java ! src/share/classes/javax/management/event/EventSubscriber.java ! src/share/classes/javax/management/loading/DefaultLoaderRepository.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/javax/management/loading/MLetObjectInputStream.java ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/management/openmbean/ArrayType.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/management/openmbean/CompositeType.java ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenType.java ! src/share/classes/javax/management/openmbean/SimpleType.java ! src/share/classes/javax/management/openmbean/TabularDataSupport.java ! src/share/classes/javax/management/openmbean/TabularType.java ! src/share/classes/javax/management/relation/MBeanServerNotificationFilter.java ! src/share/classes/javax/management/relation/RelationService.java ! src/share/classes/javax/management/relation/RelationSupport.java ! src/share/classes/javax/management/relation/Role.java ! src/share/classes/javax/management/relation/RoleList.java ! src/share/classes/javax/management/relation/RoleResult.java ! src/share/classes/javax/management/relation/RoleUnresolved.java ! src/share/classes/javax/management/relation/RoleUnresolvedList.java ! src/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java ! src/share/classes/javax/management/remote/rmi/RMIConnection.java ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java ! src/share/classes/javax/management/timer/Timer.java Changeset: 98ac3d398ed6 Author: chegar Date: 2008-10-28 16:14 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/98ac3d398ed6 6756771: com.sun.net.httpserver.HttpServer should handle POSTs larger than 2Gig Summary: update implementation to use long instead of int Reviewed-by: michaelm ! src/share/classes/sun/net/httpserver/ExchangeImpl.java ! src/share/classes/sun/net/httpserver/FixedLengthInputStream.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/ServerImpl.java + test/com/sun/net/httpserver/bugs/FixedLengthInputStream.java Changeset: 58e52eb46bd3 Author: emcmanus Date: 2008-10-28 18:21 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/58e52eb46bd3 6763051: MXBean: Incorrect type names for parametrized dealing with arrays (openType) 6713777: developer diagnosability of errors in uncompliant mxbean interfaces Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanIntrospector.java ! src/share/classes/javax/management/MBeanServerInvocationHandler.java + test/javax/management/mxbean/ExceptionDiagnosisTest.java ! test/javax/management/mxbean/TypeNameTest.java Changeset: 8dcde0b16199 Author: emcmanus Date: 2008-10-30 17:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8dcde0b16199 6252609: Two different default descriptor forms defined for ModelMBeanInfoSupport 6253137: Documentation for NotificationListener's handback parameter is confusing 6368691: javadoc for JMX Descriptors has bugs and is very hard to navigate. 6602699: support for async notification of mbeaninfo update 6759612: [javadoc] EventClient.NOTIFS_LOST has a garbled href to addEventClientListener 6759619: Clarify what EventClient.getEventClientNotificationInfo does 6759622: Clarify what EventClient.getListeners list does Summary: Documentation fixes, plus simple bugfix for 6759619. Reviewed-by: dfuchs ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/MBeanInfo.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/NotificationListener.java ! src/share/classes/javax/management/event/EventClient.java ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java ! test/javax/management/eventService/CustomForwarderTest.java ! test/javax/management/mxbean/TypeNameTest.java Changeset: cdfb6f963a60 Author: emcmanus Date: 2008-10-30 18:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/cdfb6f963a60 6450848: make it easier to get the ObjectName of a JMX Proxy Summary: Rework proxy javadoc to explain how to do this. Reviewed-by: sjiang ! src/share/classes/javax/management/JMX.java Changeset: 4ff842aee1fd Author: mullan Date: 2008-10-30 17:24 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4ff842aee1fd 6764553: com.sun.org.apache.xml.internal.security.utils.IdResolver is not thread safe Reviewed-by: valeriep ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java Changeset: f246770bcc78 Author: mullan Date: 2008-10-30 17:28 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f246770bcc78 Merge Changeset: 8d17cc67a857 Author: emcmanus Date: 2008-10-31 17:34 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8d17cc67a857 6766173: Spec should say that createMBean wraps a constructor RuntimeException in a RuntimeMBeanException Summary: JMX spec clarification Reviewed-by: dfuchs ! src/share/classes/javax/management/MBeanServerConnection.java ! src/share/classes/javax/management/namespace/MBeanServerSupport.java ! test/javax/management/MBeanServer/MBeanExceptionTest.java Changeset: 2201dad60231 Author: tbell Date: 2008-11-07 11:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2201dad60231 Merge Changeset: d00c685ae55e Author: xdono Date: 2008-11-20 11:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d00c685ae55e Added tag jdk7-b40 for changeset 2201dad60231 ! .hgtags From john.coomes at sun.com Mon Nov 24 16:02:53 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 25 Nov 2008 00:02:53 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 14 new changesets Message-ID: <20081125000315.76167DB64@hg.openjdk.java.net> Changeset: 6508d7e812e1 Author: mcimadamore Date: 2008-10-23 17:59 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/6508d7e812e1 6732484: Bound error on wildcard code Summary: Check.checkExtends should cope with captured type-variables Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/wildcards/T6732484.java Changeset: 4d2d8b6459e1 Author: mcimadamore Date: 2008-10-23 17:59 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/4d2d8b6459e1 6711619: javac doesn't allow access to protected members in intersection types Summary: Accordingly to new accessibility rules all members of intersection types (but private ones) should be accessible Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/generics/6531090/T6531090b.java + test/tools/javac/generics/6711619/T6711619a.java + test/tools/javac/generics/6711619/T6711619a.out + test/tools/javac/generics/6711619/T6711619b.java + test/tools/javac/generics/6711619/T6711619b.out Changeset: db77bf6adb53 Author: mcimadamore Date: 2008-10-23 18:00 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/db77bf6adb53 6487370: javac incorrectly gives ambiguity warning with override-equivalent abstract inherited methods Summary: Javac should not compare erased return types when checking for ambiguity errors during overload resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/6487370/T6487370.java Changeset: 433ee48257c0 Author: mcimadamore Date: 2008-10-23 18:10 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/433ee48257c0 6548436: Incorrect inconvertible types error Summary: Types.rewrite quantifiers should cope with captured type-variables properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.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 Changeset: c6e3fc6dda61 Author: mcimadamore Date: 2008-10-23 18:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/c6e3fc6dda61 6557954: Inner class type parameters doesn't get substituted when checking type well-formedness Summary: Validator.visitTypeApply should substitute all formal typevars with actual parameters Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/T6557954.java Changeset: 5e54a59bcee7 Author: mcimadamore Date: 2008-10-24 12:45 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/5e54a59bcee7 6680106: StackOverFlowError for Cyclic inheritance in TypeParameters with ArrayType Bounds Summary: Javac ends up in an infinite loop while attributing mutually referring array type-parameter bounds Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/typevars/6680106/T6680106.java + test/tools/javac/generics/typevars/6680106/T6680106.out Changeset: a23e1dc02698 Author: mcimadamore Date: 2008-10-24 12:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/a23e1dc02698 6746184: javac fails to compile call to public varargs method Summary: javac's resolution process should go through all steps described in JLS 15.12.2.2 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/varargs/T6746184.java Changeset: ddd75a295501 Author: mcimadamore Date: 2008-10-24 12:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/ddd75a295501 6758789: Some method resolution diagnostic should be improved Summary: Recent work on diagnostics left out some resolution corner cases Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/Formattable.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/6758789/T6758789a.java + test/tools/javac/6758789/T6758789a.out + test/tools/javac/6758789/T6758789b.java + test/tools/javac/6758789/T6758789b.out ! test/tools/javac/generics/inference/6718364/T6718364.out Changeset: 638d45788c9e Author: mcimadamore Date: 2008-10-24 12:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/638d45788c9e 6762569: Javac crashes with AssertionError in Types.containedBy Summary: Types.containedBy should be more liberal with UndetVars Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java - test/tools/javac/generics/wildcards/6651719/T6651719b.java + test/tools/javac/generics/wildcards/6762569/T6762569a.java + test/tools/javac/generics/wildcards/6762569/T6762569b.java Changeset: 8d7fa40da0eb Author: tbell Date: 2008-10-24 20:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/8d7fa40da0eb Merge - test/tools/javac/generics/wildcards/6651719/T6651719b.java Changeset: 5ebe90e0afff Author: jjg Date: 2008-10-27 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/5ebe90e0afff 6764226: ListTest fails on javap output with bad characters Reviewed-by: darcy ! test/tools/javap/ListTest.java Changeset: 4f7b344a1ce0 Author: mcimadamore Date: 2008-10-28 14:05 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/4f7b344a1ce0 6763518: Impossible to suppress raw-type warnings Summary: Check.validate(Type) should be invoked after -Xlint is augmented in Attr.visitVarDef Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6304921/T6304921.out + test/tools/javac/warnings/T6763518.java Changeset: 32e309883246 Author: tbell Date: 2008-11-07 11:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/32e309883246 Merge Changeset: 82463d00ac70 Author: xdono Date: 2008-11-20 11:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/82463d00ac70 Added tag jdk7-b40 for changeset 32e309883246 ! .hgtags From John.Coomes at sun.com Tue Nov 25 14:49:26 2008 From: John.Coomes at sun.com (John Coomes) Date: Tue, 25 Nov 2008 14:49:26 -0800 Subject: review request (M) - 6578152: fill_region_with_object In-Reply-To: <18705.57958.192973.973703@sun.com> References: <18705.57958.192973.973703@sun.com> Message-ID: <18732.33014.772035.500117@sun.com> John Coomes (John.Coomes at sun.com) wrote: > 6578152: fill_region_with_object has usability and safety issues > > http://webrev.invokedynamic.info/jcoomes/6578152-fill/ > > Touches 25 files, but many are trivial changes. Thanks for any > comments. Ping :-). Still looking for reviews. I updated the webrev after two minor changes: (a) the new versions of insert_deadspace() in psMarkSweepDecorator.cpp and space.cpp now mark the object live as the old versions did, and (b) fixed a typo in fill_with_array in collectedHeap.cpp (no semantic change). If anyone looked at the previous version and would like more details on these, let me know. -John P.S.: I'll be on vacation until Tue, Dec 2. From igor.veresov at sun.com Wed Nov 26 15:05:41 2008 From: igor.veresov at sun.com (igor.veresov at sun.com) Date: Wed, 26 Nov 2008 23:05:41 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 9 new changesets Message-ID: <20081126230559.0D0B5DCEF@hg.openjdk.java.net> Changeset: 316c0b576ea1 Author: xdono Date: 2008-11-20 11:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/316c0b576ea1 Added tag jdk7-b40 for changeset 81a0cbe3b284 ! .hgtags Changeset: ab42bab113e0 Author: trims Date: 2008-11-21 16:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ab42bab113e0 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp Changeset: f9d938ede196 Author: trims Date: 2008-11-21 16:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f9d938ede196 6775176: Bump HS14 build number to 08 Summary: Update the Hotspot build number to 08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 2b42b31e7928 Author: coleenp Date: 2008-11-21 08:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2b42b31e7928 6676175: BigApps crash JVM Client VM (build 10.0-b22, mixed mode, sharing) with SIGSEGV (0xb) Summary: Add test for biased locking epoch before walking own thread stack in case of rare race Reviewed-by: phh, never ! src/share/vm/runtime/biasedLocking.cpp Changeset: ba7f9d894282 Author: kamg Date: 2008-11-21 15:10 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ba7f9d894282 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp Changeset: 171e581e8161 Author: xlu Date: 2008-11-22 00:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/171e581e8161 6554406: Change switch UseVMInterruptibleIO default to false (sol) Summary: The default value of UseVMInterruptibleIO is changed to false for JDK 7, but the default isn't changed for JDK 6 and earlier. Reviewed-by: never, acorn, dholmes, kamg, alanb ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b22701a8b88f Author: coleenp Date: 2008-11-24 14:45 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b22701a8b88f 6474243: suspicious jvmti code that uses oop unsafely across GC point Summary: oop stored in unsafely in Lscratch noticed by visual inspection will not be updated by GC. Reviewed-by: kamg, never, kvn ! src/cpu/sparc/vm/templateTable_sparc.cpp Changeset: a60eabc24e2c Author: kamg Date: 2008-11-25 15:59 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a60eabc24e2c Merge Changeset: 434912c745cf Author: iveresov Date: 2008-11-26 09:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/434912c745cf Merge ! src/share/vm/runtime/globals.hpp