From rickard.backman at oracle.com Tue Nov 1 00:28:04 2011 From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=) Date: Tue, 01 Nov 2011 08:28:04 +0100 Subject: Request for review (XS): 7106766 In-Reply-To: <4EAF9001.60709@oracle.com> References: <4EAF9001.60709@oracle.com> Message-ID: <4EAF9F84.6050207@oracle.com> Sorry for being brief on the RFR, the reason we want to do this is that having the precompiled header in the "root" directory sometimes cause problems since the lookup order (at least for MS CL) is: #1 the directory of the file #2 the include path (-I /I) ... we would like to be able to modify the include path but since all files use relative includes from the "root" (src/share/vm) #1 will take precedence and make it impossible to do. The CR can also be seen here: http://monaco.sfbay.sun.com/detail.jsf?cr=7106766 Thanks Rickard On 11/01/2011 07:21 AM, Rickard B?ckman wrote: > 7106766: Move the precompiled header from the src/share/vm directory > > Moved the precompiled.hpp file from src/share/vm to > src/share/vm/precompiled > > http://cr.openjdk.java.net/~rbackman/7106766/ > > Thanks > Rickard From rickard.backman at oracle.com Tue Nov 1 01:13:39 2011 From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=) Date: Tue, 01 Nov 2011 09:13:39 +0100 Subject: Request for review (XS): 7106766 In-Reply-To: <4EAF9F84.6050207@oracle.com> References: <4EAF9001.60709@oracle.com> <4EAF9F84.6050207@oracle.com> Message-ID: <4EAFAA33.70600@oracle.com> The URL should be: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7106766 but it seems it is not yet visible. /Rickard On 11/01/2011 08:28 AM, Rickard B?ckman wrote: > Sorry for being brief on the RFR, > > the reason we want to do this is that having the precompiled header in > the "root" directory sometimes cause problems since the lookup order (at > least for MS CL) is: > > #1 the directory of the file > #2 the include path (-I /I) > ... > > we would like to be able to modify the include path but since all files > use relative includes from the "root" (src/share/vm) #1 will take > precedence and make it impossible to do. > > The CR can also be seen here: > http://monaco.sfbay.sun.com/detail.jsf?cr=7106766 > > Thanks > Rickard > > On 11/01/2011 07:21 AM, Rickard B?ckman wrote: >> 7106766: Move the precompiled header from the src/share/vm directory >> >> Moved the precompiled.hpp file from src/share/vm to >> src/share/vm/precompiled >> >> http://cr.openjdk.java.net/~rbackman/7106766/ >> >> Thanks >> Rickard > From david.holmes at oracle.com Tue Nov 1 02:31:22 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 01 Nov 2011 19:31:22 +1000 Subject: Request for review (XS): 7106766 In-Reply-To: <4EAFAA33.70600@oracle.com> References: <4EAF9001.60709@oracle.com> <4EAF9F84.6050207@oracle.com> <4EAFAA33.70600@oracle.com> Message-ID: <4EAFBC6A.6000006@oracle.com> Thanks Rickard, this change looks okay to me. David On 1/11/2011 6:13 PM, Rickard B?ckman wrote: > The URL should be: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7106766 > but it seems it is not yet visible. > > /Rickard > > On 11/01/2011 08:28 AM, Rickard B?ckman wrote: >> Sorry for being brief on the RFR, >> >> the reason we want to do this is that having the precompiled header in >> the "root" directory sometimes cause problems since the lookup order (at >> least for MS CL) is: >> >> #1 the directory of the file >> #2 the include path (-I /I) >> ... >> >> we would like to be able to modify the include path but since all files >> use relative includes from the "root" (src/share/vm) #1 will take >> precedence and make it impossible to do. >> >> The CR can also be seen here: >> http://monaco.sfbay.sun.com/detail.jsf?cr=7106766 >> >> Thanks >> Rickard >> >> On 11/01/2011 07:21 AM, Rickard B?ckman wrote: >>> 7106766: Move the precompiled header from the src/share/vm directory >>> >>> Moved the precompiled.hpp file from src/share/vm to >>> src/share/vm/precompiled >>> >>> http://cr.openjdk.java.net/~rbackman/7106766/ >>> >>> Thanks >>> Rickard >> > From coleen.phillimore at oracle.com Tue Nov 1 05:24:52 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 01 Nov 2011 08:24:52 -0400 Subject: Request for review (XS): 7106766 In-Reply-To: <4EAFBC6A.6000006@oracle.com> References: <4EAF9001.60709@oracle.com> <4EAF9F84.6050207@oracle.com> <4EAFAA33.70600@oracle.com> <4EAFBC6A.6000006@oracle.com> Message-ID: <4EAFE514.5050709@oracle.com> On 11/1/2011 5:31 AM, David Holmes wrote: > Thanks Rickard, this change looks okay to me. Looks good to me too. Thanks! Coleen > > David > > On 1/11/2011 6:13 PM, Rickard B?ckman wrote: >> The URL should be: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7106766 >> but it seems it is not yet visible. >> >> /Rickard >> >> On 11/01/2011 08:28 AM, Rickard B?ckman wrote: >>> Sorry for being brief on the RFR, >>> >>> the reason we want to do this is that having the precompiled header in >>> the "root" directory sometimes cause problems since the lookup order >>> (at >>> least for MS CL) is: >>> >>> #1 the directory of the file >>> #2 the include path (-I /I) >>> ... >>> >>> we would like to be able to modify the include path but since all files >>> use relative includes from the "root" (src/share/vm) #1 will take >>> precedence and make it impossible to do. >>> >>> The CR can also be seen here: >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7106766 >>> >>> Thanks >>> Rickard >>> >>> On 11/01/2011 07:21 AM, Rickard B?ckman wrote: >>>> 7106766: Move the precompiled header from the src/share/vm directory >>>> >>>> Moved the precompiled.hpp file from src/share/vm to >>>> src/share/vm/precompiled >>>> >>>> http://cr.openjdk.java.net/~rbackman/7106766/ >>>> >>>> Thanks >>>> Rickard >>> >> From rickard.backman at oracle.com Tue Nov 1 05:39:28 2011 From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=) Date: Tue, 01 Nov 2011 13:39:28 +0100 Subject: Request for review (XS): 7106766 In-Reply-To: <4EAFE514.5050709@oracle.com> References: <4EAF9001.60709@oracle.com> <4EAF9F84.6050207@oracle.com> <4EAFAA33.70600@oracle.com> <4EAFBC6A.6000006@oracle.com> <4EAFE514.5050709@oracle.com> Message-ID: <4EAFE880.9040704@oracle.com> Thanks Coleen! /R On 11/01/2011 01:24 PM, Coleen Phillimore wrote: > On 11/1/2011 5:31 AM, David Holmes wrote: >> Thanks Rickard, this change looks okay to me. > > Looks good to me too. Thanks! > Coleen > >> >> David >> >> On 1/11/2011 6:13 PM, Rickard B?ckman wrote: >>> The URL should be: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7106766 >>> but it seems it is not yet visible. >>> >>> /Rickard >>> >>> On 11/01/2011 08:28 AM, Rickard B?ckman wrote: >>>> Sorry for being brief on the RFR, >>>> >>>> the reason we want to do this is that having the precompiled header in >>>> the "root" directory sometimes cause problems since the lookup order >>>> (at >>>> least for MS CL) is: >>>> >>>> #1 the directory of the file >>>> #2 the include path (-I /I) >>>> ... >>>> >>>> we would like to be able to modify the include path but since all files >>>> use relative includes from the "root" (src/share/vm) #1 will take >>>> precedence and make it impossible to do. >>>> >>>> The CR can also be seen here: >>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7106766 >>>> >>>> Thanks >>>> Rickard >>>> >>>> On 11/01/2011 07:21 AM, Rickard B?ckman wrote: >>>>> 7106766: Move the precompiled header from the src/share/vm directory >>>>> >>>>> Moved the precompiled.hpp file from src/share/vm to >>>>> src/share/vm/precompiled >>>>> >>>>> http://cr.openjdk.java.net/~rbackman/7106766/ >>>>> >>>>> Thanks >>>>> Rickard >>>> >>> > From Dmitry.Samersoff at oracle.com Tue Nov 1 06:49:09 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 01 Nov 2011 17:49:09 +0400 Subject: Request for review [new bug](S): Stack guard pages are no more protected after loading a shared library with executable stack. In-Reply-To: <140FA3E3585AD840A3316D2853F974DC07BBC2802E@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC07BBC2802E@DEWDFECCR03.wdf.sap.corp> Message-ID: <4EAFF8D5.5030104@oracle.com> Goetz, I filled a bug - 7107135 Sorry for delay! -Dmitry On 2011-10-26 16:07, Lindenmaier, Goetz wrote: > Hi, > > > > I am Goetz Lindenmaier from SAP AG, working in the SAP JVM Jit Team. > > > > We found an issue loading jni libraries where the stack is set to > ?execstack?, or > > where this flag is not set at all. After loading such a library, the > stack guard > > pages are lost and though stack overflows can no more be detected. > > We had a lot of libraries in our test systems where the execstack > > flag was missing. > > > > This webrev contains a small test and a possible fix for the problem: > > http://www.sapjvm.com/gl/webrevs/noexecstack/ > > As I don?t have a bug ID yet, I just used an arbitrary number to make > > the test executable with jtreg . Please open a bug for this issue. > > I?ll fix the test if I have a proper number. > > > > This problem exists since 7019808, which adds ?z noexecstack to the > > linker command on linux. > > > > The fix I propose does the following: > > It reads the elf file to detect whether loading the library can change > > stack properties. If so, it requests a safepoint and loads the library > > during the safepoint. After loading the library, it tests the guard > > pages with SafeFetch. If they are no more protected, it reprotects > > the guard pages of all Java stacks. > > > > There might be cases where reading the elf file does not suffice > > to know that the stack access rights will change. > > As I understand, if a properly compiled jni library loads another > > library which requires execstack, the stack changes access rights, too. > > This is detected by the SafeFetch, and the stacks are fixed. But in > > this case the stacks are unprotected for a short time. > > To improve on this, one would have to request a SafePoint for each > > library loaded. But anyways, there is no bulletproof solution, > > as the loaded code could do an mprotect() at some point. > > > > Best regards, > > Goetz. > > > > > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From bengt.rutisson at oracle.com Tue Nov 1 08:04:33 2011 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Tue, 01 Nov 2011 15:04:33 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7106766: Move the precompiled header from the src/share/vm directory Message-ID: <20111101150437.A09B6471ED@hg.openjdk.java.net> Changeset: 95009f678859 Author: brutisso Date: 2011-11-01 13:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/95009f678859 7106766: Move the precompiled header from the src/share/vm directory Summary: Moved precompiled.hpp to src/share/vm/precompiled Reviewed-by: coleenp, dholmes Contributed-by: rbackman ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/gcc.make ! make/windows/makefiles/vm.make - src/share/vm/precompiled.hpp + src/share/vm/precompiled/precompiled.hpp From david.holmes at oracle.com Tue Nov 1 19:36:51 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 02 Nov 2011 12:36:51 +1000 Subject: Request for review: 7104173 sun/tools tests fail with debug build after 7012206 In-Reply-To: <4EA96E79.2080906@oracle.com> References: <4EA7A99E.6070909@oracle.com> <3BFD44CC-632A-4551-8866-E1944D6C4E03@oracle.com> <4EA9199F.4010101@oracle.com> <03BAC2FF-69AC-4C38-8D40-E7A65E94C9CE@oracle.com> <4EA920C7.4020607@oracle.com> <4EA936CB.2050507@oracle.com> <4EA947F1.3070605@oracle.com> <4EA96E79.2080906@oracle.com> Message-ID: <4EB0ACC3.7070107@oracle.com> Well this is embarrassing. 7012206 changed the tests to always pass -XX:+UsePerfData. 7104173 changed the default of PrintVMOptions in a debug build for Embedded only. That means that all non-Embedded debug builds still fail all these tests. David On 28/10/2011 12:45 AM, Paul Hohensee wrote: > Looks good to me too. And, I'm an "official reviewer". :) > > Paul > > On 10/27/11 8:00 AM, Coleen Phillimore wrote: >> This still seems fine to me (after reading the discussion and >> 6605954). I don't know why someone wanted PrintVMOptions on in the >> regular product, but it having this divergence for embedded is okay >> with me. >> >> Coleen >> >> On 10/27/2011 6:47 AM, David Holmes wrote: >>> On 27/10/2011 7:13 PM, Dmitry Samersoff wrote: >>>>> I don't know the history of that option but maybe we should disable >>>>> it for non-embedded builds too? >>>> >>>> +1 >>>> >>>> I also would prefer to keep the same behavior for embedded/non-embedded >>>> when possible. >>> >>> 6605954 was closed as "not a defect". So non-embedded has already >>> expressed a desire to keep the current behaviour. Hence the >>> embedded-only change. >>> >>> Thanks for the "reviews" ;-) I'll wait and see if I can get another >>> formal review from runtime before pushing. >>> >>> David >>> >>>> -Dmitry >>>> >>>> On 2011-10-27 13:00, Christian Thalinger wrote: >>>>> >>>>> On Oct 27, 2011, at 10:43 AM, David Holmes wrote: >>>>> >>>>>> Hi Chris, >>>>>> >>>>>> On 27/10/2011 5:51 PM, Christian Thalinger wrote: >>>>>>> >>>>>>> On Oct 26, 2011, at 8:33 AM, David Holmes wrote: >>>>>>> >>>>>>>> webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dholmes/7104173/webrev/ >>>>>>>> >>>>>>>> A trivial change for our embedded code to aid in testing. Some >>>>>>>> tests need to be passed -XX:+UsePerfData to make them work >>>>>>>> (7012206). A debug build, by default, prints any -XX options >>>>>>>> passed to it. Any such tests that parse the test output then >>>>>>>> fail with a debug build because of this extra unexpected output. >>>>>>>> >>>>>>>> So for embedded only we simply turn PrintVMOptions off by >>>>>>>> default for all builds. >>>>>>> >>>>>>> Why aren't you also passing -PrintVMOptions for the tests that >>>>>>> need +UsePerfData? >>>>>> >>>>>> When 701226 was fixed I didn't realize there would be a need to >>>>>> add -PrintVMOptions. Rather than go through and pollute all those >>>>>> test scripts with yet-another-option I decided to deal with the >>>>>> problem at the source - the VM. There really is no need to print >>>>>> the options by default with a debug build. So for the embedded >>>>>> build we turn it off. (See also 6605954) >>>>> >>>>> I don't know the history of that option but maybe we should disable >>>>> it for non-embedded builds too? Sometimes the output of the VM >>>>> options is useful but in that case I can add +PrintVMOptions manually. >>>>> >>>>> I don't have a strong opinion here I just don't like that embedded >>>>> and non-embedded are diverging here. Anyway, the change is >>>>> basically okay :-) >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>> >>>>> >>>> >>>> From goetz.lindenmaier at sap.com Thu Nov 3 08:09:49 2011 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 3 Nov 2011 16:09:49 +0100 Subject: Request for review [7107135](S): Stack guard pages are no more protected after loading a shared library with executable stack. In-Reply-To: <4EA953CC.3080105@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC07BBC2802E@DEWDFECCR03.wdf.sap.corp> <4EA8111F.7010503@oracle.com> <140FA3E3585AD840A3316D2853F974DC07BBCA3FF5@DEWDFECCR03.wdf.sap.corp> <4EA834CA.10504@oracle.com> <140FA3E3585AD840A3316D2853F974DC07BBCA4C66@DEWDFECCR03.wdf.sap.corp> <4EA953CC.3080105@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC07BC04B789@DEWDFECCR03.wdf.sap.corp> Hi Dmitry, I understand that a fix for this issue should not affect applications that use properly tagged jni applications. But I don't think reading the elf file is as problematic as you indicate. > > yes, I know that's costly. But it at most doubles the cost > > of loading the DSO, as dlopen also reads the file. > OS doesn't actually read DSO at the time of dlopen in most cases because > of caching. Yes, dlopen must not read the full file. But dlopen must know about the required stack protection of the library. To find this out, it must read the GNU_STACK entry, which is just the part my code reads, too. > Also we have to parse LD_LIBRARY_PATH and search for file over it. As far as I see, os::dll_open always gets a full path passed as argument. So we need not search LD_LIBRARY_PATH. > Also we have to care about LD_PRELOAD, symlinks, permissions - > lots of work - check ld.so sources for details. I think the common case for a jni library isn't that complicated. Anyways, there is no bulletproof solution, as the loaded library can do a mprotect() on the stack. (Symlinks should be resolved by fopen.) The other calls to dlopen (like dlopen("librt.so.1", RTLD_LAZY)) are done during initialization, so that the stack protection is changed before there are Java threads with guard pages. So they are no issue. > > An alternative is to always do a safepoint, and just reprotect > > if SafeFetch failed. This would have the advantage that > > we are sure we catch all changes of the guard page protection. > > But in that case all threads have to wait for the IO of dlopen. > > I'm not sure we have to decrease performance for all clients in order to > workaround a bug in an old library (modern tendency is to treat > executable stack as a security bug). Yep, I think so, too. But I think I should do the reprotection of the stacks in a safepoint in any case. This safepoint will be needed at most once in the runtime of a VM. > Also stack overflow is not an everyday situation for well-designed Java > app. Well, we recently even had a customer with a stack overflow while handling an other exception ;). > I plan to put more efforts to this problem and check whether we have a > clever solution for this problem or not. That's good, thank you! Best regards, Goetz. From jiangli.zhou at oracle.com Wed Nov 9 09:47:25 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 09 Nov 2011 09:47:25 -0800 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field Message-ID: <4EBABCAD.6060905@oracle.com> Compact following 4 instanceKlass boolean fields into a signal u1 field. Each flag now uses 1-bit. The new field is placed after the _idnum_allocated_count field to utilize the unused 2-byte after _idnum_allocated_count. Compacting these fields saves 4-bytes for each loaded classes. bool _is_marked_dependent; // used for marking during flushing and deoptimization bool _rewritten; // methods rewritten. bool _has_nonstatic_fields; // for sizing with UseCompressedOops bool _should_verify_class; // allow caching of preverification http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ Tested with runThese on ubuntu. Ran JPRT. Thanks, Jiangli From bob.vandette at oracle.com Wed Nov 9 14:13:49 2011 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 9 Nov 2011 17:13:49 -0500 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: <4EBABCAD.6060905@oracle.com> References: <4EBABCAD.6060905@oracle.com> Message-ID: Jiangli, src/share/vm/code/dependencies.cpp:1636 instanceKlass::cast(d)->set_is_marked_dependent(); Isn't this supposed to be clear_is_marked_dependent()? Bob. On Nov 9, 2011, at 12:47 PM, Jiangli Zhou wrote: > Compact following 4 instanceKlass boolean fields into a signal u1 field. Each flag now uses 1-bit. The new field is placed after the _idnum_allocated_count field to utilize the unused 2-byte after _idnum_allocated_count. Compacting these fields saves 4-bytes for each loaded classes. > > bool _is_marked_dependent; // used for marking during flushing and > deoptimization > bool _rewritten; // methods rewritten. > bool _has_nonstatic_fields; // for sizing with UseCompressedOops > bool _should_verify_class; // allow caching of preverification > > http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ > > Tested with runThese on ubuntu. Ran JPRT. > > Thanks, > Jiangli From christian.thalinger at oracle.com Thu Nov 10 01:26:44 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Nov 2011 10:26:44 +0100 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: <4EBABCAD.6060905@oracle.com> References: <4EBABCAD.6060905@oracle.com> Message-ID: <81961F37-734A-4900-BD66-DCF571BA8C97@oracle.com> What about: - bool _is_marked_dependent:1; // used for marking during flushing and deoptimization - bool _rewritten:1; // methods rewritten. - bool _has_nonstatic_fields:1; // for sizing with UseCompressedOops - bool _should_verify_class:1; // allow caching of preverification Wouldn't that be much easier? And we already have code like that in e.g. nmethod.hpp. -- Chris On Nov 9, 2011, at 6:47 PM, Jiangli Zhou wrote: > Compact following 4 instanceKlass boolean fields into a signal u1 field. Each flag now uses 1-bit. The new field is placed after the _idnum_allocated_count field to utilize the unused 2-byte after _idnum_allocated_count. Compacting these fields saves 4-bytes for each loaded classes. > > bool _is_marked_dependent; // used for marking during flushing and > deoptimization > bool _rewritten; // methods rewritten. > bool _has_nonstatic_fields; // for sizing with UseCompressedOops > bool _should_verify_class; // allow caching of preverification > > http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ > > Tested with runThese on ubuntu. Ran JPRT. > > Thanks, > Jiangli From david.holmes at oracle.com Thu Nov 10 03:02:24 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Nov 2011 21:02:24 +1000 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: <81961F37-734A-4900-BD66-DCF571BA8C97@oracle.com> References: <4EBABCAD.6060905@oracle.com> <81961F37-734A-4900-BD66-DCF571BA8C97@oracle.com> Message-ID: <4EBBAF40.50008@oracle.com> Hi Chris, On 10/11/2011 7:26 PM, Christian Thalinger wrote: > What about: > > - bool _is_marked_dependent:1; // used for marking during flushing and deoptimization > - bool _rewritten:1; // methods rewritten. > - bool _has_nonstatic_fields:1; // for sizing with UseCompressedOops > - bool _should_verify_class:1; // allow caching of preverification > > Wouldn't that be much easier? And we already have code like that in e.g. nmethod.hpp. I'm not familiar with this particular notation but I assume it is similar to using bitfields. This had been discussed internally but unfortunately the SA code needs to access the "is-marked-dependent" bit and as there's no guarantee as to the order in which bitfields are packed, the SA would not know how to extract that bit. David ----- > -- Chris > > On Nov 9, 2011, at 6:47 PM, Jiangli Zhou wrote: > >> Compact following 4 instanceKlass boolean fields into a signal u1 field. Each flag now uses 1-bit. The new field is placed after the _idnum_allocated_count field to utilize the unused 2-byte after _idnum_allocated_count. Compacting these fields saves 4-bytes for each loaded classes. >> >> bool _is_marked_dependent; // used for marking during flushing and >> deoptimization >> bool _rewritten; // methods rewritten. >> bool _has_nonstatic_fields; // for sizing with UseCompressedOops >> bool _should_verify_class; // allow caching of preverification >> >> http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ >> >> Tested with runThese on ubuntu. Ran JPRT. >> >> Thanks, >> Jiangli > From christian.thalinger at oracle.com Thu Nov 10 03:11:54 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Nov 2011 12:11:54 +0100 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: <4EBBAF40.50008@oracle.com> References: <4EBABCAD.6060905@oracle.com> <81961F37-734A-4900-BD66-DCF571BA8C97@oracle.com> <4EBBAF40.50008@oracle.com> Message-ID: <228AD1AF-7429-40B0-9A40-697D3ECD1701@oracle.com> On Nov 10, 2011, at 12:02 PM, David Holmes wrote: > Hi Chris, > > On 10/11/2011 7:26 PM, Christian Thalinger wrote: >> What about: >> >> - bool _is_marked_dependent:1; // used for marking during flushing and deoptimization >> - bool _rewritten:1; // methods rewritten. >> - bool _has_nonstatic_fields:1; // for sizing with UseCompressedOops >> - bool _should_verify_class:1; // allow caching of preverification >> >> Wouldn't that be much easier? And we already have code like that in e.g. nmethod.hpp. > > I'm not familiar with this particular notation but I assume it is similar to using bitfields. Correct. > This had been discussed internally but unfortunately the SA code needs to access the "is-marked-dependent" bit and as there's no guarantee as to the order in which bitfields are packed, the SA would not know how to extract that bit. Good point. Bitfields won't work then. -- Chris > > David > ----- > >> -- Chris >> >> On Nov 9, 2011, at 6:47 PM, Jiangli Zhou wrote: >> >>> Compact following 4 instanceKlass boolean fields into a signal u1 field. Each flag now uses 1-bit. The new field is placed after the _idnum_allocated_count field to utilize the unused 2-byte after _idnum_allocated_count. Compacting these fields saves 4-bytes for each loaded classes. >>> >>> bool _is_marked_dependent; // used for marking during flushing and >>> deoptimization >>> bool _rewritten; // methods rewritten. >>> bool _has_nonstatic_fields; // for sizing with UseCompressedOops >>> bool _should_verify_class; // allow caching of preverification >>> >>> http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ >>> >>> Tested with runThese on ubuntu. Ran JPRT. >>> >>> Thanks, >>> Jiangli >> From paul.hohensee at oracle.com Thu Nov 10 06:00:42 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 10 Nov 2011 09:00:42 -0500 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: <228AD1AF-7429-40B0-9A40-697D3ECD1701@oracle.com> References: <4EBABCAD.6060905@oracle.com> <81961F37-734A-4900-BD66-DCF571BA8C97@oracle.com> <4EBBAF40.50008@oracle.com> <228AD1AF-7429-40B0-9A40-697D3ECD1701@oracle.com> Message-ID: <4EBBD90A.7080609@oracle.com> Actually, and btw, it's just another form of bitfield notation. It's equivalent to bool _is_marked_dependent:1, // used for marking during flushing and deoptimization _rewritten:1, // methods rewritten. _has_nonstatic_fields:1, // for sizing with UseCompressedOops _should_verify_class:1; // allow caching of preverification You could put the atomically accessible fields in at least a byte (every machine I know of can do atomic stores to a byte), and the rest in bitfields as above or below. Paul On 11/10/11 6:11 AM, Christian Thalinger wrote: > On Nov 10, 2011, at 12:02 PM, David Holmes wrote: > >> Hi Chris, >> >> On 10/11/2011 7:26 PM, Christian Thalinger wrote: >>> What about: >>> >>> - bool _is_marked_dependent:1; // used for marking during flushing and deoptimization >>> - bool _rewritten:1; // methods rewritten. >>> - bool _has_nonstatic_fields:1; // for sizing with UseCompressedOops >>> - bool _should_verify_class:1; // allow caching of preverification >>> >>> Wouldn't that be much easier? And we already have code like that in e.g. nmethod.hpp. >> I'm not familiar with this particular notation but I assume it is similar to using bitfields. > Correct. > >> This had been discussed internally but unfortunately the SA code needs to access the "is-marked-dependent" bit and as there's no guarantee as to the order in which bitfields are packed, the SA would not know how to extract that bit. > Good point. Bitfields won't work then. > > -- Chris > >> David >> ----- >> >>> -- Chris >>> >>> On Nov 9, 2011, at 6:47 PM, Jiangli Zhou wrote: >>> >>>> Compact following 4 instanceKlass boolean fields into a signal u1 field. Each flag now uses 1-bit. The new field is placed after the _idnum_allocated_count field to utilize the unused 2-byte after _idnum_allocated_count. Compacting these fields saves 4-bytes for each loaded classes. >>>> >>>> bool _is_marked_dependent; // used for marking during flushing and >>>> deoptimization >>>> bool _rewritten; // methods rewritten. >>>> bool _has_nonstatic_fields; // for sizing with UseCompressedOops >>>> bool _should_verify_class; // allow caching of preverification >>>> >>>> http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ >>>> >>>> Tested with runThese on ubuntu. Ran JPRT. >>>> >>>> Thanks, >>>> Jiangli From david.holmes at oracle.com Thu Nov 10 08:15:42 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 10 Nov 2011 16:15:42 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7108264: Fix for 7104173 is insufficient Message-ID: <20111110161550.3A733472ED@hg.openjdk.java.net> Changeset: 3c7d67df8d07 Author: dholmes Date: 2011-11-10 06:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3c7d67df8d07 7108264: Fix for 7104173 is insufficient Summary: Disable PrintVMOptions by default for all builds Reviewed-by: dsamersoff, twisti ! src/share/vm/runtime/globals.hpp From bob.vandette at oracle.com Thu Nov 10 10:41:15 2011 From: bob.vandette at oracle.com (bob.vandette at oracle.com) Date: Thu, 10 Nov 2011 18:41:15 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 18 new changesets Message-ID: <20111110184150.ED722472F4@hg.openjdk.java.net> Changeset: 5e5d4821bf07 Author: brutisso Date: 2011-10-20 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5e5d4821bf07 7097516: G1: assert(0<= from_card && from_card ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/gcc.make ! make/windows/makefiles/vm.make - src/share/vm/precompiled.hpp + src/share/vm/precompiled/precompiled.hpp Changeset: ddb34559f9a7 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ddb34559f9a7 Added tag jdk8-b12 for changeset 1d3900713a67 ! .hgtags Changeset: 3e609627e780 Author: jcoomes Date: 2011-11-04 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/3e609627e780 Merge - src/share/vm/precompiled.hpp Changeset: b92ca8e229d2 Author: jcoomes Date: 2011-11-04 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b92ca8e229d2 Added tag hs23-b05 for changeset 3e609627e780 ! .hgtags Changeset: 869804b759e7 Author: jcoomes Date: 2011-11-04 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/869804b759e7 7108553: Bump the hs23 build number to 06 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version From jiangli.zhou at oracle.com Thu Nov 10 11:32:23 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 10 Nov 2011 11:32:23 -0800 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: <228AD1AF-7429-40B0-9A40-697D3ECD1701@oracle.com> References: <4EBABCAD.6060905@oracle.com> <81961F37-734A-4900-BD66-DCF571BA8C97@oracle.com> <4EBBAF40.50008@oracle.com> <228AD1AF-7429-40B0-9A40-697D3ECD1701@oracle.com> Message-ID: <4EBC26C7.2050805@oracle.com> Hi Chris, Thanks for the review. Comments below. On 11/10/2011 03:11 AM, Christian Thalinger wrote: > On Nov 10, 2011, at 12:02 PM, David Holmes wrote: > >> Hi Chris, >> >> On 10/11/2011 7:26 PM, Christian Thalinger wrote: >>> What about: >>> >>> - bool _is_marked_dependent:1; // used for marking during flushing and deoptimization >>> - bool _rewritten:1; // methods rewritten. >>> - bool _has_nonstatic_fields:1; // for sizing with UseCompressedOops >>> - bool _should_verify_class:1; // allow caching of preverification >>> >>> Wouldn't that be much easier? And we already have code like that in e.g. nmethod.hpp. >> I'm not familiar with this particular notation but I assume it is similar to using bitfields. > Correct. > >> This had been discussed internally but unfortunately the SA code needs to access the "is-marked-dependent" bit and as there's no guarantee as to the order in which bitfields are packed, the SA would not know how to extract that bit. > Good point. Bitfields won't work then. Besides the bit addressing issue, it cannot guarantee that the bit fields are always packed into the smallest size by all compilers. Thanks, Jiangli > -- Chris > >> David >> ----- >> >>> -- Chris >>> >>> On Nov 9, 2011, at 6:47 PM, Jiangli Zhou wrote: >>> >>>> Compact following 4 instanceKlass boolean fields into a signal u1 field. Each flag now uses 1-bit. The new field is placed after the _idnum_allocated_count field to utilize the unused 2-byte after _idnum_allocated_count. Compacting these fields saves 4-bytes for each loaded classes. >>>> >>>> bool _is_marked_dependent; // used for marking during flushing and >>>> deoptimization >>>> bool _rewritten; // methods rewritten. >>>> bool _has_nonstatic_fields; // for sizing with UseCompressedOops >>>> bool _should_verify_class; // allow caching of preverification >>>> >>>> http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ >>>> >>>> Tested with runThese on ubuntu. Ran JPRT. >>>> >>>> Thanks, >>>> Jiangli From paul.hohensee at oracle.com Thu Nov 10 12:05:15 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 10 Nov 2011 15:05:15 -0500 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: <4EBC26C7.2050805@oracle.com> References: <4EBABCAD.6060905@oracle.com> <81961F37-734A-4900-BD66-DCF571BA8C97@oracle.com> <4EBBAF40.50008@oracle.com> <228AD1AF-7429-40B0-9A40-697D3ECD1701@oracle.com> <4EBC26C7.2050805@oracle.com> Message-ID: <4EBC2E7B.3040005@oracle.com> Actually, the C/C++ standards do guarantee dense bit packing in bitfields, because they were originally intended to be used to access device registers. The type of the bitfield determines how much space the underlying integral type occupies. E.g., unsigned char bit1:1, bit2:1, bit3:1; occupies the "first" 3 bits of a one-byte class data member, while unsigned int bit1:1, bit2:1, bit3:1; occupies the "first" 3 bits of a 4-byte class data member. Note that "first" means that bitfields are allocated starting from the lowest addressed byte in the bitfield type. That means that on big-endian machines, the first allocated bit in an unsigned int bitfield will be the msb, while on little-endian machines it'll be the lsb. If you want a bitfield that's endian-independent, you have to use the masking technique in the webrev: e.g., if you want to pass a bitfield to Java code, which has no concept of endianness. Paul On 11/10/11 2:32 PM, Jiangli Zhou wrote: > Hi Chris, > > Thanks for the review. Comments below. > > On 11/10/2011 03:11 AM, Christian Thalinger wrote: >> On Nov 10, 2011, at 12:02 PM, David Holmes wrote: >> >>> Hi Chris, >>> >>> On 10/11/2011 7:26 PM, Christian Thalinger wrote: >>>> What about: >>>> >>>> - bool _is_marked_dependent:1; // used for marking >>>> during flushing and deoptimization >>>> - bool _rewritten:1; // methods rewritten. >>>> - bool _has_nonstatic_fields:1; // for sizing with >>>> UseCompressedOops >>>> - bool _should_verify_class:1; // allow caching of >>>> preverification >>>> >>>> Wouldn't that be much easier? And we already have code like that >>>> in e.g. nmethod.hpp. >>> I'm not familiar with this particular notation but I assume it is >>> similar to using bitfields. >> Correct. >> >>> This had been discussed internally but unfortunately the SA code >>> needs to access the "is-marked-dependent" bit and as there's no >>> guarantee as to the order in which bitfields are packed, the SA >>> would not know how to extract that bit. >> Good point. Bitfields won't work then. > > Besides the bit addressing issue, it cannot guarantee that the bit > fields are always packed into the smallest size by all compilers. > > Thanks, > Jiangli > >> -- Chris >> >>> David >>> ----- >>> >>>> -- Chris >>>> >>>> On Nov 9, 2011, at 6:47 PM, Jiangli Zhou wrote: >>>> >>>>> Compact following 4 instanceKlass boolean fields into a signal u1 >>>>> field. Each flag now uses 1-bit. The new field is placed after the >>>>> _idnum_allocated_count field to utilize the unused 2-byte after >>>>> _idnum_allocated_count. Compacting these fields saves 4-bytes for >>>>> each loaded classes. >>>>> >>>>> bool _is_marked_dependent; // used for marking during flushing and >>>>> deoptimization >>>>> bool _rewritten; // methods rewritten. >>>>> bool _has_nonstatic_fields; // for sizing with UseCompressedOops >>>>> bool _should_verify_class; // allow caching of preverification >>>>> >>>>> http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ >>>>> >>>>> Tested with runThese on ubuntu. Ran JPRT. >>>>> >>>>> Thanks, >>>>> Jiangli > From jiangli.zhou at oracle.com Thu Nov 10 13:00:49 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 10 Nov 2011 13:00:49 -0800 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: <4EBC2E7B.3040005@oracle.com> References: <4EBABCAD.6060905@oracle.com> <81961F37-734A-4900-BD66-DCF571BA8C97@oracle.com> <4EBBAF40.50008@oracle.com> <228AD1AF-7429-40B0-9A40-697D3ECD1701@oracle.com> <4EBC26C7.2050805@oracle.com> <4EBC2E7B.3040005@oracle.com> Message-ID: <4EBC3B81.1080902@oracle.com> Hi Paul, Thanks for the details and review. The bit field padding due to alignment is more of an issue when there are mixed types. Thanks, Jiangli Paul Hohensee wrote: > Actually, the C/C++ standards do guarantee dense bit packing in > bitfields, > because they were originally intended to be used to access device > registers. > > The type of the bitfield determines how much space the underlying > integral > type occupies. E.g., > > unsigned char bit1:1, bit2:1, bit3:1; > > occupies the "first" 3 bits of a one-byte class data member, while > > unsigned int bit1:1, bit2:1, bit3:1; > > occupies the "first" 3 bits of a 4-byte class data member. > > Note that "first" means that bitfields are allocated starting from the > lowest addressed > byte in the bitfield type. That means that on big-endian machines, > the first allocated > bit in an unsigned int bitfield will be the msb, while on > little-endian machines > it'll be the lsb. If you want a bitfield that's endian-independent, > you have to > use the masking technique in the webrev: e.g., if you want to pass a > bitfield to Java > code, which has no concept of endianness. > > Paul > > On 11/10/11 2:32 PM, Jiangli Zhou wrote: >> Hi Chris, >> >> Thanks for the review. Comments below. >> >> On 11/10/2011 03:11 AM, Christian Thalinger wrote: >>> On Nov 10, 2011, at 12:02 PM, David Holmes wrote: >>> >>>> Hi Chris, >>>> >>>> On 10/11/2011 7:26 PM, Christian Thalinger wrote: >>>>> What about: >>>>> >>>>> - bool _is_marked_dependent:1; // used for marking >>>>> during flushing and deoptimization >>>>> - bool _rewritten:1; // methods rewritten. >>>>> - bool _has_nonstatic_fields:1; // for sizing with >>>>> UseCompressedOops >>>>> - bool _should_verify_class:1; // allow caching of >>>>> preverification >>>>> >>>>> Wouldn't that be much easier? And we already have code like that >>>>> in e.g. nmethod.hpp. >>>> I'm not familiar with this particular notation but I assume it is >>>> similar to using bitfields. >>> Correct. >>> >>>> This had been discussed internally but unfortunately the SA code >>>> needs to access the "is-marked-dependent" bit and as there's no >>>> guarantee as to the order in which bitfields are packed, the SA >>>> would not know how to extract that bit. >>> Good point. Bitfields won't work then. >> >> Besides the bit addressing issue, it cannot guarantee that the bit >> fields are always packed into the smallest size by all compilers. >> >> Thanks, >> Jiangli >> >>> -- Chris >>> >>>> David >>>> ----- >>>> >>>>> -- Chris >>>>> >>>>> On Nov 9, 2011, at 6:47 PM, Jiangli Zhou wrote: >>>>> >>>>>> Compact following 4 instanceKlass boolean fields into a signal u1 >>>>>> field. Each flag now uses 1-bit. The new field is placed after >>>>>> the _idnum_allocated_count field to utilize the unused 2-byte >>>>>> after _idnum_allocated_count. Compacting these fields saves >>>>>> 4-bytes for each loaded classes. >>>>>> >>>>>> bool _is_marked_dependent; // used for marking during flushing and >>>>>> deoptimization >>>>>> bool _rewritten; // methods rewritten. >>>>>> bool _has_nonstatic_fields; // for sizing with UseCompressedOops >>>>>> bool _should_verify_class; // allow caching of preverification >>>>>> >>>>>> http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ >>>>>> >>>>>> Tested with runThese on ubuntu. Ran JPRT. >>>>>> >>>>>> Thanks, >>>>>> Jiangli >> From paul.hohensee at oracle.com Thu Nov 10 13:06:42 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 10 Nov 2011 16:06:42 -0500 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: <4EBC3B81.1080902@oracle.com> References: <4EBABCAD.6060905@oracle.com> <81961F37-734A-4900-BD66-DCF571BA8C97@oracle.com> <4EBBAF40.50008@oracle.com> <228AD1AF-7429-40B0-9A40-697D3ECD1701@oracle.com> <4EBC26C7.2050805@oracle.com> <4EBC2E7B.3040005@oracle.com> <4EBC3B81.1080902@oracle.com> Message-ID: <4EBC3CE2.3070104@oracle.com> True. Field alignment is the alignment of the underlying integral type. On 11/10/11 4:00 PM, Jiangli Zhou wrote: > Hi Paul, > > Thanks for the details and review. The bit field padding due to > alignment is more of an issue when there are mixed types. > > Thanks, > Jiangli > > Paul Hohensee wrote: >> Actually, the C/C++ standards do guarantee dense bit packing in >> bitfields, >> because they were originally intended to be used to access device >> registers. >> >> The type of the bitfield determines how much space the underlying >> integral >> type occupies. E.g., >> >> unsigned char bit1:1, bit2:1, bit3:1; >> >> occupies the "first" 3 bits of a one-byte class data member, while >> >> unsigned int bit1:1, bit2:1, bit3:1; >> >> occupies the "first" 3 bits of a 4-byte class data member. >> >> Note that "first" means that bitfields are allocated starting from >> the lowest addressed >> byte in the bitfield type. That means that on big-endian machines, >> the first allocated >> bit in an unsigned int bitfield will be the msb, while on >> little-endian machines >> it'll be the lsb. If you want a bitfield that's endian-independent, >> you have to >> use the masking technique in the webrev: e.g., if you want to pass a >> bitfield to Java >> code, which has no concept of endianness. >> >> Paul >> >> On 11/10/11 2:32 PM, Jiangli Zhou wrote: >>> Hi Chris, >>> >>> Thanks for the review. Comments below. >>> >>> On 11/10/2011 03:11 AM, Christian Thalinger wrote: >>>> On Nov 10, 2011, at 12:02 PM, David Holmes wrote: >>>> >>>>> Hi Chris, >>>>> >>>>> On 10/11/2011 7:26 PM, Christian Thalinger wrote: >>>>>> What about: >>>>>> >>>>>> - bool _is_marked_dependent:1; // used for marking >>>>>> during flushing and deoptimization >>>>>> - bool _rewritten:1; // methods rewritten. >>>>>> - bool _has_nonstatic_fields:1; // for sizing with >>>>>> UseCompressedOops >>>>>> - bool _should_verify_class:1; // allow caching of >>>>>> preverification >>>>>> >>>>>> Wouldn't that be much easier? And we already have code like that >>>>>> in e.g. nmethod.hpp. >>>>> I'm not familiar with this particular notation but I assume it is >>>>> similar to using bitfields. >>>> Correct. >>>> >>>>> This had been discussed internally but unfortunately the SA code >>>>> needs to access the "is-marked-dependent" bit and as there's no >>>>> guarantee as to the order in which bitfields are packed, the SA >>>>> would not know how to extract that bit. >>>> Good point. Bitfields won't work then. >>> >>> Besides the bit addressing issue, it cannot guarantee that the bit >>> fields are always packed into the smallest size by all compilers. >>> >>> Thanks, >>> Jiangli >>> >>>> -- Chris >>>> >>>>> David >>>>> ----- >>>>> >>>>>> -- Chris >>>>>> >>>>>> On Nov 9, 2011, at 6:47 PM, Jiangli Zhou wrote: >>>>>> >>>>>>> Compact following 4 instanceKlass boolean fields into a signal >>>>>>> u1 field. Each flag now uses 1-bit. The new field is placed >>>>>>> after the _idnum_allocated_count field to utilize the unused >>>>>>> 2-byte after _idnum_allocated_count. Compacting these fields >>>>>>> saves 4-bytes for each loaded classes. >>>>>>> >>>>>>> bool _is_marked_dependent; // used for marking during flushing >>>>>>> and >>>>>>> deoptimization >>>>>>> bool _rewritten; // methods rewritten. >>>>>>> bool _has_nonstatic_fields; // for sizing with UseCompressedOops >>>>>>> bool _should_verify_class; // allow caching of preverification >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ >>>>>>> >>>>>>> Tested with runThese on ubuntu. Ran JPRT. >>>>>>> >>>>>>> Thanks, >>>>>>> Jiangli >>> > From poonam.bajaj at oracle.com Thu Nov 10 21:20:15 2011 From: poonam.bajaj at oracle.com (poonam.bajaj at oracle.com) Date: Fri, 11 Nov 2011 10:50:15 +0530 Subject: Request for review: 7110428 Crash during HeapDump operation Message-ID: <4EBCB08F.1060402@oracle.com> Hi, Can I get a couple of reviews for this change: CR 7110428: Crash during HeapDump operation http://monaco.sfbay.sun.com/detail.jsf?cr=7110428 The crash happens when VM thread traverses the heap during heapdump operation and it finds the heap in non-parseable state. The heap can be left in non-parseable state if due to some reason GC is skipped and we didn't call ensure_parsability() either before dumping the heap. The solution is to always call ensure_parsability() In VM_HeapDumper::doit(), whether or not a GC is requested before the heap dumping. http://cr.openjdk.java.net/~poonam/7110428/webrev.00/ Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111111/b8100605/attachment.html From david.holmes at oracle.com Thu Nov 10 22:18:53 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Nov 2011 16:18:53 +1000 Subject: Request for review: 7110428 Crash during HeapDump operation In-Reply-To: <4EBCB08F.1060402@oracle.com> References: <4EBCB08F.1060402@oracle.com> Message-ID: <4EBCBE4D.8020002@oracle.com> Hi Poonam, I've cc'ed GC-dev as this is more their area. It seems very wasteful to potentially ensure_parsability and also do a full GC. And the check for the active GC_Locker is somewhat arbitrary as it could change the instant you've queried it. It seems to me that a more complete solution here would enable collect_as_vm_thread to indicate whether or not GC occurred. Which in turn requires that do_full_collection report that info - a RFE that is already noted in the G1 code at least: void G1CollectedHeap::do_full_collection(bool clear_all_soft_refs) { // do_collection() will return whether it succeeded in performing // the GC. Currently, there is no facility on the // do_full_collection() API to notify the caller than the collection // did not succeed (e.g., because it was locked out by the GC // locker). So, right now, we'll ignore the return value. bool dummy = do_collection(true, /* explicit_gc */ clear_all_soft_refs, 0 /* word_size */); } David ----- On 11/11/2011 3:20 PM, poonam.bajaj at oracle.com wrote: > Hi, > > Can I get a couple of reviews for this change: > > CR 7110428: Crash during HeapDump operation > http://monaco.sfbay.sun.com/detail.jsf?cr=7110428 > > The crash happens when VM thread traverses the heap during heapdump > operation and it finds the heap in non-parseable state. The heap can be > left in non-parseable state if due to some reason GC is skipped and we > didn't call ensure_parsability() either before dumping the heap. The > solution is to always call ensure_parsability() In > VM_HeapDumper::doit(), whether or not a GC is requested before the heap > dumping. > > http://cr.openjdk.java.net/~poonam/7110428/webrev.00/ > > > Thanks, > Poonam > > From poonam.bajaj at oracle.com Thu Nov 10 23:14:24 2011 From: poonam.bajaj at oracle.com (poonam.bajaj at oracle.com) Date: Fri, 11 Nov 2011 12:44:24 +0530 Subject: Request for review: 7110428 Crash during HeapDump operation In-Reply-To: <4EBCBE4D.8020002@oracle.com> References: <4EBCB08F.1060402@oracle.com> <4EBCBE4D.8020002@oracle.com> Message-ID: <4EBCCB50.10204@oracle.com> Hi David, On 11/11/2011 11:48 AM, David Holmes wrote: > Hi Poonam, > > I've cc'ed GC-dev as this is more their area. It seems very wasteful > to potentially ensure_parsability and also do a full GC. And the check > for the active GC_Locker is somewhat arbitrary as it could change the > instant you've queried it. > Thanks for adding GC-dev. > It seems to me that a more complete solution here would enable > collect_as_vm_thread to indicate whether or not GC occurred. Which in > turn requires that do_full_collection report that info - a RFE that is > already noted in the G1 code at least: > > void G1CollectedHeap::do_full_collection(bool clear_all_soft_refs) { > // do_collection() will return whether it succeeded in performing > // the GC. Currently, there is no facility on the > // do_full_collection() API to notify the caller than the collection > // did not succeed (e.g., because it was locked out by the GC > // locker). So, right now, we'll ignore the return value. > bool dummy = do_collection(true, /* explicit_gc */ > clear_all_soft_refs, > 0 /* word_size */); > } > Yes, that would be the ideal solution. What is the time frame of having this RFE implemented for other collectors? This bug was discovered during the FMW stress testing and needs to fixed as soon as we can. The solution I proposed is being used by other VM operations as well e.g. VM_GC_HeapInspection and was somehow missed for VM_HeapDumper.. So, I guess until we have the RFE implemented that allows us to have the result whether a GC succeeded or not, this could be a short term solution. Thanks, Poonam > David > ----- > > On 11/11/2011 3:20 PM, poonam.bajaj at oracle.com wrote: >> Hi, >> >> Can I get a couple of reviews for this change: >> >> CR 7110428: Crash during HeapDump operation >> http://monaco.sfbay.sun.com/detail.jsf?cr=7110428 >> >> The crash happens when VM thread traverses the heap during heapdump >> operation and it finds the heap in non-parseable state. The heap can be >> left in non-parseable state if due to some reason GC is skipped and we >> didn't call ensure_parsability() either before dumping the heap. The >> solution is to always call ensure_parsability() In >> VM_HeapDumper::doit(), whether or not a GC is requested before the heap >> dumping. >> >> http://cr.openjdk.java.net/~poonam/7110428/webrev.00/ >> >> >> Thanks, >> Poonam >> >> -- Best regards, Poonam Oracle Poonam Bajaj | Principal Member of Technical Staff Phone: +91 80 66937451 | Mobile: +91 9844511366 Oracle JVM Sustaining Engineering ORACLE India Bangalore Green Oracle Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111111/1eb93263/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111111/1eb93263/oracle_sig_logo-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: green-for-email-sig_0.gif Type: image/gif Size: 356 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111111/1eb93263/green-for-email-sig_0-0001.gif From david.holmes at oracle.com Thu Nov 10 23:36:49 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Nov 2011 17:36:49 +1000 Subject: Request for review: 7110428 Crash during HeapDump operation In-Reply-To: <4EBCCB50.10204@oracle.com> References: <4EBCB08F.1060402@oracle.com> <4EBCBE4D.8020002@oracle.com> <4EBCCB50.10204@oracle.com> Message-ID: <4EBCD091.6080602@oracle.com> As a short-term quick-fix I'm okay with this but I defer to the GC folks. If similar code is already being used then this seems reasonable. David On 11/11/2011 5:14 PM, poonam.bajaj at oracle.com wrote: > Hi David, > > On 11/11/2011 11:48 AM, David Holmes wrote: >> Hi Poonam, >> >> I've cc'ed GC-dev as this is more their area. It seems very wasteful >> to potentially ensure_parsability and also do a full GC. And the check >> for the active GC_Locker is somewhat arbitrary as it could change the >> instant you've queried it. >> > Thanks for adding GC-dev. > >> It seems to me that a more complete solution here would enable >> collect_as_vm_thread to indicate whether or not GC occurred. Which in >> turn requires that do_full_collection report that info - a RFE that is >> already noted in the G1 code at least: >> >> void G1CollectedHeap::do_full_collection(bool clear_all_soft_refs) { >> // do_collection() will return whether it succeeded in performing >> // the GC. Currently, there is no facility on the >> // do_full_collection() API to notify the caller than the collection >> // did not succeed (e.g., because it was locked out by the GC >> // locker). So, right now, we'll ignore the return value. >> bool dummy = do_collection(true, /* explicit_gc */ >> clear_all_soft_refs, >> 0 /* word_size */); >> } >> > Yes, that would be the ideal solution. > > What is the time frame of having this RFE implemented for other > collectors? This bug was discovered during the FMW stress testing and > needs to fixed as soon as we can. > > The solution I proposed is being used by other VM operations as well > e.g. VM_GC_HeapInspection and was somehow missed for VM_HeapDumper.. So, > I guess until we have the RFE implemented that allows us to have the > result whether a GC succeeded or not, this could be a short term solution. > > > Thanks, > Poonam > > >> David >> ----- >> >> On 11/11/2011 3:20 PM, poonam.bajaj at oracle.com wrote: >>> Hi, >>> >>> Can I get a couple of reviews for this change: >>> >>> CR 7110428: Crash during HeapDump operation >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7110428 >>> >>> The crash happens when VM thread traverses the heap during heapdump >>> operation and it finds the heap in non-parseable state. The heap can be >>> left in non-parseable state if due to some reason GC is skipped and we >>> didn't call ensure_parsability() either before dumping the heap. The >>> solution is to always call ensure_parsability() In >>> VM_HeapDumper::doit(), whether or not a GC is requested before the heap >>> dumping. >>> >>> http://cr.openjdk.java.net/~poonam/7110428/webrev.00/ >>> >>> >>> Thanks, >>> Poonam >>> >>> > > -- > Best regards, Poonam > > Oracle > Poonam Bajaj | Principal Member of Technical Staff > Phone: +91 80 66937451 | Mobile: +91 > 9844511366 > Oracle JVM Sustaining Engineering > > ORACLE India Bangalore > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > From chris.hegarty at oracle.com Fri Nov 11 03:12:49 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Nov 2011 11:12:49 +0000 Subject: Code Review 7110017: is_headless_jre should be updated to reflect the new,location of awt toolkit libraries Message-ID: <4EBD0331.6060604@oracle.com> With the changes proposed by CR 7110002: "Rename xawt/libmawt.so and headless/libmawt.so so they can be colocated with libawt", os::is_headless_jre() will have to be updated to look for the renamed awt toolkit libraries. See the discussion on awt-dev for further information: http://mail.openjdk.java.net/pipermail/awt-dev/2011-November/002026.html The check for the motif toolkit can also be removed as the motif based toolkit has been removed in JDK7. Since is_headless_jre is checking is for headless and short circuits and returns false ( headed ) if it finds any headed library we can just check for the existence of either the new or old library, without JDK version specific code. If either exists then it is a headed environment. Webrev: http://cr.openjdk.java.net/~dholmes/7110017/webrev/ -Chris. P.S. Thanks to David Holmes for helping drive this on the vm side. From david.holmes at oracle.com Fri Nov 11 03:11:50 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Nov 2011 21:11:50 +1000 Subject: Code Review 7110017: is_headless_jre should be updated to reflect the new,location of awt toolkit libraries In-Reply-To: <4EBD0331.6060604@oracle.com> References: <4EBD0331.6060604@oracle.com> Message-ID: <4EBD02F6.1050305@oracle.com> Chris, Thanks for contributing the changes. I've applied them and tested them so it is a Thumbs Up from me. We need one further Reviewer from runtime. Thanks, David On 11/11/2011 9:12 PM, Chris Hegarty wrote: > > With the changes proposed by CR 7110002: "Rename xawt/libmawt.so and > headless/libmawt.so so they can be colocated with libawt", > os::is_headless_jre() will have to be updated to look for the renamed > awt toolkit libraries. See the discussion on awt-dev for further > information: > http://mail.openjdk.java.net/pipermail/awt-dev/2011-November/002026.html > > The check for the motif toolkit can also be removed as the motif based > toolkit has been removed in JDK7. > > Since is_headless_jre is checking is for headless and short circuits > and returns false ( headed ) if it finds any headed library we can > just check for the existence of either the new or old library, without > JDK version specific code. If either exists then it is a headed > environment. > > Webrev: > http://cr.openjdk.java.net/~dholmes/7110017/webrev/ > > -Chris. > > P.S. Thanks to David Holmes for helping drive this on the vm side. From ysr1729 at gmail.com Fri Nov 11 10:42:48 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 11 Nov 2011 10:42:48 -0800 Subject: Request for review: 7110428 Crash during HeapDump operation In-Reply-To: <4EBCD091.6080602@oracle.com> References: <4EBCB08F.1060402@oracle.com> <4EBCBE4D.8020002@oracle.com> <4EBCCB50.10204@oracle.com> <4EBCD091.6080602@oracle.com> Message-ID: I tend to agree with David that it's cleaner to have collect_as_vm_thread() return an indication of whether GC was done or not, and for the caller to then make the heap parsable if GC was skipped and the plan is to subsequently walk the heap regardless. I also appreciate that what Poonam proposed may be the short-term expedient fix, and in that case the fix looks OK to me as a temporary solution (i can imagine that with very large Edens and many, many threads on a highly multi-core server just walking the threads twice is an unnecessary cost); reviewed. thanks. - ramki (openjdk: ysr) On Thu, Nov 10, 2011 at 11:36 PM, David Holmes wrote: > As a short-term quick-fix I'm okay with this but I defer to the GC folks. > If similar code is already being used then this seems reasonable. > > David > > > On 11/11/2011 5:14 PM, poonam.bajaj at oracle.com wrote: > >> Hi David, >> >> On 11/11/2011 11:48 AM, David Holmes wrote: >> >>> Hi Poonam, >>> >>> I've cc'ed GC-dev as this is more their area. It seems very wasteful >>> to potentially ensure_parsability and also do a full GC. And the check >>> for the active GC_Locker is somewhat arbitrary as it could change the >>> instant you've queried it. >>> >>> Thanks for adding GC-dev. >> >> It seems to me that a more complete solution here would enable >>> collect_as_vm_thread to indicate whether or not GC occurred. Which in >>> turn requires that do_full_collection report that info - a RFE that is >>> already noted in the G1 code at least: >>> >>> void G1CollectedHeap::do_full_**collection(bool clear_all_soft_refs) { >>> // do_collection() will return whether it succeeded in performing >>> // the GC. Currently, there is no facility on the >>> // do_full_collection() API to notify the caller than the collection >>> // did not succeed (e.g., because it was locked out by the GC >>> // locker). So, right now, we'll ignore the return value. >>> bool dummy = do_collection(true, /* explicit_gc */ >>> clear_all_soft_refs, >>> 0 /* word_size */); >>> } >>> >>> Yes, that would be the ideal solution. >> >> What is the time frame of having this RFE implemented for other >> collectors? This bug was discovered during the FMW stress testing and >> needs to fixed as soon as we can. >> >> The solution I proposed is being used by other VM operations as well >> e.g. VM_GC_HeapInspection and was somehow missed for VM_HeapDumper.. So, >> I guess until we have the RFE implemented that allows us to have the >> result whether a GC succeeded or not, this could be a short term >> solution. >> >> >> Thanks, >> Poonam >> >> >> David >>> ----- >>> >>> On 11/11/2011 3:20 PM, poonam.bajaj at oracle.com wrote: >>> >>>> Hi, >>>> >>>> Can I get a couple of reviews for this change: >>>> >>>> CR 7110428: Crash during HeapDump operation >>>> http://monaco.sfbay.sun.com/**detail.jsf?cr=7110428 >>>> >>>> The crash happens when VM thread traverses the heap during heapdump >>>> operation and it finds the heap in non-parseable state. The heap can be >>>> left in non-parseable state if due to some reason GC is skipped and we >>>> didn't call ensure_parsability() either before dumping the heap. The >>>> solution is to always call ensure_parsability() In >>>> VM_HeapDumper::doit(), whether or not a GC is requested before the heap >>>> dumping. >>>> >>>> http://cr.openjdk.java.net/~**poonam/7110428/webrev.00/ >>>> >>>> >>>> Thanks, >>>> Poonam >>>> >>>> >>>> >> -- >> Best regards, Poonam >> >> Oracle >> >> Poonam Bajaj | Principal Member of Technical Staff >> Phone: +91 80 66937451 | Mobile: +91 >> 9844511366 >> >> Oracle JVM Sustaining Engineering >> >> ORACLE India Bangalore >> Green Oracle > >> Oracle is committed to >> >> developing practices and products that help protect the environment >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111111/ecdcbc1c/attachment.html From sebastian.sickelmann at gmx.de Sat Nov 12 14:31:45 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sat, 12 Nov 2011 23:31:45 +0100 Subject: Question about klassOop instanceKlass::find_field with and without boolean is_static parameter Message-ID: <4EBEF3D1.1080702@gmx.de> While evalutation some stuff in hotspot i got to the two instanceKlass::find_field methods. First i thought it could be an easy target for an code-deduplication refactoring. But than i saw that changing "instanceKlass::find_field(Symbol* name, Symbol* sig, fieldDescriptor* fd)" to klassOop instanceKlass::find_field(Symbol* name, Symbol* sig, fieldDescriptor* fd) const { find_field(name,sig,false,fd); } would change behavoir. There main reason that make me stop to refactor it was the difference between a call to instanceKlass::find_field(Symbol* name, Symbol* sig, fieldDescriptor* fd) and a call to instanceKlass::find_field(Symbol* name, Symbol* sig, bool is_static, fieldDescriptor* fd) with is_static = false. It is the part of // 2) search for field recursively in direct superinterfaces if (is_static) { klassOop intf = find_interface_field(name, sig, fd); if (intf != NULL) return intf; } in instanceKlass::find_field(Symbol* name, Symbol* sig, bool is_static, fieldDescriptor* fd) method that make the difference. I searched for the calls to these two methods to understand what's going on here. I found that the three usage of the method with the boolean parameter are needed by jni (GetFieldID and GetStaticFieldID) and the method ciInstanceKlass::get_field_by_name which is only used by PhaseStringOpts::PhaseStringOpts to find the sizeTable instancefield of the Integer Class. The Method without the boolean parameter is used for normal field lookup (JVM spec (5.4.3.2, p.167).) I think that the comment to the jvm spec in the method with the boolean parameter is misleading. This is a special function which is needed to fulfill the requirements of the two jni methods and the special case of the static sizeTable field. I think we can change the sizeTable example to something that uses the other method and does some checking(is field static and declaring class equals to Integer) afterwards. If this is possible i would suggest to rename the method with the boolean parameter to something more special and remove the comment to JVM spec (5.4.3.2, p.167). If i am totally wrong, please let me know. Kind regards Sebastian From sebastian.sickelmann at gmx.de Sun Nov 13 20:18:33 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Mon, 14 Nov 2011 05:18:33 +0100 Subject: Accessing Annotations In-Reply-To: <4EBBDC3F.1060000@gmx.de> References: <4EBBDC3F.1060000@gmx.de> Message-ID: <4EC09699.8090702@gmx.de> Hi, i unfortunatly send my previous mail to hs-comp-dev but i think it should be hs-runtime-dev. So crossposting hs-comp-dev here to end the thread and move to hs-runtime-dev. I found the a part of the answer by myself. The bytes of the typeArray are exactly the bytes after the attribute_length field in RuntimeVisibleAnnotations_attribute from Classfile-Spec. RuntimeVisibleAnnotations_attribute { u2 attribute_name_index; u4 attribute_length; u2 num_annotations; annotation annotations[num_annotations]; } I checked the indices it with the constant-pool and it matches exactly with my expectations. The second-part of my question is still unanswered and i hope to get some hint. I want to implement a class that helps me processing the annotation(type-array), my idea is to create a annotationKlass class so that i can code something like this: annotationKlass::cast(typeArrayOop annotationTypeArray) and some accessory methods to easiliy work with annotations inside the vm. Or is there any implementation that does the annotation access-part that i haven't found yet? -- Sebastian Am 10.11.2011 15:14, schrieb Sebastian Sickelmann: > Hi, > > i actually explore how i could implement > "Removing public fields without breaking binary > compatibility"[0][1][2] inside of the vm. > > In [0] i made an early prototype with annotations and > class-weaving(changing) at load-time. > Now i want to shift this prototype to an inside-the-vm implementation. > > The first place i ran into is the verifier. Here i need to return true > if there is are methods > annotated with the new AccessorMethod-Annotation (which i made part of > java/lang in my > private openjdk clone). Just for completeness: the methods parameters > and return value must > fit to the expected field (said in other words "one get and one set > method"). > > I tried to hack on Reflection::verify_field_access and added something > like this[3] to access the > methods and their annotations. I tried it in various ways (and after > some errors on my side) i > get an typeArrayOop/typeArrayKlass which i think i can access the > annotations. Asking the > typeArrayKlass for its name/external-name/dimensions answers [B/[B/1 > which seems to be an > one-dimensional byte-array. Is this the structure of the > RuntimeVisibleAnnotation described in > class-file-spec[4]? > > > Must i access its byte content and parse it, or have i missed an > "annotationKlass" impl? > > If i first must implement such a annotationKlass-implementation. Is > there a good starting for this? > > > Some hints to get me working on this again would be fine. > > Kind regards > Sebastian > > [0] > http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-October/000199.html > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-September/007676.html > > [2] > http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ > [3] > http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/compatiblefieldaccess/question1-2011-11-10/index.html > [4] > http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf From mchr3k at gmail.com Mon Nov 14 07:56:54 2011 From: mchr3k at gmail.com (Martin Hare Robertson) Date: Mon, 14 Nov 2011 15:56:54 +0000 Subject: What does BufferBlob::Interpreter in a JVM crash log mean Message-ID: This mailing list looks like the best bet to get an answer to my question. However, please let me know if I should be posting this somewhere more appropriate. I am investigating a JVM crash which happens occasionally in my application. The hs_err file contains the following details about the crash. # SIGSEGV (0xb) at pc=0x065e68f4, pid=20208, tid=570166160 # # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86) ... # Problematic frame: # V [libjvm.so+0x5e68f4] ... Current thread (0x099ea800): JavaThread "Thread-315" daemon [_thread_in_vm, id=25782, stack(0x21fa3000,0x21fc1000)] ... vm_info: Java HotSpot(TM) Server VM (10.0-b23) for linux-x86 JRE (1.6.0_07-b06), built on Jun 10 2008 01:20:15 by "java_re" with gcc 3.2.1-7a (J2SE release) So this tells me that the JVM hit a segfault when running some Java code. The error log also contains information about the stack of the thread which crashed. Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x5e68f4] V [libjvm.so+0x1c054f] V [libjvm.so+0x1bfef2] V [libjvm.so+0x1bf57f] V [libjvm.so+0x592495] V [libjvm.so+0x365c4e] v ~BufferBlob::Interpreter v ~BufferBlob::Interpreter v ~BufferBlob::Interpreter v ~BufferBlob::Interpreter v ~BufferBlob::Interpreter Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) v ~BufferBlob::Interpreter v ~BufferBlob::Interpreter v ~BufferBlob::Interpreter v ~BufferBlob::Interpreter v ~BufferBlob::Interpreter J org.myapp.AppClass.getBytes()Lorg/myapp/ByteHolder; I have used GDB to connect to the core file from the crash and get more detail about the stack. This gives me the following output. #5 #6 0x065e68f4 in interpretedVFrame::monitors() const () from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so #7 0x061c054f in get_or_compute_monitor_info(JavaThread*) () from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so #8 0x061bfef2 in revoke_bias(oopDesc*, bool, bool, JavaThread*) () from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so #9 0x061bf57f in BiasedLocking::revoke_and_rebias(Handle, bool, Thread*) () from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so #10 0x06592495 in ObjectSynchronizer::fast_enter(Handle, BasicLock*, bool, Thread*) () from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so #11 0x06365c4e in InterpreterRuntime::monitorenter(JavaThread*, BasicObjectLock*) () from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so This shows that the six libjvm.so frames listed in the original bug report were related to grabbing a Java lock. However, I can't find any code within org.myapp.AppClass.getBytes() which uses any locks. ___ 1) What do the BufferBlob::Interpreter lines in the stack mean? - Are these Java stack frames? - JVM stack frames? - Is it possible to work out what was being called in these stack frames? ___ NOTE: Please don't suggest that I try to switch to a newer Hotspot JVM. I rely on the CMS collector and none of the more recent V1.6 Hotspot JVMs have been stable enough with the CMS collector in the testing which I have done. org.myapp.AppClass.getBytes() reads from a DataInputStream. This could produce the following stack trace: AppClass.getBytes() AppClass.readByte() DataInputStream.readByte() SocketInputStream.read() SocketInputStream.read(byte[],int,int) PlainSocketImpl.aquireFD() This final method grabs a lock. This could be the source of the eventual call into the JVM code listed above. This stack above has the convenient feature that there are 5 Java stack frames below getBytes(). This would match up neatly with the 5 lines of BufferBlob::Interpreter in the list of "Java frames". ___ 2) Could these 5 BufferBlob::Interpreter frames correspond to the Java stack trace I identified above? Is it possible that the 5 lines of BufferBlob::Interpreter under the "Native frames" section refer to the same stack frames as the same lines under the "Java frames" section? ___ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111114/9e35ba0c/attachment-0001.html From vitalyd at gmail.com Mon Nov 14 09:33:00 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 14 Nov 2011 12:33:00 -0500 Subject: What does BufferBlob::Interpreter in a JVM crash log mean In-Reply-To: References: Message-ID: You can try disabling biased locking, -XX:-UseBiasedLocking, as a possible workaround. On Nov 14, 2011 11:01 AM, "Martin Hare Robertson" wrote: > This mailing list looks like the best bet to get an answer to my question. > However, please let me know if I should be posting this somewhere more > appropriate. > > I am investigating a JVM crash which happens occasionally in my > application. The hs_err file contains the following details about the crash. > > # SIGSEGV (0xb) at pc=0x065e68f4, pid=20208, tid=570166160 > > # > # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86) > > ... > > # Problematic frame: > # V [libjvm.so+0x5e68f4] > > ... > > Current thread (0x099ea800): JavaThread "Thread-315" daemon [_thread_in_vm, id=25782, stack(0x21fa3000,0x21fc1000)] > > ... > > vm_info: Java HotSpot(TM) Server VM (10.0-b23) for linux-x86 JRE (1.6.0_07-b06), built on Jun 10 2008 01:20:15 by "java_re" with gcc 3.2.1-7a (J2SE release) > > So this tells me that the JVM hit a segfault when running some Java > code. The error log also contains information about the stack of the thread > which crashed. > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > > > V [libjvm.so+0x5e68f4] > > V [libjvm.so+0x1c054f] > > V [libjvm.so+0x1bfef2] > > V [libjvm.so+0x1bf57f] > > V [libjvm.so+0x592495] > > V [libjvm.so+0x365c4e] > > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > > v ~BufferBlob::Interpreter > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > > > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > > v ~BufferBlob::Interpreter > J org.myapp.AppClass.getBytes()Lorg/myapp/ByteHolder; > > I have used GDB to connect to the core file from the crash and get more > detail about the stack. This gives me the following output. > > #5 > #6 0x065e68f4 in interpretedVFrame::monitors() const () > > > from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so > > #7 0x061c054f in get_or_compute_monitor_info(JavaThread*) () > > from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so > > #8 0x061bfef2 in revoke_bias(oopDesc*, bool, bool, JavaThread*) () > > > from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so > > #9 0x061bf57f in BiasedLocking::revoke_and_rebias(Handle, bool, Thread*) () > > > from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so > > #10 0x06592495 in ObjectSynchronizer::fast_enter(Handle, BasicLock*, bool, Thread*) () > > > from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so > > #11 0x06365c4e in InterpreterRuntime::monitorenter(JavaThread*, BasicObjectLock*) () > > > from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so > > This shows that the six libjvm.so frames listed in the original bug > report were related to grabbing a Java lock. However, I can't find any code > within org.myapp.AppClass.getBytes() which uses any locks. > > ___ > > 1) What do the BufferBlob::Interpreter lines in the stack mean? > > - Are these Java stack frames? > > - JVM stack frames? > > - Is it possible to work out what was being called in these stack frames? > > ___ > > NOTE: Please don't suggest that I try to switch to a newer Hotspot JVM. I > rely on the CMS collector and none of the more recent V1.6 Hotspot JVMs > have been stable enough with the CMS collector in the testing which I have > done. > org.myapp.AppClass.getBytes() reads from a DataInputStream. This could > produce the following stack trace: > > AppClass.getBytes() > AppClass.readByte() > DataInputStream.readByte() > SocketInputStream.read() > SocketInputStream.read(byte[],int,int) > PlainSocketImpl.aquireFD() > > This final method grabs a lock. This could be the source of the eventual > call into the JVM code listed above. This stack above has the convenient > feature that there are 5 Java stack frames below getBytes(). This would > match up neatly with the 5 lines of BufferBlob::Interpreter in the list of > "Java frames". > > ___ > > 2) Could these 5 BufferBlob::Interpreter frames correspond to the Java > stack trace I identified above? Is it possible that the 5 lines of > BufferBlob::Interpreter under the "Native frames" section refer to the same > stack frames as the same lines under the "Java frames" section? > ___ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111114/89d1687b/attachment.html From jiangli.zhou at oracle.com Mon Nov 14 10:20:41 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 14 Nov 2011 10:20:41 -0800 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: References: <4EBABCAD.6060905@oracle.com> Message-ID: <4EC15BF9.4060407@oracle.com> Hi Bob, Sorry for the delay. Here is the updated webrev with dependencies.cpp fixed: http://cr.openjdk.java.net/~bobv/7102776/webrev.01/. Thanks for catching that! Thanks, Jiangli On 11/09/2011 02:13 PM, Bob Vandette wrote: > Jiangli, > > src/share/vm/code/dependencies.cpp:1636 instanceKlass::cast(d)->set_is_marked_dependent(); > > Isn't this supposed to be clear_is_marked_dependent()? > > Bob. > > > On Nov 9, 2011, at 12:47 PM, Jiangli Zhou wrote: > >> Compact following 4 instanceKlass boolean fields into a signal u1 field. Each flag now uses 1-bit. The new field is placed after the _idnum_allocated_count field to utilize the unused 2-byte after _idnum_allocated_count. Compacting these fields saves 4-bytes for each loaded classes. >> >> bool _is_marked_dependent; // used for marking during flushing and >> deoptimization >> bool _rewritten; // methods rewritten. >> bool _has_nonstatic_fields; // for sizing with UseCompressedOops >> bool _should_verify_class; // allow caching of preverification >> >> http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ >> >> Tested with runThese on ubuntu. Ran JPRT. >> >> Thanks, >> Jiangli From dean.long at oracle.com Mon Nov 14 10:33:20 2011 From: dean.long at oracle.com (Dean Long) Date: Mon, 14 Nov 2011 10:33:20 -0800 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: <4EC15BF9.4060407@oracle.com> References: <4EBABCAD.6060905@oracle.com> <4EC15BF9.4060407@oracle.com> Message-ID: <4EC15EF0.8070708@oracle.com> By the way, is there a test that would have caught that "set" was being called instead of "clear"? dl On 11/14/2011 10:20 AM, Jiangli Zhou wrote: > Hi Bob, > > Sorry for the delay. Here is the updated webrev with dependencies.cpp fixed: http://cr.openjdk.java.net/~bobv/7102776/webrev.01/. Thanks for catching that! > > Thanks, > Jiangli > > > On 11/09/2011 02:13 PM, Bob Vandette wrote: >> Jiangli, >> >> src/share/vm/code/dependencies.cpp:1636 instanceKlass::cast(d)->set_is_marked_dependent(); >> >> Isn't this supposed to be clear_is_marked_dependent()? >> >> Bob. >> >> >> On Nov 9, 2011, at 12:47 PM, Jiangli Zhou wrote: >> >>> Compact following 4 instanceKlass boolean fields into a signal u1 field. Each flag now uses 1-bit. The new field is placed after the _idnum_allocated_count field to utilize the unused 2-byte after _idnum_allocated_count. Compacting these fields saves 4-bytes for each loaded classes. >>> >>> bool _is_marked_dependent; // used for marking during flushing and >>> deoptimization >>> bool _rewritten; // methods rewritten. >>> bool _has_nonstatic_fields; // for sizing with UseCompressedOops >>> bool _should_verify_class; // allow caching of preverification >>> >>> http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ >>> >>> Tested with runThese on ubuntu. Ran JPRT. >>> >>> Thanks, >>> Jiangli > From john.cuthbertson at oracle.com Mon Nov 14 10:46:45 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 14 Nov 2011 10:46:45 -0800 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. Message-ID: <4EC16215.3080107@oracle.com> Hi Everyone, Can I have a couple of volnteers to review the fix for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. The issue here was that the routine GCNotifier::pushNotification(), which uses GC data held in GCMemoryManager::_last_gc_stat, was being called before the values in GCMemoryManager::_last_gc_stat were being populated for the current GC. As a result the JVM could pass uninitialized or stale data to a listener. The fix is to move the call to GCNotifier::pushNotification() after the code that populates GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo constructor to fully initialize instances of that class. Testing: The supplied test case on Windows, a crafted test case on Solaris, and the nsk GC tests. Thanks, JohnC From tom.rodriguez at oracle.com Mon Nov 14 10:50:25 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 14 Nov 2011 10:50:25 -0800 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: <4EC15EF0.8070708@oracle.com> References: <4EBABCAD.6060905@oracle.com> <4EC15BF9.4060407@oracle.com> <4EC15EF0.8070708@oracle.com> Message-ID: I don't know that there's a specific test which would have caught this. The purpose of the flag is minimize the time spent searching around in the class hierarchy when rechecking dependencies. Mostly it would have resulted in spending a little more time checking but I can't say for sure that it would have been noticed. tom On Nov 14, 2011, at 10:33 AM, Dean Long wrote: > By the way, is there a test that would have caught that "set" was being called instead of "clear"? > > dl > > On 11/14/2011 10:20 AM, Jiangli Zhou wrote: >> Hi Bob, >> >> Sorry for the delay. Here is the updated webrev with dependencies.cpp fixed: http://cr.openjdk.java.net/~bobv/7102776/webrev.01/. Thanks for catching that! >> >> Thanks, >> Jiangli >> >> >> On 11/09/2011 02:13 PM, Bob Vandette wrote: >>> Jiangli, >>> >>> src/share/vm/code/dependencies.cpp:1636 instanceKlass::cast(d)->set_is_marked_dependent(); >>> >>> Isn't this supposed to be clear_is_marked_dependent()? >>> >>> Bob. >>> >>> >>> On Nov 9, 2011, at 12:47 PM, Jiangli Zhou wrote: >>> >>>> Compact following 4 instanceKlass boolean fields into a signal u1 field. Each flag now uses 1-bit. The new field is placed after the _idnum_allocated_count field to utilize the unused 2-byte after _idnum_allocated_count. Compacting these fields saves 4-bytes for each loaded classes. >>>> >>>> bool _is_marked_dependent; // used for marking during flushing and >>>> deoptimization >>>> bool _rewritten; // methods rewritten. >>>> bool _has_nonstatic_fields; // for sizing with UseCompressedOops >>>> bool _should_verify_class; // allow caching of preverification >>>> >>>> http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ >>>> >>>> Tested with runThese on ubuntu. Ran JPRT. >>>> >>>> Thanks, >>>> Jiangli >> From mchr3k at gmail.com Mon Nov 14 11:55:16 2011 From: mchr3k at gmail.com (Martin Hare Robertson) Date: Mon, 14 Nov 2011 19:55:16 +0000 Subject: What does BufferBlob::Interpreter in a JVM crash log mean In-Reply-To: References: Message-ID: Thanks for the tip. I should have mentioned that I already spotted that option. However, I am concerned that disabling biased locking will dramatically impact perf. I am also really keen to understand what the BufferBlob::Interpreter line actually means. On 14 Nov 2011, at 17:33, Vitaly Davidovich wrote: > You can try disabling biased locking, -XX:-UseBiasedLocking, as a possible workaround. > > On Nov 14, 2011 11:01 AM, "Martin Hare Robertson" wrote: > This mailing list looks like the best bet to get an answer to my question. However, please let me know if I should be posting this somewhere more appropriate. > I am investigating a JVM crash which happens occasionally in my application. The hs_err file contains the following details about the crash. > > # SIGSEGV (0xb) at pc=0x065e68f4, pid=20208, tid=570166160 > > > > # > # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86) > > > > ... > > # Problematic frame: > # V [libjvm.so+0x5e68f4] > > > > ... > > Current thread (0x099ea800): JavaThread "Thread-315" daemon [_thread_in_vm, id=25782, stack(0x21fa3000,0x21fc1000)] > > > > ... > > vm_info: Java HotSpot(TM) Server VM (10.0-b23) for linux-x86 JRE (1.6.0_07-b06), built on Jun 10 2008 01:20:15 by "java_re" with gcc 3.2.1-7a (J2SE release) > > > > So this tells me that the JVM hit a segfault when running some Java code. The error log also contains information about the stack of the thread which crashed. > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > > > > V [libjvm.so+0x5e68f4] > > V [libjvm.so+0x1c054f] > > V [libjvm.so+0x1bfef2] > > V [libjvm.so+0x1bf57f] > > V [libjvm.so+0x592495] > > V [libjvm.so+0x365c4e] > > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > > v ~BufferBlob::Interpreter > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > > > > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > > v ~BufferBlob::Interpreter > J org.myapp.AppClass.getBytes()Lorg/myapp/ByteHolder; > > > > I have used GDB to connect to the core file from the crash and get more detail about the stack. This gives me the following output. > > #5 > > #6 0x065e68f4 in interpretedVFrame::monitors() const () > > > > from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so > > > > #7 0x061c054f in get_or_compute_monitor_info(JavaThread*) () > > from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so > > > > #8 0x061bfef2 in revoke_bias(oopDesc*, bool, bool, JavaThread*) () > > > > from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so > > > > #9 0x061bf57f in BiasedLocking::revoke_and_rebias(Handle, bool, Thread*) () > > > > from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so > > > > #10 0x06592495 in ObjectSynchronizer::fast_enter(Handle, BasicLock*, bool, Thread*) () > > > > from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so > > > > #11 0x06365c4e in InterpreterRuntime::monitorenter(JavaThread*, BasicObjectLock*) () > > > > from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so > > > > This shows that the six libjvm.so frames listed in the original bug report were related to grabbing a Java lock. However, I can't find any code within org.myapp.AppClass.getBytes() which uses any locks. > > ___ > > 1) What do the BufferBlob::Interpreter lines in the stack mean? > > - Are these Java stack frames? > > - JVM stack frames? > > - Is it possible to work out what was being called in these stack frames? > > ___ > > NOTE: Please don't suggest that I try to switch to a newer Hotspot JVM. I rely on the CMS collector and none of the more recent V1.6 Hotspot JVMs have been stable enough with the CMS collector in the testing which I have done. > > org.myapp.AppClass.getBytes() reads from a DataInputStream. This could produce the following stack trace: > AppClass.getBytes() > AppClass.readByte() > > DataInputStream.readByte() > SocketInputStream.read() > > SocketInputStream.read(byte[],int,int) > > PlainSocketImpl.aquireFD() > This final method grabs a lock. This could be the source of the eventual call into the JVM code listed above. This stack above has the convenient feature that there are 5 Java stack frames below getBytes(). This would match up neatly with the 5 lines of BufferBlob::Interpreter in the list of "Java frames". > > ___ > > 2) Could these 5 BufferBlob::Interpreter frames correspond to the Java stack trace I identified above? Is it possible that the 5 lines of BufferBlob::Interpreter under the "Native frames" section refer to the same stack frames as the same lines under the "Java frames" section? > > ___ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111114/8f64de5c/attachment.html From tom.rodriguez at oracle.com Mon Nov 14 13:02:47 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 14 Nov 2011 13:02:47 -0800 Subject: What does BufferBlob::Interpreter in a JVM crash log mean In-Reply-To: References: Message-ID: > > ___ > > 1) What do the BufferBlob::Interpreter lines in the stack mean? > > - Are these Java stack frames? > > - JVM stack frames? > > - Is it possible to work out what was being called in these stack frames? These are Java interpreter frames and normally they should be printed as Java method names and bci instead of setting the name BufferBlob::interpreter. That's the internal name of the chunk of memory where the assembly for the interpreter resides. The fact they you are seeing it probably represents a bug. I have a vague memory of a bug in the error reporting like this a while back but I can't remember off hand what it was. > > ___ > > NOTE: Please don't suggest that I try to switch to a newer Hotspot JVM. I rely on the CMS collector and none of the more recent V1.6 Hotspot JVMs have been stable enough with the CMS collector in the testing which I have done. > > org.myapp.AppClass.getBytes() reads from a DataInputStream. This could produce the following stack trace: > AppClass.getBytes() > AppClass.readByte() > > DataInputStream.readByte() > SocketInputStream.read() > > SocketInputStream.read(byte[],int,int) > > PlainSocketImpl.aquireFD() > This final method grabs a lock. This could be the source of the eventual call into the JVM code listed above. This stack above has the convenient feature that there are 5 Java stack frames below getBytes(). This would match up neatly with the 5 lines of BufferBlob::Interpreter in the list of "Java frames". > > ___ > > 2) Could these 5 BufferBlob::Interpreter frames correspond to the Java stack trace I identified above? Is it possible that the 5 lines of BufferBlob::Interpreter under the "Native frames" section refer to the same stack frames as the same lines under the "Java frames" section? The native frames you see in gdb correspond to the libjvm.so frames in the crash log and I suspect the BufferBlob frames correspond roughly to the Java call stack you posited above. The crash isn't in biased locking itself but in part of the logic that's walking the stack to revoke biases. So it may not have anything to do with biased locking itself. Turning it off and seeing if it fails in another way might be informative. If you aren't able to move to a more recent JVM then your only option is to try turning stuff off in hopes of making it go away, though it's possible it's a CMS issue. If you are having specific problems with hotspot that keep you from upgrading then I'd encourage to raise those issues so that we can get them resolved. tom > > ___ From mchr3k at gmail.com Mon Nov 14 14:00:31 2011 From: mchr3k at gmail.com (Martin Hare Robertson) Date: Mon, 14 Nov 2011 22:00:31 +0000 Subject: What does BufferBlob::Interpreter in a JVM crash log mean In-Reply-To: References: Message-ID: Thanks for your quick response. See inline below. On 14 Nov 2011, at 21:02, Tom Rodriguez wrote: >> >> ___ >> >> 1) What do the BufferBlob::Interpreter lines in the stack mean? >> >> - Are these Java stack frames? >> >> - JVM stack frames? >> >> - Is it possible to work out what was being called in these stack frames? > > These are Java interpreter frames and normally they should be printed as Java method names and bci instead of setting the name BufferBlob::interpreter. That's the internal name of the chunk of memory where the assembly for the interpreter resides. The fact they you are seeing it probably represents a bug. I have a vague memory of a bug in the error reporting like this a while back but I can't remember off hand what it was. Ok that makes sense to me. How about my guess regarding the fact that the BufferBlob::interpreter lines appear in both the Java and Native stacks? Is it likely that these frames refer to the same stack or is there really 5 frames of Java code above 5 frames of Native code? >> >> ___ >> >> NOTE: Please don't suggest that I try to switch to a newer Hotspot JVM. I rely on the CMS collector and none of the more recent V1.6 Hotspot JVMs have been stable enough with the CMS collector in the testing which I have done. >> >> org.myapp.AppClass.getBytes() reads from a DataInputStream. This could produce the following stack trace: >> AppClass.getBytes() >> AppClass.readByte() >> >> DataInputStream.readByte() >> SocketInputStream.read() >> >> SocketInputStream.read(byte[],int,int) >> >> PlainSocketImpl.aquireFD() >> This final method grabs a lock. This could be the source of the eventual call into the JVM code listed above. This stack above has the convenient feature that there are 5 Java stack frames below getBytes(). This would match up neatly with the 5 lines of BufferBlob::Interpreter in the list of "Java frames". >> >> ___ >> >> 2) Could these 5 BufferBlob::Interpreter frames correspond to the Java stack trace I identified above? Is it possible that the 5 lines of BufferBlob::Interpreter under the "Native frames" section refer to the same stack frames as the same lines under the "Java frames" section? > > The native frames you see in gdb correspond to the libjvm.so frames in the crash log and I suspect the BufferBlob frames correspond roughly to the Java call stack you posited above. > > The crash isn't in biased locking itself but in part of the logic that's walking the stack to revoke biases. So it may not have anything to do with biased locking itself. Turning it off and seeing if it fails in another way might be informative. Presumably if I turn off biased locking then the logic which walks the stack to revoke biases shouldn't be run? Or is the stack walking code more generic? > If you aren't able to move to a more recent JVM then your only option is to try turning stuff off in hopes of making it go away, though it's possible it's a CMS issue. If you are having specific problems with hotspot that keep you from upgrading then I'd encourage to raise those issues so that we can get them resolved. The biggest unresolved problem was reported under bug 7066603. Sadly this seems to have been marked as low priority. > tom > >> >> ___ > From dean.long at oracle.com Mon Nov 14 15:52:21 2011 From: dean.long at oracle.com (Dean Long) Date: Mon, 14 Nov 2011 15:52:21 -0800 Subject: Request for review: 7102776 Pack instanceKlass boolean fields into single u1 field In-Reply-To: References: <4EBABCAD.6060905@oracle.com> <4EC15BF9.4060407@oracle.com> <4EC15EF0.8070708@oracle.com> Message-ID: <4EC1A9B5.6000705@oracle.com> OK thanks. dl On 11/14/2011 10:50 AM, Tom Rodriguez wrote: > I don't know that there's a specific test which would have caught this. The purpose of the flag is minimize the time spent searching around in the class hierarchy when rechecking dependencies. Mostly it would have resulted in spending a little more time checking but I can't say for sure that it would have been noticed. > > tom > > On Nov 14, 2011, at 10:33 AM, Dean Long wrote: > >> By the way, is there a test that would have caught that "set" was being called instead of "clear"? >> >> dl >> >> On 11/14/2011 10:20 AM, Jiangli Zhou wrote: >>> Hi Bob, >>> >>> Sorry for the delay. Here is the updated webrev with dependencies.cpp fixed: http://cr.openjdk.java.net/~bobv/7102776/webrev.01/. Thanks for catching that! >>> >>> Thanks, >>> Jiangli >>> >>> >>> On 11/09/2011 02:13 PM, Bob Vandette wrote: >>>> Jiangli, >>>> >>>> src/share/vm/code/dependencies.cpp:1636 instanceKlass::cast(d)->set_is_marked_dependent(); >>>> >>>> Isn't this supposed to be clear_is_marked_dependent()? >>>> >>>> Bob. >>>> >>>> >>>> On Nov 9, 2011, at 12:47 PM, Jiangli Zhou wrote: >>>> >>>>> Compact following 4 instanceKlass boolean fields into a signal u1 field. Each flag now uses 1-bit. The new field is placed after the _idnum_allocated_count field to utilize the unused 2-byte after _idnum_allocated_count. Compacting these fields saves 4-bytes for each loaded classes. >>>>> >>>>> bool _is_marked_dependent; // used for marking during flushing and >>>>> deoptimization >>>>> bool _rewritten; // methods rewritten. >>>>> bool _has_nonstatic_fields; // for sizing with UseCompressedOops >>>>> bool _should_verify_class; // allow caching of preverification >>>>> >>>>> http://cr.openjdk.java.net/~bobv/7102776/webrev.00/ >>>>> >>>>> Tested with runThese on ubuntu. Ran JPRT. >>>>> >>>>> Thanks, >>>>> Jiangli From david.holmes at oracle.com Mon Nov 14 18:05:22 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Nov 2011 12:05:22 +1000 Subject: Code Review 7110017: is_headless_jre should be updated to reflect the new,location of awt toolkit libraries In-Reply-To: <4EBD02F6.1050305@oracle.com> References: <4EBD0331.6060604@oracle.com> <4EBD02F6.1050305@oracle.com> Message-ID: <4EC1C8E2.5050106@oracle.com> Pinging runtime! One more Reviewer please. Thanks, David On 11/11/2011 9:11 PM, David Holmes wrote: > Chris, > > Thanks for contributing the changes. I've applied them and tested them > so it is a Thumbs Up from me. > > We need one further Reviewer from runtime. > > Thanks, > David > > On 11/11/2011 9:12 PM, Chris Hegarty wrote: >> >> With the changes proposed by CR 7110002: "Rename xawt/libmawt.so and >> headless/libmawt.so so they can be colocated with libawt", >> os::is_headless_jre() will have to be updated to look for the renamed >> awt toolkit libraries. See the discussion on awt-dev for further >> information: >> http://mail.openjdk.java.net/pipermail/awt-dev/2011-November/002026.html >> >> The check for the motif toolkit can also be removed as the motif based >> toolkit has been removed in JDK7. >> >> Since is_headless_jre is checking is for headless and short circuits >> and returns false ( headed ) if it finds any headed library we can >> just check for the existence of either the new or old library, without >> JDK version specific code. If either exists then it is a headed >> environment. >> >> Webrev: >> http://cr.openjdk.java.net/~dholmes/7110017/webrev/ >> >> -Chris. >> >> P.S. Thanks to David Holmes for helping drive this on the vm side. From poonam.bajaj at oracle.com Mon Nov 14 22:11:01 2011 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Tue, 15 Nov 2011 11:41:01 +0530 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC16215.3080107@oracle.com> References: <4EC16215.3080107@oracle.com> Message-ID: <4EC20275.9070308@oracle.com> Hi John, The changes look good to me. Thanks, Poonam On 11/15/2011 12:16 AM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volnteers to review the fix for this CR? The > webrev can be found at: > http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. > > The issue here was that the routine GCNotifier::pushNotification(), > which uses GC data held in GCMemoryManager::_last_gc_stat, was being > called before the values in GCMemoryManager::_last_gc_stat were being > populated for the current GC. As a result the JVM could pass > uninitialized or stale data to a listener. The fix is to move the call > to GCNotifier::pushNotification() after the code that populates > GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo > constructor to fully initialize instances of that class. > > Testing: The supplied test case on Windows, a crafted test case on > Solaris, and the nsk GC tests. > > Thanks, > > JohnC From david.holmes at oracle.com Mon Nov 14 22:35:05 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Nov 2011 16:35:05 +1000 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC16215.3080107@oracle.com> References: <4EC16215.3080107@oracle.com> Message-ID: <4EC20819.1060906@oracle.com> Hi John, On 15/11/2011 4:46 AM, John Cuthbertson wrote: > Can I have a couple of volnteers to review the fix for this CR? The > webrev can be found at: > http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. In the original code the pushNotification is conditional on recordPostGCUsage, but you've removed that guard by moving the code. David ----- > The issue here was that the routine GCNotifier::pushNotification(), > which uses GC data held in GCMemoryManager::_last_gc_stat, was being > called before the values in GCMemoryManager::_last_gc_stat were being > populated for the current GC. As a result the JVM could pass > uninitialized or stale data to a listener. The fix is to move the call > to GCNotifier::pushNotification() after the code that populates > GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo > constructor to fully initialize instances of that class. > > Testing: The supplied test case on Windows, a crafted test case on > Solaris, and the nsk GC tests. > > Thanks, > > JohnC From Dmitry.Samersoff at oracle.com Tue Nov 15 04:17:13 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 15 Nov 2011 16:17:13 +0400 Subject: Code Review 7110017: is_headless_jre should be updated to reflect the new,location of awt toolkit libraries In-Reply-To: <4EC1C8E2.5050106@oracle.com> References: <4EBD0331.6060604@oracle.com> <4EBD02F6.1050305@oracle.com> <4EC1C8E2.5050106@oracle.com> Message-ID: <4EC25849.4010108@oracle.com> David, Some nit picking. 1. What is the goal of renaming xawtstr to new_xawtstr? 2. (Not to your code but as far as you touch it) "libawt_xawt" is longer than "libjvm" but we are copying it to static buffer without a boundary check - it can cause buffer overflow in some marginal case and clearly exploitable. I would prefer to add extra 5 bytes to libmawtpath ( sizeof("libawt_xawt.so") - sizeof("libjvm.so") ) char libmawtpath[MAXPATHLEN + 5]; 3. I don't see Windows changes - is it OK ? On 2011-11-15 06:05, David Holmes wrote: > Pinging runtime! One more Reviewer please. > > Thanks, > David > > On 11/11/2011 9:11 PM, David Holmes wrote: >> Chris, >> >> Thanks for contributing the changes. I've applied them and tested them >> so it is a Thumbs Up from me. >> >> We need one further Reviewer from runtime. >> >> Thanks, >> David >> >> On 11/11/2011 9:12 PM, Chris Hegarty wrote: >>> >>> With the changes proposed by CR 7110002: "Rename xawt/libmawt.so and >>> headless/libmawt.so so they can be colocated with libawt", >>> os::is_headless_jre() will have to be updated to look for the renamed >>> awt toolkit libraries. See the discussion on awt-dev for further >>> information: >>> http://mail.openjdk.java.net/pipermail/awt-dev/2011-November/002026.html >>> >>> The check for the motif toolkit can also be removed as the motif based >>> toolkit has been removed in JDK7. >>> >>> Since is_headless_jre is checking is for headless and short circuits >>> and returns false ( headed ) if it finds any headed library we can >>> just check for the existence of either the new or old library, without >>> JDK version specific code. If either exists then it is a headed >>> environment. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~dholmes/7110017/webrev/ >>> >>> -Chris. >>> >>> P.S. Thanks to David Holmes for helping drive this on the vm side. -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From john.cuthbertson at oracle.com Tue Nov 15 09:33:23 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 15 Nov 2011 09:33:23 -0800 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC20819.1060906@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> Message-ID: <4EC2A263.1060803@oracle.com> Hi David, Thanks for the review. I did and I did that consciously. As you say - with the current code the listener would only be notified if the _recordPostGCUsage field of the TraceMemoryManagerStats object is true (which it is by default) and none of the TraceMemoryManagerStats instances created by the collectors change this. But there's nothing to stop a collector creating a TraceMemoryManagerStats object with _recordPostGCUsage false and_recordGCEndTime true. In this case wouldn't we still want to notify the listener? I may be wrong (in which case I'll add the extra guard) but I believe that recording (some) data and notification should be two independent operations. Thanks, JohnC On 11/14/11 22:35, David Holmes wrote: > Hi John, > > On 15/11/2011 4:46 AM, John Cuthbertson wrote: >> Can I have a couple of volnteers to review the fix for this CR? The >> webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. > > In the original code the pushNotification is conditional on > recordPostGCUsage, but you've removed that guard by moving the code. > > David > ----- > >> The issue here was that the routine GCNotifier::pushNotification(), >> which uses GC data held in GCMemoryManager::_last_gc_stat, was being >> called before the values in GCMemoryManager::_last_gc_stat were being >> populated for the current GC. As a result the JVM could pass >> uninitialized or stale data to a listener. The fix is to move the call >> to GCNotifier::pushNotification() after the code that populates >> GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo >> constructor to fully initialize instances of that class. >> >> Testing: The supplied test case on Windows, a crafted test case on >> Solaris, and the nsk GC tests. >> >> Thanks, >> >> JohnC From tom.rodriguez at oracle.com Tue Nov 15 12:05:49 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 15 Nov 2011 12:05:49 -0800 Subject: What does BufferBlob::Interpreter in a JVM crash log mean In-Reply-To: References: Message-ID: On Nov 14, 2011, at 2:00 PM, Martin Hare Robertson wrote: > Thanks for your quick response. > > See inline below. > > On 14 Nov 2011, at 21:02, Tom Rodriguez wrote: > >>> >>> ___ >>> >>> 1) What do the BufferBlob::Interpreter lines in the stack mean? >>> >>> - Are these Java stack frames? >>> >>> - JVM stack frames? >>> >>> - Is it possible to work out what was being called in these stack frames? >> >> These are Java interpreter frames and normally they should be printed as Java method names and bci instead of setting the name BufferBlob::interpreter. That's the internal name of the chunk of memory where the assembly for the interpreter resides. The fact they you are seeing it probably represents a bug. I have a vague memory of a bug in the error reporting like this a while back but I can't remember off hand what it was. > > Ok that makes sense to me. How about my guess regarding the fact that the BufferBlob::interpreter lines appear in both the Java and Native stacks? Is it likely that these frames refer to the same stack or is there really 5 frames of Java code above 5 frames of Native code? It's five+ frames of Java calling 6 frames of native code and then crashing. >> >> The native frames you see in gdb correspond to the libjvm.so frames in the crash log and I suspect the BufferBlob frames correspond roughly to the Java call stack you posited above. >> >> The crash isn't in biased locking itself but in part of the logic that's walking the stack to revoke biases. So it may not have anything to do with biased locking itself. Turning it off and seeing if it fails in another way might be informative. > > Presumably if I turn off biased locking then the logic which walks the stack to revoke biases shouldn't be run? Or is the stack walking code more generic? The stack walk is pretty generic so the fact that it's failing there suggests it might not be a biased locking issue. That's why I think you might get a different failure with it turned off. > >> If you aren't able to move to a more recent JVM then your only option is to try turning stuff off in hopes of making it go away, though it's possible it's a CMS issue. If you are having specific problems with hotspot that keep you from upgrading then I'd encourage to raise those issues so that we can get them resolved. > > The biggest unresolved problem was reported under bug 7066603. Sadly this seems to have been marked as low priority. It seems to have gotten stuck over in the wrong category. I've moved into the proper category and updated it. It appears CMS isn't visiting some regular Java objects held in perm so they are missing from the dump. The recent changes to move Strings and Classes out of perm make this problem disappear in JDK7. So it only affects JDK6 at this point. I believe the bug is in the obj_is_alive logic that CMS uses to visit only live objects in perm. tom > >> tom >> >>> >>> ___ >> > From coleen.phillimore at oracle.com Tue Nov 15 13:47:36 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 15 Nov 2011 21:47:36 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 32 new changesets Message-ID: <20111115214841.0A5AA4736B@hg.openjdk.java.net> Changeset: ddb34559f9a7 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ddb34559f9a7 Added tag jdk8-b12 for changeset 1d3900713a67 ! .hgtags Changeset: 3e609627e780 Author: jcoomes Date: 2011-11-04 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3e609627e780 Merge - src/share/vm/precompiled.hpp Changeset: b92ca8e229d2 Author: jcoomes Date: 2011-11-04 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b92ca8e229d2 Added tag hs23-b05 for changeset 3e609627e780 ! .hgtags Changeset: 869804b759e7 Author: jcoomes Date: 2011-11-04 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/869804b759e7 7108553: Bump the hs23 build number to 06 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5bda8dae4e14 Author: never Date: 2011-10-23 20:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5bda8dae4e14 7103784: enable some flags by default Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 754110e02bd5 Author: never Date: 2011-10-23 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/754110e02bd5 7103380: assertion failure with -XX:+PrintNativeNMethods Reviewed-by: kvn, iveresov ! src/share/vm/asm/codeBuffer.cpp Changeset: 42783d1414b2 Author: never Date: 2011-10-23 23:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/42783d1414b2 Merge - make/templates/bsd-header Changeset: b20d64f83668 Author: twisti Date: 2011-10-24 07:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b20d64f83668 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop Reviewed-by: kvn, never, jrose ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp Changeset: 12d38ffcba2a Author: twisti Date: 2011-10-25 00:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/12d38ffcba2a 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check Reviewed-by: iveresov, never ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 2ec638646e86 Author: twisti Date: 2011-10-25 04:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2ec638646e86 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I Reviewed-by: kvn, iveresov ! src/share/vm/runtime/sharedRuntime.cpp Changeset: a6eef545f1a2 Author: never Date: 2011-10-25 08:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a6eef545f1a2 7103224: collision between __LEAF define in interfaceSupport.hpp and /usr/include/sys/cdefs.h with gcc Reviewed-by: never Contributed-by: Omair Majid ! src/share/vm/opto/addnode.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/interfaceSupport.hpp Changeset: e69a66a1457b Author: kvn Date: 2011-10-25 12:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e69a66a1457b 7059039: EA: don't change non-escaping state of NULL pointer Summary: NULL pointers do not escape but escape state propagation may change it leading to worser results. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: d8cb48376797 Author: kvn Date: 2011-10-26 06:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d8cb48376797 7097546: Optimize use of CMOVE instructions Summary: Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.hpp Changeset: cec1757a0134 Author: twisti Date: 2011-10-27 04:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cec1757a0134 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely Reviewed-by: never, bdelsart ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/opto/runtime.cpp Changeset: e0658a9b3f87 Author: kvn Date: 2011-10-27 09:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e0658a9b3f87 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" Summary: Define ciMethodHandle::print_chain_impl() and ciMethodHandle::print_chain() bodies only in debug builds. Reviewed-by: never, twisti ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp Changeset: 34535d2cb362 Author: iveresov Date: 2011-10-27 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/34535d2cb362 7104177: Tiered: -XX:+PrintCanonicalization doesn't work with -XX:+TieredCompilation Summary: Initialize printable_bci of instruction when passed to Canonicalizer Reviewed-by: kvn, never ! src/share/vm/c1/c1_Canonicalizer.hpp Changeset: f350490a45fd Author: kvn Date: 2011-10-27 18:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f350490a45fd 7105611: Set::print() is broken Summary: Reimplemented class VSetI_ to restore Set::print(). Reviewed-by: never ! src/share/vm/libadt/vectset.cpp ! src/share/vm/libadt/vectset.hpp Changeset: eba044a722a4 Author: never Date: 2011-10-28 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/eba044a722a4 7103261: crash with jittester on sparc Reviewed-by: iveresov, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp + test/compiler/7103261/Test7103261.java Changeset: e3b0dcc327b9 Author: twisti Date: 2011-10-31 03:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e3b0dcc327b9 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes Reviewed-by: never, kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/opto/machnode.cpp Changeset: 71699e9d8673 Author: kvn Date: 2011-10-31 15:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/71699e9d8673 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java Summary: Use -Xss224k instead of -Xss128k. Reviewed-by: never ! test/compiler/6865265/StackOverflowBug.java Changeset: e342a5110bed Author: twisti Date: 2011-11-03 01:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e342a5110bed 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result Reviewed-by: kvn ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 448691f285a5 Author: twisti Date: 2011-11-03 04:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/448691f285a5 7106944: assert(_pc == *pc_addr) failed may be too strong Reviewed-by: kvn, never ! src/cpu/x86/vm/frame_x86.cpp Changeset: 1feb272af3a7 Author: never Date: 2011-11-04 13:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1feb272af3a7 6636110: unaligned stackpointer leads to crash during deoptimization Reviewed-by: never, kvn Contributed-by: Andreas Schoesser ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: 59e515ee9354 Author: kvn Date: 2011-11-07 14:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/59e515ee9354 7059047: EA: can't find initializing store with several CheckCastPP Summary: Split adjust_escape_state() method into two methods to find initializing stores. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 44ce519bc3d1 Author: never Date: 2011-11-08 10:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/44ce519bc3d1 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer Reviewed-by: kvn, jrose, twisti ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp Changeset: c9a03402fe56 Author: never Date: 2011-11-08 17:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c9a03402fe56 7105305: assert check_method_context proper context Reviewed-by: jrose, kvn ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/constantPoolKlass.cpp Changeset: e3e363b2bf19 Author: never Date: 2011-11-08 20:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e3e363b2bf19 7108242: jinfo -permstat shouldn't report interned strings as part of perm Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 83d0b5cd1438 Author: twisti Date: 2011-11-09 00:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/83d0b5cd1438 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use Reviewed-by: jrose, kvn, never ! src/share/vm/opto/callGenerator.cpp Changeset: 7e0e43cf86d6 Author: kvn Date: 2011-11-09 06:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7e0e43cf86d6 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot Summary: zero array when compiled code is deoptimized. Reviewed-by: never, twisti ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: 670a74b863fc Author: kvn Date: 2011-11-09 07:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/670a74b863fc 7107042: assert(no_dead_loop) failed: dead loop detected Summary: Use dead nodes elimination code in PhaseIdealLoop before executing EA. Reviewed-by: never, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/runtime/globals.hpp Changeset: 78bef05801ca Author: twisti Date: 2011-11-10 04:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/78bef05801ca Merge - src/share/vm/precompiled.hpp ! src/share/vm/runtime/globals.hpp Changeset: f9a80a035a4a Author: coleenp Date: 2011-11-15 12:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9a80a035a4a Merge ! src/share/vm/runtime/globals.hpp From david.holmes at oracle.com Tue Nov 15 16:01:11 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Nov 2011 10:01:11 +1000 Subject: Code Review 7110017: is_headless_jre should be updated to reflect the new,location of awt toolkit libraries In-Reply-To: <4EC25849.4010108@oracle.com> References: <4EBD0331.6060604@oracle.com> <4EBD02F6.1050305@oracle.com> <4EC1C8E2.5050106@oracle.com> <4EC25849.4010108@oracle.com> Message-ID: <4EC2FD47.2080905@oracle.com> Hi Dmitry, On 15/11/2011 10:17 PM, Dmitry Samersoff wrote: > 1. What is the goal of renaming xawtstr to new_xawtstr? It isn't renamed. We added new_xawtstr to refer to the new library name, while keeping xawtstr to refer to the old library name - this code has to work for JDK 8 and JDK 7 and the library renaming is only in 8. We removed the (as of JDK7) unused motifstr. > 2. (Not to your code but as far as you touch it) "libawt_xawt" is > longer than "libjvm" but we are copying it to static buffer without a > boundary check - it can cause buffer overflow in some marginal case and > clearly exploitable. > > I would prefer to add extra 5 bytes to libmawtpath > ( sizeof("libawt_xawt.so") - sizeof("libjvm.so") ) > > char libmawtpath[MAXPATHLEN + 5]; Note that we are replacing either client/libjvm.so (16 chars) or server/libjvm.so (16 chars) with either: xawt/libmawt.so (15 chars) or libawt_xawt.so (14 chars) so there is no danger of overflow. > 3. I don't see Windows changes - is it OK ? Yes. is_headless_jre() is always false on Windows as there is no headless JRE there. Thanks, David ----- > > > > On 2011-11-15 06:05, David Holmes wrote: >> Pinging runtime! One more Reviewer please. >> >> Thanks, >> David >> >> On 11/11/2011 9:11 PM, David Holmes wrote: >>> Chris, >>> >>> Thanks for contributing the changes. I've applied them and tested them >>> so it is a Thumbs Up from me. >>> >>> We need one further Reviewer from runtime. >>> >>> Thanks, >>> David >>> >>> On 11/11/2011 9:12 PM, Chris Hegarty wrote: >>>> >>>> With the changes proposed by CR 7110002: "Rename xawt/libmawt.so and >>>> headless/libmawt.so so they can be colocated with libawt", >>>> os::is_headless_jre() will have to be updated to look for the renamed >>>> awt toolkit libraries. See the discussion on awt-dev for further >>>> information: >>>> http://mail.openjdk.java.net/pipermail/awt-dev/2011-November/002026.html >>>> >>>> The check for the motif toolkit can also be removed as the motif based >>>> toolkit has been removed in JDK7. >>>> >>>> Since is_headless_jre is checking is for headless and short circuits >>>> and returns false ( headed ) if it finds any headed library we can >>>> just check for the existence of either the new or old library, without >>>> JDK version specific code. If either exists then it is a headed >>>> environment. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~dholmes/7110017/webrev/ >>>> >>>> -Chris. >>>> >>>> P.S. Thanks to David Holmes for helping drive this on the vm side. > > From david.holmes at oracle.com Tue Nov 15 16:59:14 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Nov 2011 10:59:14 +1000 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC2A263.1060803@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> Message-ID: <4EC30AE2.9050805@oracle.com> Hi John, On 16/11/2011 3:33 AM, John Cuthbertson wrote: > Thanks for the review. I did and I did that consciously. As you say - > with the current code the listener would only be notified if the > _recordPostGCUsage field of the TraceMemoryManagerStats object is true > (which it is by default) and none of the TraceMemoryManagerStats > instances created by the collectors change this. But there's nothing to > stop a collector creating a TraceMemoryManagerStats object with > _recordPostGCUsage false and_recordGCEndTime true. In this case wouldn't > we still want to notify the listener? I may be wrong (in which case I'll > add the extra guard) but I believe that recording (some) data and > notification should be two independent operations. It depends on what data the listener is expecting to receive. If you push the notification when there hasn't been an update does that make sense? I don't know what the spec is for this. Anyway I just wanted to flag the change in potential behaviour. If no-one from GC has any issue with this then it's fine by me. David ----- > > Thanks, > > JohnC > > On 11/14/11 22:35, David Holmes wrote: >> Hi John, >> >> On 15/11/2011 4:46 AM, John Cuthbertson wrote: >>> Can I have a couple of volnteers to review the fix for this CR? The >>> webrev can be found at: >>> http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. >> >> In the original code the pushNotification is conditional on >> recordPostGCUsage, but you've removed that guard by moving the code. >> >> David >> ----- >> >>> The issue here was that the routine GCNotifier::pushNotification(), >>> which uses GC data held in GCMemoryManager::_last_gc_stat, was being >>> called before the values in GCMemoryManager::_last_gc_stat were being >>> populated for the current GC. As a result the JVM could pass >>> uninitialized or stale data to a listener. The fix is to move the call >>> to GCNotifier::pushNotification() after the code that populates >>> GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo >>> constructor to fully initialize instances of that class. >>> >>> Testing: The supplied test case on Windows, a crafted test case on >>> Solaris, and the nsk GC tests. >>> >>> Thanks, >>> >>> JohnC > From mandy.chung at oracle.com Tue Nov 15 18:26:42 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Nov 2011 18:26:42 -0800 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC30AE2.9050805@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> Message-ID: <4EC31F62.8080306@oracle.com> I'm including Frederic and serviceability-dev since this is part of the instrumentation done for serviceability. On 11/15/2011 4:59 PM, David Holmes wrote: > Hi John, > > On 16/11/2011 3:33 AM, John Cuthbertson wrote: >> Thanks for the review. I did and I did that consciously. As you say - >> with the current code the listener would only be notified if the >> _recordPostGCUsage field of the TraceMemoryManagerStats object is true >> (which it is by default) and none of the TraceMemoryManagerStats >> instances created by the collectors change this. But there's nothing to >> stop a collector creating a TraceMemoryManagerStats object with >> _recordPostGCUsage false and_recordGCEndTime true. In this case wouldn't >> we still want to notify the listener? I may be wrong (in which case I'll >> add the extra guard) but I believe that recording (some) data and >> notification should be two independent operations. > > It depends on what data the listener is expecting to receive. If you > push the notification when there hasn't been an update does that make > sense? I don't know what the spec is for this. > The GC notifier and pushNotification call was added as this changeset: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/78542e2b5e35 The spec for this is: http://download.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/GarbageCollectionNotificationInfo.html > Anyway I just wanted to flag the change in potential behaviour. If > no-one from GC has any issue with this then it's fine by me. > I think David is right that it should check recordPostGCUsage==true to push a notification. The notification is sent with the last GC statistics. If my memory serves correctly, if recordPostGCUsage is false, it doesn't update the last GC usage but sending a notification when recordPostGCUsage is false seems to be incorrect. Also, the recording was specifically added for CMS since CMS has separate phases that it needs to record different things. Frederic would be the best person to comment on this. Frederic - it seems to me that the pushNotification can be moved to the end of gc_end function but within the if (countCollection) statement. Sorry I don't have time to check the details out. It'd be good if you can help. Thanks Mandy > David > ----- > >> >> Thanks, >> >> JohnC >> >> On 11/14/11 22:35, David Holmes wrote: >>> Hi John, >>> >>> On 15/11/2011 4:46 AM, John Cuthbertson wrote: >>>> Can I have a couple of volnteers to review the fix for this CR? The >>>> webrev can be found at: >>>> http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. >>> >>> In the original code the pushNotification is conditional on >>> recordPostGCUsage, but you've removed that guard by moving the code. >>> >>> David >>> ----- >>> >>>> The issue here was that the routine GCNotifier::pushNotification(), >>>> which uses GC data held in GCMemoryManager::_last_gc_stat, was being >>>> called before the values in GCMemoryManager::_last_gc_stat were being >>>> populated for the current GC. As a result the JVM could pass >>>> uninitialized or stale data to a listener. The fix is to move the call >>>> to GCNotifier::pushNotification() after the code that populates >>>> GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo >>>> constructor to fully initialize instances of that class. >>>> >>>> Testing: The supplied test case on Windows, a crafted test case on >>>> Solaris, and the nsk GC tests. >>>> >>>> Thanks, >>>> >>>> JohnC >> From Dmitry.Samersoff at oracle.com Wed Nov 16 01:07:27 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 16 Nov 2011 13:07:27 +0400 Subject: Code Review 7110017: is_headless_jre should be updated to reflect the new,location of awt toolkit libraries In-Reply-To: <4EC2FD47.2080905@oracle.com> References: <4EBD0331.6060604@oracle.com> <4EBD02F6.1050305@oracle.com> <4EC1C8E2.5050106@oracle.com> <4EC25849.4010108@oracle.com> <4EC2FD47.2080905@oracle.com> Message-ID: <4EC37D4F.3040806@oracle.com> David, OK. Looks fine for me. -Dmitry On 2011-11-16 04:01, David Holmes wrote: > Hi Dmitry, > > On 15/11/2011 10:17 PM, Dmitry Samersoff wrote: >> 1. What is the goal of renaming xawtstr to new_xawtstr? > > It isn't renamed. We added new_xawtstr to refer to the new library name, > while keeping xawtstr to refer to the old library name - this code has > to work for JDK 8 and JDK 7 and the library renaming is only in 8. We > removed the (as of JDK7) unused motifstr. > >> 2. (Not to your code but as far as you touch it) "libawt_xawt" is >> longer than "libjvm" but we are copying it to static buffer without a >> boundary check - it can cause buffer overflow in some marginal case and >> clearly exploitable. >> >> I would prefer to add extra 5 bytes to libmawtpath >> ( sizeof("libawt_xawt.so") - sizeof("libjvm.so") ) >> >> char libmawtpath[MAXPATHLEN + 5]; > > Note that we are replacing either > > client/libjvm.so (16 chars) > > or > > server/libjvm.so (16 chars) > > with either: > > xawt/libmawt.so (15 chars) > > or > > libawt_xawt.so (14 chars) > > so there is no danger of overflow. > >> 3. I don't see Windows changes - is it OK ? > > Yes. is_headless_jre() is always false on Windows as there is no > headless JRE there. > > Thanks, > David > ----- > >> >> >> >> On 2011-11-15 06:05, David Holmes wrote: >>> Pinging runtime! One more Reviewer please. >>> >>> Thanks, >>> David >>> >>> On 11/11/2011 9:11 PM, David Holmes wrote: >>>> Chris, >>>> >>>> Thanks for contributing the changes. I've applied them and tested them >>>> so it is a Thumbs Up from me. >>>> >>>> We need one further Reviewer from runtime. >>>> >>>> Thanks, >>>> David >>>> >>>> On 11/11/2011 9:12 PM, Chris Hegarty wrote: >>>>> >>>>> With the changes proposed by CR 7110002: "Rename xawt/libmawt.so and >>>>> headless/libmawt.so so they can be colocated with libawt", >>>>> os::is_headless_jre() will have to be updated to look for the renamed >>>>> awt toolkit libraries. See the discussion on awt-dev for further >>>>> information: >>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2011-November/002026.html >>>>> >>>>> >>>>> The check for the motif toolkit can also be removed as the motif based >>>>> toolkit has been removed in JDK7. >>>>> >>>>> Since is_headless_jre is checking is for headless and short circuits >>>>> and returns false ( headed ) if it finds any headed library we can >>>>> just check for the existence of either the new or old library, without >>>>> JDK version specific code. If either exists then it is a headed >>>>> environment. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~dholmes/7110017/webrev/ >>>>> >>>>> -Chris. >>>>> >>>>> P.S. Thanks to David Holmes for helping drive this on the vm side. >> >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From frederic.parain at oracle.com Wed Nov 16 02:00:39 2011 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 16 Nov 2011 11:00:39 +0100 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC31F62.8080306@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> <4EC31F62.8080306@oracle.com> Message-ID: <4EC389C7.4050201@oracle.com> Hi, The reason why the memory usage data are bundled with the notification is to prevent data lost. If the notification doesn't provide the memory usage data, the client has to perform a getLastGcInfo() call to retrieve the data each time it receives a notification. But several GC cycles might occur between the time the notification is received and the time getLastGcInfo() is invoked. And there's no API to get memory usage data older than the one from the last GC cycle. With the notification including the memory usage data, the client is ensured to get data for all GC cycles. That said, the notification contains two memory usage datasets, one created at the beginning of the GC cycle and one created at the end of the cycle. There's no reason to condition the notification to the recording of the post GC cycle data recording. It's reasonable to send a notification for a GC which only collects the pre GC data for instance. So I think it's ok to move the notification code out of the recordPostGCUsage==true condition as long as the values in the non recorded memory usage data set can clearly be identified as being invalid. Right now they are initialized to zero, so it looks ok to me. Moving the notification code after the "if(countCollection)" block looks good too. However, I'm not an official reviewer, so you'll need more approvals for this changeset. Fred On 11/16/11 03:26 AM, Mandy Chung wrote: > I'm including Frederic and serviceability-dev since this is part of the > instrumentation done for serviceability. > > On 11/15/2011 4:59 PM, David Holmes wrote: >> Hi John, >> >> On 16/11/2011 3:33 AM, John Cuthbertson wrote: >>> Thanks for the review. I did and I did that consciously. As you say - >>> with the current code the listener would only be notified if the >>> _recordPostGCUsage field of the TraceMemoryManagerStats object is true >>> (which it is by default) and none of the TraceMemoryManagerStats >>> instances created by the collectors change this. But there's nothing to >>> stop a collector creating a TraceMemoryManagerStats object with >>> _recordPostGCUsage false and_recordGCEndTime true. In this case wouldn't >>> we still want to notify the listener? I may be wrong (in which case I'll >>> add the extra guard) but I believe that recording (some) data and >>> notification should be two independent operations. >> >> It depends on what data the listener is expecting to receive. If you >> push the notification when there hasn't been an update does that make >> sense? I don't know what the spec is for this. >> > > The GC notifier and pushNotification call was added as this changeset: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/78542e2b5e35 > > The spec for this is: > http://download.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/GarbageCollectionNotificationInfo.html > > >> Anyway I just wanted to flag the change in potential behaviour. If >> no-one from GC has any issue with this then it's fine by me. >> > > I think David is right that it should check recordPostGCUsage==true to > push a notification. The notification is sent with the last GC > statistics. If my memory serves correctly, if recordPostGCUsage is > false, it doesn't update the last GC usage but sending a notification > when recordPostGCUsage is false seems to be incorrect. Also, the > recording was specifically added for CMS since CMS has separate phases > that it needs to record different things. > > Frederic would be the best person to comment on this. Frederic - it > seems to me that the pushNotification can be moved to the end of gc_end > function but within the if (countCollection) statement. Sorry I don't > have time to check the details out. It'd be good if you can help. > > Thanks > Mandy > >> David >> ----- >> >>> >>> Thanks, >>> >>> JohnC >>> >>> On 11/14/11 22:35, David Holmes wrote: >>>> Hi John, >>>> >>>> On 15/11/2011 4:46 AM, John Cuthbertson wrote: >>>>> Can I have a couple of volnteers to review the fix for this CR? The >>>>> webrev can be found at: >>>>> http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. >>>> >>>> In the original code the pushNotification is conditional on >>>> recordPostGCUsage, but you've removed that guard by moving the code. >>>> >>>> David >>>> ----- >>>> >>>>> The issue here was that the routine GCNotifier::pushNotification(), >>>>> which uses GC data held in GCMemoryManager::_last_gc_stat, was being >>>>> called before the values in GCMemoryManager::_last_gc_stat were being >>>>> populated for the current GC. As a result the JVM could pass >>>>> uninitialized or stale data to a listener. The fix is to move the call >>>>> to GCNotifier::pushNotification() after the code that populates >>>>> GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo >>>>> constructor to fully initialize instances of that class. >>>>> >>>>> Testing: The supplied test case on Windows, a crafted test case on >>>>> Solaris, and the nsk GC tests. >>>>> >>>>> Thanks, >>>>> >>>>> JohnC >>> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From David.Holmes at oracle.com Wed Nov 16 02:03:17 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 16 Nov 2011 20:03:17 +1000 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC389C7.4050201@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> <4EC31F62.8080306@oracle.com> <4EC389C7.4050201@oracle.com> Message-ID: <4EC38A65.6010800@oracle.com> Well if Fred is okay with the change then all is good. :) So my Review stands. Cheers, David On 16/11/2011 8:00 PM, Frederic Parain wrote: > Hi, > > The reason why the memory usage data are bundled with the notification > is to prevent data lost. If the notification doesn't provide the > memory usage data, the client has to perform a getLastGcInfo() call > to retrieve the data each time it receives a notification. But several > GC cycles might occur between the time the notification is received and > the time getLastGcInfo() is invoked. And there's no API to get memory > usage data older than the one from the last GC cycle. With the > notification including the memory usage data, the client is ensured > to get data for all GC cycles. > > That said, the notification contains two memory usage datasets, one > created at the beginning of the GC cycle and one created at the end > of the cycle. There's no reason to condition the notification to > the recording of the post GC cycle data recording. It's reasonable > to send a notification for a GC which only collects the pre GC data > for instance. So I think it's ok to move the notification code out > of the recordPostGCUsage==true condition as long as the values in > the non recorded memory usage data set can clearly be identified > as being invalid. Right now they are initialized to zero, so it > looks ok to me. > > Moving the notification code after the "if(countCollection)" block > looks good too. > > However, I'm not an official reviewer, so you'll need more approvals > for this changeset. > > Fred > > On 11/16/11 03:26 AM, Mandy Chung wrote: >> I'm including Frederic and serviceability-dev since this is part of the >> instrumentation done for serviceability. >> >> On 11/15/2011 4:59 PM, David Holmes wrote: >>> Hi John, >>> >>> On 16/11/2011 3:33 AM, John Cuthbertson wrote: >>>> Thanks for the review. I did and I did that consciously. As you say - >>>> with the current code the listener would only be notified if the >>>> _recordPostGCUsage field of the TraceMemoryManagerStats object is true >>>> (which it is by default) and none of the TraceMemoryManagerStats >>>> instances created by the collectors change this. But there's nothing to >>>> stop a collector creating a TraceMemoryManagerStats object with >>>> _recordPostGCUsage false and_recordGCEndTime true. In this case wouldn't >>>> we still want to notify the listener? I may be wrong (in which case I'll >>>> add the extra guard) but I believe that recording (some) data and >>>> notification should be two independent operations. >>> >>> It depends on what data the listener is expecting to receive. If you >>> push the notification when there hasn't been an update does that make >>> sense? I don't know what the spec is for this. >>> >> >> The GC notifier and pushNotification call was added as this changeset: >> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/78542e2b5e35 >> >> The spec for this is: >> http://download.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/GarbageCollectionNotificationInfo.html >> >> >> >>> Anyway I just wanted to flag the change in potential behaviour. If >>> no-one from GC has any issue with this then it's fine by me. >>> >> >> I think David is right that it should check recordPostGCUsage==true to >> push a notification. The notification is sent with the last GC >> statistics. If my memory serves correctly, if recordPostGCUsage is >> false, it doesn't update the last GC usage but sending a notification >> when recordPostGCUsage is false seems to be incorrect. Also, the >> recording was specifically added for CMS since CMS has separate phases >> that it needs to record different things. >> >> Frederic would be the best person to comment on this. Frederic - it >> seems to me that the pushNotification can be moved to the end of gc_end >> function but within the if (countCollection) statement. Sorry I don't >> have time to check the details out. It'd be good if you can help. >> >> Thanks >> Mandy >> >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> >>>> JohnC >>>> >>>> On 11/14/11 22:35, David Holmes wrote: >>>>> Hi John, >>>>> >>>>> On 15/11/2011 4:46 AM, John Cuthbertson wrote: >>>>>> Can I have a couple of volnteers to review the fix for this CR? The >>>>>> webrev can be found at: >>>>>> http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. >>>>> >>>>> In the original code the pushNotification is conditional on >>>>> recordPostGCUsage, but you've removed that guard by moving the code. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> The issue here was that the routine GCNotifier::pushNotification(), >>>>>> which uses GC data held in GCMemoryManager::_last_gc_stat, was being >>>>>> called before the values in GCMemoryManager::_last_gc_stat were being >>>>>> populated for the current GC. As a result the JVM could pass >>>>>> uninitialized or stale data to a listener. The fix is to move the call >>>>>> to GCNotifier::pushNotification() after the code that populates >>>>>> GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo >>>>>> constructor to fully initialize instances of that class. >>>>>> >>>>>> Testing: The supplied test case on Windows, a crafted test case on >>>>>> Solaris, and the nsk GC tests. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> JohnC >>>> > From john.cuthbertson at oracle.com Wed Nov 16 09:40:19 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 16 Nov 2011 09:40:19 -0800 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC389C7.4050201@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> <4EC31F62.8080306@oracle.com> <4EC389C7.4050201@oracle.com> Message-ID: <4EC3F583.50800@oracle.com> Hi Fred, Thanks for the review and explanation. As for being an 'official' reviewer - 'official' is in the eye of the beholder. Since you have been looking at this code recently, you and your comments carry more weight. JohnC On 11/16/2011 2:00 AM, Frederic Parain wrote: > Hi, > > The reason why the memory usage data are bundled with the notification > is to prevent data lost. If the notification doesn't provide the > memory usage data, the client has to perform a getLastGcInfo() call > to retrieve the data each time it receives a notification. But several > GC cycles might occur between the time the notification is received and > the time getLastGcInfo() is invoked. And there's no API to get memory > usage data older than the one from the last GC cycle. With the > notification including the memory usage data, the client is ensured > to get data for all GC cycles. > > That said, the notification contains two memory usage datasets, one > created at the beginning of the GC cycle and one created at the end > of the cycle. There's no reason to condition the notification to > the recording of the post GC cycle data recording. It's reasonable > to send a notification for a GC which only collects the pre GC data > for instance. So I think it's ok to move the notification code out > of the recordPostGCUsage==true condition as long as the values in > the non recorded memory usage data set can clearly be identified > as being invalid. Right now they are initialized to zero, so it > looks ok to me. > > Moving the notification code after the "if(countCollection)" block > looks good too. > > However, I'm not an official reviewer, so you'll need more approvals > for this changeset. > > Fred > > On 11/16/11 03:26 AM, Mandy Chung wrote: >> I'm including Frederic and serviceability-dev since this is part of the >> instrumentation done for serviceability. >> >> On 11/15/2011 4:59 PM, David Holmes wrote: >>> Hi John, >>> >>> On 16/11/2011 3:33 AM, John Cuthbertson wrote: >>>> Thanks for the review. I did and I did that consciously. As you say - >>>> with the current code the listener would only be notified if the >>>> _recordPostGCUsage field of the TraceMemoryManagerStats object is true >>>> (which it is by default) and none of the TraceMemoryManagerStats >>>> instances created by the collectors change this. But there's >>>> nothing to >>>> stop a collector creating a TraceMemoryManagerStats object with >>>> _recordPostGCUsage false and_recordGCEndTime true. In this case >>>> wouldn't >>>> we still want to notify the listener? I may be wrong (in which case >>>> I'll >>>> add the extra guard) but I believe that recording (some) data and >>>> notification should be two independent operations. >>> >>> It depends on what data the listener is expecting to receive. If you >>> push the notification when there hasn't been an update does that make >>> sense? I don't know what the spec is for this. >>> >> >> The GC notifier and pushNotification call was added as this changeset: >> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/78542e2b5e35 >> >> The spec for this is: >> http://download.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/GarbageCollectionNotificationInfo.html >> >> >> >>> Anyway I just wanted to flag the change in potential behaviour. If >>> no-one from GC has any issue with this then it's fine by me. >>> >> >> I think David is right that it should check recordPostGCUsage==true to >> push a notification. The notification is sent with the last GC >> statistics. If my memory serves correctly, if recordPostGCUsage is >> false, it doesn't update the last GC usage but sending a notification >> when recordPostGCUsage is false seems to be incorrect. Also, the >> recording was specifically added for CMS since CMS has separate phases >> that it needs to record different things. >> >> Frederic would be the best person to comment on this. Frederic - it >> seems to me that the pushNotification can be moved to the end of gc_end >> function but within the if (countCollection) statement. Sorry I don't >> have time to check the details out. It'd be good if you can help. >> >> Thanks >> Mandy >> >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> >>>> JohnC >>>> >>>> On 11/14/11 22:35, David Holmes wrote: >>>>> Hi John, >>>>> >>>>> On 15/11/2011 4:46 AM, John Cuthbertson wrote: >>>>>> Can I have a couple of volnteers to review the fix for this CR? The >>>>>> webrev can be found at: >>>>>> http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. >>>>> >>>>> In the original code the pushNotification is conditional on >>>>> recordPostGCUsage, but you've removed that guard by moving the code. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> The issue here was that the routine GCNotifier::pushNotification(), >>>>>> which uses GC data held in GCMemoryManager::_last_gc_stat, was being >>>>>> called before the values in GCMemoryManager::_last_gc_stat were >>>>>> being >>>>>> populated for the current GC. As a result the JVM could pass >>>>>> uninitialized or stale data to a listener. The fix is to move the >>>>>> call >>>>>> to GCNotifier::pushNotification() after the code that populates >>>>>> GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo >>>>>> constructor to fully initialize instances of that class. >>>>>> >>>>>> Testing: The supplied test case on Windows, a crafted test case on >>>>>> Solaris, and the nsk GC tests. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> JohnC >>>> > From john.cuthbertson at oracle.com Wed Nov 16 09:42:28 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 16 Nov 2011 09:42:28 -0800 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC38A65.6010800@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> <4EC31F62.8080306@oracle.com> <4EC389C7.4050201@oracle.com> <4EC38A65.6010800@oracle.com> Message-ID: <4EC3F604.5010609@oracle.com> Hi David, I agree - if Fed thinks it's OK then I'm happy. Thanks for the initial review and asking what was a pertinent question. JohnC On 11/16/2011 2:03 AM, David Holmes wrote: > Well if Fred is okay with the change then all is good. :) > > So my Review stands. > > Cheers, > David > > > On 16/11/2011 8:00 PM, Frederic Parain wrote: >> Hi, >> >> The reason why the memory usage data are bundled with the notification >> is to prevent data lost. If the notification doesn't provide the >> memory usage data, the client has to perform a getLastGcInfo() call >> to retrieve the data each time it receives a notification. But several >> GC cycles might occur between the time the notification is received and >> the time getLastGcInfo() is invoked. And there's no API to get memory >> usage data older than the one from the last GC cycle. With the >> notification including the memory usage data, the client is ensured >> to get data for all GC cycles. >> >> That said, the notification contains two memory usage datasets, one >> created at the beginning of the GC cycle and one created at the end >> of the cycle. There's no reason to condition the notification to >> the recording of the post GC cycle data recording. It's reasonable >> to send a notification for a GC which only collects the pre GC data >> for instance. So I think it's ok to move the notification code out >> of the recordPostGCUsage==true condition as long as the values in >> the non recorded memory usage data set can clearly be identified >> as being invalid. Right now they are initialized to zero, so it >> looks ok to me. >> >> Moving the notification code after the "if(countCollection)" block >> looks good too. >> >> However, I'm not an official reviewer, so you'll need more approvals >> for this changeset. >> >> Fred >> >> On 11/16/11 03:26 AM, Mandy Chung wrote: >>> I'm including Frederic and serviceability-dev since this is part of the >>> instrumentation done for serviceability. >>> >>> On 11/15/2011 4:59 PM, David Holmes wrote: >>>> Hi John, >>>> >>>> On 16/11/2011 3:33 AM, John Cuthbertson wrote: >>>>> Thanks for the review. I did and I did that consciously. As you say - >>>>> with the current code the listener would only be notified if the >>>>> _recordPostGCUsage field of the TraceMemoryManagerStats object is >>>>> true >>>>> (which it is by default) and none of the TraceMemoryManagerStats >>>>> instances created by the collectors change this. But there's >>>>> nothing to >>>>> stop a collector creating a TraceMemoryManagerStats object with >>>>> _recordPostGCUsage false and_recordGCEndTime true. In this case >>>>> wouldn't >>>>> we still want to notify the listener? I may be wrong (in which >>>>> case I'll >>>>> add the extra guard) but I believe that recording (some) data and >>>>> notification should be two independent operations. >>>> >>>> It depends on what data the listener is expecting to receive. If you >>>> push the notification when there hasn't been an update does that make >>>> sense? I don't know what the spec is for this. >>>> >>> >>> The GC notifier and pushNotification call was added as this changeset: >>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/78542e2b5e35 >>> >>> The spec for this is: >>> http://download.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/GarbageCollectionNotificationInfo.html >>> >>> >>> >>> >>>> Anyway I just wanted to flag the change in potential behaviour. If >>>> no-one from GC has any issue with this then it's fine by me. >>>> >>> >>> I think David is right that it should check recordPostGCUsage==true to >>> push a notification. The notification is sent with the last GC >>> statistics. If my memory serves correctly, if recordPostGCUsage is >>> false, it doesn't update the last GC usage but sending a notification >>> when recordPostGCUsage is false seems to be incorrect. Also, the >>> recording was specifically added for CMS since CMS has separate phases >>> that it needs to record different things. >>> >>> Frederic would be the best person to comment on this. Frederic - it >>> seems to me that the pushNotification can be moved to the end of gc_end >>> function but within the if (countCollection) statement. Sorry I don't >>> have time to check the details out. It'd be good if you can help. >>> >>> Thanks >>> Mandy >>> >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> >>>>> JohnC >>>>> >>>>> On 11/14/11 22:35, David Holmes wrote: >>>>>> Hi John, >>>>>> >>>>>> On 15/11/2011 4:46 AM, John Cuthbertson wrote: >>>>>>> Can I have a couple of volnteers to review the fix for this CR? The >>>>>>> webrev can be found at: >>>>>>> http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. >>>>>> >>>>>> In the original code the pushNotification is conditional on >>>>>> recordPostGCUsage, but you've removed that guard by moving the code. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> The issue here was that the routine GCNotifier::pushNotification(), >>>>>>> which uses GC data held in GCMemoryManager::_last_gc_stat, was >>>>>>> being >>>>>>> called before the values in GCMemoryManager::_last_gc_stat were >>>>>>> being >>>>>>> populated for the current GC. As a result the JVM could pass >>>>>>> uninitialized or stale data to a listener. The fix is to move >>>>>>> the call >>>>>>> to GCNotifier::pushNotification() after the code that populates >>>>>>> GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo >>>>>>> constructor to fully initialize instances of that class. >>>>>>> >>>>>>> Testing: The supplied test case on Windows, a crafted test case on >>>>>>> Solaris, and the nsk GC tests. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> JohnC >>>>> >> From mandy.chung at oracle.com Wed Nov 16 10:23:27 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Nov 2011 10:23:27 -0800 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC389C7.4050201@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> <4EC31F62.8080306@oracle.com> <4EC389C7.4050201@oracle.com> Message-ID: <4EC3FF9F.2040407@oracle.com> John, Frederic, I looked at the implementation and I still think pushNotification should only be called *once* at the end of the GC cycle but not every MemoryManager::gc_end call (might be better to rename gc_end to something else). MemoryManager::gc_end is called at the destructor of TraceMemoryManagerStats and also TraceCMSMemoryManagerStats ( a subclass of TraceMemoryManagerStats). For the stop-the-world collectors, there is a clear begin and end of GC cycle. But for CMS, it has 3 stop-the-world phases. That's the reason why it has a list of flags to specify what to record since at different CMS phase, it will record different stats. At the end of entire CMS cycle, it will increment the collector count and gc end time etc. So the GC notification should be pushed only at the end of one collection cycle (for CMS case - would be SWEEPING phase). Below is the code of the TraceCMSMemoryManagerStats constructor that would make it clear: switch (phase) { case CMSCollector::InitialMarking: initialize(true /* fullGC */ , cause /* cause of the GC */, true /* recordGCBeginTime */, true /* recordPreGCUsage */, false /* recordPeakUsage */, false /* recordPostGCusage */, true /* recordAccumulatedGCTime */, false /* recordGCEndTime */, false /* countCollection */ ); break; case CMSCollector::FinalMarking: initialize(true /* fullGC */ , cause /* cause of the GC */, false /* recordGCBeginTime */, false /* recordPreGCUsage */, false /* recordPeakUsage */, false /* recordPostGCusage */, true /* recordAccumulatedGCTime */, false /* recordGCEndTime */, false /* countCollection */ ); break; case CMSCollector::Sweeping: initialize(true /* fullGC */ , cause /* cause of the GC */, false /* recordGCBeginTime */, false /* recordPreGCUsage */, true /* recordPeakUsage */, true /* recordPostGCusage */, false /* recordAccumulatedGCTime */, true /* recordGCEndTime */, true /* countCollection */ ); break; default: ShouldNotReachHere(); } I believe moving the pushNotification to inside the "if (countCollection)" statement would be a correct fix. It might be better to rename "countCollection" variable to something like "gcCompleted". I suggest to run jdk/test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java on CMS and see how many notifications are sent and what data it includes. You may need to modify it to print any other necessary information. I can help further next week once I finish a few things that I committed to complete this week. Mandy On 11/16/11 2:00 AM, Frederic Parain wrote: > Hi, > > The reason why the memory usage data are bundled with the notification > is to prevent data lost. If the notification doesn't provide the > memory usage data, the client has to perform a getLastGcInfo() call > to retrieve the data each time it receives a notification. But several > GC cycles might occur between the time the notification is received and > the time getLastGcInfo() is invoked. And there's no API to get memory > usage data older than the one from the last GC cycle. With the > notification including the memory usage data, the client is ensured > to get data for all GC cycles. > > That said, the notification contains two memory usage datasets, one > created at the beginning of the GC cycle and one created at the end > of the cycle. There's no reason to condition the notification to > the recording of the post GC cycle data recording. It's reasonable > to send a notification for a GC which only collects the pre GC data > for instance. So I think it's ok to move the notification code out > of the recordPostGCUsage==true condition as long as the values in > the non recorded memory usage data set can clearly be identified > as being invalid. Right now they are initialized to zero, so it > looks ok to me. > > Moving the notification code after the "if(countCollection)" block > looks good too. > > However, I'm not an official reviewer, so you'll need more approvals > for this changeset. > > Fred > > On 11/16/11 03:26 AM, Mandy Chung wrote: >> I'm including Frederic and serviceability-dev since this is part of the >> instrumentation done for serviceability. >> >> On 11/15/2011 4:59 PM, David Holmes wrote: >>> Hi John, >>> >>> On 16/11/2011 3:33 AM, John Cuthbertson wrote: >>>> Thanks for the review. I did and I did that consciously. As you say - >>>> with the current code the listener would only be notified if the >>>> _recordPostGCUsage field of the TraceMemoryManagerStats object is true >>>> (which it is by default) and none of the TraceMemoryManagerStats >>>> instances created by the collectors change this. But there's >>>> nothing to >>>> stop a collector creating a TraceMemoryManagerStats object with >>>> _recordPostGCUsage false and_recordGCEndTime true. In this case >>>> wouldn't >>>> we still want to notify the listener? I may be wrong (in which case >>>> I'll >>>> add the extra guard) but I believe that recording (some) data and >>>> notification should be two independent operations. >>> >>> It depends on what data the listener is expecting to receive. If you >>> push the notification when there hasn't been an update does that make >>> sense? I don't know what the spec is for this. >>> >> >> The GC notifier and pushNotification call was added as this changeset: >> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/78542e2b5e35 >> >> The spec for this is: >> http://download.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/GarbageCollectionNotificationInfo.html >> >> >> >>> Anyway I just wanted to flag the change in potential behaviour. If >>> no-one from GC has any issue with this then it's fine by me. >>> >> >> I think David is right that it should check recordPostGCUsage==true to >> push a notification. The notification is sent with the last GC >> statistics. If my memory serves correctly, if recordPostGCUsage is >> false, it doesn't update the last GC usage but sending a notification >> when recordPostGCUsage is false seems to be incorrect. Also, the >> recording was specifically added for CMS since CMS has separate phases >> that it needs to record different things. >> >> Frederic would be the best person to comment on this. Frederic - it >> seems to me that the pushNotification can be moved to the end of gc_end >> function but within the if (countCollection) statement. Sorry I don't >> have time to check the details out. It'd be good if you can help. >> >> Thanks >> Mandy >> >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> >>>> JohnC >>>> >>>> On 11/14/11 22:35, David Holmes wrote: >>>>> Hi John, >>>>> >>>>> On 15/11/2011 4:46 AM, John Cuthbertson wrote: >>>>>> Can I have a couple of volnteers to review the fix for this CR? The >>>>>> webrev can be found at: >>>>>> http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. >>>>> >>>>> In the original code the pushNotification is conditional on >>>>> recordPostGCUsage, but you've removed that guard by moving the code. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> The issue here was that the routine GCNotifier::pushNotification(), >>>>>> which uses GC data held in GCMemoryManager::_last_gc_stat, was being >>>>>> called before the values in GCMemoryManager::_last_gc_stat were >>>>>> being >>>>>> populated for the current GC. As a result the JVM could pass >>>>>> uninitialized or stale data to a listener. The fix is to move the >>>>>> call >>>>>> to GCNotifier::pushNotification() after the code that populates >>>>>> GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo >>>>>> constructor to fully initialize instances of that class. >>>>>> >>>>>> Testing: The supplied test case on Windows, a crafted test case on >>>>>> Solaris, and the nsk GC tests. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> JohnC >>>> > From david.holmes at oracle.com Wed Nov 16 22:11:24 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 17 Nov 2011 06:11:24 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7110017: is_headless_jre should be updated to reflect the new location of awt toolkit libraries Message-ID: <20111117061128.85598473AC@hg.openjdk.java.net> Changeset: 36b057451829 Author: dholmes Date: 2011-11-16 20:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/36b057451829 7110017: is_headless_jre should be updated to reflect the new location of awt toolkit libraries Reviewed-by: dholmes, dsamersoff Contributed-by: Chris Hegarty ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp From frederic.parain at oracle.com Thu Nov 17 05:43:27 2011 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 17 Nov 2011 14:43:27 +0100 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC3FF9F.2040407@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> <4EC31F62.8080306@oracle.com> <4EC389C7.4050201@oracle.com> <4EC3FF9F.2040407@oracle.com> Message-ID: <4EC50F7F.10402@oracle.com> Hi Mandy, It would have been nice to have notifications providing detailed information about CMS different phases, but it doesn't seem easy to do right now. I did the experiments with CMS using JConsole, and the result is not really satisfactory: - several notifications are sent for each CMS cycle but the notification lacks the information to identify the CMS phase associated with the notification (worse than that, they all claim they notify the "end of a major GC cycle" which is certainly not true for CMS. - according to the TraceCMSMemoryManagerStats constructor code, some information reported by the notification are inaccurate because the stats recorded for the current phase are still in _current_gc_stat while the notification code is using _last_gc_stat (so basically some notifications contain data from the previous GC cycle instead of data from the current cycle) So I agree that moving the pushNotification to inside the "if (countCollection)" statement would be a correct fix for CMS. +1 for the renaming of the 'countCollection' variable. Fred On 11/16/11 7:23 PM, Mandy Chung wrote: > John, Frederic, > > I looked at the implementation and I still think pushNotification > should only be called *once* at the end of the GC cycle but not > every MemoryManager::gc_end call (might be better to rename > gc_end to something else). > > MemoryManager::gc_end is called at the destructor of > TraceMemoryManagerStats and also TraceCMSMemoryManagerStats ( > a subclass of TraceMemoryManagerStats). For the stop-the-world > collectors, there is a clear begin and end of GC cycle. But > for CMS, it has 3 stop-the-world phases. That's the reason why > it has a list of flags to specify what to record since at different > CMS phase, it will record different stats. At the end of entire > CMS cycle, it will increment the collector count and gc end time > etc. So the GC notification should be pushed only at the end of > one collection cycle (for CMS case - would be SWEEPING phase). > > Below is the code of the TraceCMSMemoryManagerStats constructor > that would make it clear: > > switch (phase) { > case CMSCollector::InitialMarking: > initialize(true /* fullGC */ , > cause /* cause of the GC */, > true /* recordGCBeginTime */, > true /* recordPreGCUsage */, > false /* recordPeakUsage */, > false /* recordPostGCusage */, > true /* recordAccumulatedGCTime */, > false /* recordGCEndTime */, > false /* countCollection */ ); > break; > > case CMSCollector::FinalMarking: > initialize(true /* fullGC */ , > cause /* cause of the GC */, > false /* recordGCBeginTime */, > false /* recordPreGCUsage */, > false /* recordPeakUsage */, > false /* recordPostGCusage */, > true /* recordAccumulatedGCTime */, > false /* recordGCEndTime */, > false /* countCollection */ ); > break; > > case CMSCollector::Sweeping: > initialize(true /* fullGC */ , > cause /* cause of the GC */, > false /* recordGCBeginTime */, > false /* recordPreGCUsage */, > true /* recordPeakUsage */, > true /* recordPostGCusage */, > false /* recordAccumulatedGCTime */, > true /* recordGCEndTime */, > true /* countCollection */ ); > break; > > default: > ShouldNotReachHere(); > } > > I believe moving the pushNotification to inside the "if (countCollection)" > statement would be a correct fix. It might be better to rename > "countCollection" variable to something like "gcCompleted". > > I suggest to run > jdk/test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java > > > on CMS and see how many notifications are sent and what data it > includes. You may need to modify it to print any other necessary > information. I can help further next week once I finish a few > things that I committed to complete this week. > > Mandy > > > On 11/16/11 2:00 AM, Frederic Parain wrote: >> Hi, >> >> The reason why the memory usage data are bundled with the notification >> is to prevent data lost. If the notification doesn't provide the >> memory usage data, the client has to perform a getLastGcInfo() call >> to retrieve the data each time it receives a notification. But several >> GC cycles might occur between the time the notification is received and >> the time getLastGcInfo() is invoked. And there's no API to get memory >> usage data older than the one from the last GC cycle. With the >> notification including the memory usage data, the client is ensured >> to get data for all GC cycles. >> >> That said, the notification contains two memory usage datasets, one >> created at the beginning of the GC cycle and one created at the end >> of the cycle. There's no reason to condition the notification to >> the recording of the post GC cycle data recording. It's reasonable >> to send a notification for a GC which only collects the pre GC data >> for instance. So I think it's ok to move the notification code out >> of the recordPostGCUsage==true condition as long as the values in >> the non recorded memory usage data set can clearly be identified >> as being invalid. Right now they are initialized to zero, so it >> looks ok to me. >> >> Moving the notification code after the "if(countCollection)" block >> looks good too. >> >> However, I'm not an official reviewer, so you'll need more approvals >> for this changeset. >> >> Fred >> >> On 11/16/11 03:26 AM, Mandy Chung wrote: >>> I'm including Frederic and serviceability-dev since this is part of the >>> instrumentation done for serviceability. >>> >>> On 11/15/2011 4:59 PM, David Holmes wrote: >>>> Hi John, >>>> >>>> On 16/11/2011 3:33 AM, John Cuthbertson wrote: >>>>> Thanks for the review. I did and I did that consciously. As you say - >>>>> with the current code the listener would only be notified if the >>>>> _recordPostGCUsage field of the TraceMemoryManagerStats object is true >>>>> (which it is by default) and none of the TraceMemoryManagerStats >>>>> instances created by the collectors change this. But there's >>>>> nothing to >>>>> stop a collector creating a TraceMemoryManagerStats object with >>>>> _recordPostGCUsage false and_recordGCEndTime true. In this case >>>>> wouldn't >>>>> we still want to notify the listener? I may be wrong (in which case >>>>> I'll >>>>> add the extra guard) but I believe that recording (some) data and >>>>> notification should be two independent operations. >>>> >>>> It depends on what data the listener is expecting to receive. If you >>>> push the notification when there hasn't been an update does that make >>>> sense? I don't know what the spec is for this. >>>> >>> >>> The GC notifier and pushNotification call was added as this changeset: >>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/78542e2b5e35 >>> >>> The spec for this is: >>> http://download.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/GarbageCollectionNotificationInfo.html >>> >>> >>> >>>> Anyway I just wanted to flag the change in potential behaviour. If >>>> no-one from GC has any issue with this then it's fine by me. >>>> >>> >>> I think David is right that it should check recordPostGCUsage==true to >>> push a notification. The notification is sent with the last GC >>> statistics. If my memory serves correctly, if recordPostGCUsage is >>> false, it doesn't update the last GC usage but sending a notification >>> when recordPostGCUsage is false seems to be incorrect. Also, the >>> recording was specifically added for CMS since CMS has separate phases >>> that it needs to record different things. >>> >>> Frederic would be the best person to comment on this. Frederic - it >>> seems to me that the pushNotification can be moved to the end of gc_end >>> function but within the if (countCollection) statement. Sorry I don't >>> have time to check the details out. It'd be good if you can help. >>> >>> Thanks >>> Mandy >>> >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> >>>>> JohnC >>>>> >>>>> On 11/14/11 22:35, David Holmes wrote: >>>>>> Hi John, >>>>>> >>>>>> On 15/11/2011 4:46 AM, John Cuthbertson wrote: >>>>>>> Can I have a couple of volnteers to review the fix for this CR? The >>>>>>> webrev can be found at: >>>>>>> http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. >>>>>> >>>>>> In the original code the pushNotification is conditional on >>>>>> recordPostGCUsage, but you've removed that guard by moving the code. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> The issue here was that the routine GCNotifier::pushNotification(), >>>>>>> which uses GC data held in GCMemoryManager::_last_gc_stat, was being >>>>>>> called before the values in GCMemoryManager::_last_gc_stat were >>>>>>> being >>>>>>> populated for the current GC. As a result the JVM could pass >>>>>>> uninitialized or stale data to a listener. The fix is to move the >>>>>>> call >>>>>>> to GCNotifier::pushNotification() after the code that populates >>>>>>> GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo >>>>>>> constructor to fully initialize instances of that class. >>>>>>> >>>>>>> Testing: The supplied test case on Windows, a crafted test case on >>>>>>> Solaris, and the nsk GC tests. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> JohnC >>>>> >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From frederic.parain at oracle.com Thu Nov 17 06:27:19 2011 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 17 Nov 2011 15:27:19 +0100 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC5158F.7080303@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> <4EC31F62.8080306@oracle.com> <4EC389C7.4050201@oracle.com> <4EC3FF9F.2040407@oracle.com> <4EC50F7F.10402@oracle.com> <4EC5158F.7080303@oracle.com> Message-ID: <4EC519C7.7000903@oracle.com> On 11/17/11 3:09 PM, Tony Printezis wrote: > Fred, > > I haven't been following this thread closely, but I do have a question > (see below). > > On 11/17/2011 8:43 AM, Frederic Parain wrote: >> Hi Mandy, >> >> It would have been nice to have notifications providing >> detailed information about CMS different phases, but it >> doesn't seem easy to do right now. I did the experiments >> with CMS using JConsole, and the result is not really >> satisfactory: >> - several notifications are sent for each CMS cycle >> but the notification lacks the information to identify >> the CMS phase associated with the notification (worse >> than that, they all claim they notify the "end of a major >> GC cycle" which is certainly not true for CMS. > > Are you referring to notifications at the end of a concurrent cycle > (i.e., at the end of sweeping)? Depends on how you look at it, but a > concurrent cycle is a major cycle given that it collects the entire > heap. In fact, IIRC, the a concurrent cycle should increase the full gc > count. I'm not referring to the concurrent cycles, but to the different phases of CMS. It seems that CMS is calling GCMemoryManager::gc_end() after the initial marking, the final marking and the sweeping phase. The gc count (_num_collections) is incremented only after the completion of the sweeping phase. The actual notification code is confused by the fact that CMS is executing GCMemoryManager::gc_end() several times during a GC cycle. I made the assumption that calling gc_end() means that the GC cycle is completed, but this assumption is wrong with CMS, so the notification message is wrong in this case. Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From rickard.backman at oracle.com Thu Nov 17 07:04:56 2011 From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=) Date: Thu, 17 Nov 2011 16:04:56 +0100 Subject: Request for review: 7112308 Fix Visual Studio build for precompiled header Message-ID: <4EC52298.8070208@oracle.com> Hi All, my move of the precompiled header broke the project file creation for Visual Studio. Here is a small fix to the problem: 7112308: Fix Visual Studio build for precompiled header http://cr.openjdk.java.net/~rbackman/7112308/ Thanks Rickard From mandy.chung at oracle.com Thu Nov 17 08:05:41 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Nov 2011 08:05:41 -0800 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC50F7F.10402@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> <4EC31F62.8080306@oracle.com> <4EC389C7.4050201@oracle.com> <4EC3FF9F.2040407@oracle.com> <4EC50F7F.10402@oracle.com> Message-ID: <4EC530D5.9090709@oracle.com> On 11/17/2011 5:43 AM, Frederic Parain wrote: > Hi Mandy, > > It would have been nice to have notifications providing > detailed information about CMS different phases, but it > doesn't seem easy to do right now. I did the experiments > with CMS using JConsole, and the result is not really > satisfactory: > - several notifications are sent for each CMS cycle > but the notification lacks the information to identify > the CMS phase associated with the notification (worse > than that, they all claim they notify the "end of a major > GC cycle" which is certainly not true for CMS. > - according to the TraceCMSMemoryManagerStats constructor > code, some information reported by the notification > are inaccurate because the stats recorded for the current > phase are still in _current_gc_stat while the notification > code is using _last_gc_stat (so basically some notifications > contain data from the previous GC cycle instead of data > from the current cycle) I suggest to create a CR for this problem and fix it later. > > So I agree that moving the pushNotification to inside the "if > (countCollection)" statement would be a correct fix for CMS. > > +1 for the renaming of the 'countCollection' variable. > John - hope this clarifies it. Sending notification only if countCollection is true would be the right fix. Thanks Mandy > Fred > > On 11/16/11 7:23 PM, Mandy Chung wrote: >> John, Frederic, >> >> I looked at the implementation and I still think pushNotification >> should only be called *once* at the end of the GC cycle but not >> every MemoryManager::gc_end call (might be better to rename >> gc_end to something else). >> >> MemoryManager::gc_end is called at the destructor of >> TraceMemoryManagerStats and also TraceCMSMemoryManagerStats ( >> a subclass of TraceMemoryManagerStats). For the stop-the-world >> collectors, there is a clear begin and end of GC cycle. But >> for CMS, it has 3 stop-the-world phases. That's the reason why >> it has a list of flags to specify what to record since at different >> CMS phase, it will record different stats. At the end of entire >> CMS cycle, it will increment the collector count and gc end time >> etc. So the GC notification should be pushed only at the end of >> one collection cycle (for CMS case - would be SWEEPING phase). >> >> Below is the code of the TraceCMSMemoryManagerStats constructor >> that would make it clear: >> >> switch (phase) { >> case CMSCollector::InitialMarking: >> initialize(true /* fullGC */ , >> cause /* cause of the GC */, >> true /* recordGCBeginTime */, >> true /* recordPreGCUsage */, >> false /* recordPeakUsage */, >> false /* recordPostGCusage */, >> true /* recordAccumulatedGCTime */, >> false /* recordGCEndTime */, >> false /* countCollection */ ); >> break; >> >> case CMSCollector::FinalMarking: >> initialize(true /* fullGC */ , >> cause /* cause of the GC */, >> false /* recordGCBeginTime */, >> false /* recordPreGCUsage */, >> false /* recordPeakUsage */, >> false /* recordPostGCusage */, >> true /* recordAccumulatedGCTime */, >> false /* recordGCEndTime */, >> false /* countCollection */ ); >> break; >> >> case CMSCollector::Sweeping: >> initialize(true /* fullGC */ , >> cause /* cause of the GC */, >> false /* recordGCBeginTime */, >> false /* recordPreGCUsage */, >> true /* recordPeakUsage */, >> true /* recordPostGCusage */, >> false /* recordAccumulatedGCTime */, >> true /* recordGCEndTime */, >> true /* countCollection */ ); >> break; >> >> default: >> ShouldNotReachHere(); >> } >> >> I believe moving the pushNotification to inside the "if >> (countCollection)" >> statement would be a correct fix. It might be better to rename >> "countCollection" variable to something like "gcCompleted". >> >> I suggest to run >> jdk/test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java >> >> >> >> on CMS and see how many notifications are sent and what data it >> includes. You may need to modify it to print any other necessary >> information. I can help further next week once I finish a few >> things that I committed to complete this week. >> >> Mandy >> >> >> On 11/16/11 2:00 AM, Frederic Parain wrote: >>> Hi, >>> >>> The reason why the memory usage data are bundled with the notification >>> is to prevent data lost. If the notification doesn't provide the >>> memory usage data, the client has to perform a getLastGcInfo() call >>> to retrieve the data each time it receives a notification. But several >>> GC cycles might occur between the time the notification is received and >>> the time getLastGcInfo() is invoked. And there's no API to get memory >>> usage data older than the one from the last GC cycle. With the >>> notification including the memory usage data, the client is ensured >>> to get data for all GC cycles. >>> >>> That said, the notification contains two memory usage datasets, one >>> created at the beginning of the GC cycle and one created at the end >>> of the cycle. There's no reason to condition the notification to >>> the recording of the post GC cycle data recording. It's reasonable >>> to send a notification for a GC which only collects the pre GC data >>> for instance. So I think it's ok to move the notification code out >>> of the recordPostGCUsage==true condition as long as the values in >>> the non recorded memory usage data set can clearly be identified >>> as being invalid. Right now they are initialized to zero, so it >>> looks ok to me. >>> >>> Moving the notification code after the "if(countCollection)" block >>> looks good too. >>> >>> However, I'm not an official reviewer, so you'll need more approvals >>> for this changeset. >>> >>> Fred >>> >>> On 11/16/11 03:26 AM, Mandy Chung wrote: >>>> I'm including Frederic and serviceability-dev since this is part of >>>> the >>>> instrumentation done for serviceability. >>>> >>>> On 11/15/2011 4:59 PM, David Holmes wrote: >>>>> Hi John, >>>>> >>>>> On 16/11/2011 3:33 AM, John Cuthbertson wrote: >>>>>> Thanks for the review. I did and I did that consciously. As you >>>>>> say - >>>>>> with the current code the listener would only be notified if the >>>>>> _recordPostGCUsage field of the TraceMemoryManagerStats object is >>>>>> true >>>>>> (which it is by default) and none of the TraceMemoryManagerStats >>>>>> instances created by the collectors change this. But there's >>>>>> nothing to >>>>>> stop a collector creating a TraceMemoryManagerStats object with >>>>>> _recordPostGCUsage false and_recordGCEndTime true. In this case >>>>>> wouldn't >>>>>> we still want to notify the listener? I may be wrong (in which case >>>>>> I'll >>>>>> add the extra guard) but I believe that recording (some) data and >>>>>> notification should be two independent operations. >>>>> >>>>> It depends on what data the listener is expecting to receive. If you >>>>> push the notification when there hasn't been an update does that make >>>>> sense? I don't know what the spec is for this. >>>>> >>>> >>>> The GC notifier and pushNotification call was added as this changeset: >>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/78542e2b5e35 >>>> >>>> The spec for this is: >>>> http://download.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/GarbageCollectionNotificationInfo.html >>>> >>>> >>>> >>>> >>>>> Anyway I just wanted to flag the change in potential behaviour. If >>>>> no-one from GC has any issue with this then it's fine by me. >>>>> >>>> >>>> I think David is right that it should check recordPostGCUsage==true to >>>> push a notification. The notification is sent with the last GC >>>> statistics. If my memory serves correctly, if recordPostGCUsage is >>>> false, it doesn't update the last GC usage but sending a notification >>>> when recordPostGCUsage is false seems to be incorrect. Also, the >>>> recording was specifically added for CMS since CMS has separate phases >>>> that it needs to record different things. >>>> >>>> Frederic would be the best person to comment on this. Frederic - it >>>> seems to me that the pushNotification can be moved to the end of >>>> gc_end >>>> function but within the if (countCollection) statement. Sorry I don't >>>> have time to check the details out. It'd be good if you can help. >>>> >>>> Thanks >>>> Mandy >>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> JohnC >>>>>> >>>>>> On 11/14/11 22:35, David Holmes wrote: >>>>>>> Hi John, >>>>>>> >>>>>>> On 15/11/2011 4:46 AM, John Cuthbertson wrote: >>>>>>>> Can I have a couple of volnteers to review the fix for this CR? >>>>>>>> The >>>>>>>> webrev can be found at: >>>>>>>> http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. >>>>>>> >>>>>>> In the original code the pushNotification is conditional on >>>>>>> recordPostGCUsage, but you've removed that guard by moving the >>>>>>> code. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> The issue here was that the routine >>>>>>>> GCNotifier::pushNotification(), >>>>>>>> which uses GC data held in GCMemoryManager::_last_gc_stat, was >>>>>>>> being >>>>>>>> called before the values in GCMemoryManager::_last_gc_stat were >>>>>>>> being >>>>>>>> populated for the current GC. As a result the JVM could pass >>>>>>>> uninitialized or stale data to a listener. The fix is to move the >>>>>>>> call >>>>>>>> to GCNotifier::pushNotification() after the code that populates >>>>>>>> GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo >>>>>>>> constructor to fully initialize instances of that class. >>>>>>>> >>>>>>>> Testing: The supplied test case on Windows, a crafted test case on >>>>>>>> Solaris, and the nsk GC tests. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> JohnC >>>>>> >>> >> > From tony.printezis at oracle.com Thu Nov 17 06:39:29 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 17 Nov 2011 09:39:29 -0500 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC519C7.7000903@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> <4EC31F62.8080306@oracle.com> <4EC389C7.4050201@oracle.com> <4EC3FF9F.2040407@oracle.com> <4EC50F7F.10402@oracle.com> <4EC5158F.7080303@oracle.com> <4EC519C7.7000903@oracle.com> Message-ID: <4EC51CA1.2020406@oracle.com> Fred, Thanks for the clarification. You're totally right that the end of the individual CMS pauses should not be seen as major GCs. Tony On 11/17/2011 9:27 AM, Frederic Parain wrote: > > > On 11/17/11 3:09 PM, Tony Printezis wrote: >> Fred, >> >> I haven't been following this thread closely, but I do have a question >> (see below). >> >> On 11/17/2011 8:43 AM, Frederic Parain wrote: >>> Hi Mandy, >>> >>> It would have been nice to have notifications providing >>> detailed information about CMS different phases, but it >>> doesn't seem easy to do right now. I did the experiments >>> with CMS using JConsole, and the result is not really >>> satisfactory: >>> - several notifications are sent for each CMS cycle >>> but the notification lacks the information to identify >>> the CMS phase associated with the notification (worse >>> than that, they all claim they notify the "end of a major >>> GC cycle" which is certainly not true for CMS. >> >> Are you referring to notifications at the end of a concurrent cycle >> (i.e., at the end of sweeping)? Depends on how you look at it, but a >> concurrent cycle is a major cycle given that it collects the entire >> heap. In fact, IIRC, the a concurrent cycle should increase the full gc >> count. > > I'm not referring to the concurrent cycles, but to the different phases > of CMS. It seems that CMS is calling GCMemoryManager::gc_end() after > the initial marking, the final marking and the sweeping phase. The > gc count (_num_collections) is incremented only after the completion of > the sweeping phase. The actual notification code is confused > by the fact that CMS is executing GCMemoryManager::gc_end() several > times during a GC cycle. I made the assumption that calling gc_end() > means that the GC cycle is completed, but this assumption is wrong > with CMS, so the notification message is wrong in this case. > > Fred > From coleen.phillimore at oracle.com Thu Nov 17 14:10:06 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Nov 2011 22:10:06 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 7102776: Pack instanceKlass boolean fields into single u1 field Message-ID: <20111117221009.E108B473BC@hg.openjdk.java.net> Changeset: 75c0a73eee98 Author: coleenp Date: 2011-11-17 12:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/75c0a73eee98 7102776: Pack instanceKlass boolean fields into single u1 field Summary: Reduce class runtime memory usage by packing 4 instanceKlass boolean fields into single u1 field. Save 4-byte for each loaded class. Reviewed-by: dholmes, bobv, phh, twisti, never, coleenp Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp From david.holmes at oracle.com Thu Nov 17 17:42:55 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Nov 2011 11:42:55 +1000 Subject: Request for review: 7112308 Fix Visual Studio build for precompiled header In-Reply-To: <4EC52298.8070208@oracle.com> References: <4EC52298.8070208@oracle.com> Message-ID: <4EC5B81F.2070609@oracle.com> Looks okay to me. Hopefully there are no other implicit references to "precompiled" lurking. David On 18/11/2011 1:04 AM, Rickard B?ckman wrote: > Hi All, > > my move of the precompiled header broke the project file creation for > Visual Studio. Here is a small fix to the problem: > > 7112308: Fix Visual Studio build for precompiled header > http://cr.openjdk.java.net/~rbackman/7112308/ > > Thanks > Rickard From coleen.phillimore at oracle.com Thu Nov 17 18:23:50 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 17 Nov 2011 21:23:50 -0500 Subject: Request for review: 7112308 Fix Visual Studio build for precompiled header In-Reply-To: <4EC5B81F.2070609@oracle.com> References: <4EC52298.8070208@oracle.com> <4EC5B81F.2070609@oracle.com> Message-ID: <4EC5C1B6.30206@oracle.com> This looks good. Coleen On 11/17/2011 8:42 PM, David Holmes wrote: > Looks okay to me. > > Hopefully there are no other implicit references to "precompiled" > lurking. > > David > > On 18/11/2011 1:04 AM, Rickard B?ckman wrote: >> Hi All, >> >> my move of the precompiled header broke the project file creation for >> Visual Studio. Here is a small fix to the problem: >> >> 7112308: Fix Visual Studio build for precompiled header >> http://cr.openjdk.java.net/~rbackman/7112308/ >> >> Thanks >> Rickard From bengt.rutisson at oracle.com Fri Nov 18 00:17:14 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 18 Nov 2011 09:17:14 +0100 Subject: Request for review: 7112308 Fix Visual Studio build for precompiled header In-Reply-To: <4EC52298.8070208@oracle.com> References: <4EC52298.8070208@oracle.com> Message-ID: <4EC6148A.5060506@oracle.com> Rickard, Thanks for finding this! Your fix looks good. Just verified a Visual Studio build with your changes applied. Works fine. I assume you need this in hotspot-rt as soon as possible. But I anyway just want to ask if there is any chance of pushing this through hotspot-gc instead? Tony integrated hotspot-gc and hotspot-main yesterday. That integration brought your original precompiled.hpp change over to hotspot-gc. So, up until now I have not had any problems with my VS projects. Now I guess they will be broken until your new change has propagated from hotspot-rt to hotspot-gc... But if you need it in hotspot-rt you will have the same issue. So there is really no good solution. Just thought I'd ask. Bengt On 2011-11-17 16:04, Rickard B?ckman wrote: > Hi All, > > my move of the precompiled header broke the project file creation for > Visual Studio. Here is a small fix to the problem: > > 7112308: Fix Visual Studio build for precompiled header > http://cr.openjdk.java.net/~rbackman/7112308/ > > Thanks > Rickard From rickard.backman at oracle.com Fri Nov 18 01:03:25 2011 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 18 Nov 2011 10:03:25 +0100 Subject: Request for review: 7112308 Fix Visual Studio build for precompiled header In-Reply-To: <4EC5B81F.2070609@oracle.com> References: <4EC52298.8070208@oracle.com> <4EC5B81F.2070609@oracle.com> Message-ID: <627E6D44-9257-40FA-B8A6-EF35D3796718@oracle.com> Thanks for the review David. Rickard On Nov 18, 2011, at 2:42 AM, David Holmes wrote: > Looks okay to me. > > Hopefully there are no other implicit references to "precompiled" lurking. > > David > > On 18/11/2011 1:04 AM, Rickard B?ckman wrote: >> Hi All, >> >> my move of the precompiled header broke the project file creation for >> Visual Studio. Here is a small fix to the problem: >> >> 7112308: Fix Visual Studio build for precompiled header >> http://cr.openjdk.java.net/~rbackman/7112308/ >> >> Thanks >> Rickard From rickard.backman at oracle.com Fri Nov 18 01:03:46 2011 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 18 Nov 2011 10:03:46 +0100 Subject: Request for review: 7112308 Fix Visual Studio build for precompiled header In-Reply-To: <4EC5C1B6.30206@oracle.com> References: <4EC52298.8070208@oracle.com> <4EC5B81F.2070609@oracle.com> <4EC5C1B6.30206@oracle.com> Message-ID: Thanks Coleen! /R On Nov 18, 2011, at 3:23 AM, Coleen Phillimore wrote: > This looks good. > Coleen > > On 11/17/2011 8:42 PM, David Holmes wrote: >> Looks okay to me. >> >> Hopefully there are no other implicit references to "precompiled" lurking. >> >> David >> >> On 18/11/2011 1:04 AM, Rickard B?ckman wrote: >>> Hi All, >>> >>> my move of the precompiled header broke the project file creation for >>> Visual Studio. Here is a small fix to the problem: >>> >>> 7112308: Fix Visual Studio build for precompiled header >>> http://cr.openjdk.java.net/~rbackman/7112308/ >>> >>> Thanks >>> Rickard From rickard.backman at oracle.com Fri Nov 18 01:05:51 2011 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 18 Nov 2011 10:05:51 +0100 Subject: Request for review: 7112308 Fix Visual Studio build for precompiled header In-Reply-To: <4EC6148A.5060506@oracle.com> References: <4EC52298.8070208@oracle.com> <4EC6148A.5060506@oracle.com> Message-ID: <28592A1F-9F7E-4F3C-8B31-B7610E3B6766@oracle.com> Thanks for the review Bengt, feel free to push it for me as I don't have the right role to do so. On Nov 18, 2011, at 9:17 AM, Bengt Rutisson wrote: > > Rickard, > > Thanks for finding this! Your fix looks good. Just verified a Visual Studio build with your changes applied. Works fine. I'll give credit to Karen who filed the bug. > > > I assume you need this in hotspot-rt as soon as possible. But I anyway just want to ask if there is any chance of pushing this through hotspot-gc instead? > > Tony integrated hotspot-gc and hotspot-main yesterday. That integration brought your original precompiled.hpp change over to hotspot-gc. So, up until now I have not had any problems with my VS projects. Now I guess they will be broken until your new change has propagated from hotspot-rt to hotspot-gc... > > But if you need it in hotspot-rt you will have the same issue. So there is really no good solution. Just thought I'd ask. > > Bengt > > > On 2011-11-17 16:04, Rickard B?ckman wrote: >> Hi All, >> >> my move of the precompiled header broke the project file creation for Visual Studio. Here is a small fix to the problem: >> >> 7112308: Fix Visual Studio build for precompiled header >> http://cr.openjdk.java.net/~rbackman/7112308/ >> >> Thanks >> Rickard > From daniel.daugherty at oracle.com Fri Nov 18 06:48:49 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 18 Nov 2011 07:48:49 -0700 Subject: Request for review: 7112308 Fix Visual Studio build for precompiled header In-Reply-To: <28592A1F-9F7E-4F3C-8B31-B7610E3B6766@oracle.com> References: <4EC52298.8070208@oracle.com> <4EC6148A.5060506@oracle.com> <28592A1F-9F7E-4F3C-8B31-B7610E3B6766@oracle.com> Message-ID: <4EC67051.3000105@oracle.com> I think this is one of the few cases where a push to Main_Baseline would be warranted. Particularly since more folks are starting to use Visual Studio (again...) Dan > Thanks for the review Bengt, > feel free to push it for me as I don't have the right role to do so. > > On Nov 18, 2011, at 9:17 AM, Bengt Rutisson wrote: > >> Rickard, >> >> Thanks for finding this! Your fix looks good. Just verified a Visual Studio build with your changes applied. Works fine. > I'll give credit to Karen who filed the bug. > >> >> I assume you need this in hotspot-rt as soon as possible. But I anyway just want to ask if there is any chance of pushing this through hotspot-gc instead? >> >> Tony integrated hotspot-gc and hotspot-main yesterday. That integration brought your original precompiled.hpp change over to hotspot-gc. So, up until now I have not had any problems with my VS projects. Now I guess they will be broken until your new change has propagated from hotspot-rt to hotspot-gc... >> >> But if you need it in hotspot-rt you will have the same issue. So there is really no good solution. Just thought I'd ask. >> >> Bengt >> >> >> On 2011-11-17 16:04, Rickard B?ckman wrote: >>> Hi All, >>> >>> my move of the precompiled header broke the project file creation for Visual Studio. Here is a small fix to the problem: >>> >>> 7112308: Fix Visual Studio build for precompiled header >>> http://cr.openjdk.java.net/~rbackman/7112308/ >>> >>> Thanks >>> Rickard From john.cuthbertson at oracle.com Fri Nov 18 10:31:54 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 18 Nov 2011 10:31:54 -0800 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC530D5.9090709@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> <4EC31F62.8080306@oracle.com> <4EC389C7.4050201@oracle.com> <4EC3FF9F.2040407@oracle.com> <4EC50F7F.10402@oracle.com> <4EC530D5.9090709@oracle.com> Message-ID: <4EC6A49A.5030108@oracle.com> Hi Mandy, Yes, thanks, and thanks to everyone. This clarifies what needs to be done. I'll make the change and a modified test case against all the collectors. JohnC On 11/17/11 08:05, Mandy Chung wrote: > > > On 11/17/2011 5:43 AM, Frederic Parain wrote: >> Hi Mandy, >> >> It would have been nice to have notifications providing >> detailed information about CMS different phases, but it >> doesn't seem easy to do right now. I did the experiments >> with CMS using JConsole, and the result is not really >> satisfactory: >> - several notifications are sent for each CMS cycle >> but the notification lacks the information to identify >> the CMS phase associated with the notification (worse >> than that, they all claim they notify the "end of a major >> GC cycle" which is certainly not true for CMS. >> - according to the TraceCMSMemoryManagerStats constructor >> code, some information reported by the notification >> are inaccurate because the stats recorded for the current >> phase are still in _current_gc_stat while the notification >> code is using _last_gc_stat (so basically some notifications >> contain data from the previous GC cycle instead of data >> from the current cycle) > > I suggest to create a CR for this problem and fix it later. >> >> So I agree that moving the pushNotification to inside the "if >> (countCollection)" statement would be a correct fix for CMS. >> >> +1 for the renaming of the 'countCollection' variable. >> > > John - hope this clarifies it. Sending notification only if > countCollection is true would be the right fix. > > Thanks > Mandy > >> Fred >> >> On 11/16/11 7:23 PM, Mandy Chung wrote: >>> John, Frederic, >>> >>> I looked at the implementation and I still think pushNotification >>> should only be called *once* at the end of the GC cycle but not >>> every MemoryManager::gc_end call (might be better to rename >>> gc_end to something else). >>> >>> MemoryManager::gc_end is called at the destructor of >>> TraceMemoryManagerStats and also TraceCMSMemoryManagerStats ( >>> a subclass of TraceMemoryManagerStats). For the stop-the-world >>> collectors, there is a clear begin and end of GC cycle. But >>> for CMS, it has 3 stop-the-world phases. That's the reason why >>> it has a list of flags to specify what to record since at different >>> CMS phase, it will record different stats. At the end of entire >>> CMS cycle, it will increment the collector count and gc end time >>> etc. So the GC notification should be pushed only at the end of >>> one collection cycle (for CMS case - would be SWEEPING phase). >>> >>> Below is the code of the TraceCMSMemoryManagerStats constructor >>> that would make it clear: >>> >>> switch (phase) { >>> case CMSCollector::InitialMarking: >>> initialize(true /* fullGC */ , >>> cause /* cause of the GC */, >>> true /* recordGCBeginTime */, >>> true /* recordPreGCUsage */, >>> false /* recordPeakUsage */, >>> false /* recordPostGCusage */, >>> true /* recordAccumulatedGCTime */, >>> false /* recordGCEndTime */, >>> false /* countCollection */ ); >>> break; >>> >>> case CMSCollector::FinalMarking: >>> initialize(true /* fullGC */ , >>> cause /* cause of the GC */, >>> false /* recordGCBeginTime */, >>> false /* recordPreGCUsage */, >>> false /* recordPeakUsage */, >>> false /* recordPostGCusage */, >>> true /* recordAccumulatedGCTime */, >>> false /* recordGCEndTime */, >>> false /* countCollection */ ); >>> break; >>> >>> case CMSCollector::Sweeping: >>> initialize(true /* fullGC */ , >>> cause /* cause of the GC */, >>> false /* recordGCBeginTime */, >>> false /* recordPreGCUsage */, >>> true /* recordPeakUsage */, >>> true /* recordPostGCusage */, >>> false /* recordAccumulatedGCTime */, >>> true /* recordGCEndTime */, >>> true /* countCollection */ ); >>> break; >>> >>> default: >>> ShouldNotReachHere(); >>> } >>> >>> I believe moving the pushNotification to inside the "if >>> (countCollection)" >>> statement would be a correct fix. It might be better to rename >>> "countCollection" variable to something like "gcCompleted". >>> >>> I suggest to run >>> jdk/test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java >>> >>> >>> >>> on CMS and see how many notifications are sent and what data it >>> includes. You may need to modify it to print any other necessary >>> information. I can help further next week once I finish a few >>> things that I committed to complete this week. >>> >>> Mandy >>> >>> >>> On 11/16/11 2:00 AM, Frederic Parain wrote: >>>> Hi, >>>> >>>> The reason why the memory usage data are bundled with the notification >>>> is to prevent data lost. If the notification doesn't provide the >>>> memory usage data, the client has to perform a getLastGcInfo() call >>>> to retrieve the data each time it receives a notification. But several >>>> GC cycles might occur between the time the notification is received >>>> and >>>> the time getLastGcInfo() is invoked. And there's no API to get memory >>>> usage data older than the one from the last GC cycle. With the >>>> notification including the memory usage data, the client is ensured >>>> to get data for all GC cycles. >>>> >>>> That said, the notification contains two memory usage datasets, one >>>> created at the beginning of the GC cycle and one created at the end >>>> of the cycle. There's no reason to condition the notification to >>>> the recording of the post GC cycle data recording. It's reasonable >>>> to send a notification for a GC which only collects the pre GC data >>>> for instance. So I think it's ok to move the notification code out >>>> of the recordPostGCUsage==true condition as long as the values in >>>> the non recorded memory usage data set can clearly be identified >>>> as being invalid. Right now they are initialized to zero, so it >>>> looks ok to me. >>>> >>>> Moving the notification code after the "if(countCollection)" block >>>> looks good too. >>>> >>>> However, I'm not an official reviewer, so you'll need more approvals >>>> for this changeset. >>>> >>>> Fred >>>> >>>> On 11/16/11 03:26 AM, Mandy Chung wrote: >>>>> I'm including Frederic and serviceability-dev since this is part >>>>> of the >>>>> instrumentation done for serviceability. >>>>> >>>>> On 11/15/2011 4:59 PM, David Holmes wrote: >>>>>> Hi John, >>>>>> >>>>>> On 16/11/2011 3:33 AM, John Cuthbertson wrote: >>>>>>> Thanks for the review. I did and I did that consciously. As you >>>>>>> say - >>>>>>> with the current code the listener would only be notified if the >>>>>>> _recordPostGCUsage field of the TraceMemoryManagerStats object >>>>>>> is true >>>>>>> (which it is by default) and none of the TraceMemoryManagerStats >>>>>>> instances created by the collectors change this. But there's >>>>>>> nothing to >>>>>>> stop a collector creating a TraceMemoryManagerStats object with >>>>>>> _recordPostGCUsage false and_recordGCEndTime true. In this case >>>>>>> wouldn't >>>>>>> we still want to notify the listener? I may be wrong (in which case >>>>>>> I'll >>>>>>> add the extra guard) but I believe that recording (some) data and >>>>>>> notification should be two independent operations. >>>>>> >>>>>> It depends on what data the listener is expecting to receive. If you >>>>>> push the notification when there hasn't been an update does that >>>>>> make >>>>>> sense? I don't know what the spec is for this. >>>>>> >>>>> >>>>> The GC notifier and pushNotification call was added as this >>>>> changeset: >>>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/78542e2b5e35 >>>>> >>>>> The spec for this is: >>>>> http://download.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/GarbageCollectionNotificationInfo.html >>>>> >>>>> >>>>> >>>>> >>>>>> Anyway I just wanted to flag the change in potential behaviour. If >>>>>> no-one from GC has any issue with this then it's fine by me. >>>>>> >>>>> >>>>> I think David is right that it should check >>>>> recordPostGCUsage==true to >>>>> push a notification. The notification is sent with the last GC >>>>> statistics. If my memory serves correctly, if recordPostGCUsage is >>>>> false, it doesn't update the last GC usage but sending a notification >>>>> when recordPostGCUsage is false seems to be incorrect. Also, the >>>>> recording was specifically added for CMS since CMS has separate >>>>> phases >>>>> that it needs to record different things. >>>>> >>>>> Frederic would be the best person to comment on this. Frederic - it >>>>> seems to me that the pushNotification can be moved to the end of >>>>> gc_end >>>>> function but within the if (countCollection) statement. Sorry I don't >>>>> have time to check the details out. It'd be good if you can help. >>>>> >>>>> Thanks >>>>> Mandy >>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> JohnC >>>>>>> >>>>>>> On 11/14/11 22:35, David Holmes wrote: >>>>>>>> Hi John, >>>>>>>> >>>>>>>> On 15/11/2011 4:46 AM, John Cuthbertson wrote: >>>>>>>>> Can I have a couple of volnteers to review the fix for this >>>>>>>>> CR? The >>>>>>>>> webrev can be found at: >>>>>>>>> http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. >>>>>>>> >>>>>>>> In the original code the pushNotification is conditional on >>>>>>>> recordPostGCUsage, but you've removed that guard by moving the >>>>>>>> code. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> The issue here was that the routine >>>>>>>>> GCNotifier::pushNotification(), >>>>>>>>> which uses GC data held in GCMemoryManager::_last_gc_stat, was >>>>>>>>> being >>>>>>>>> called before the values in GCMemoryManager::_last_gc_stat were >>>>>>>>> being >>>>>>>>> populated for the current GC. As a result the JVM could pass >>>>>>>>> uninitialized or stale data to a listener. The fix is to move the >>>>>>>>> call >>>>>>>>> to GCNotifier::pushNotification() after the code that populates >>>>>>>>> GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo >>>>>>>>> constructor to fully initialize instances of that class. >>>>>>>>> >>>>>>>>> Testing: The supplied test case on Windows, a crafted test >>>>>>>>> case on >>>>>>>>> Solaris, and the nsk GC tests. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> JohnC >>>>>>> >>>> >>> >> From john.cuthbertson at oracle.com Fri Nov 18 14:52:50 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 18 Nov 2011 14:52:50 -0800 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC530D5.9090709@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> <4EC31F62.8080306@oracle.com> <4EC389C7.4050201@oracle.com> <4EC3FF9F.2040407@oracle.com> <4EC50F7F.10402@oracle.com> <4EC530D5.9090709@oracle.com> Message-ID: <4EC6E1C2.2090901@oracle.com> Hi Everyone, Here's a new webrev based upon all the feedback: http://cr.openjdk.java.net/~johnc/7110173/webrev.1/ When running the modified test case using CMS with the previous version of the fix the output gave: 11:05:27.719 11:05:27.638 [ name:ParNew, action:end of minor GC, cause:Allocation Failure, id:1, secs:0.004532 ] 11:05:27.743 [ name:ParNew, action:end of minor GC, cause:Allocation Failure, id:2, secs:0.034764 ] 11:05:27.746 [ name:ConcurrentMarkSweep, action:end of major GC, cause:CMS Initial Mark, id:0, secs:0.000000 ] 11:05:27.755 [ name:ConcurrentMarkSweep, action:end of major GC, cause:CMS Final Remark, id:0, secs:0.000000 ] 11:05:27.758 [ name:ConcurrentMarkSweep, action:end of major GC, cause:No GC, id:1, secs:0.065867 ] 11:05:28.000 [GC 17447K->9077K(23492K), 0.0081359 secs] [GC 17328K(23492K), 0.0062915 secs] 11:05:28.020 [ name:ParNew, action:end of minor GC, cause:Allocation Failure, id:3, secs:0.008242 ] 11:05:28.021 [ name:ConcurrentMarkSweep, action:end of major GC, cause:CMS Initial Mark, id:1, secs:0.065867 ] 11:05:29.000 [GC 17417K->9206K(23492K), 0.0158274 secs] 11:05:29.018 [ name:ParNew, action:end of minor GC, cause:Allocation Failure, id:4, secs:0.015948 ] [GC 17437K(23492K), 0.0062690 secs] 11:05:29.129 [ name:ConcurrentMarkSweep, action:end of major GC, cause:CMS Final Remark, id:1, secs:0.065867 ] 11:05:29.147 [ name:ConcurrentMarkSweep, action:end of major GC, cause:No GC, id:2, secs:1.134064 ] 11:05:30.000 With the new fix, this becomes: 11:08:37.066 11:08:36.986 [ name:ParNew, action:end of minor GC, cause:Allocation Failure, id:1, secs:0.004572 ] 11:08:37.089 [ name:ParNew, action:end of minor GC, cause:Allocation Failure, id:2, secs:0.036141 ] 11:08:37.091 [ name:ConcurrentMarkSweep, action:end of major GC, cause:No GC, id:1, secs:0.062465 ] 11:08:38.000 [GC 17432K->8874K(23492K), 0.0115349 secs] [GC 17125K(23492K), 0.0060453 secs] 11:08:38.024 [ name:ParNew, action:end of minor GC, cause:Allocation Failure, id:3, secs:0.011659 ] 11:08:39.000 [GC 17214K->9208K(23492K), 0.0166641 secs] [GC 17439K(23492K), 0.0066408 secs] 11:08:39.028 [ name:ParNew, action:end of minor GC, cause:Allocation Failure, id:4, secs:0.016793 ] 11:08:39.046 [ name:ConcurrentMarkSweep, action:end of major GC, cause:No GC, id:2, secs:1.028856 ] 11:08:40.000 [GC 9305K->681K(23492K), 0.0061482 secs] Thanks for the help. JohnC On 11/17/2011 8:05 AM, Mandy Chung wrote: > > > On 11/17/2011 5:43 AM, Frederic Parain wrote: >> Hi Mandy, >> >> It would have been nice to have notifications providing >> detailed information about CMS different phases, but it >> doesn't seem easy to do right now. I did the experiments >> with CMS using JConsole, and the result is not really >> satisfactory: >> - several notifications are sent for each CMS cycle >> but the notification lacks the information to identify >> the CMS phase associated with the notification (worse >> than that, they all claim they notify the "end of a major >> GC cycle" which is certainly not true for CMS. >> - according to the TraceCMSMemoryManagerStats constructor >> code, some information reported by the notification >> are inaccurate because the stats recorded for the current >> phase are still in _current_gc_stat while the notification >> code is using _last_gc_stat (so basically some notifications >> contain data from the previous GC cycle instead of data >> from the current cycle) > > I suggest to create a CR for this problem and fix it later. >> >> So I agree that moving the pushNotification to inside the "if >> (countCollection)" statement would be a correct fix for CMS. >> >> +1 for the renaming of the 'countCollection' variable. >> > > John - hope this clarifies it. Sending notification only if > countCollection is true would be the right fix. > > Thanks > Mandy > >> Fred >> >> On 11/16/11 7:23 PM, Mandy Chung wrote: >>> John, Frederic, >>> >>> I looked at the implementation and I still think pushNotification >>> should only be called *once* at the end of the GC cycle but not >>> every MemoryManager::gc_end call (might be better to rename >>> gc_end to something else). >>> >>> MemoryManager::gc_end is called at the destructor of >>> TraceMemoryManagerStats and also TraceCMSMemoryManagerStats ( >>> a subclass of TraceMemoryManagerStats). For the stop-the-world >>> collectors, there is a clear begin and end of GC cycle. But >>> for CMS, it has 3 stop-the-world phases. That's the reason why >>> it has a list of flags to specify what to record since at different >>> CMS phase, it will record different stats. At the end of entire >>> CMS cycle, it will increment the collector count and gc end time >>> etc. So the GC notification should be pushed only at the end of >>> one collection cycle (for CMS case - would be SWEEPING phase). >>> >>> Below is the code of the TraceCMSMemoryManagerStats constructor >>> that would make it clear: >>> >>> switch (phase) { >>> case CMSCollector::InitialMarking: >>> initialize(true /* fullGC */ , >>> cause /* cause of the GC */, >>> true /* recordGCBeginTime */, >>> true /* recordPreGCUsage */, >>> false /* recordPeakUsage */, >>> false /* recordPostGCusage */, >>> true /* recordAccumulatedGCTime */, >>> false /* recordGCEndTime */, >>> false /* countCollection */ ); >>> break; >>> >>> case CMSCollector::FinalMarking: >>> initialize(true /* fullGC */ , >>> cause /* cause of the GC */, >>> false /* recordGCBeginTime */, >>> false /* recordPreGCUsage */, >>> false /* recordPeakUsage */, >>> false /* recordPostGCusage */, >>> true /* recordAccumulatedGCTime */, >>> false /* recordGCEndTime */, >>> false /* countCollection */ ); >>> break; >>> >>> case CMSCollector::Sweeping: >>> initialize(true /* fullGC */ , >>> cause /* cause of the GC */, >>> false /* recordGCBeginTime */, >>> false /* recordPreGCUsage */, >>> true /* recordPeakUsage */, >>> true /* recordPostGCusage */, >>> false /* recordAccumulatedGCTime */, >>> true /* recordGCEndTime */, >>> true /* countCollection */ ); >>> break; >>> >>> default: >>> ShouldNotReachHere(); >>> } >>> >>> I believe moving the pushNotification to inside the "if >>> (countCollection)" >>> statement would be a correct fix. It might be better to rename >>> "countCollection" variable to something like "gcCompleted". >>> >>> I suggest to run >>> jdk/test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java >>> >>> >>> >>> on CMS and see how many notifications are sent and what data it >>> includes. You may need to modify it to print any other necessary >>> information. I can help further next week once I finish a few >>> things that I committed to complete this week. >>> >>> Mandy >>> >>> >>> On 11/16/11 2:00 AM, Frederic Parain wrote: >>>> Hi, >>>> >>>> The reason why the memory usage data are bundled with the notification >>>> is to prevent data lost. If the notification doesn't provide the >>>> memory usage data, the client has to perform a getLastGcInfo() call >>>> to retrieve the data each time it receives a notification. But several >>>> GC cycles might occur between the time the notification is received >>>> and >>>> the time getLastGcInfo() is invoked. And there's no API to get memory >>>> usage data older than the one from the last GC cycle. With the >>>> notification including the memory usage data, the client is ensured >>>> to get data for all GC cycles. >>>> >>>> That said, the notification contains two memory usage datasets, one >>>> created at the beginning of the GC cycle and one created at the end >>>> of the cycle. There's no reason to condition the notification to >>>> the recording of the post GC cycle data recording. It's reasonable >>>> to send a notification for a GC which only collects the pre GC data >>>> for instance. So I think it's ok to move the notification code out >>>> of the recordPostGCUsage==true condition as long as the values in >>>> the non recorded memory usage data set can clearly be identified >>>> as being invalid. Right now they are initialized to zero, so it >>>> looks ok to me. >>>> >>>> Moving the notification code after the "if(countCollection)" block >>>> looks good too. >>>> >>>> However, I'm not an official reviewer, so you'll need more approvals >>>> for this changeset. >>>> >>>> Fred >>>> >>>> On 11/16/11 03:26 AM, Mandy Chung wrote: >>>>> I'm including Frederic and serviceability-dev since this is part >>>>> of the >>>>> instrumentation done for serviceability. >>>>> >>>>> On 11/15/2011 4:59 PM, David Holmes wrote: >>>>>> Hi John, >>>>>> >>>>>> On 16/11/2011 3:33 AM, John Cuthbertson wrote: >>>>>>> Thanks for the review. I did and I did that consciously. As you >>>>>>> say - >>>>>>> with the current code the listener would only be notified if the >>>>>>> _recordPostGCUsage field of the TraceMemoryManagerStats object >>>>>>> is true >>>>>>> (which it is by default) and none of the TraceMemoryManagerStats >>>>>>> instances created by the collectors change this. But there's >>>>>>> nothing to >>>>>>> stop a collector creating a TraceMemoryManagerStats object with >>>>>>> _recordPostGCUsage false and_recordGCEndTime true. In this case >>>>>>> wouldn't >>>>>>> we still want to notify the listener? I may be wrong (in which case >>>>>>> I'll >>>>>>> add the extra guard) but I believe that recording (some) data and >>>>>>> notification should be two independent operations. >>>>>> >>>>>> It depends on what data the listener is expecting to receive. If you >>>>>> push the notification when there hasn't been an update does that >>>>>> make >>>>>> sense? I don't know what the spec is for this. >>>>>> >>>>> >>>>> The GC notifier and pushNotification call was added as this >>>>> changeset: >>>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/78542e2b5e35 >>>>> >>>>> The spec for this is: >>>>> http://download.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/GarbageCollectionNotificationInfo.html >>>>> >>>>> >>>>> >>>>> >>>>>> Anyway I just wanted to flag the change in potential behaviour. If >>>>>> no-one from GC has any issue with this then it's fine by me. >>>>>> >>>>> >>>>> I think David is right that it should check >>>>> recordPostGCUsage==true to >>>>> push a notification. The notification is sent with the last GC >>>>> statistics. If my memory serves correctly, if recordPostGCUsage is >>>>> false, it doesn't update the last GC usage but sending a notification >>>>> when recordPostGCUsage is false seems to be incorrect. Also, the >>>>> recording was specifically added for CMS since CMS has separate >>>>> phases >>>>> that it needs to record different things. >>>>> >>>>> Frederic would be the best person to comment on this. Frederic - it >>>>> seems to me that the pushNotification can be moved to the end of >>>>> gc_end >>>>> function but within the if (countCollection) statement. Sorry I don't >>>>> have time to check the details out. It'd be good if you can help. >>>>> >>>>> Thanks >>>>> Mandy >>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> JohnC >>>>>>> >>>>>>> On 11/14/11 22:35, David Holmes wrote: >>>>>>>> Hi John, >>>>>>>> >>>>>>>> On 15/11/2011 4:46 AM, John Cuthbertson wrote: >>>>>>>>> Can I have a couple of volnteers to review the fix for this >>>>>>>>> CR? The >>>>>>>>> webrev can be found at: >>>>>>>>> http://cr.openjdk.java.net/~johnc/7110173/webrev.0/. >>>>>>>> >>>>>>>> In the original code the pushNotification is conditional on >>>>>>>> recordPostGCUsage, but you've removed that guard by moving the >>>>>>>> code. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> The issue here was that the routine >>>>>>>>> GCNotifier::pushNotification(), >>>>>>>>> which uses GC data held in GCMemoryManager::_last_gc_stat, was >>>>>>>>> being >>>>>>>>> called before the values in GCMemoryManager::_last_gc_stat were >>>>>>>>> being >>>>>>>>> populated for the current GC. As a result the JVM could pass >>>>>>>>> uninitialized or stale data to a listener. The fix is to move the >>>>>>>>> call >>>>>>>>> to GCNotifier::pushNotification() after the code that populates >>>>>>>>> GCMemoryManager::_last_gc_stat. I also modified the GCStatInfo >>>>>>>>> constructor to fully initialize instances of that class. >>>>>>>>> >>>>>>>>> Testing: The supplied test case on Windows, a crafted test >>>>>>>>> case on >>>>>>>>> Solaris, and the nsk GC tests. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> JohnC >>>>>>> >>>> >>> >> From mandy.chung at oracle.com Fri Nov 18 15:38:00 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Nov 2011 15:38:00 -0800 Subject: RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data. In-Reply-To: <4EC6E1C2.2090901@oracle.com> References: <4EC16215.3080107@oracle.com> <4EC20819.1060906@oracle.com> <4EC2A263.1060803@oracle.com> <4EC30AE2.9050805@oracle.com> <4EC31F62.8080306@oracle.com> <4EC389C7.4050201@oracle.com> <4EC3FF9F.2040407@oracle.com> <4EC50F7F.10402@oracle.com> <4EC530D5.9090709@oracle.com> <4EC6E1C2.2090901@oracle.com> Message-ID: <4EC6EC58.4060304@oracle.com> On 11/18/2011 2:52 PM, John Cuthbertson wrote: > Here's a new webrev based upon all the feedback: > > http://cr.openjdk.java.net/~johnc/7110173/webrev.1/ Thanks John. Looks good. Mandy From coleen.phillimore at oracle.com Fri Nov 18 19:28:01 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Sat, 19 Nov 2011 03:28:01 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 11 new changesets Message-ID: <20111119032824.E42EE473EA@hg.openjdk.java.net> Changeset: 5a5ed80bea5b Author: ysr Date: 2011-10-26 21:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5a5ed80bea5b 7105163: CMS: some mentions of MinChunkSize should be IndexSetStart Summary: Fixed the instances that were missed in the changeset for 7099817. Reviewed-by: stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp Changeset: 59519b7d7b9d Author: tonyp Date: 2011-10-28 13:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/59519b7d7b9d Merge Changeset: 6fd81579526f Author: brutisso Date: 2011-10-31 08:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6fd81579526f 7102044: G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise Summary: arrayOopDesc::max_array_length() should return a value that does not overflow a size_t if it is converted to bytes. Reviewed-by: kvn, dholmes ! make/jprt.properties ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! test/Makefile Changeset: ed80554efa25 Author: brutisso Date: 2011-11-02 08:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ed80554efa25 7106751: G1: gc/gctests/nativeGC03 crashes VM with SIGSEGV Summary: _cset_rs_update_cl[] was indexed with values beyond what it is set up to handle. Reviewed-by: ysr, jmasa, johnc ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 8aae2050e83e Author: tonyp Date: 2011-11-07 22:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8aae2050e83e 7092309: G1: introduce old region set Summary: Keep track of all the old regions in the heap with a heap region set. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 53074c2c4600 Author: tonyp Date: 2011-11-08 00:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/53074c2c4600 7099849: G1: include heap region information in hs_err files Reviewed-by: johnc, brutisso, poonam ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/utilities/vmError.cpp Changeset: ab5107bee78c Author: brutisso Date: 2011-11-09 23:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ab5107bee78c 7110190: GCCause::to_string missing case for _adaptive_size_policy Summary: Added case for _adaptive_size_policy Reviewed-by: johnc, ysr ! src/share/vm/gc_interface/gcCause.cpp Changeset: aa4c21b00f7f Author: brutisso Date: 2011-11-15 20:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aa4c21b00f7f 7110152: assert(size_in_words <= (julong)max_jint) failed: no overflow Summary: Reduce what arrayOopDesc::max_array_length() returns to avoid int overflow Reviewed-by: kvn, dholmes, tonyp ! src/share/vm/oops/arrayOop.hpp Changeset: 2ceafe3ceb65 Author: poonam Date: 2011-11-16 16:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2ceafe3ceb65 7110428: Crash during HeapDump operation Reviewed-by: ysr, dholmes ! src/share/vm/services/heapDumper.cpp Changeset: b1754f3fbbd8 Author: tonyp Date: 2011-11-17 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b1754f3fbbd8 Merge Changeset: 002cb3fc8256 Author: coleenp Date: 2011-11-18 17:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/002cb3fc8256 Merge From bengt.rutisson at oracle.com Mon Nov 21 05:17:56 2011 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 21 Nov 2011 13:17:56 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7112308: Fix Visual Studio build for precompiled header Message-ID: <20111121131801.09BB54740F@hg.openjdk.java.net> Changeset: c17bc65648de Author: brutisso Date: 2011-11-21 08:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c17bc65648de 7112308: Fix Visual Studio build for precompiled header Summary: Add the new path to precompiled.hpp in the project make file Reviewed-by: coleenp, dholmes, brutisso Contributed-by: rbackman ! make/windows/makefiles/projectcreator.make From bengt.rutisson at oracle.com Mon Nov 21 05:25:42 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 21 Nov 2011 14:25:42 +0100 Subject: Request for review: 7112308 Fix Visual Studio build for precompiled header In-Reply-To: <4EC67051.3000105@oracle.com> References: <4EC52298.8070208@oracle.com> <4EC6148A.5060506@oracle.com> <28592A1F-9F7E-4F3C-8B31-B7610E3B6766@oracle.com> <4EC67051.3000105@oracle.com> Message-ID: <4ECA5156.2010404@oracle.com> On 2011-11-18 15:48, Daniel D. Daugherty wrote: > I think this is one of the few cases where a push to Main_Baseline > would be warranted. Particularly since more folks are starting to > use Visual Studio (again...) Good point, Dan. I was not really sure what kind of approval I needed to push directly to hotspot-main. So, finally I decided on pushing this fix to hotspot-rt in the hope that it will be integrated up to hotspot-main tomorrow. I *think* that the runtime team normally integrates on Tuesdays. In that case I can pull it down into hotspot-gc on Wednesday. Thanks, Bengt > > Dan > > > >> Thanks for the review Bengt, >> feel free to push it for me as I don't have the right role to do so. >> >> On Nov 18, 2011, at 9:17 AM, Bengt Rutisson wrote: >> >>> Rickard, >>> >>> Thanks for finding this! Your fix looks good. Just verified a Visual >>> Studio build with your changes applied. Works fine. >> I'll give credit to Karen who filed the bug. >> >>> >>> I assume you need this in hotspot-rt as soon as possible. But I >>> anyway just want to ask if there is any chance of pushing this >>> through hotspot-gc instead? >>> >>> Tony integrated hotspot-gc and hotspot-main yesterday. That >>> integration brought your original precompiled.hpp change over to >>> hotspot-gc. So, up until now I have not had any problems with my VS >>> projects. Now I guess they will be broken until your new change has >>> propagated from hotspot-rt to hotspot-gc... >>> >>> But if you need it in hotspot-rt you will have the same issue. So >>> there is really no good solution. Just thought I'd ask. >>> >>> Bengt >>> >>> >>> On 2011-11-17 16:04, Rickard B?ckman wrote: >>>> Hi All, >>>> >>>> my move of the precompiled header broke the project file creation >>>> for Visual Studio. Here is a small fix to the problem: >>>> >>>> 7112308: Fix Visual Studio build for precompiled header >>>> http://cr.openjdk.java.net/~rbackman/7112308/ >>>> >>>> Thanks >>>> Rickard From john.coomes at oracle.com Thu Nov 24 20:43:33 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:43:33 +0000 Subject: hg: hsx/hotspot-emb: 8 new changesets Message-ID: <20111125044333.E117F4744A@hg.openjdk.java.net> Changeset: 26fb81a1e9ce Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/26fb81a1e9ce Added tag jdk8-b12 for changeset 8e2104d565ba ! .hgtags Changeset: 8da26d5c32a7 Author: katleman Date: 2011-11-10 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/8da26d5c32a7 Added tag jdk8-b13 for changeset 26fb81a1e9ce ! .hgtags Changeset: a62a0f35eb9c Author: asaha Date: 2011-06-27 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/a62a0f35eb9c Merge Changeset: f9b3e6b2aa2c Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/f9b3e6b2aa2c Merge Changeset: ea2ab83ce564 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/ea2ab83ce564 Merge Changeset: 8f525559ae73 Author: asaha Date: 2011-11-07 21:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/8f525559ae73 Merge Changeset: 23aa7f2c80a2 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/23aa7f2c80a2 Merge Changeset: a4f28069d44a Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/a4f28069d44a Added tag jdk8-b14 for changeset 23aa7f2c80a2 ! .hgtags From john.coomes at oracle.com Thu Nov 24 20:43:43 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:43:43 +0000 Subject: hg: hsx/hotspot-emb/corba: 9 new changesets Message-ID: <20111125044350.856DA4744B@hg.openjdk.java.net> Changeset: 5b9d9b839d3d Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/5b9d9b839d3d Added tag jdk8-b12 for changeset 31d70911b712 ! .hgtags Changeset: 6f601a737e0f Author: katleman Date: 2011-11-10 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/6f601a737e0f Added tag jdk8-b13 for changeset 5b9d9b839d3d ! .hgtags Changeset: d84682019b5f Author: asaha Date: 2011-06-27 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/d84682019b5f Merge Changeset: 9c20c1e7cdd9 Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/9c20c1e7cdd9 Merge Changeset: cb5aec0570a5 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/cb5aec0570a5 Merge Changeset: 21369018a679 Author: mbankal Date: 2011-08-09 05:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/21369018a679 7055902: Oracle Java IIOP Deserialization Type Confusion Remote Code Execution Vulnerability Reviewed-by: coffeys ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: 058c18d237a9 Author: asaha Date: 2011-11-07 21:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/058c18d237a9 Merge Changeset: e59c47de1ad8 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/e59c47de1ad8 Merge Changeset: 99925e8d1b86 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/99925e8d1b86 Added tag jdk8-b14 for changeset e59c47de1ad8 ! .hgtags From john.coomes at oracle.com Thu Nov 24 20:43:59 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:43:59 +0000 Subject: hg: hsx/hotspot-emb/jaxp: 8 new changesets Message-ID: <20111125044359.C47694744C@hg.openjdk.java.net> Changeset: bcc739229f63 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/bcc739229f63 Added tag jdk8-b12 for changeset ca977d167697 ! .hgtags Changeset: e7172d80a8f4 Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/e7172d80a8f4 Added tag jdk8-b13 for changeset bcc739229f63 ! .hgtags Changeset: 7adf14d6060c Author: asaha Date: 2011-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/7adf14d6060c Merge Changeset: d239aa024b6e Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/d239aa024b6e Merge Changeset: eca33f89c823 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/eca33f89c823 Merge Changeset: 0ed9ae36ee2a Author: asaha Date: 2011-11-07 21:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/0ed9ae36ee2a Merge Changeset: 9d0c9d638757 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/9d0c9d638757 Merge Changeset: 804f666d6d44 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/804f666d6d44 Added tag jdk8-b14 for changeset 9d0c9d638757 ! .hgtags From john.coomes at oracle.com Thu Nov 24 20:44:09 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:44:09 +0000 Subject: hg: hsx/hotspot-emb/jaxws: 10 new changesets Message-ID: <20111125044409.8F7804744D@hg.openjdk.java.net> Changeset: adf2a6b5fde1 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/adf2a6b5fde1 Added tag jdk8-b12 for changeset e6eed2ff5d5f ! .hgtags Changeset: f502a343a92e Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/f502a343a92e Added tag jdk8-b13 for changeset adf2a6b5fde1 ! .hgtags Changeset: 75a652e72489 Author: asaha Date: 2011-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/75a652e72489 Merge Changeset: b058cae6fd3b Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/b058cae6fd3b Merge Changeset: 61c046c6895a Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/61c046c6895a Merge Changeset: 9e82b46cd4fa Author: asaha Date: 2011-07-25 11:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/9e82b46cd4fa 7046794: Configurable behavior for server-side stacktraces Reviewed-by: ramap ! jaxws.properties Changeset: c78fccb01d4e Author: asaha Date: 2011-11-07 21:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/c78fccb01d4e Merge Changeset: cae6db74d6af Author: asaha Date: 2011-11-10 13:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/cae6db74d6af 7110676: Update jaf source download url for jaxws Reviewed-by: ramap ! jaxws.properties Changeset: 54c4bf4b83ec Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/54c4bf4b83ec Merge Changeset: c9ab96ff23d5 Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/c9ab96ff23d5 Added tag jdk8-b14 for changeset 54c4bf4b83ec ! .hgtags From john.coomes at oracle.com Thu Nov 24 20:54:42 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:54:42 +0000 Subject: hg: hsx/hotspot-rt: 8 new changesets Message-ID: <20111125045442.7EC1247452@hg.openjdk.java.net> Changeset: 26fb81a1e9ce Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/26fb81a1e9ce Added tag jdk8-b12 for changeset 8e2104d565ba ! .hgtags Changeset: 8da26d5c32a7 Author: katleman Date: 2011-11-10 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/8da26d5c32a7 Added tag jdk8-b13 for changeset 26fb81a1e9ce ! .hgtags Changeset: a62a0f35eb9c Author: asaha Date: 2011-06-27 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/a62a0f35eb9c Merge Changeset: f9b3e6b2aa2c Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/f9b3e6b2aa2c Merge Changeset: ea2ab83ce564 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/ea2ab83ce564 Merge Changeset: 8f525559ae73 Author: asaha Date: 2011-11-07 21:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/8f525559ae73 Merge Changeset: 23aa7f2c80a2 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/23aa7f2c80a2 Merge Changeset: a4f28069d44a Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/a4f28069d44a Added tag jdk8-b14 for changeset 23aa7f2c80a2 ! .hgtags From john.coomes at oracle.com Thu Nov 24 20:55:17 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:55:17 +0000 Subject: hg: hsx/hotspot-rt/jaxp: 8 new changesets Message-ID: <20111125045518.1C75847455@hg.openjdk.java.net> Changeset: bcc739229f63 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/bcc739229f63 Added tag jdk8-b12 for changeset ca977d167697 ! .hgtags Changeset: e7172d80a8f4 Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/e7172d80a8f4 Added tag jdk8-b13 for changeset bcc739229f63 ! .hgtags Changeset: 7adf14d6060c Author: asaha Date: 2011-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/7adf14d6060c Merge Changeset: d239aa024b6e Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/d239aa024b6e Merge Changeset: eca33f89c823 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/eca33f89c823 Merge Changeset: 0ed9ae36ee2a Author: asaha Date: 2011-11-07 21:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/0ed9ae36ee2a Merge Changeset: 9d0c9d638757 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/9d0c9d638757 Merge Changeset: 804f666d6d44 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/804f666d6d44 Added tag jdk8-b14 for changeset 9d0c9d638757 ! .hgtags From john.coomes at oracle.com Thu Nov 24 20:55:28 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:55:28 +0000 Subject: hg: hsx/hotspot-rt/jaxws: 10 new changesets Message-ID: <20111125045528.9A03D47456@hg.openjdk.java.net> Changeset: adf2a6b5fde1 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/adf2a6b5fde1 Added tag jdk8-b12 for changeset e6eed2ff5d5f ! .hgtags Changeset: f502a343a92e Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/f502a343a92e Added tag jdk8-b13 for changeset adf2a6b5fde1 ! .hgtags Changeset: 75a652e72489 Author: asaha Date: 2011-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/75a652e72489 Merge Changeset: b058cae6fd3b Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/b058cae6fd3b Merge Changeset: 61c046c6895a Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/61c046c6895a Merge Changeset: 9e82b46cd4fa Author: asaha Date: 2011-07-25 11:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/9e82b46cd4fa 7046794: Configurable behavior for server-side stacktraces Reviewed-by: ramap ! jaxws.properties Changeset: c78fccb01d4e Author: asaha Date: 2011-11-07 21:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/c78fccb01d4e Merge Changeset: cae6db74d6af Author: asaha Date: 2011-11-10 13:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/cae6db74d6af 7110676: Update jaf source download url for jaxws Reviewed-by: ramap ! jaxws.properties Changeset: 54c4bf4b83ec Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/54c4bf4b83ec Merge Changeset: c9ab96ff23d5 Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/c9ab96ff23d5 Added tag jdk8-b14 for changeset 54c4bf4b83ec ! .hgtags From john.coomes at oracle.com Thu Nov 24 20:54:53 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:54:53 +0000 Subject: hg: hsx/hotspot-rt/corba: 9 new changesets Message-ID: <20111125045506.2A4A247453@hg.openjdk.java.net> Changeset: 5b9d9b839d3d Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/5b9d9b839d3d Added tag jdk8-b12 for changeset 31d70911b712 ! .hgtags Changeset: 6f601a737e0f Author: katleman Date: 2011-11-10 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/6f601a737e0f Added tag jdk8-b13 for changeset 5b9d9b839d3d ! .hgtags Changeset: d84682019b5f Author: asaha Date: 2011-06-27 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/d84682019b5f Merge Changeset: 9c20c1e7cdd9 Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/9c20c1e7cdd9 Merge Changeset: cb5aec0570a5 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/cb5aec0570a5 Merge Changeset: 21369018a679 Author: mbankal Date: 2011-08-09 05:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/21369018a679 7055902: Oracle Java IIOP Deserialization Type Confusion Remote Code Execution Vulnerability Reviewed-by: coffeys ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: 058c18d237a9 Author: asaha Date: 2011-11-07 21:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/058c18d237a9 Merge Changeset: e59c47de1ad8 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/e59c47de1ad8 Merge Changeset: 99925e8d1b86 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/99925e8d1b86 Added tag jdk8-b14 for changeset e59c47de1ad8 ! .hgtags From john.coomes at oracle.com Thu Nov 24 20:59:21 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:59:21 +0000 Subject: hg: hsx/hotspot-rt/jdk: 94 new changesets Message-ID: <20111125052723.9FA264745B@hg.openjdk.java.net> Changeset: 7746eb8c610b Author: bae Date: 2011-10-17 15:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7746eb8c610b 6997116: The case automatically failed due to java.lang.ClassCastException. Reviewed-by: jgodinez, prr ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java + test/sun/java2d/DirectX/DrawBitmaskToSurfaceTest.java Changeset: a7a001378444 Author: jgodinez Date: 2011-10-24 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a7a001378444 6604109: javax.print.PrintServiceLookup.lookupPrintServices fails SOMETIMES for Cups Reviewed-by: bae, prr ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: 8f9b0629d088 Author: lana Date: 2011-10-25 21:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8f9b0629d088 Merge Changeset: 2b27e14a4c82 Author: vinnie Date: 2011-10-13 12:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2b27e14a4c82 7099228: Use a PKCS11 config attribute to control encoding of an EC point Reviewed-by: valeriep, mullan ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! test/ProblemList.txt Changeset: 01615d3e74ed Author: mullan Date: 2011-10-13 13:50 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/01615d3e74ed 6953295: Move few sun.security.{util, x509, pkcs} classes used by keytool/jarsigner to another package Reviewed-by: mchung ! make/sun/security/other/Makefile - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java + src/share/classes/sun/security/pkcs10/PKCS10.java + src/share/classes/sun/security/pkcs10/PKCS10Attribute.java + src/share/classes/sun/security/pkcs10/PKCS10Attributes.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java + src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStore.java + src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStoreHelper.java + src/share/classes/sun/security/tools/CertAndKeyGen.java ! src/share/classes/sun/security/tools/KeyTool.java + src/share/classes/sun/security/tools/PathList.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 04ecbd2bcf5a Author: mullan Date: 2011-10-13 13:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/04ecbd2bcf5a Merge Changeset: 6cb07b35acf5 Author: weijun Date: 2011-10-17 17:11 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6cb07b35acf5 7099399: cannot deal with CRL file larger than 16MB Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/provider/X509Factory.java + test/sun/security/provider/X509Factory/BigCRL.java Changeset: 9bf526cc4046 Author: mullan Date: 2011-10-18 10:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9bf526cc4046 7092897: sun.security.util.Cache should be generified Reviewed-by: xuelei ! src/share/classes/sun/security/pkcs11/KeyCache.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/X509CertificatePair.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/util/Cache.java Changeset: f566cd364a90 Author: mullan Date: 2011-10-18 10:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f566cd364a90 Merge ! src/share/classes/sun/security/provider/X509Factory.java Changeset: 8640b7185be1 Author: wetmore Date: 2011-10-18 11:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8640b7185be1 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine Reviewed-by: xuelei, weijun, asaha ! src/share/classes/sun/security/ssl/CipherBox.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java Changeset: 57eb9136b73b Author: mullan Date: 2011-10-19 10:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/57eb9136b73b 7102686: Restructure timestamp code so that jars and modules can more easily share the same code Reviewed-by: mchung ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/timestamp/HttpTimestamper.java ! src/share/classes/sun/security/timestamp/TSRequest.java ! src/share/classes/sun/security/timestamp/TSResponse.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/TimestampedSigner.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java Changeset: 15078025eed9 Author: mullan Date: 2011-10-19 10:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/15078025eed9 Merge Changeset: c5c91589b126 Author: mduigou Date: 2011-10-19 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c5c91589b126 5029031: Add Collections.checkedQueue() Reviewed-by: mduigou Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/CheckedQueue.java Changeset: 634cd6f050ba Author: chegar Date: 2011-10-20 09:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/634cd6f050ba 7102704: test/java/net/DatagramSocket/ChangingAddress.java failing Reviewed-by: chegar Contributed-by: kurchi.subhra.hazra at oracle.com - test/java/net/DatagramSocket/ChangingAddress.java Changeset: 2d89c3f74aa5 Author: michaelm Date: 2011-10-20 09:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2d89c3f74aa5 7102665: Move tests to Problemlist Reviewed-by: chegar, alanb ! test/ProblemList.txt Changeset: 52c2dd336207 Author: michaelm Date: 2011-10-20 09:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/52c2dd336207 Merge - test/java/net/DatagramSocket/ChangingAddress.java Changeset: c3da0672a882 Author: ngmr Date: 2011-10-13 12:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c3da0672a882 7100054: (porting) Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Summary: Use POSIX defined includes for unistd.h and fcntl.h Reviewed-by: dholmes, alanb, chegar, ngmr Contributed-by: Charles Lee ! src/solaris/native/sun/nio/fs/genSolarisConstants.c ! src/solaris/native/sun/nio/fs/genUnixConstants.c Changeset: d979afceb792 Author: peytoia Date: 2011-10-21 15:56 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d979afceb792 7103108: (tz) Support tzdata2011l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: db9e246c651e Author: peytoia Date: 2011-10-21 18:01 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/db9e246c651e 7103405: Correct display names for Pacific/Apia timezone Reviewed-by: okutsu ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 3f391e649ccb Author: chegar Date: 2011-10-24 20:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3f391e649ccb 7104209: Cleanup and remove librmi (native library) Reviewed-by: mduigou, alanb ! make/java/java/mapfile-vers ! make/sun/rmi/rmi/Makefile - make/sun/rmi/rmi/mapfile-vers ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/native/java/io/ObjectInputStream.c ! src/share/native/sun/misc/VM.c - src/share/native/sun/rmi/server/MarshalInputStream.c Changeset: b375523d6037 Author: chegar Date: 2011-10-24 21:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b375523d6037 7103549: Remove dependencies on libjava and libjvm from security libraries Reviewed-by: vinnie, ohair, alanb, dholmes ! make/com/sun/security/auth/module/Makefile ! make/common/Defs.gmk ! make/common/Library.gmk ! make/sun/security/ec/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/security/smartcardio/Makefile ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c ! src/windows/native/sun/security/pkcs11/j2secmod_md.c Changeset: 72666cd49ac3 Author: alanb Date: 2011-10-25 09:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/72666cd49ac3 7104577: Changes for 7104209 cause many RMI tests to fail Reviewed-by: chegar ! src/share/classes/sun/rmi/server/MarshalInputStream.java Changeset: 7814800c64bd Author: lana Date: 2011-10-25 21:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7814800c64bd Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 09fd2067f715 Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/09fd2067f715 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: d636e737c478 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d636e737c478 Added tag jdk8-b12 for changeset 09fd2067f715 ! .hgtags Changeset: bfd720647db2 Author: yhuang Date: 2011-10-31 20:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bfd720647db2 7077119: remove past transition dates from CurrencyData.properties file Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! test/java/util/Currency/CurrencyTest.java ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt Changeset: cfc6fd491b97 Author: yhuang Date: 2011-10-31 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cfc6fd491b97 6755060: Collator.compare() does not compare correctly for the Thai locale Reviewed-by: naoto ! src/share/classes/sun/text/resources/CollationData_th.java + test/sun/text/resources/Collator/Bug6755060.java Changeset: 0549410acf26 Author: yhuang Date: 2011-10-31 21:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0549410acf26 Merge Changeset: f3227efde13d Author: yhuang Date: 2011-10-31 21:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f3227efde13d 7101495: In Latvia first day of week is Monday Reviewed-by: naoto, peytoia ! src/share/classes/sun/util/resources/CalendarData_lv.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: ab837acc60fb Author: yhuang Date: 2011-10-31 21:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ab837acc60fb Merge Changeset: 631ee738378a Author: mfang Date: 2011-11-03 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/631ee738378a Merge Changeset: 94e5604022fa Author: ngmr Date: 2011-09-15 19:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/94e5604022fa 6988099: jvmti demos missing Publisher (COMPANY resource) in dlls/exes on windows Summary: Add creation/linking of resource data to link step for demos on Windows Reviewed-by: dcubed, zgu, ngmr, ohair Contributed-by: Sean Chou ! make/common/Demo.gmk Changeset: 5791714b9472 Author: ohair Date: 2011-11-04 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5791714b9472 Merge Changeset: 4cb2e8679b27 Author: katleman Date: 2011-11-09 13:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4cb2e8679b27 Merge Changeset: 52bd7fc8fcb0 Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/52bd7fc8fcb0 Added tag jdk8-b13 for changeset 4cb2e8679b27 ! .hgtags Changeset: 9de1dbf8c9be Author: lana Date: 2011-10-26 17:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9de1dbf8c9be Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: 76defa20906a Author: ngmr Date: 2011-09-23 15:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/76defa20906a 7105640: Unix printing does not check the result of exec'd lpr/lp command Summary: Add checking, exception for spool process failure Reviewed-by: prr, jgodinez Contributed-by: Neil Richards ! src/share/classes/sun/print/PSPrinterJob.java ! src/solaris/classes/sun/print/UnixPrintJob.java Changeset: 4544585a3cea Author: lana Date: 2011-11-05 14:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4544585a3cea Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: aa3f5117c485 Author: rupashka Date: 2011-10-17 15:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/aa3f5117c485 7099251: javax.swing.text.html.HTMLDocument.insertAfterStart(null, something) throws NPE Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 4f74e3fdf86b Author: rupashka Date: 2011-10-17 16:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4f74e3fdf86b 7100004: javax.swing.JTable.setAutoCreateRowSorter(boolean autoCreateRowSorter) should mention default value Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/javax/swing/JTable.java Changeset: f1dbc62c7c6d Author: rupashka Date: 2011-10-17 17:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f1dbc62c7c6d 7077293: javax/swing/JComponent/4337267/bug4337267.java failed on windows 2003 Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: a2f5d7049258 Author: dbuck Date: 2011-10-17 19:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a2f5d7049258 6887286: StackOverflowError at sun.awt.image.ImageWatched$WeakLink.isWatcher Summary: Fixed OffScreenImageSource to call imageComplete() with SINGLEFAMEDONE, not STATICIMAGEDONE. This fixed memory leak (that caused SOFE when we use recursion to iterate over linked list). Reviewed-by: bae ! src/share/classes/sun/awt/image/OffScreenImageSource.java Changeset: 7636a62aba7e Author: anthony Date: 2011-11-01 18:01 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7636a62aba7e 7104625: sun.awt.X11.XEvent is creating 600 MB of char[] for no good reason Summary: Wrap logging calls with if(){} statements Reviewed-by: anthony, son Contributed-by: Federico Tello Gentile ! src/solaris/classes/sun/awt/X11/XComponentPeer.java Changeset: ac55f169fadd Author: anthony Date: 2011-11-01 18:03 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ac55f169fadd 7105529: XAWT: Optimize getFieldsAsString() methods generated by WrapperGenerator Summary: Replace string concatenation with StringBuilder.append() Reviewed-by: anthony, son Contributed-by: Federico Tello Gentile ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java Changeset: 41610a897379 Author: rupashka Date: 2011-11-02 14:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/41610a897379 6624077: Regression test fails: closed/javax/swing/ToolTipManager/6256140/bug6256140.java Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/ToolTipManager/Test6256140.java Changeset: 8068f1584715 Author: mrkam Date: 2011-11-02 17:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8068f1584715 7074853: TransparentRuler demos Readme should mention the correct jar file name Reviewed-by: rupashka ! src/share/demo/jfc/TransparentRuler/README.txt Changeset: 323f6d046cc9 Author: rupashka Date: 2011-11-02 23:53 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/323f6d046cc9 7049024: DnD fails with JTextArea and JTextField Reviewed-by: rupashka Contributed-by: Sean Chou ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/JTextArea/7049024/bug7049024.java Changeset: 7c29751a9331 Author: rupashka Date: 2011-11-03 14:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7c29751a9331 6955919: Intermittent ClassCastException in bug4492274 test Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JEditorPane/4492274/bug4492274.java + test/javax/swing/JEditorPane/4492274/test.html Changeset: 1c0624d9a2b6 Author: ngmr Date: 2011-10-13 13:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1c0624d9a2b6 7107957: AWT: Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Summary: Use POSIX defined includes for unistd.h and fcntl.h Reviewed-by: anthony, ngmr Contributed-by: Charles Lee ! src/solaris/native/sun/awt/splashscreen/splashscreen_config.h Changeset: adb31ff942ef Author: rupashka Date: 2011-11-07 16:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/adb31ff942ef 7080203: JTree.getSelectionPaths() now returns empty array instead of null Reviewed-by: malenkov ! src/share/classes/javax/swing/JTree.java Changeset: d219e0b11327 Author: lana Date: 2011-11-07 10:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d219e0b11327 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: f8a3dff76b48 Author: rupashka Date: 2011-11-08 14:36 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f8a3dff76b48 7107585: Test incorrect calculate position of object on frame Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JSlider/6348946/bug6348946.java Changeset: af4fb33fca29 Author: lana Date: 2011-11-08 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/af4fb33fca29 Merge Changeset: 88a260444e4d Author: chegar Date: 2011-10-26 13:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/88a260444e4d 7104650: rawtype warnings in several net, nio and security source files Summary: Also reviewed by Ulf.Zibis at gmx.de Reviewed-by: mcimadamore, alanb, dholmes ! make/sun/net/Makefile ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/security/Security.java ! src/share/classes/sun/nio/ch/Util.java Changeset: 0d371f2911a1 Author: peytoia Date: 2011-10-26 22:16 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0d371f2911a1 7090046: Lots of invalid link in java.text.BreakIterator comments Reviewed-by: okutsu ! src/share/classes/java/text/BreakIterator.java Changeset: 291b55aa9b1e Author: lana Date: 2011-10-25 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/291b55aa9b1e Merge - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 64faf533b99d Author: lana Date: 2011-10-26 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/64faf533b99d Merge Changeset: 449113aea001 Author: weijun Date: 2011-10-27 17:23 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/449113aea001 7104161: test/sun/tools/jinfo/Basic.sh fails on Ubuntu Reviewed-by: alanb ! test/sun/tools/jinfo/Basic.sh Changeset: 64ccf18bbad5 Author: coffeys Date: 2011-10-27 10:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/64ccf18bbad5 7099658: Properties.loadFromXML fails with ClassCastException Reviewed-by: alanb, mchung ! src/share/classes/sun/util/xml/XMLUtils.java Changeset: 56cc907fc8dc Author: mullan Date: 2011-10-27 10:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/56cc907fc8dc 7094155: JSR105 code throws javax.xml.crypto.URIReferenceException when running into Java 7 VM Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! test/javax/xml/crypto/dsig/GenerationTests.java Changeset: 8cd2e3b8127a Author: mullan Date: 2011-10-27 11:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8cd2e3b8127a Merge - make/sun/rmi/rmi/mapfile-vers - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c Changeset: 6e59c482e9b8 Author: xuelei Date: 2011-10-28 07:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6e59c482e9b8 7105940: Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore Reviewed-by: weijun ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java Changeset: bb2b9a8b6e77 Author: alanb Date: 2011-10-30 14:53 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bb2b9a8b6e77 7103889: (fs) Reduce String concatenation when iterating over directory Reviewed-by: alanb Contributed-by: mike.skells at talk21.com ! src/share/classes/java/nio/file/Files.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsPathParser.java Changeset: 30900a1a9cfc Author: xuelei Date: 2011-10-30 20:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/30900a1a9cfc 7106277: Brokenness in the seqNumberOverflow of MAC Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/MAC.java Changeset: 8681362a2f04 Author: wetmore Date: 2011-10-31 11:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8681362a2f04 7105780: Add SSLSocket client/SSLEngine server to templates directory Reviewed-by: xuelei + test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: b60e88ef5d8d Author: wetmore Date: 2011-10-31 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b60e88ef5d8d 7053252: New regression test does not compile on windows-amd64 Reviewed-by: valeriep ! test/ProblemList.txt ! test/sun/security/pkcs11/Provider/Absolute.java Changeset: 5f2838744544 Author: ysr Date: 2011-10-31 17:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5f2838744544 4243978: (ref) Race condition in Reference.enqueue() 4268317: (ref) Reference.isEnqueued() can return true when instance not enqueued Summary: The reference handler now declares, and assumes, that the discovered field, rather than the next field, is (to be) used to link the entries in the pending list, thus allowing a reference object to be safely enqueued even while it is in the pending state. Also added slightly modified regression tests from the two bug reports. Reviewed-by: mchung, alanb, jcoomes ! src/share/classes/java/lang/ref/Reference.java ! src/share/javavm/export/jvm.h ! src/share/native/common/jdk_util.c + test/java/lang/ref/ReferenceEnqueue.java + test/java/lang/ref/ReferenceEnqueuePending.java Changeset: 2f2f56ac8b82 Author: mduigou Date: 2011-11-03 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2f2f56ac8b82 4533691: Add Collections.emptySortedSet() Reviewed-by: mduigou, alanb, dholmes Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/EmptySortedSet.java Changeset: ead9dabe8c75 Author: lana Date: 2011-11-05 00:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ead9dabe8c75 Merge Changeset: 417d91754849 Author: sherman Date: 2011-11-07 13:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/417d91754849 7096080: UTF8 update and new CESU-8 charset 7082884: Incorrect UTF8 conversion for sequence ED 31 7082883: Incorrect UTF8 conversion for sequence fc 80 80 8f bf bf Summary: Updated UTF8 and added CESU-8 to following the latest Standard Reviewed-by: alanb ! make/java/nio/FILES_java.gmk + src/share/classes/sun/nio/cs/CESU_8.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/standard-charsets ! test/java/nio/charset/coders/Errors.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/TestStringCodingUTF8.java ! test/sun/nio/cs/TestUTF8.java Changeset: 0bb498332894 Author: lana Date: 2011-11-08 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0bb498332894 Merge Changeset: 51db54a3b953 Author: lana Date: 2011-11-14 18:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/51db54a3b953 Merge Changeset: 3b2128c89361 Author: alanb Date: 2011-06-15 14:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3b2128c89361 7000600: InputStream.skip() makes sensitive data accessible to malicious code Reviewed-by: hawtin, chegar ! src/share/classes/java/io/InputStream.java Changeset: 06e0d91548b3 Author: anthony Date: 2011-06-21 20:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/06e0d91548b3 7022113: Security icon can be moved behind the window using the com.sun.SecurityWarning.setPosition() method Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Window.cpp Changeset: d32b75c73389 Author: alanb Date: 2011-06-27 20:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d32b75c73389 7059259: (process) ProcessBuilder.start permission check should be improved when redirecting output to append Reviewed-by: hawtin ! src/windows/classes/java/lang/ProcessImpl.java Changeset: 446b13a08aca Author: asaha Date: 2011-06-27 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/446b13a08aca Merge Changeset: 4fdd1a44e846 Author: asaha Date: 2011-06-27 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4fdd1a44e846 Merge Changeset: 3e42f7893861 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3e42f7893861 Merge Changeset: f578448792b9 Author: ksrini Date: 2011-07-15 13:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f578448792b9 7057857: SIGSEGV [libunpack.so] store_Utf8_char(signed char*, unsigned short) in java.util.jar.pack200 Reviewed-by: jrose, asaha, hawtin ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.h Changeset: 4b20375fe623 Author: asaha Date: 2011-07-19 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4b20375fe623 Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: bc9c70e57f62 Author: asaha Date: 2011-07-20 09:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bc9c70e57f62 7032417: Fix for 6981922 does not address multiple VM case Reviewed-by: michaelm ! src/share/classes/sun/net/ResourceManager.java Changeset: a7177942302f Author: asaha Date: 2011-07-20 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a7177942302f 7023640: calculation for malloc size in TransformHelper.c could overflow an integer Reviewed-by: flar ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: 6c76f2a49061 Author: denis Date: 2011-07-22 21:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6c76f2a49061 7019773: AWTKeyStroke.ctor is a mutable static Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: b25558c39ffc Author: smarks Date: 2011-08-30 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b25558c39ffc 7077466: fix for RMI DGC Reviewed-by: valeriep ! src/share/classes/sun/rmi/server/UnicastServerRef.java Changeset: efd8035f3d14 Author: smarks Date: 2011-08-30 17:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/efd8035f3d14 7083012: fix for RMI Registry Reviewed-by: jdn, valeriep ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java Changeset: 27bda11f1330 Author: smarks Date: 2011-09-21 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/27bda11f1330 7092186: adjust package access in rmiregistry Reviewed-by: asaha, coffeys ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! test/sun/tools/jstatd/jstatdExternalRegistry.sh Changeset: 42eb725f739c Author: xuelei Date: 2011-09-29 17:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/42eb725f739c 7064341: jsse/runtime security problem Reviewed-by: wetmore ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java Changeset: 53a16cf28db3 Author: xuelei Date: 2011-09-30 18:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/53a16cf28db3 7096936: issue in jsse/runtime 7096937: TEST: com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java need modification as a result of TLS fix Reviewed-by: wetmore, jdn, xuelei ! src/share/classes/com/sun/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java Changeset: 27a8f4fc555a Author: asaha Date: 2011-11-14 11:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/27a8f4fc555a Merge ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java ! test/sun/tools/jstatd/jstatdExternalRegistry.sh Changeset: 99632935785e Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/99632935785e Merge Changeset: 00e2c88e2234 Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/00e2c88e2234 Added tag jdk8-b14 for changeset 99632935785e ! .hgtags Changeset: 2a147f854257 Author: twisti Date: 2011-11-02 02:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2a147f854257 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Reviewed-by: jrose, never ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + test/java/lang/invoke/CallSiteTest.java Changeset: 5c34ed65176e Author: twisti Date: 2011-11-09 00:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5c34ed65176e 7109063: JSR 292: fix for 7085860 is incomplete Reviewed-by: iveresov, alanb, jrose ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/ProblemList.txt ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java Changeset: bdb2d63c176c Author: jcoomes Date: 2011-11-18 16:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bdb2d63c176c Merge ! test/ProblemList.txt From john.coomes at oracle.com Thu Nov 24 20:47:07 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:47:07 +0000 Subject: hg: hsx/hotspot-emb/jdk: 94 new changesets Message-ID: <20111125051849.EBB2B47458@hg.openjdk.java.net> Changeset: 7746eb8c610b Author: bae Date: 2011-10-17 15:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7746eb8c610b 6997116: The case automatically failed due to java.lang.ClassCastException. Reviewed-by: jgodinez, prr ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java + test/sun/java2d/DirectX/DrawBitmaskToSurfaceTest.java Changeset: a7a001378444 Author: jgodinez Date: 2011-10-24 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a7a001378444 6604109: javax.print.PrintServiceLookup.lookupPrintServices fails SOMETIMES for Cups Reviewed-by: bae, prr ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: 8f9b0629d088 Author: lana Date: 2011-10-25 21:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8f9b0629d088 Merge Changeset: 2b27e14a4c82 Author: vinnie Date: 2011-10-13 12:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2b27e14a4c82 7099228: Use a PKCS11 config attribute to control encoding of an EC point Reviewed-by: valeriep, mullan ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! test/ProblemList.txt Changeset: 01615d3e74ed Author: mullan Date: 2011-10-13 13:50 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/01615d3e74ed 6953295: Move few sun.security.{util, x509, pkcs} classes used by keytool/jarsigner to another package Reviewed-by: mchung ! make/sun/security/other/Makefile - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java + src/share/classes/sun/security/pkcs10/PKCS10.java + src/share/classes/sun/security/pkcs10/PKCS10Attribute.java + src/share/classes/sun/security/pkcs10/PKCS10Attributes.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java + src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStore.java + src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStoreHelper.java + src/share/classes/sun/security/tools/CertAndKeyGen.java ! src/share/classes/sun/security/tools/KeyTool.java + src/share/classes/sun/security/tools/PathList.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 04ecbd2bcf5a Author: mullan Date: 2011-10-13 13:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/04ecbd2bcf5a Merge Changeset: 6cb07b35acf5 Author: weijun Date: 2011-10-17 17:11 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6cb07b35acf5 7099399: cannot deal with CRL file larger than 16MB Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/provider/X509Factory.java + test/sun/security/provider/X509Factory/BigCRL.java Changeset: 9bf526cc4046 Author: mullan Date: 2011-10-18 10:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9bf526cc4046 7092897: sun.security.util.Cache should be generified Reviewed-by: xuelei ! src/share/classes/sun/security/pkcs11/KeyCache.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/X509CertificatePair.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/util/Cache.java Changeset: f566cd364a90 Author: mullan Date: 2011-10-18 10:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f566cd364a90 Merge ! src/share/classes/sun/security/provider/X509Factory.java Changeset: 8640b7185be1 Author: wetmore Date: 2011-10-18 11:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8640b7185be1 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine Reviewed-by: xuelei, weijun, asaha ! src/share/classes/sun/security/ssl/CipherBox.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java Changeset: 57eb9136b73b Author: mullan Date: 2011-10-19 10:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/57eb9136b73b 7102686: Restructure timestamp code so that jars and modules can more easily share the same code Reviewed-by: mchung ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/timestamp/HttpTimestamper.java ! src/share/classes/sun/security/timestamp/TSRequest.java ! src/share/classes/sun/security/timestamp/TSResponse.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/TimestampedSigner.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java Changeset: 15078025eed9 Author: mullan Date: 2011-10-19 10:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/15078025eed9 Merge Changeset: c5c91589b126 Author: mduigou Date: 2011-10-19 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c5c91589b126 5029031: Add Collections.checkedQueue() Reviewed-by: mduigou Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/CheckedQueue.java Changeset: 634cd6f050ba Author: chegar Date: 2011-10-20 09:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/634cd6f050ba 7102704: test/java/net/DatagramSocket/ChangingAddress.java failing Reviewed-by: chegar Contributed-by: kurchi.subhra.hazra at oracle.com - test/java/net/DatagramSocket/ChangingAddress.java Changeset: 2d89c3f74aa5 Author: michaelm Date: 2011-10-20 09:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2d89c3f74aa5 7102665: Move tests to Problemlist Reviewed-by: chegar, alanb ! test/ProblemList.txt Changeset: 52c2dd336207 Author: michaelm Date: 2011-10-20 09:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/52c2dd336207 Merge - test/java/net/DatagramSocket/ChangingAddress.java Changeset: c3da0672a882 Author: ngmr Date: 2011-10-13 12:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c3da0672a882 7100054: (porting) Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Summary: Use POSIX defined includes for unistd.h and fcntl.h Reviewed-by: dholmes, alanb, chegar, ngmr Contributed-by: Charles Lee ! src/solaris/native/sun/nio/fs/genSolarisConstants.c ! src/solaris/native/sun/nio/fs/genUnixConstants.c Changeset: d979afceb792 Author: peytoia Date: 2011-10-21 15:56 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d979afceb792 7103108: (tz) Support tzdata2011l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: db9e246c651e Author: peytoia Date: 2011-10-21 18:01 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/db9e246c651e 7103405: Correct display names for Pacific/Apia timezone Reviewed-by: okutsu ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 3f391e649ccb Author: chegar Date: 2011-10-24 20:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3f391e649ccb 7104209: Cleanup and remove librmi (native library) Reviewed-by: mduigou, alanb ! make/java/java/mapfile-vers ! make/sun/rmi/rmi/Makefile - make/sun/rmi/rmi/mapfile-vers ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/native/java/io/ObjectInputStream.c ! src/share/native/sun/misc/VM.c - src/share/native/sun/rmi/server/MarshalInputStream.c Changeset: b375523d6037 Author: chegar Date: 2011-10-24 21:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b375523d6037 7103549: Remove dependencies on libjava and libjvm from security libraries Reviewed-by: vinnie, ohair, alanb, dholmes ! make/com/sun/security/auth/module/Makefile ! make/common/Defs.gmk ! make/common/Library.gmk ! make/sun/security/ec/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/security/smartcardio/Makefile ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c ! src/windows/native/sun/security/pkcs11/j2secmod_md.c Changeset: 72666cd49ac3 Author: alanb Date: 2011-10-25 09:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/72666cd49ac3 7104577: Changes for 7104209 cause many RMI tests to fail Reviewed-by: chegar ! src/share/classes/sun/rmi/server/MarshalInputStream.java Changeset: 7814800c64bd Author: lana Date: 2011-10-25 21:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7814800c64bd Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 09fd2067f715 Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/09fd2067f715 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: d636e737c478 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d636e737c478 Added tag jdk8-b12 for changeset 09fd2067f715 ! .hgtags Changeset: bfd720647db2 Author: yhuang Date: 2011-10-31 20:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bfd720647db2 7077119: remove past transition dates from CurrencyData.properties file Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! test/java/util/Currency/CurrencyTest.java ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt Changeset: cfc6fd491b97 Author: yhuang Date: 2011-10-31 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/cfc6fd491b97 6755060: Collator.compare() does not compare correctly for the Thai locale Reviewed-by: naoto ! src/share/classes/sun/text/resources/CollationData_th.java + test/sun/text/resources/Collator/Bug6755060.java Changeset: 0549410acf26 Author: yhuang Date: 2011-10-31 21:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0549410acf26 Merge Changeset: f3227efde13d Author: yhuang Date: 2011-10-31 21:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f3227efde13d 7101495: In Latvia first day of week is Monday Reviewed-by: naoto, peytoia ! src/share/classes/sun/util/resources/CalendarData_lv.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: ab837acc60fb Author: yhuang Date: 2011-10-31 21:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ab837acc60fb Merge Changeset: 631ee738378a Author: mfang Date: 2011-11-03 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/631ee738378a Merge Changeset: 94e5604022fa Author: ngmr Date: 2011-09-15 19:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/94e5604022fa 6988099: jvmti demos missing Publisher (COMPANY resource) in dlls/exes on windows Summary: Add creation/linking of resource data to link step for demos on Windows Reviewed-by: dcubed, zgu, ngmr, ohair Contributed-by: Sean Chou ! make/common/Demo.gmk Changeset: 5791714b9472 Author: ohair Date: 2011-11-04 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5791714b9472 Merge Changeset: 4cb2e8679b27 Author: katleman Date: 2011-11-09 13:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4cb2e8679b27 Merge Changeset: 52bd7fc8fcb0 Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/52bd7fc8fcb0 Added tag jdk8-b13 for changeset 4cb2e8679b27 ! .hgtags Changeset: 9de1dbf8c9be Author: lana Date: 2011-10-26 17:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9de1dbf8c9be Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: 76defa20906a Author: ngmr Date: 2011-09-23 15:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/76defa20906a 7105640: Unix printing does not check the result of exec'd lpr/lp command Summary: Add checking, exception for spool process failure Reviewed-by: prr, jgodinez Contributed-by: Neil Richards ! src/share/classes/sun/print/PSPrinterJob.java ! src/solaris/classes/sun/print/UnixPrintJob.java Changeset: 4544585a3cea Author: lana Date: 2011-11-05 14:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4544585a3cea Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: aa3f5117c485 Author: rupashka Date: 2011-10-17 15:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/aa3f5117c485 7099251: javax.swing.text.html.HTMLDocument.insertAfterStart(null, something) throws NPE Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 4f74e3fdf86b Author: rupashka Date: 2011-10-17 16:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4f74e3fdf86b 7100004: javax.swing.JTable.setAutoCreateRowSorter(boolean autoCreateRowSorter) should mention default value Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/javax/swing/JTable.java Changeset: f1dbc62c7c6d Author: rupashka Date: 2011-10-17 17:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f1dbc62c7c6d 7077293: javax/swing/JComponent/4337267/bug4337267.java failed on windows 2003 Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: a2f5d7049258 Author: dbuck Date: 2011-10-17 19:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a2f5d7049258 6887286: StackOverflowError at sun.awt.image.ImageWatched$WeakLink.isWatcher Summary: Fixed OffScreenImageSource to call imageComplete() with SINGLEFAMEDONE, not STATICIMAGEDONE. This fixed memory leak (that caused SOFE when we use recursion to iterate over linked list). Reviewed-by: bae ! src/share/classes/sun/awt/image/OffScreenImageSource.java Changeset: 7636a62aba7e Author: anthony Date: 2011-11-01 18:01 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7636a62aba7e 7104625: sun.awt.X11.XEvent is creating 600 MB of char[] for no good reason Summary: Wrap logging calls with if(){} statements Reviewed-by: anthony, son Contributed-by: Federico Tello Gentile ! src/solaris/classes/sun/awt/X11/XComponentPeer.java Changeset: ac55f169fadd Author: anthony Date: 2011-11-01 18:03 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ac55f169fadd 7105529: XAWT: Optimize getFieldsAsString() methods generated by WrapperGenerator Summary: Replace string concatenation with StringBuilder.append() Reviewed-by: anthony, son Contributed-by: Federico Tello Gentile ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java Changeset: 41610a897379 Author: rupashka Date: 2011-11-02 14:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/41610a897379 6624077: Regression test fails: closed/javax/swing/ToolTipManager/6256140/bug6256140.java Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/ToolTipManager/Test6256140.java Changeset: 8068f1584715 Author: mrkam Date: 2011-11-02 17:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8068f1584715 7074853: TransparentRuler demos Readme should mention the correct jar file name Reviewed-by: rupashka ! src/share/demo/jfc/TransparentRuler/README.txt Changeset: 323f6d046cc9 Author: rupashka Date: 2011-11-02 23:53 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/323f6d046cc9 7049024: DnD fails with JTextArea and JTextField Reviewed-by: rupashka Contributed-by: Sean Chou ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/JTextArea/7049024/bug7049024.java Changeset: 7c29751a9331 Author: rupashka Date: 2011-11-03 14:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7c29751a9331 6955919: Intermittent ClassCastException in bug4492274 test Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JEditorPane/4492274/bug4492274.java + test/javax/swing/JEditorPane/4492274/test.html Changeset: 1c0624d9a2b6 Author: ngmr Date: 2011-10-13 13:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1c0624d9a2b6 7107957: AWT: Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Summary: Use POSIX defined includes for unistd.h and fcntl.h Reviewed-by: anthony, ngmr Contributed-by: Charles Lee ! src/solaris/native/sun/awt/splashscreen/splashscreen_config.h Changeset: adb31ff942ef Author: rupashka Date: 2011-11-07 16:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/adb31ff942ef 7080203: JTree.getSelectionPaths() now returns empty array instead of null Reviewed-by: malenkov ! src/share/classes/javax/swing/JTree.java Changeset: d219e0b11327 Author: lana Date: 2011-11-07 10:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d219e0b11327 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: f8a3dff76b48 Author: rupashka Date: 2011-11-08 14:36 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f8a3dff76b48 7107585: Test incorrect calculate position of object on frame Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JSlider/6348946/bug6348946.java Changeset: af4fb33fca29 Author: lana Date: 2011-11-08 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/af4fb33fca29 Merge Changeset: 88a260444e4d Author: chegar Date: 2011-10-26 13:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/88a260444e4d 7104650: rawtype warnings in several net, nio and security source files Summary: Also reviewed by Ulf.Zibis at gmx.de Reviewed-by: mcimadamore, alanb, dholmes ! make/sun/net/Makefile ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/security/Security.java ! src/share/classes/sun/nio/ch/Util.java Changeset: 0d371f2911a1 Author: peytoia Date: 2011-10-26 22:16 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0d371f2911a1 7090046: Lots of invalid link in java.text.BreakIterator comments Reviewed-by: okutsu ! src/share/classes/java/text/BreakIterator.java Changeset: 291b55aa9b1e Author: lana Date: 2011-10-25 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/291b55aa9b1e Merge - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 64faf533b99d Author: lana Date: 2011-10-26 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/64faf533b99d Merge Changeset: 449113aea001 Author: weijun Date: 2011-10-27 17:23 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/449113aea001 7104161: test/sun/tools/jinfo/Basic.sh fails on Ubuntu Reviewed-by: alanb ! test/sun/tools/jinfo/Basic.sh Changeset: 64ccf18bbad5 Author: coffeys Date: 2011-10-27 10:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/64ccf18bbad5 7099658: Properties.loadFromXML fails with ClassCastException Reviewed-by: alanb, mchung ! src/share/classes/sun/util/xml/XMLUtils.java Changeset: 56cc907fc8dc Author: mullan Date: 2011-10-27 10:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/56cc907fc8dc 7094155: JSR105 code throws javax.xml.crypto.URIReferenceException when running into Java 7 VM Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! test/javax/xml/crypto/dsig/GenerationTests.java Changeset: 8cd2e3b8127a Author: mullan Date: 2011-10-27 11:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8cd2e3b8127a Merge - make/sun/rmi/rmi/mapfile-vers - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c Changeset: 6e59c482e9b8 Author: xuelei Date: 2011-10-28 07:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6e59c482e9b8 7105940: Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore Reviewed-by: weijun ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java Changeset: bb2b9a8b6e77 Author: alanb Date: 2011-10-30 14:53 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bb2b9a8b6e77 7103889: (fs) Reduce String concatenation when iterating over directory Reviewed-by: alanb Contributed-by: mike.skells at talk21.com ! src/share/classes/java/nio/file/Files.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsPathParser.java Changeset: 30900a1a9cfc Author: xuelei Date: 2011-10-30 20:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/30900a1a9cfc 7106277: Brokenness in the seqNumberOverflow of MAC Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/MAC.java Changeset: 8681362a2f04 Author: wetmore Date: 2011-10-31 11:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8681362a2f04 7105780: Add SSLSocket client/SSLEngine server to templates directory Reviewed-by: xuelei + test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: b60e88ef5d8d Author: wetmore Date: 2011-10-31 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b60e88ef5d8d 7053252: New regression test does not compile on windows-amd64 Reviewed-by: valeriep ! test/ProblemList.txt ! test/sun/security/pkcs11/Provider/Absolute.java Changeset: 5f2838744544 Author: ysr Date: 2011-10-31 17:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5f2838744544 4243978: (ref) Race condition in Reference.enqueue() 4268317: (ref) Reference.isEnqueued() can return true when instance not enqueued Summary: The reference handler now declares, and assumes, that the discovered field, rather than the next field, is (to be) used to link the entries in the pending list, thus allowing a reference object to be safely enqueued even while it is in the pending state. Also added slightly modified regression tests from the two bug reports. Reviewed-by: mchung, alanb, jcoomes ! src/share/classes/java/lang/ref/Reference.java ! src/share/javavm/export/jvm.h ! src/share/native/common/jdk_util.c + test/java/lang/ref/ReferenceEnqueue.java + test/java/lang/ref/ReferenceEnqueuePending.java Changeset: 2f2f56ac8b82 Author: mduigou Date: 2011-11-03 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2f2f56ac8b82 4533691: Add Collections.emptySortedSet() Reviewed-by: mduigou, alanb, dholmes Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/EmptySortedSet.java Changeset: ead9dabe8c75 Author: lana Date: 2011-11-05 00:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ead9dabe8c75 Merge Changeset: 417d91754849 Author: sherman Date: 2011-11-07 13:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/417d91754849 7096080: UTF8 update and new CESU-8 charset 7082884: Incorrect UTF8 conversion for sequence ED 31 7082883: Incorrect UTF8 conversion for sequence fc 80 80 8f bf bf Summary: Updated UTF8 and added CESU-8 to following the latest Standard Reviewed-by: alanb ! make/java/nio/FILES_java.gmk + src/share/classes/sun/nio/cs/CESU_8.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/standard-charsets ! test/java/nio/charset/coders/Errors.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/TestStringCodingUTF8.java ! test/sun/nio/cs/TestUTF8.java Changeset: 0bb498332894 Author: lana Date: 2011-11-08 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0bb498332894 Merge Changeset: 51db54a3b953 Author: lana Date: 2011-11-14 18:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/51db54a3b953 Merge Changeset: 3b2128c89361 Author: alanb Date: 2011-06-15 14:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3b2128c89361 7000600: InputStream.skip() makes sensitive data accessible to malicious code Reviewed-by: hawtin, chegar ! src/share/classes/java/io/InputStream.java Changeset: 06e0d91548b3 Author: anthony Date: 2011-06-21 20:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/06e0d91548b3 7022113: Security icon can be moved behind the window using the com.sun.SecurityWarning.setPosition() method Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Window.cpp Changeset: d32b75c73389 Author: alanb Date: 2011-06-27 20:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d32b75c73389 7059259: (process) ProcessBuilder.start permission check should be improved when redirecting output to append Reviewed-by: hawtin ! src/windows/classes/java/lang/ProcessImpl.java Changeset: 446b13a08aca Author: asaha Date: 2011-06-27 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/446b13a08aca Merge Changeset: 4fdd1a44e846 Author: asaha Date: 2011-06-27 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4fdd1a44e846 Merge Changeset: 3e42f7893861 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3e42f7893861 Merge Changeset: f578448792b9 Author: ksrini Date: 2011-07-15 13:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f578448792b9 7057857: SIGSEGV [libunpack.so] store_Utf8_char(signed char*, unsigned short) in java.util.jar.pack200 Reviewed-by: jrose, asaha, hawtin ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.h Changeset: 4b20375fe623 Author: asaha Date: 2011-07-19 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4b20375fe623 Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: bc9c70e57f62 Author: asaha Date: 2011-07-20 09:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bc9c70e57f62 7032417: Fix for 6981922 does not address multiple VM case Reviewed-by: michaelm ! src/share/classes/sun/net/ResourceManager.java Changeset: a7177942302f Author: asaha Date: 2011-07-20 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a7177942302f 7023640: calculation for malloc size in TransformHelper.c could overflow an integer Reviewed-by: flar ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: 6c76f2a49061 Author: denis Date: 2011-07-22 21:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6c76f2a49061 7019773: AWTKeyStroke.ctor is a mutable static Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: b25558c39ffc Author: smarks Date: 2011-08-30 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b25558c39ffc 7077466: fix for RMI DGC Reviewed-by: valeriep ! src/share/classes/sun/rmi/server/UnicastServerRef.java Changeset: efd8035f3d14 Author: smarks Date: 2011-08-30 17:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/efd8035f3d14 7083012: fix for RMI Registry Reviewed-by: jdn, valeriep ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java Changeset: 27bda11f1330 Author: smarks Date: 2011-09-21 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/27bda11f1330 7092186: adjust package access in rmiregistry Reviewed-by: asaha, coffeys ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! test/sun/tools/jstatd/jstatdExternalRegistry.sh Changeset: 42eb725f739c Author: xuelei Date: 2011-09-29 17:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/42eb725f739c 7064341: jsse/runtime security problem Reviewed-by: wetmore ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java Changeset: 53a16cf28db3 Author: xuelei Date: 2011-09-30 18:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/53a16cf28db3 7096936: issue in jsse/runtime 7096937: TEST: com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java need modification as a result of TLS fix Reviewed-by: wetmore, jdn, xuelei ! src/share/classes/com/sun/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java Changeset: 27a8f4fc555a Author: asaha Date: 2011-11-14 11:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/27a8f4fc555a Merge ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java ! test/sun/tools/jstatd/jstatdExternalRegistry.sh Changeset: 99632935785e Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/99632935785e Merge Changeset: 00e2c88e2234 Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/00e2c88e2234 Added tag jdk8-b14 for changeset 99632935785e ! .hgtags Changeset: 2a147f854257 Author: twisti Date: 2011-11-02 02:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2a147f854257 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Reviewed-by: jrose, never ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + test/java/lang/invoke/CallSiteTest.java Changeset: 5c34ed65176e Author: twisti Date: 2011-11-09 00:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5c34ed65176e 7109063: JSR 292: fix for 7085860 is incomplete Reviewed-by: iveresov, alanb, jrose ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/ProblemList.txt ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java Changeset: bdb2d63c176c Author: jcoomes Date: 2011-11-18 16:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bdb2d63c176c Merge ! test/ProblemList.txt From paul.hohensee at oracle.com Mon Nov 28 11:46:53 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 28 Nov 2011 14:46:53 -0500 Subject: Pls review 7116189 (XXS) Message-ID: <4ED3E52D.1080106@oracle.com> 7116189: Export JVM_SetNativeThreadName from Hotspot. The initial Mac OSX port added a JVM entry point JVM_SetNativeThreadName for use by the JDK libraries, but failed to export it in libjvm.so on Solaris and Linux. Mike McMahon from the core libs team produced a fix, which is just to add JVM_SetNativeThreadName to the Solaris and Linux linker mapfiles. Webrev here: http://cr.openjdk.java.net/~phh/7116189.0 Thanks, Paul From daniel.daugherty at oracle.com Mon Nov 28 12:50:49 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 28 Nov 2011 13:50:49 -0700 Subject: Pls review 7116189 (XXS) In-Reply-To: <4ED3E52D.1080106@oracle.com> References: <4ED3E52D.1080106@oracle.com> Message-ID: <4ED3F429.3020607@oracle.com> On 11/28/11 12:46 PM, Paul Hohensee wrote: > 7116189: Export JVM_SetNativeThreadName from Hotspot. > > The initial Mac OSX port added a JVM entry point > JVM_SetNativeThreadName for > use by the JDK libraries, but failed to export it in libjvm.so on > Solaris and Linux. > Mike McMahon from the core libs team produced a fix, which is just to add > JVM_SetNativeThreadName to the Solaris and Linux linker mapfiles. > > Webrev here: > > http://cr.openjdk.java.net/~phh/7116189.0 Thumbs up! make/linux/makefiles/mapfile-vers-debug make/linux/makefiles/mapfile-vers-product make/solaris/makefiles/mapfile-vers No comments except for why do these files still have expanded SCCS ident strings? Dan > > Thanks, > > Paul > > From paul.hohensee at oracle.com Mon Nov 28 13:36:05 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 28 Nov 2011 16:36:05 -0500 Subject: Pls review 7116189 (XXS) In-Reply-To: <4ED3F429.3020607@oracle.com> References: <4ED3E52D.1080106@oracle.com> <4ED3F429.3020607@oracle.com> Message-ID: <4ED3FEC5.9000405@oracle.com> Thanks very much for the review. I actually hadn't noticed the SCCS ident strings. I'll remove them. Paul On 11/28/11 3:50 PM, Daniel D. Daugherty wrote: > On 11/28/11 12:46 PM, Paul Hohensee wrote: >> 7116189: Export JVM_SetNativeThreadName from Hotspot. >> >> The initial Mac OSX port added a JVM entry point >> JVM_SetNativeThreadName for >> use by the JDK libraries, but failed to export it in libjvm.so on >> Solaris and Linux. >> Mike McMahon from the core libs team produced a fix, which is just to >> add >> JVM_SetNativeThreadName to the Solaris and Linux linker mapfiles. >> >> Webrev here: >> >> http://cr.openjdk.java.net/~phh/7116189.0 > > Thumbs up! > > make/linux/makefiles/mapfile-vers-debug > make/linux/makefiles/mapfile-vers-product > make/solaris/makefiles/mapfile-vers > No comments except for why do these files still have > expanded SCCS ident strings? > > Dan > > > >> >> Thanks, >> >> Paul >> >> From david.holmes at oracle.com Mon Nov 28 18:48:35 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Nov 2011 12:48:35 +1000 Subject: Pls review 7116189 (XXS) In-Reply-To: <4ED3E52D.1080106@oracle.com> References: <4ED3E52D.1080106@oracle.com> Message-ID: <4ED44803.1020702@oracle.com> On 29/11/2011 5:46 AM, Paul Hohensee wrote: > 7116189: Export JVM_SetNativeThreadName from Hotspot. > > The initial Mac OSX port added a JVM entry point JVM_SetNativeThreadName > for > use by the JDK libraries, but failed to export it in libjvm.so on > Solaris and Linux. > Mike McMahon from the core libs team produced a fix, which is just to add > JVM_SetNativeThreadName to the Solaris and Linux linker mapfiles. > > Webrev here: > > http://cr.openjdk.java.net/~phh/7116189.0 I has some discussions about this with Paul via email, not realizing the review request was out here. To clarify, neither Solaris nor Linux support JVM_SetNativeThreadName - it is a no-op**. I assume this fix is needed to address build and/or link issues with JDK code that wants to call this method? David ----- ** pthread_setname_np is a non-portable extension to pthreads. Apparently Linux supports it from glibc 2.12 http://stackoverflow.com/questions/2369738/can-i-set-the-name-of-a-thread-in-pthreads-linux but I don't see it on our linux build machines and also not in Solaris. From paul.hohensee at oracle.com Tue Nov 29 11:30:11 2011 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Tue, 29 Nov 2011 19:30:11 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7116189: Export JVM_SetNativeThreadName from Hotspot Message-ID: <20111129193013.7F5204749C@hg.openjdk.java.net> Changeset: 242b4e0e6f73 Author: phh Date: 2011-11-29 09:21 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/242b4e0e6f73 7116189: Export JVM_SetNativeThreadName from Hotspot Summary: Added JVM_SetNativeThreadName to linker mapfiles on Solaris and Linux. Reviewed-by: dcubed, dholmes Contributed-by: michael.x.mcmahon at oracle.com ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers From bob.vandette at oracle.com Tue Nov 29 14:25:38 2011 From: bob.vandette at oracle.com (bob.vandette at oracle.com) Date: Tue, 29 Nov 2011 22:25:38 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 49 new changesets Message-ID: <20111129222713.6AF7D474A2@hg.openjdk.java.net> Changeset: 5bda8dae4e14 Author: never Date: 2011-10-23 20:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5bda8dae4e14 7103784: enable some flags by default Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 754110e02bd5 Author: never Date: 2011-10-23 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/754110e02bd5 7103380: assertion failure with -XX:+PrintNativeNMethods Reviewed-by: kvn, iveresov ! src/share/vm/asm/codeBuffer.cpp Changeset: 42783d1414b2 Author: never Date: 2011-10-23 23:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/42783d1414b2 Merge - make/templates/bsd-header Changeset: b20d64f83668 Author: twisti Date: 2011-10-24 07:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b20d64f83668 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop Reviewed-by: kvn, never, jrose ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp Changeset: 12d38ffcba2a Author: twisti Date: 2011-10-25 00:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/12d38ffcba2a 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check Reviewed-by: iveresov, never ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 2ec638646e86 Author: twisti Date: 2011-10-25 04:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2ec638646e86 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I Reviewed-by: kvn, iveresov ! src/share/vm/runtime/sharedRuntime.cpp Changeset: a6eef545f1a2 Author: never Date: 2011-10-25 08:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/a6eef545f1a2 7103224: collision between __LEAF define in interfaceSupport.hpp and /usr/include/sys/cdefs.h with gcc Reviewed-by: never Contributed-by: Omair Majid ! src/share/vm/opto/addnode.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/interfaceSupport.hpp Changeset: e69a66a1457b Author: kvn Date: 2011-10-25 12:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e69a66a1457b 7059039: EA: don't change non-escaping state of NULL pointer Summary: NULL pointers do not escape but escape state propagation may change it leading to worser results. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: d8cb48376797 Author: kvn Date: 2011-10-26 06:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d8cb48376797 7097546: Optimize use of CMOVE instructions Summary: Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.hpp Changeset: cec1757a0134 Author: twisti Date: 2011-10-27 04:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/cec1757a0134 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely Reviewed-by: never, bdelsart ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/opto/runtime.cpp Changeset: e0658a9b3f87 Author: kvn Date: 2011-10-27 09:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e0658a9b3f87 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" Summary: Define ciMethodHandle::print_chain_impl() and ciMethodHandle::print_chain() bodies only in debug builds. Reviewed-by: never, twisti ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp Changeset: 34535d2cb362 Author: iveresov Date: 2011-10-27 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/34535d2cb362 7104177: Tiered: -XX:+PrintCanonicalization doesn't work with -XX:+TieredCompilation Summary: Initialize printable_bci of instruction when passed to Canonicalizer Reviewed-by: kvn, never ! src/share/vm/c1/c1_Canonicalizer.hpp Changeset: f350490a45fd Author: kvn Date: 2011-10-27 18:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f350490a45fd 7105611: Set::print() is broken Summary: Reimplemented class VSetI_ to restore Set::print(). Reviewed-by: never ! src/share/vm/libadt/vectset.cpp ! src/share/vm/libadt/vectset.hpp Changeset: eba044a722a4 Author: never Date: 2011-10-28 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/eba044a722a4 7103261: crash with jittester on sparc Reviewed-by: iveresov, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp + test/compiler/7103261/Test7103261.java Changeset: e3b0dcc327b9 Author: twisti Date: 2011-10-31 03:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e3b0dcc327b9 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes Reviewed-by: never, kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/opto/machnode.cpp Changeset: 71699e9d8673 Author: kvn Date: 2011-10-31 15:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/71699e9d8673 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java Summary: Use -Xss224k instead of -Xss128k. Reviewed-by: never ! test/compiler/6865265/StackOverflowBug.java Changeset: e342a5110bed Author: twisti Date: 2011-11-03 01:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e342a5110bed 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result Reviewed-by: kvn ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 448691f285a5 Author: twisti Date: 2011-11-03 04:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/448691f285a5 7106944: assert(_pc == *pc_addr) failed may be too strong Reviewed-by: kvn, never ! src/cpu/x86/vm/frame_x86.cpp Changeset: 1feb272af3a7 Author: never Date: 2011-11-04 13:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1feb272af3a7 6636110: unaligned stackpointer leads to crash during deoptimization Reviewed-by: never, kvn Contributed-by: Andreas Schoesser ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: 59e515ee9354 Author: kvn Date: 2011-11-07 14:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/59e515ee9354 7059047: EA: can't find initializing store with several CheckCastPP Summary: Split adjust_escape_state() method into two methods to find initializing stores. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 44ce519bc3d1 Author: never Date: 2011-11-08 10:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/44ce519bc3d1 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer Reviewed-by: kvn, jrose, twisti ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp Changeset: c9a03402fe56 Author: never Date: 2011-11-08 17:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c9a03402fe56 7105305: assert check_method_context proper context Reviewed-by: jrose, kvn ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/constantPoolKlass.cpp Changeset: e3e363b2bf19 Author: never Date: 2011-11-08 20:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e3e363b2bf19 7108242: jinfo -permstat shouldn't report interned strings as part of perm Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 83d0b5cd1438 Author: twisti Date: 2011-11-09 00:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/83d0b5cd1438 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use Reviewed-by: jrose, kvn, never ! src/share/vm/opto/callGenerator.cpp Changeset: 7e0e43cf86d6 Author: kvn Date: 2011-11-09 06:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7e0e43cf86d6 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot Summary: zero array when compiled code is deoptimized. Reviewed-by: never, twisti ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: 670a74b863fc Author: kvn Date: 2011-11-09 07:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/670a74b863fc 7107042: assert(no_dead_loop) failed: dead loop detected Summary: Use dead nodes elimination code in PhaseIdealLoop before executing EA. Reviewed-by: never, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/runtime/globals.hpp Changeset: 78bef05801ca Author: twisti Date: 2011-11-10 04:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/78bef05801ca Merge - src/share/vm/precompiled.hpp ! src/share/vm/runtime/globals.hpp Changeset: 3c7d67df8d07 Author: dholmes Date: 2011-11-10 06:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/3c7d67df8d07 7108264: Fix for 7104173 is insufficient Summary: Disable PrintVMOptions by default for all builds Reviewed-by: dsamersoff, twisti ! src/share/vm/runtime/globals.hpp Changeset: f9a80a035a4a Author: coleenp Date: 2011-11-15 12:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f9a80a035a4a Merge ! src/share/vm/runtime/globals.hpp Changeset: 5a5ed80bea5b Author: ysr Date: 2011-10-26 21:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5a5ed80bea5b 7105163: CMS: some mentions of MinChunkSize should be IndexSetStart Summary: Fixed the instances that were missed in the changeset for 7099817. Reviewed-by: stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp Changeset: 59519b7d7b9d Author: tonyp Date: 2011-10-28 13:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/59519b7d7b9d Merge Changeset: 6fd81579526f Author: brutisso Date: 2011-10-31 08:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6fd81579526f 7102044: G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise Summary: arrayOopDesc::max_array_length() should return a value that does not overflow a size_t if it is converted to bytes. Reviewed-by: kvn, dholmes ! make/jprt.properties ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! test/Makefile Changeset: ed80554efa25 Author: brutisso Date: 2011-11-02 08:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ed80554efa25 7106751: G1: gc/gctests/nativeGC03 crashes VM with SIGSEGV Summary: _cset_rs_update_cl[] was indexed with values beyond what it is set up to handle. Reviewed-by: ysr, jmasa, johnc ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 8aae2050e83e Author: tonyp Date: 2011-11-07 22:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8aae2050e83e 7092309: G1: introduce old region set Summary: Keep track of all the old regions in the heap with a heap region set. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 53074c2c4600 Author: tonyp Date: 2011-11-08 00:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/53074c2c4600 7099849: G1: include heap region information in hs_err files Reviewed-by: johnc, brutisso, poonam ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/utilities/vmError.cpp Changeset: ab5107bee78c Author: brutisso Date: 2011-11-09 23:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ab5107bee78c 7110190: GCCause::to_string missing case for _adaptive_size_policy Summary: Added case for _adaptive_size_policy Reviewed-by: johnc, ysr ! src/share/vm/gc_interface/gcCause.cpp Changeset: aa4c21b00f7f Author: brutisso Date: 2011-11-15 20:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/aa4c21b00f7f 7110152: assert(size_in_words <= (julong)max_jint) failed: no overflow Summary: Reduce what arrayOopDesc::max_array_length() returns to avoid int overflow Reviewed-by: kvn, dholmes, tonyp ! src/share/vm/oops/arrayOop.hpp Changeset: 2ceafe3ceb65 Author: poonam Date: 2011-11-16 16:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2ceafe3ceb65 7110428: Crash during HeapDump operation Reviewed-by: ysr, dholmes ! src/share/vm/services/heapDumper.cpp Changeset: b1754f3fbbd8 Author: tonyp Date: 2011-11-17 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b1754f3fbbd8 Merge Changeset: 088d09a130ff Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/088d09a130ff Added tag jdk8-b13 for changeset b92ca8e229d2 ! .hgtags Changeset: 883328bfc472 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/883328bfc472 Added tag jdk8-b14 for changeset 088d09a130ff ! .hgtags Changeset: 6c2a55d4902f Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6c2a55d4902f Merge Changeset: fde2a39ed7f3 Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/fde2a39ed7f3 Added tag hs23-b06 for changeset 6c2a55d4902f ! .hgtags Changeset: da4182086289 Author: jcoomes Date: 2011-11-18 17:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/da4182086289 7113503: Bump the hs23 build number to 07 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 36b057451829 Author: dholmes Date: 2011-11-16 20:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/36b057451829 7110017: is_headless_jre should be updated to reflect the new location of awt toolkit libraries Reviewed-by: dholmes, dsamersoff Contributed-by: Chris Hegarty ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 002cb3fc8256 Author: coleenp Date: 2011-11-18 17:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/002cb3fc8256 Merge Changeset: c17bc65648de Author: brutisso Date: 2011-11-21 08:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c17bc65648de 7112308: Fix Visual Studio build for precompiled header Summary: Add the new path to precompiled.hpp in the project make file Reviewed-by: coleenp, dholmes, brutisso Contributed-by: rbackman ! make/windows/makefiles/projectcreator.make Changeset: 1d090cf33da6 Author: coleenp Date: 2011-11-21 10:22 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1d090cf33da6 Merge Changeset: da4dd142ea01 Author: bobv Date: 2011-11-29 14:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/da4dd142ea01 Merge ! src/share/vm/code/dependencies.cpp From paul.hohensee at oracle.com Tue Nov 29 17:19:58 2011 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Wed, 30 Nov 2011 01:19:58 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7116481: Commercial features in Hotspot must be gated by a switch Message-ID: <20111130012001.11737474A3@hg.openjdk.java.net> Changeset: 763f01599ff4 Author: phh Date: 2011-11-29 17:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/763f01599ff4 7116481: Commercial features in Hotspot must be gated by a switch Summary: Add -XX:+UnlockCommercialVMOptions to gate use of commercial feature switches in the same way as -XX:UnlockDiagnosticVMOptions gates use of diagnostic feature switches. Reviewed-by: jwilhelm, kamg ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp From kirk at kodewerk.com Tue Nov 29 22:21:54 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Wed, 30 Nov 2011 07:21:54 +0100 Subject: hg: hsx/hotspot-rt/hotspot: 7116481: Commercial features in Hotspot must be gated by a switch In-Reply-To: <20111130012001.11737474A3@hg.openjdk.java.net> References: <20111130012001.11737474A3@hg.openjdk.java.net> Message-ID: Hi all, Some how i missed how this flag came to be. Is there a discussion thread that I read to understand the thinking behind this type of flag in OpenJDK? Kind regards, Kirk Pepperdine On Nov 30, 2011, at 2:19 AM, paul.hohensee at oracle.com wrote: > Changeset: 763f01599ff4 > Author: phh > Date: 2011-11-29 17:00 -0500 > URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/763f01599ff4 > > 7116481: Commercial features in Hotspot must be gated by a switch > Summary: Add -XX:+UnlockCommercialVMOptions to gate use of commercial feature switches in the same way as -XX:UnlockDiagnosticVMOptions gates use of diagnostic feature switches. > Reviewed-by: jwilhelm, kamg > > ! src/share/vm/runtime/globals.cpp > ! src/share/vm/runtime/globals.hpp > ! src/share/vm/runtime/globals_extension.hpp > From dalibor.topic at oracle.com Wed Nov 30 06:08:42 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 30 Nov 2011 15:08:42 +0100 Subject: hg: hsx/hotspot-rt/hotspot: 7116481: Commercial features in Hotspot must be gated by a switch In-Reply-To: References: <20111130012001.11737474A3@hg.openjdk.java.net> Message-ID: <4ED638EA.6050403@oracle.com> On 11/30/11 7:21 AM, Charles K Pepperdine wrote: > Hi all, > > Some how i missed how this flag came to be. Is there a discussion thread that I read to understand the thinking behind this type of flag in OpenJDK? The review thread starts here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-November/004785.html cheers, dalibor topic > > Kind regards, > Kirk Pepperdine > > On Nov 30, 2011, at 2:19 AM, paul.hohensee at oracle.com wrote: > >> Changeset: 763f01599ff4 >> Author: phh >> Date: 2011-11-29 17:00 -0500 >> URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/763f01599ff4 >> >> 7116481: Commercial features in Hotspot must be gated by a switch >> Summary: Add -XX:+UnlockCommercialVMOptions to gate use of commercial feature switches in the same way as -XX:UnlockDiagnosticVMOptions gates use of diagnostic feature switches. >> Reviewed-by: jwilhelm, kamg >> >> ! src/share/vm/runtime/globals.cpp >> ! src/share/vm/runtime/globals.hpp >> ! src/share/vm/runtime/globals_extension.hpp >> > -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From paul.hohensee at oracle.com Wed Nov 30 13:49:28 2011 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Wed, 30 Nov 2011 21:49:28 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7116730: Revert 7116481: Commercial features in Hotspot must be gated by a switch Message-ID: <20111130214930.6D6A8474CB@hg.openjdk.java.net> Changeset: 358eca91be48 Author: phh Date: 2011-11-30 12:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/358eca91be48 7116730: Revert 7116481: Commercial features in Hotspot must be gated by a switch Summary: Revert 7116481 to current hsx/hotspot-main Reviewed-by: kamg ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp