From aleksey.shipilev at oracle.com Wed Oct 1 07:23:59 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 01 Oct 2014 11:23:59 +0400 Subject: RFR (XS) 8059474: Clean up vm/utilities/Bitmap type uses In-Reply-To: <542B2A63.2090500@oracle.com> References: <542AC64C.1090401@oracle.com> <542B2A63.2090500@oracle.com> Message-ID: <542BAC0F.1030203@oracle.com> Thanks for review, Coleen! Any GC guys around? Please take a look. -Aleksey. On 10/01/2014 02:10 AM, Coleen Phillimore wrote: > > Aleksey, > > This looks good to me. GC code uses BitMap a lot and JPRT tests the > different collectors so I think this is fine. Someone from the GC team > should look at this also. > > Thanks! > Coleen > > > On 9/30/14, 11:03 AM, Aleksey Shipilev wrote: >> Hi, >> >> Not sure which group this belongs to, using the generic hotspot-dev at . >> >> vm/utilities/BitMap inconsistencies bugged me for quite some time: the >> mention of naked uintptr_t instead of properly typedef-ed bm_word_t >> alias; casting AllBits/NoBits constants of (luckily) the same type; >> other things like a benign inconsistency in init_pop_count_table >> new/free, etc. >> >> Here is a cleanup, please review: >> http://cr.openjdk.java.net/~shade/8059474/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8059474 >> >> Testing: >> JPRT, Nashorn/Octane on Linux/x86_64/fastdebug. >> >> Thanks, >> -Aleksey. >> > From erik.helin at oracle.com Wed Oct 1 07:31:25 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 01 Oct 2014 09:31:25 +0200 Subject: RFR: 8049599: MetaspaceGC::_capacity_until_GC can overflow In-Reply-To: <542AABF9.2090700@oracle.com> References: <53F4780D.9040005@oracle.com> <5422F225.1090105@oracle.com> <542AA565.2070608@oracle.com> <542AABF9.2090700@oracle.com> Message-ID: <542BADCD.6070608@oracle.com> On 2014-09-30 15:11, Stefan Karlsson wrote: > On 2014-09-30 14:43, Erik Helin wrote: >> All, >> >> got some great feedback from StefanK: >> - Use cmpxchg_ptr instead of cmpxchg >> - Add a comment describing the while loop in expand_and_allocate >> - Add a comment in the test describing the overflow attempt >> - Change the loop in expand_and_allocate to do/while >> - Shorten the names of the local variables in expand_and_allocate >> >> The result can be seen in the following webrevs: >> - full: http://cr.openjdk.java.net/~ehelin/8049599/webrev.02/ >> - inc: http://cr.openjdk.java.net/~ehelin/8049599/webrev.01-02/ > > Looks good. Thanks! Erik > thanks, > StefanK > >> >> Thanks, >> Erik >> >> On 2014-09-24 18:32, Erik Helin wrote: >>> All, >>> >>> I've reworked the patch quite a bit based on (great!) internal feedback >>> from StefanK and Mikael Gerdin. The patch still uses an overflow check >>> and a CAS to update the high-water mark (HWM), but the new behavior >>> should be the same as the old one (which used Atomic::add_ptr). >>> >>> With the current code, each thread always increments the HWM, but there >>> is a race in that another thread can allocate metadata (due to the >>> increased HWM) before the thread that increased the HWM gets around to >>> allocate. With the new code, each thread will increase the pointer at >>> most once using a CAS. Even if increasing the HWM fails, the allocation >>> attempt might still succeed (for the reason described above). >>> >>> There is a theoretical problem of starvation in the new code, a thread >>> might forever fail to increase the HWM and forever fail to allocate due >>> to contention, but in practice this should not be a problem. In the >>> current code, Atomic::add_ptr is implemented as a CAS in a >>> (theoretically) never ending loop on non-x86 CPUs, so the same >>> theoretical starvation problem is present in the current code as well >>> (on non-x86 CPUs that is). >>> >>> Webrevs: >>> - full: >>> http://cr.openjdk.java.net/~ehelin/8049599/webrev.01/ >>> - incremental: >>> http://cr.openjdk.java.net/~ehelin/8049599/webrev.00-01/ >>> >>> Testing: >>> - JPRT >>> - Aurora: >>> - Kitchensink >>> - Weblogic+Medrec >>> - runThese >>> - vm.quick, regression, gc, compiler, runtime, parallel class >>> loading, >>> metaspace, oom >>> - JTReg tests >>> - Running newly added JTREG test >>> >>> Thanks, >>> Erik >>> >>> On 2014-08-20 12:27, Erik Helin wrote: >>>> Hi all, >>>> >>>> this patch fixes a problem where Metaspace::_capacityUntilGC can >>>> overflow ("wrap around"). Since _capacityUntilGC is treated as a size_t >>>> everywhere it used, we won't calculate with negative numbers, but an >>>> eventual wrap around will still cause unnecessary GCs. >>>> >>>> The problem is solved by detecting an eventual wrap around in >>>> Metaspace::incCapacityUntilGC. The overflow check means that >>>> _capacityUntilGC now must be updated with a CAS. If the CAS fails more >>>> than five times due to contention, no update will be done, because this >>>> means that other threads must have incremented _capacityUntilGC (it is >>>> decremented only during a safepoint). This also means that a thread >>>> calling incCapacityUntilGC might have "its" requested memory >>>> "stolen" by >>>> another thread, but incCapacityUntilGC has never given any fairness >>>> guarantees. >>>> >>>> The patch also adds two functions to the WhiteBox API to be able to >>>> update and read Metaspace::_capacityUntilGC from a JTREG test. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8049599 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8049599/webrev.00/ >>>> >>>> Testing: >>>> - JPRT >>>> - Aurora ad-hoc testing (on all platforms, both 32-bit and 64-bit): >>>> - Kitchensink, runThese and Dacapo >>>> - JTREG tests >>>> - Parallel Class Loading testlist >>>> - GC, runtime and compiler testlists >>>> - OOM and stress testlists >>>> - Running newly added JTREG test >>>> >>>> Thanks, >>>> Erik > From erik.helin at oracle.com Wed Oct 1 07:31:45 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 01 Oct 2014 09:31:45 +0200 Subject: RFR: 8049599: MetaspaceGC::_capacity_until_GC can overflow In-Reply-To: <542B078E.6050400@oracle.com> References: <53F4780D.9040005@oracle.com> <5422F225.1090105@oracle.com> <542AA565.2070608@oracle.com> <542B078E.6050400@oracle.com> Message-ID: <542BADE1.2040501@oracle.com> On 2014-09-30 21:42, Jon Masamitsu wrote: > Erik, > > Changes look good. > > Reviewed. Thanks! Erik > Jon > > On 9/30/2014 5:43 AM, Erik Helin wrote: >> All, >> >> got some great feedback from StefanK: >> - Use cmpxchg_ptr instead of cmpxchg >> - Add a comment describing the while loop in expand_and_allocate >> - Add a comment in the test describing the overflow attempt >> - Change the loop in expand_and_allocate to do/while >> - Shorten the names of the local variables in expand_and_allocate >> >> The result can be seen in the following webrevs: >> - full: http://cr.openjdk.java.net/~ehelin/8049599/webrev.02/ >> - inc: http://cr.openjdk.java.net/~ehelin/8049599/webrev.01-02/ >> >> Thanks, >> Erik >> >> On 2014-09-24 18:32, Erik Helin wrote: >>> All, >>> >>> I've reworked the patch quite a bit based on (great!) internal feedback >>> from StefanK and Mikael Gerdin. The patch still uses an overflow check >>> and a CAS to update the high-water mark (HWM), but the new behavior >>> should be the same as the old one (which used Atomic::add_ptr). >>> >>> With the current code, each thread always increments the HWM, but there >>> is a race in that another thread can allocate metadata (due to the >>> increased HWM) before the thread that increased the HWM gets around to >>> allocate. With the new code, each thread will increase the pointer at >>> most once using a CAS. Even if increasing the HWM fails, the allocation >>> attempt might still succeed (for the reason described above). >>> >>> There is a theoretical problem of starvation in the new code, a thread >>> might forever fail to increase the HWM and forever fail to allocate due >>> to contention, but in practice this should not be a problem. In the >>> current code, Atomic::add_ptr is implemented as a CAS in a >>> (theoretically) never ending loop on non-x86 CPUs, so the same >>> theoretical starvation problem is present in the current code as well >>> (on non-x86 CPUs that is). >>> >>> Webrevs: >>> - full: >>> http://cr.openjdk.java.net/~ehelin/8049599/webrev.01/ >>> - incremental: >>> http://cr.openjdk.java.net/~ehelin/8049599/webrev.00-01/ >>> >>> Testing: >>> - JPRT >>> - Aurora: >>> - Kitchensink >>> - Weblogic+Medrec >>> - runThese >>> - vm.quick, regression, gc, compiler, runtime, parallel class >>> loading, >>> metaspace, oom >>> - JTReg tests >>> - Running newly added JTREG test >>> >>> Thanks, >>> Erik >>> >>> On 2014-08-20 12:27, Erik Helin wrote: >>>> Hi all, >>>> >>>> this patch fixes a problem where Metaspace::_capacityUntilGC can >>>> overflow ("wrap around"). Since _capacityUntilGC is treated as a size_t >>>> everywhere it used, we won't calculate with negative numbers, but an >>>> eventual wrap around will still cause unnecessary GCs. >>>> >>>> The problem is solved by detecting an eventual wrap around in >>>> Metaspace::incCapacityUntilGC. The overflow check means that >>>> _capacityUntilGC now must be updated with a CAS. If the CAS fails more >>>> than five times due to contention, no update will be done, because this >>>> means that other threads must have incremented _capacityUntilGC (it is >>>> decremented only during a safepoint). This also means that a thread >>>> calling incCapacityUntilGC might have "its" requested memory >>>> "stolen" by >>>> another thread, but incCapacityUntilGC has never given any fairness >>>> guarantees. >>>> >>>> The patch also adds two functions to the WhiteBox API to be able to >>>> update and read Metaspace::_capacityUntilGC from a JTREG test. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8049599 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8049599/webrev.00/ >>>> >>>> Testing: >>>> - JPRT >>>> - Aurora ad-hoc testing (on all platforms, both 32-bit and 64-bit): >>>> - Kitchensink, runThese and Dacapo >>>> - JTREG tests >>>> - Parallel Class Loading testlist >>>> - GC, runtime and compiler testlists >>>> - OOM and stress testlists >>>> - Running newly added JTREG test >>>> >>>> Thanks, >>>> Erik > From mikael.gerdin at oracle.com Wed Oct 1 07:36:46 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 01 Oct 2014 09:36:46 +0200 Subject: RFR (XS) 8059474: Clean up vm/utilities/Bitmap type uses In-Reply-To: <542BAC0F.1030203@oracle.com> References: <542AC64C.1090401@oracle.com> <542B2A63.2090500@oracle.com> <542BAC0F.1030203@oracle.com> Message-ID: <11673853.13tLNhCG5a@mgerdin03> Hi Aleksey, On Wednesday 01 October 2014 11.23.59 Aleksey Shipilev wrote: > Thanks for review, Coleen! > > Any GC guys around? Please take a look. In 338 bool BitMap::set_union_with_result(BitMap other) { 339 assert(size() == other.size(), "must have same size"); 340 bool changed = false; 341 bm_word_t* dest_map = map(); 342 bm_word_t* other_map = other.map(); 343 idx_t size = size_in_words(); 344 for (idx_t index = 0; index < size; index++) { 345 idx_t temp = map(index) | other_map[index]; 346 changed = changed || (temp != map(index)); 347 dest_map[index] = temp; 348 } 349 return changed; 350 } You changed one call to map() to use the local variable dest_map, can you make it consistently use the locals instead of calling map(index)? The rest of the change looks good, thanks for cleaning this up a bit. There are some tests in TestBitMap_test(), you can run them with -XX:+ExecuteInternalVMTests on a fastdebug VM. /Mikael > > -Aleksey. > > On 10/01/2014 02:10 AM, Coleen Phillimore wrote: > > Aleksey, > > > > This looks good to me. GC code uses BitMap a lot and JPRT tests the > > different collectors so I think this is fine. Someone from the GC team > > should look at this also. > > > > Thanks! > > Coleen > > > > On 9/30/14, 11:03 AM, Aleksey Shipilev wrote: > >> Hi, > >> > >> Not sure which group this belongs to, using the generic hotspot-dev at . > >> > >> vm/utilities/BitMap inconsistencies bugged me for quite some time: the > >> mention of naked uintptr_t instead of properly typedef-ed bm_word_t > >> alias; casting AllBits/NoBits constants of (luckily) the same type; > >> other things like a benign inconsistency in init_pop_count_table > >> new/free, etc. > >> > >> Here is a cleanup, please review: > >> http://cr.openjdk.java.net/~shade/8059474/webrev.00/ > >> https://bugs.openjdk.java.net/browse/JDK-8059474 > >> > >> Testing: > >> JPRT, Nashorn/Octane on Linux/x86_64/fastdebug. > >> > >> Thanks, > >> -Aleksey. From aleksey.shipilev at oracle.com Wed Oct 1 10:00:34 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 01 Oct 2014 14:00:34 +0400 Subject: RFR (XS) 8059474: Clean up vm/utilities/Bitmap type uses In-Reply-To: <11673853.13tLNhCG5a@mgerdin03> References: <542AC64C.1090401@oracle.com> <542B2A63.2090500@oracle.com> <542BAC0F.1030203@oracle.com> <11673853.13tLNhCG5a@mgerdin03> Message-ID: <542BD0C2.5040708@oracle.com> Hi Mikael, Thanks for a review. Truly, I missed that spot, done here: http://cr.openjdk.java.net/~shade/8059474/webrev.01/ Testing: JPRT, Nashorn/Octane with Linux x86_64/fastdebug, -XX:+ExecuteInternalVMTests If you are happy with this change, please sponsor: http://cr.openjdk.java.net/~shade/8059474/8059474.changeset -Aleksey. On 10/01/2014 11:36 AM, Mikael Gerdin wrote: > Hi Aleksey, > > On Wednesday 01 October 2014 11.23.59 Aleksey Shipilev wrote: >> Thanks for review, Coleen! >> >> Any GC guys around? Please take a look. > > In > 338 bool BitMap::set_union_with_result(BitMap other) { > 339 assert(size() == other.size(), "must have same size"); > 340 bool changed = false; > 341 bm_word_t* dest_map = map(); > 342 bm_word_t* other_map = other.map(); > 343 idx_t size = size_in_words(); > 344 for (idx_t index = 0; index < size; index++) { > 345 idx_t temp = map(index) | other_map[index]; > 346 changed = changed || (temp != map(index)); > 347 dest_map[index] = temp; > 348 } > 349 return changed; > 350 } > > You changed one call to map() to use the local variable dest_map, can you make > it consistently use the locals instead of calling map(index)? > > The rest of the change looks good, thanks for cleaning this up a bit. > > There are some tests in TestBitMap_test(), you can run them with > -XX:+ExecuteInternalVMTests on a fastdebug VM. > > /Mikael > >> >> -Aleksey. >> >> On 10/01/2014 02:10 AM, Coleen Phillimore wrote: >>> Aleksey, >>> >>> This looks good to me. GC code uses BitMap a lot and JPRT tests the >>> different collectors so I think this is fine. Someone from the GC team >>> should look at this also. >>> >>> Thanks! >>> Coleen >>> >>> On 9/30/14, 11:03 AM, Aleksey Shipilev wrote: >>>> Hi, >>>> >>>> Not sure which group this belongs to, using the generic hotspot-dev at . >>>> >>>> vm/utilities/BitMap inconsistencies bugged me for quite some time: the >>>> mention of naked uintptr_t instead of properly typedef-ed bm_word_t >>>> alias; casting AllBits/NoBits constants of (luckily) the same type; >>>> other things like a benign inconsistency in init_pop_count_table >>>> new/free, etc. >>>> >>>> Here is a cleanup, please review: >>>> http://cr.openjdk.java.net/~shade/8059474/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8059474 >>>> >>>> Testing: >>>> JPRT, Nashorn/Octane on Linux/x86_64/fastdebug. >>>> >>>> Thanks, >>>> -Aleksey. > From mikael.gerdin at oracle.com Wed Oct 1 11:14:37 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 01 Oct 2014 13:14:37 +0200 Subject: RFR (XS) 8059474: Clean up vm/utilities/Bitmap type uses In-Reply-To: <542BD0C2.5040708@oracle.com> References: <542AC64C.1090401@oracle.com> <11673853.13tLNhCG5a@mgerdin03> <542BD0C2.5040708@oracle.com> Message-ID: <1702553.oe70Ucaim8@mgerdin03> Aleksey, On Wednesday 01 October 2014 14.00.34 Aleksey Shipilev wrote: > Hi Mikael, > > Thanks for a review. Truly, I missed that spot, done here: > http://cr.openjdk.java.net/~shade/8059474/webrev.01/ > > Testing: JPRT, Nashorn/Octane with Linux x86_64/fastdebug, > -XX:+ExecuteInternalVMTests > > If you are happy with this change, please sponsor: > http://cr.openjdk.java.net/~shade/8059474/8059474.changeset Looks good. I'll sponsor it. /Mikael > > -Aleksey. > > On 10/01/2014 11:36 AM, Mikael Gerdin wrote: > > Hi Aleksey, > > > > On Wednesday 01 October 2014 11.23.59 Aleksey Shipilev wrote: > >> Thanks for review, Coleen! > >> > >> Any GC guys around? Please take a look. > > > > In > > > > 338 bool BitMap::set_union_with_result(BitMap other) { > > 339 assert(size() == other.size(), "must have same size"); > > 340 bool changed = false; > > 341 bm_word_t* dest_map = map(); > > 342 bm_word_t* other_map = other.map(); > > 343 idx_t size = size_in_words(); > > 344 for (idx_t index = 0; index < size; index++) { > > 345 idx_t temp = map(index) | other_map[index]; > > 346 changed = changed || (temp != map(index)); > > 347 dest_map[index] = temp; > > 348 } > > 349 return changed; > > 350 } > > > > You changed one call to map() to use the local variable dest_map, can you > > make it consistently use the locals instead of calling map(index)? > > > > The rest of the change looks good, thanks for cleaning this up a bit. > > > > There are some tests in TestBitMap_test(), you can run them with > > -XX:+ExecuteInternalVMTests on a fastdebug VM. > > > > /Mikael > > > >> -Aleksey. > >> > >> On 10/01/2014 02:10 AM, Coleen Phillimore wrote: > >>> Aleksey, > >>> > >>> This looks good to me. GC code uses BitMap a lot and JPRT tests the > >>> different collectors so I think this is fine. Someone from the GC team > >>> should look at this also. > >>> > >>> Thanks! > >>> Coleen > >>> > >>> On 9/30/14, 11:03 AM, Aleksey Shipilev wrote: > >>>> Hi, > >>>> > >>>> Not sure which group this belongs to, using the generic hotspot-dev at . > >>>> > >>>> vm/utilities/BitMap inconsistencies bugged me for quite some time: the > >>>> mention of naked uintptr_t instead of properly typedef-ed bm_word_t > >>>> alias; casting AllBits/NoBits constants of (luckily) the same type; > >>>> other things like a benign inconsistency in init_pop_count_table > >>>> new/free, etc. > >>>> > >>>> Here is a cleanup, please review: > >>>> http://cr.openjdk.java.net/~shade/8059474/webrev.00/ > >>>> https://bugs.openjdk.java.net/browse/JDK-8059474 > >>>> > >>>> Testing: > >>>> JPRT, Nashorn/Octane on Linux/x86_64/fastdebug. > >>>> > >>>> Thanks, > >>>> -Aleksey. From frederic.parain at oracle.com Wed Oct 1 13:50:01 2014 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 01 Oct 2014 15:50:01 +0200 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <542B2841.2080401@oracle.com> References: <542AC0E8.9040409@oracle.com> <542B2841.2080401@oracle.com> Message-ID: <542C0689.8020106@oracle.com> Thanks Coleen, Fred On 10/01/2014 12:01 AM, Coleen Phillimore wrote: > > Fred, > > I reviewed this change. It looks great. Some of the functions removed > seem to be not only unused but dangerous. Some of these I have made > changes to that I didn't realize that the JVM didn't use these > functions. Thank you for doing this! > > Coleen > > On 9/30/14, 10:40 AM, Frederic Parain wrote: >> Hi all, >> >> Please review changes for bug JDK-8057777 "Cleanup of old >> and unused VM interfaces" >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8057777 >> >> This is basically a big cleanup of VM interfaces that are >> not used anymore by the JDK but have been kept in our code >> base for historical reasons (HotSpot Express for instance). >> These changesets remove these interfaces from both the >> JDK and the HotSpot side, and also perform some cleanup >> on code that directly referenced the removed interfaces. >> >> These changes do not modify the behavior of the Java >> classes impacted by the cleanup. >> >> VM interfaces removal has been approved by CCC and >> a Release Note has been prepared that explicitly list >> all the removed interfaces. >> >> Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core >> >> Webrevs: >> http://cr.openjdk.java.net/~fparain/8057777/ >> >> Thank you, >> >> Fred >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From erik.osterlund at lnu.se Wed Oct 1 18:32:41 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Wed, 1 Oct 2014 18:32:41 +0000 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: References: <54124F11.8060100@oracle.com> <8E69D7A0-CD8D-4EC6-B708-5F2C0098B183@lnu.se> <54197E53.9030307@oracle.com> Message-ID: Hi, There is now a new webrev with my jbyte cmpxchg changes here: http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01/ The change from last time is: 1. Fixed an issue where cmpxchgl was incorrectly emitted instead of cmpxchgb for one of the configurations as pointed out by Andrew Haley, cheers for finding that 2. Changed the "design" around a bit to make it easy to override the cmpxchgb for different platforms without having #if defined(PLATFORM_X) || defined(PLATFORMY) etc. in the headers.. If not explicitly overridden, the old general solution be used instead like normal and this should hence not break any of the different ports to other architectures not included in the main hotspot project. Jesper ran it through jprt and it was all green. Thanks for checking that! Would be nice if I could get some reviews. :) Thanks, Erik On 20 Sep 2014, at 23:53, Erik ?sterlund > wrote: I don't want to break the ported builds so I made a special variant of the third option where the x86 inline methods also have a #define next to them. The atomic.inline.hpp file then simply defines an inline Atomic::cmpxchg calling the general solution if there is no #define for an override. That way it's using variant three, but there is no need to write overrides for every platform port (which are sometimes in other repos) there is to simply run the default member function. We can add them one by one instead. :) Hope this seems satisfactory. Thanks, Erik On 17 Sep 2014, at 14:28, David Holmes > wrote: On 17/09/2014 9:13 PM, Erik ?sterlund wrote: I am back! Did you guys have time to do some thinking? I see three different solutions: 1. Good old class inheritance! Class Atomic is-a Atomic_YourArchHere is-a AtomicAbstract Using the CRTP (Curiously Recurring Template Pattern) for C++, this could be done without a virtual call where we want inlining. I would prefer this approach (here and elsewhere) but it is not a short-term option. 2. Similar except with the SFINAE idiom (Substitution Failure Is Not An Error) for C++, to pick the right overload based on statically determined constraints. E.g. define if Atomic::has_general_byte_CAS and based on whether this is defined or not, pick the general or specific overload variant of the CAS member function. Not sure what this one is but it sounds like a manual virtual dispatch - which seems not a good solution. 3. Simply make the current CAS a normal function which is called from billions of new inline method definitions that we have to create for every single architecture. I think the simple version of 3 is just move cmpxchg(jbtye) out of the shared code and define for each platform - there aren't that many and it is consistent with many of the other variants. What do we prefer here? Does anyone else have a better idea? Also, should I start a new thread or is it okay to post it here? Continuing this thread is fine by me. I think short-term the simple version of 3 is preferable. Thanks, David From david.holmes at oracle.com Wed Oct 1 19:41:27 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 02 Oct 2014 05:41:27 +1000 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: References: <54124F11.8060100@oracle.com> <8E69D7A0-CD8D-4EC6-B708-5F2C0098B183@lnu.se> <54197E53.9030307@oracle.com> Message-ID: <542C58E7.7050907@oracle.com> Hi Erik, Currently at JavaOne and then travelling back to Australia tomorrow. It will be Tuesday (Holiday Monday) before I can take another look at this. Sorry. David On 2/10/2014 4:32 AM, Erik ?sterlund wrote: > Hi, > > There is now a new webrev with my jbyte cmpxchg changes here: http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01/ > > The change from last time is: > 1. Fixed an issue where cmpxchgl was incorrectly emitted instead of cmpxchgb for one of the configurations as pointed out by Andrew Haley, cheers for finding that > 2. Changed the "design" around a bit to make it easy to override the cmpxchgb for different platforms without having #if defined(PLATFORM_X) || defined(PLATFORMY) etc. in the headers.. If not explicitly overridden, the old general solution be used instead like normal and this should hence not break any of the different ports to other architectures not included in the main hotspot project. > > Jesper ran it through jprt and it was all green. Thanks for checking that! > > Would be nice if I could get some reviews. :) > > Thanks, > Erik > > > On 20 Sep 2014, at 23:53, Erik ?sterlund > wrote: > > I don't want to break the ported builds so I made a special variant of the third option where the x86 inline methods also have a #define next to them. > The atomic.inline.hpp file then simply defines an inline Atomic::cmpxchg calling the general solution if there is no #define for an override. > > That way it's using variant three, but there is no need to write overrides for every platform port (which are sometimes in other repos) there is to simply run the default member function. > We can add them one by one instead. :) > > Hope this seems satisfactory. > > Thanks, > Erik > > On 17 Sep 2014, at 14:28, David Holmes > wrote: > > On 17/09/2014 9:13 PM, Erik ?sterlund wrote: > I am back! Did you guys have time to do some thinking? I see three different solutions: > > 1. Good old class inheritance! Class Atomic is-a Atomic_YourArchHere is-a AtomicAbstract > Using the CRTP (Curiously Recurring Template Pattern) for C++, this could be done without a virtual call where we want inlining. > > I would prefer this approach (here and elsewhere) but it is not a short-term option. > > 2. Similar except with the SFINAE idiom (Substitution Failure Is Not An Error) for C++, to pick the right overload based on statically determined constraints. > E.g. define if Atomic::has_general_byte_CAS and based on whether this is defined or not, pick the general or specific overload variant of the CAS member function. > > Not sure what this one is but it sounds like a manual virtual dispatch - which seems not a good solution. > > 3. Simply make the current CAS a normal function which is called from billions of new inline method definitions that we have to create for every single architecture. > > I think the simple version of 3 is just move cmpxchg(jbtye) out of the shared code and define for each platform - there aren't that many and it is consistent with many of the other variants. > > What do we prefer here? Does anyone else have a better idea? Also, should I start a new thread or is it okay to post it here? > > Continuing this thread is fine by me. > > I think short-term the simple version of 3 is preferable. > > Thanks, > David > From yasuenag at gmail.com Wed Oct 1 22:38:44 2014 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 02 Oct 2014 07:38:44 +0900 Subject: RFR: JDK-8059586: hs_err report should treat redirected core pattern. Message-ID: <542C8274.3010809@gmail.com> I'm in Hackergarten @ JavaOne :-) Hi all, I would like to enhance the messages in hs_err report. Modern Linux kernel can treat core dump with user process (e.g. ABRT) However, hs_err report cannot detect it. I think that hs_err report should output messages as below: ------------- Failed to write core dump. Core dumps may be treated with "/usr/sbin/chroot /proc/%P/root /usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e" ------------- I've uploaded webrev of this enhancement. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.00/ This patch works fine on Fedora20 x86_64. Thanks, Yasumasa From goetz.lindenmaier at sap.com Thu Oct 2 08:06:47 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 2 Oct 2014 08:06:47 +0000 Subject: RFR(M): 8059592: Recent bugfixes in ppc64 port. Message-ID: <4295855A5C1DE049A61835A1887419CC2CF0AB1E@DEWDFEMB12A.global.corp.sap> Hi, This change contains some bugfixes in the ppc64 coding, and some minor improvements. It only touches code used in the port. http://cr.openjdk.java.net/~goetz/webrevs/8059592-ppc_bugs/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8059592 Please review and test this change. I please need a sponsor. This change also should go to 8u40, please. Best regards, Goetz. From tobias.hartmann at oracle.com Thu Oct 2 09:17:59 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 02 Oct 2014 11:17:59 +0200 Subject: [9] RFR(XS): 8059596: VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize is set Message-ID: <542D1847.7090107@oracle.com> Hi, please review this small patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8059596 Webrev: http://cr.openjdk.java.net/~thartmann/8059596/webrev.00/ Problem: The VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize >= 240M is specified. The problem is that in Arguments::set_tiered_flags() the code cache size is increased by 5 if TieredCompilation is enabled. This should only be done for default values. Solution: Add missing FLAG_IS_DEFAULT(ReservedCodeCacheSize) check. Thanks, Tobias From aleksey.shipilev at oracle.com Thu Oct 2 09:27:44 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 02 Oct 2014 13:27:44 +0400 Subject: [9] RFR(XS): 8059596: VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize is set In-Reply-To: <542D1847.7090107@oracle.com> References: <542D1847.7090107@oracle.com> Message-ID: <542D1A90.5010408@oracle.com> On 10/02/2014 01:17 PM, Tobias Hartmann wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8059596 > Webrev: http://cr.openjdk.java.net/~thartmann/8059596/webrev.00/ The patch makes perfect sense to me. -Aleksey. (not a Reviewer) From tobias.hartmann at oracle.com Thu Oct 2 10:09:24 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 02 Oct 2014 12:09:24 +0200 Subject: [9] RFR(XS): 8059596: VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize is set In-Reply-To: <542D1A90.5010408@oracle.com> References: <542D1847.7090107@oracle.com> <542D1A90.5010408@oracle.com> Message-ID: <542D2454.9020908@oracle.com> Thanks, Aleksey. Can I get another review? Best, Tobias On 02.10.2014 11:27, Aleksey Shipilev wrote: > On 10/02/2014 01:17 PM, Tobias Hartmann wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059596 >> Webrev: http://cr.openjdk.java.net/~thartmann/8059596/webrev.00/ > The patch makes perfect sense to me. > > -Aleksey. (not a Reviewer) > > > From staffan.larsen at oracle.com Thu Oct 2 10:29:38 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 2 Oct 2014 12:29:38 +0200 Subject: [9] RFR(XS): 8059596: VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize is set In-Reply-To: <542D1847.7090107@oracle.com> References: <542D1847.7090107@oracle.com> Message-ID: <74C8A22E-565A-4A79-B310-DF64C3D0CCE9@oracle.com> Looks good! Thanks, /Staffan On 2 okt 2014, at 11:17, Tobias Hartmann wrote: > Hi, > > please review this small patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059596 > Webrev: http://cr.openjdk.java.net/~thartmann/8059596/webrev.00/ > > Problem: > The VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize >= 240M is specified. The problem is that in Arguments::set_tiered_flags() the code cache size is increased by 5 if TieredCompilation is enabled. This should only be done for default values. > > Solution: > Add missing FLAG_IS_DEFAULT(ReservedCodeCacheSize) check. > > Thanks, > Tobias From tobias.hartmann at oracle.com Thu Oct 2 10:44:55 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 02 Oct 2014 12:44:55 +0200 Subject: [9] RFR(XS): 8059596: VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize is set In-Reply-To: <74C8A22E-565A-4A79-B310-DF64C3D0CCE9@oracle.com> References: <542D1847.7090107@oracle.com> <74C8A22E-565A-4A79-B310-DF64C3D0CCE9@oracle.com> Message-ID: <542D2CA7.3070505@oracle.com> Thanks, Staffan. Best, Tobias On 02.10.2014 12:29, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 2 okt 2014, at 11:17, Tobias Hartmann wrote: > >> Hi, >> >> please review this small patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059596 >> Webrev: http://cr.openjdk.java.net/~thartmann/8059596/webrev.00/ >> >> Problem: >> The VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize >= 240M is specified. The problem is that in Arguments::set_tiered_flags() the code cache size is increased by 5 if TieredCompilation is enabled. This should only be done for default values. >> >> Solution: >> Add missing FLAG_IS_DEFAULT(ReservedCodeCacheSize) check. >> >> Thanks, >> Tobias From vladimir.x.ivanov at oracle.com Thu Oct 2 10:49:50 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 02 Oct 2014 14:49:50 +0400 Subject: [9] RFR(XS): 8059596: VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize is set In-Reply-To: <542D1847.7090107@oracle.com> References: <542D1847.7090107@oracle.com> Message-ID: <542D2DCE.3040407@oracle.com> The fix looks ok. FTR I find the whole logic in Arguments::set_tiered_flags very fragile. Considering all the complications we discussed privately, CodeCache::initialize_heaps() is a much better place to preserve the problematic code cache invariant [1]. But I'm fine with fixing that separately. Best regards, Vladimir Ivanov [1] NonMethodCodeHeapSize + NonProfiledCodeHeapSize + ProfiledCodeHeapSize) != ReservedCodeCacheSize On 10/2/14, 1:17 PM, Tobias Hartmann wrote: > Hi, > > please review this small patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059596 > Webrev: http://cr.openjdk.java.net/~thartmann/8059596/webrev.00/ > > Problem: > The VM startup fails with 'Invalid code heap sizes' if > -XX:ReservedCodeCacheSize >= 240M is specified. The problem is that in > Arguments::set_tiered_flags() the code cache size is increased by 5 if > TieredCompilation is enabled. This should only be done for default values. > > Solution: > Add missing FLAG_IS_DEFAULT(ReservedCodeCacheSize) check. > > Thanks, > Tobias From tobias.hartmann at oracle.com Thu Oct 2 10:56:42 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 02 Oct 2014 12:56:42 +0200 Subject: [9] RFR(XS): 8059596: VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize is set In-Reply-To: <542D2DCE.3040407@oracle.com> References: <542D1847.7090107@oracle.com> <542D2DCE.3040407@oracle.com> Message-ID: <542D2F6A.5040700@oracle.com> Hi Vladimir, thanks for the review. On 02.10.2014 12:49, Vladimir Ivanov wrote: > The fix looks ok. > > FTR I find the whole logic in Arguments::set_tiered_flags very fragile. > Considering all the complications we discussed privately, > CodeCache::initialize_heaps() is a much better place to preserve the > problematic code cache invariant [1]. But I'm fine with fixing that > separately. Yes, I agree. I'll file a RFE and fix that separately. Best, Tobias > > Best regards, > Vladimir Ivanov > > [1] NonMethodCodeHeapSize + NonProfiledCodeHeapSize + > ProfiledCodeHeapSize) != ReservedCodeCacheSize > > On 10/2/14, 1:17 PM, Tobias Hartmann wrote: >> Hi, >> >> please review this small patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059596 >> Webrev: http://cr.openjdk.java.net/~thartmann/8059596/webrev.00/ >> >> Problem: >> The VM startup fails with 'Invalid code heap sizes' if >> -XX:ReservedCodeCacheSize >= 240M is specified. The problem is that in >> Arguments::set_tiered_flags() the code cache size is increased by 5 if >> TieredCompilation is enabled. This should only be done for default >> values. >> >> Solution: >> Add missing FLAG_IS_DEFAULT(ReservedCodeCacheSize) check. >> >> Thanks, >> Tobias From stefan.karlsson at oracle.com Thu Oct 2 10:53:53 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 02 Oct 2014 12:53:53 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse Message-ID: <542D2EC1.5030303@oracle.com> Hi all, (The following patch changes HotSpot code in areas concerning GC, RT, and Compiler. So, it would be good to get reviews from all three teams.) Please, review this patch to optimize and parallelize the CodeCache part of MetadaOnStackMark. G1 performance measurements showed longer than expected remark times on an application using a lot of nmethods and Metadata. The cause for this performance regression was the call to CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in MetadataOnStackMark. This code path is only taken when class redefinition is used. Class redefinition is typically used in monitoring and diagnostic frameworks. With this patch we now: 1) Filter out duplicate Metadata* entries instead of storing a Metadata* per visited metadata reference. 2) Collect the set of Metadata* entries in parallel. The code piggy-backs on the parallel CodeCache cleaning task. http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8056240 Functional testing: JPRT, Kitchensink, parallel_class_unloading, unit tests Performance testing: CRM Fuse - where the regression was found The patch changes HotSpot code in areas concerning GC, RT, Compiler, and Serviceability. It would be good to get some reviews from the other teams, and not only from the GC team. thanks, StefanK From aph at redhat.com Thu Oct 2 15:50:45 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 02 Oct 2014 16:50:45 +0100 Subject: RFD: Add Linux/AArch64 to the set of supported OpenJDK platforms Message-ID: <542D7455.3020807@redhat.com> https://bugs.openjdk.java.net/browse/JDK-8044552 http://openjdk.java.net/jeps/8044552 The AArch64 port has been complete for some time, and the rate of churn has slowed to the point where I believe it is stable enough to be moved into the mainline sources. It has passed the full JCK on JDK 7 and 8, but as yet there is no JCK 9, so I can say nothing about that. We are regularly testing using jtreg, Hadoop, and a bunch of other tests, and our results are similar to the same tests on x86. I hope that this process will be less involved and require less effort from approvers (at Oracle and elsewhere) than that for the Power PC port. I believe this because there are few changes to shared code beyond the trivial #ifdefs for header files which appear in many places. In a few places we've had to #ifdef out code which is in src/share but makes architectural assumptions which are not valid on AArch64. So, our proposal as detailed in the JEP is to create a staging forest which at the start will be a clone of the current JDK9. This staging forest will have jcheck fully enabled (unlike the AArch64 development repositories). We will then submit webrevs for approval to the appropriate groups, and then check them in to the staging forest. I presume that for each webrev it will be necessary to create a Jira Issue. A few questions arise: To which mailing lists should requests for approval be sent? I'm guessing hotspot-dev for the HotSpot patches, and jdk9-dev for everything else. What should the granularity of the webrevs be? I don't think that any subset of the src/cpu/aarch64 directory would make sense, but it's a big bite to chew. The JEP, which was based on that for the Power PC, talks about a more detailed Integration Plan in the AArch64 Port OpenJDK Wiki Space, but I have no plans beyond submitting webrevs for approval. Is there anything else we should do before creating issues and submitting webrevs? Thanks, Andrew. From coleen.phillimore at oracle.com Thu Oct 2 15:59:33 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 02 Oct 2014 11:59:33 -0400 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <542D2EC1.5030303@oracle.com> References: <542D2EC1.5030303@oracle.com> Message-ID: <542D7665.70401@oracle.com> This is going to take a while to review since it's so complicated. One thing, I've been meaning to take on_stack out of access_flags in method.hpp because there are other flags in method where it can be added. That would eliminate the need for the accessFlags.hpp change. Can you move it? Coleen On 10/2/14, 6:53 AM, Stefan Karlsson wrote: > Hi all, > > (The following patch changes HotSpot code in areas concerning GC, RT, > and Compiler. So, it would be good to get reviews from all three teams.) > > Please, review this patch to optimize and parallelize the CodeCache > part of MetadaOnStackMark. > > G1 performance measurements showed longer than expected remark times > on an application using a lot of nmethods and Metadata. The cause for > this performance regression was the call to > CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in > MetadataOnStackMark. This code path is only taken when class > redefinition is used. Class redefinition is typically used in > monitoring and diagnostic frameworks. > > With this patch we now: > 1) Filter out duplicate Metadata* entries instead of storing a > Metadata* per visited metadata reference. > 2) Collect the set of Metadata* entries in parallel. The code > piggy-backs on the parallel CodeCache cleaning task. > > http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8056240 > > Functional testing: > JPRT, Kitchensink, parallel_class_unloading, unit tests > > Performance testing: > CRM Fuse - where the regression was found > > The patch changes HotSpot code in areas concerning GC, RT, Compiler, > and Serviceability. It would be good to get some reviews from the > other teams, and not only from the GC team. > > thanks, > StefanK From vladimir.kozlov at oracle.com Thu Oct 2 19:20:21 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 02 Oct 2014 12:20:21 -0700 Subject: RFR(M): 8059592: Recent bugfixes in ppc64 port. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF0AB1E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF0AB1E@DEWDFEMB12A.global.corp.sap> Message-ID: <542DA575.3040701@oracle.com> Looks fine. One question is how you can have failing state during code generation?: if (Compile::current()->env()->failing()) { return; } // Code cache may be full. There should be bailout in opto/output.cpp when codecache is full. Did it happen because estimated buffer size was less then needed? Thanks, Vladimir On 10/2/14 1:06 AM, Lindenmaier, Goetz wrote: > Hi, > > This change contains some bugfixes in the ppc64 coding, and some minor > improvements. It only touches code used in the port. > http://cr.openjdk.java.net/~goetz/webrevs/8059592-ppc_bugs/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8059592 > > Please review and test this change. I please need a sponsor. > This change also should go to 8u40, please. > > Best regards, > Goetz. > > From erik.osterlund at lnu.se Fri Oct 3 00:33:14 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Fri, 3 Oct 2014 00:33:14 +0000 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: <542C58E7.7050907@oracle.com> References: <54124F11.8060100@oracle.com> <8E69D7A0-CD8D-4EC6-B708-5F2C0098B183@lnu.se> <54197E53.9030307@oracle.com> , <542C58E7.7050907@oracle.com> Message-ID: <59611879-FD5F-40EB-8F78-AB095789154D@lnu.se> G'Day David, No problem mate! Rage on at JavaOne, hope it's a ripper and talk to you when you get back to Australia mate. ;) Thanks, /Erik > On 1 okt 2014, at 21:41, David Holmes wrote: > > Hi Erik, > > Currently at JavaOne and then travelling back to Australia tomorrow. It will be Tuesday (Holiday Monday) before I can take another look at this. > > Sorry. > > David > >> On 2/10/2014 4:32 AM, Erik ?sterlund wrote: >> Hi, >> >> There is now a new webrev with my jbyte cmpxchg changes here: http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01/ >> >> The change from last time is: >> 1. Fixed an issue where cmpxchgl was incorrectly emitted instead of cmpxchgb for one of the configurations as pointed out by Andrew Haley, cheers for finding that >> 2. Changed the "design" around a bit to make it easy to override the cmpxchgb for different platforms without having #if defined(PLATFORM_X) || defined(PLATFORMY) etc. in the headers.. If not explicitly overridden, the old general solution be used instead like normal and this should hence not break any of the different ports to other architectures not included in the main hotspot project. >> >> Jesper ran it through jprt and it was all green. Thanks for checking that! >> >> Would be nice if I could get some reviews. :) >> >> Thanks, >> Erik >> >> >> On 20 Sep 2014, at 23:53, Erik ?sterlund > wrote: >> >> I don't want to break the ported builds so I made a special variant of the third option where the x86 inline methods also have a #define next to them. >> The atomic.inline.hpp file then simply defines an inline Atomic::cmpxchg calling the general solution if there is no #define for an override. >> >> That way it's using variant three, but there is no need to write overrides for every platform port (which are sometimes in other repos) there is to simply run the default member function. >> We can add them one by one instead. :) >> >> Hope this seems satisfactory. >> >> Thanks, >> Erik >> >> On 17 Sep 2014, at 14:28, David Holmes > wrote: >> >> On 17/09/2014 9:13 PM, Erik ?sterlund wrote: >> I am back! Did you guys have time to do some thinking? I see three different solutions: >> >> 1. Good old class inheritance! Class Atomic is-a Atomic_YourArchHere is-a AtomicAbstract >> Using the CRTP (Curiously Recurring Template Pattern) for C++, this could be done without a virtual call where we want inlining. >> >> I would prefer this approach (here and elsewhere) but it is not a short-term option. >> >> 2. Similar except with the SFINAE idiom (Substitution Failure Is Not An Error) for C++, to pick the right overload based on statically determined constraints. >> E.g. define if Atomic::has_general_byte_CAS and based on whether this is defined or not, pick the general or specific overload variant of the CAS member function. >> >> Not sure what this one is but it sounds like a manual virtual dispatch - which seems not a good solution. >> >> 3. Simply make the current CAS a normal function which is called from billions of new inline method definitions that we have to create for every single architecture. >> >> I think the simple version of 3 is just move cmpxchg(jbtye) out of the shared code and define for each platform - there aren't that many and it is consistent with many of the other variants. >> >> What do we prefer here? Does anyone else have a better idea? Also, should I start a new thread or is it okay to post it here? >> >> Continuing this thread is fine by me. >> >> I think short-term the simple version of 3 is preferable. >> >> Thanks, >> David >> From boris.molodenkov at oracle.com Fri Oct 3 11:00:16 2014 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Fri, 03 Oct 2014 15:00:16 +0400 Subject: [8u40] Request for approval: backport of JDK-8057165 In-Reply-To: <542E8041.1010101@oracle.com> References: <542E8041.1010101@oracle.com> Message-ID: <542E81C0.9000602@oracle.com> Sorry, Latest webrev is http://cr.openjdk.java.net/~fzhinkin/bmoloden/8057165/webrev.01/ Boris On 10/03/2014 02:53 PM, Boris Molodenkov wrote: > Hi All, > > I would like to backport fix for JDK-8057165 to 8u40. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8057165 > Webrev: http://cr.openjdk.java.net/~fzhinkin/bmoloden/8057165/webrev.00/ > Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3a59d786378b > Review thread for original fix: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-September/015514.html > > > testing: jprt > > Thanks, > Boris > From bertrand.delsart at oracle.com Fri Oct 3 12:42:34 2014 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Fri, 03 Oct 2014 14:42:34 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <542D2EC1.5030303@oracle.com> References: <542D2EC1.5030303@oracle.com> Message-ID: <542E99BA.2000207@oracle.com> Hi Stefan, I'll do a more in depth review next week but here are a few quick comments to keep us busy in between :-) -1- The fact that set_on_stack() is now implemented by just a atomic_try_set_bits seems dangerous. We could end up not setting the JVM_ACC_ON_STACK flag. In your case, you may be sure that the only concurrent operation that might happen is a setting of the same flag but this looks error prone with respect to future possible usages of that method (or new concurrent operations). I would prefer to be sure the flag has really been set when exiting from set_on_stack(), as was the case before. More generally, the semantic of the new atomic_try_set_bits is IMHO dangerous. It returns false both if the bits were already set or if another flag was changed concurrently (in which case the bits may not be set). This should at least be clearly documented in the .hpp file. An alternative would be for atomic_try_set_bits to return the current value when the cas failed or was not performed. It would be up to the caller to decide whether to loop or not (by checking whether the bits are set in the returned value). -2- There is one part of the change that does not seem to be described in the RFR or the CR. You added something to keep alive some metadata in case of klass redefinition (the mark_on_stack stuff in nmethod.cpp, which for instance now marks the content of the CompiledICHolder). Did you just change when that marking was performed or is that a marking that we were not doing previously ? (sorry, cannot review it all currently and see whether that marking was indeed removed elsewhere) Regards, Bertrand On 02/10/14 12:53, Stefan Karlsson wrote: > Hi all, > > (The following patch changes HotSpot code in areas concerning GC, RT, > and Compiler. So, it would be good to get reviews from all three teams.) > > Please, review this patch to optimize and parallelize the CodeCache part > of MetadaOnStackMark. > > G1 performance measurements showed longer than expected remark times on > an application using a lot of nmethods and Metadata. The cause for this > performance regression was the call to > CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in > MetadataOnStackMark. This code path is only taken when class > redefinition is used. Class redefinition is typically used in monitoring > and diagnostic frameworks. > > With this patch we now: > 1) Filter out duplicate Metadata* entries instead of storing a Metadata* > per visited metadata reference. > 2) Collect the set of Metadata* entries in parallel. The code > piggy-backs on the parallel CodeCache cleaning task. > > http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8056240 > > Functional testing: > JPRT, Kitchensink, parallel_class_unloading, unit tests > > Performance testing: > CRM Fuse - where the regression was found > > The patch changes HotSpot code in areas concerning GC, RT, Compiler, and > Serviceability. It would be good to get some reviews from the other > teams, and not only from the GC team. > > thanks, > StefanK -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38334 Saint Ismier, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From bertrand.delsart at oracle.com Fri Oct 3 12:47:45 2014 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Fri, 03 Oct 2014 14:47:45 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <542E99BA.2000207@oracle.com> References: <542D2EC1.5030303@oracle.com> <542E99BA.2000207@oracle.com> Message-ID: <542E9AF1.8080201@oracle.com> On 03/10/14 14:42, Bertrand Delsart wrote: > Hi Stefan, > > I'll do a more in depth review next week but here are a few quick > comments to keep us busy in between :-) > > -1- The fact that set_on_stack() is now implemented by just a > atomic_try_set_bits seems dangerous. > > We could end up not setting the JVM_ACC_ON_STACK flag. > > In your case, you may be sure that the only concurrent operation that > might happen is a setting of the same flag but this looks error prone > with respect to future possible usages of that method (or new concurrent > operations). > > I would prefer to be sure the flag has really been set when exiting from > set_on_stack(), as was the case before. Or, if you really do not want to loop, to add an assert verifying that your concurrency hypothesis is still correct by checking that the flag is indeed always set when exiting from the atomic_try_set_bits. > > More generally, the semantic of the new atomic_try_set_bits is IMHO > dangerous. It returns false both if the bits were already set or if > another flag was changed concurrently (in which case the bits may not be > set). This should at least be clearly documented in the .hpp file. > > An alternative would be for atomic_try_set_bits to return the current > value when the cas failed or was not performed. It would be up to the > caller to decide whether to loop or not (by checking whether the bits > are set in the returned value). > > -2- There is one part of the change that does not seem to be described > in the RFR or the CR. You added something to keep alive some metadata in > case of klass redefinition (the mark_on_stack stuff in nmethod.cpp, > which for instance now marks the content of the CompiledICHolder). > > Did you just change when that marking was performed or is that a marking > that we were not doing previously ? (sorry, cannot review it all > currently and see whether that marking was indeed removed elsewhere) > > Regards, > > Bertrand > > On 02/10/14 12:53, Stefan Karlsson wrote: >> Hi all, >> >> (The following patch changes HotSpot code in areas concerning GC, RT, >> and Compiler. So, it would be good to get reviews from all three teams.) >> >> Please, review this patch to optimize and parallelize the CodeCache part >> of MetadaOnStackMark. >> >> G1 performance measurements showed longer than expected remark times on >> an application using a lot of nmethods and Metadata. The cause for this >> performance regression was the call to >> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >> MetadataOnStackMark. This code path is only taken when class >> redefinition is used. Class redefinition is typically used in monitoring >> and diagnostic frameworks. >> >> With this patch we now: >> 1) Filter out duplicate Metadata* entries instead of storing a Metadata* >> per visited metadata reference. >> 2) Collect the set of Metadata* entries in parallel. The code >> piggy-backs on the parallel CodeCache cleaning task. >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8056240 >> >> Functional testing: >> JPRT, Kitchensink, parallel_class_unloading, unit tests >> >> Performance testing: >> CRM Fuse - where the regression was found >> >> The patch changes HotSpot code in areas concerning GC, RT, Compiler, and >> Serviceability. It would be good to get some reviews from the other >> teams, and not only from the GC team. >> >> thanks, >> StefanK > > -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38334 Saint Ismier, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From harold.seigel at oracle.com Fri Oct 3 12:54:07 2014 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 03 Oct 2014 08:54:07 -0400 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <542C0689.8020106@oracle.com> References: <542AC0E8.9040409@oracle.com> <542B2841.2080401@oracle.com> <542C0689.8020106@oracle.com> Message-ID: <542E9C6F.6090800@oracle.com> Hi Fred, It's great to see all this code go away. Since JVM_AllocateNewObject() is getting removed, can JavaCalls::call_default_constructor() also be removed? Also, why were JVM_DesiredAssertionStatus and JVM_DoPrivileged moved in make/solaris/makefiles/mapfile-vers ? They are no longer in alphabetical order. Thanks, Harold On 10/1/2014 9:50 AM, Frederic Parain wrote: > Thanks Coleen, > > Fred > > On 10/01/2014 12:01 AM, Coleen Phillimore wrote: >> >> Fred, >> >> I reviewed this change. It looks great. Some of the functions removed >> seem to be not only unused but dangerous. Some of these I have made >> changes to that I didn't realize that the JVM didn't use these >> functions. Thank you for doing this! >> >> Coleen >> >> On 9/30/14, 10:40 AM, Frederic Parain wrote: >>> Hi all, >>> >>> Please review changes for bug JDK-8057777 "Cleanup of old >>> and unused VM interfaces" >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8057777 >>> >>> This is basically a big cleanup of VM interfaces that are >>> not used anymore by the JDK but have been kept in our code >>> base for historical reasons (HotSpot Express for instance). >>> These changesets remove these interfaces from both the >>> JDK and the HotSpot side, and also perform some cleanup >>> on code that directly referenced the removed interfaces. >>> >>> These changes do not modify the behavior of the Java >>> classes impacted by the cleanup. >>> >>> VM interfaces removal has been approved by CCC and >>> a Release Note has been prepared that explicitly list >>> all the removed interfaces. >>> >>> Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~fparain/8057777/ >>> >>> Thank you, >>> >>> Fred >>> >> > From stefan.karlsson at oracle.com Fri Oct 3 13:38:18 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 03 Oct 2014 15:38:18 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <542E99BA.2000207@oracle.com> References: <542D2EC1.5030303@oracle.com> <542E99BA.2000207@oracle.com> Message-ID: <542EA6CA.5020502@oracle.com> Hi Betrand, Thanks for taking the time to review this. On 2014-10-03 14:42, Bertrand Delsart wrote: > Hi Stefan, > > I'll do a more in depth review next week but here are a few quick > comments to keep us busy in between :-) > > -1- The fact that set_on_stack() is now implemented by just a > atomic_try_set_bits seems dangerous. > > We could end up not setting the JVM_ACC_ON_STACK flag. > > In your case, you may be sure that the only concurrent operation that > might happen is a setting of the same flag but this looks error prone > with respect to future possible usages of that method (or new > concurrent operations). OK. I see your point about future-proofing this. Is this currently broken in that sense that two racing threads can both fail to set the on_stack bit? > > I would prefer to be sure the flag has really been set when exiting > from set_on_stack(), as was the case before. > > More generally, the semantic of the new atomic_try_set_bits is IMHO > dangerous. It returns false both if the bits were already set or if > another flag was changed concurrently (in which case the bits may not > be set). This should at least be clearly documented in the .hpp file. > > > An alternative would be for atomic_try_set_bits to return the current > value when the cas failed or was not performed. It would be up to the > caller to decide whether to loop or not (by checking whether the bits > are set in the returned value). I can change the code to use a slightly altered version of atomic_set_bit that returns 'true' if it was this thread that succeeded in setting the bit. > > -2- There is one part of the change that does not seem to be described > in the RFR or the CR. You added something to keep alive some metadata > in case of klass redefinition (the mark_on_stack stuff in nmethod.cpp, > which for instance now marks the content of the CompiledICHolder). > > Did you just change when that marking was performed or is that a > marking that we were not doing previously ? (sorry, cannot review it > all currently and see whether that marking was indeed removed elsewhere) Before my change, this code was done by the call to: CodeCache::alive_nmethods_do(nmethod::mark_on_stack); if you look at: static void mark_on_stack(nmethod* nm) { nm->metadata_do(Metadata::mark_on_stack); } and then: // Iterate over metadata calling this function. Used by RedefineClasses void nmethod::metadata_do(void f(Metadata*)) { address low_boundary = verified_entry_point(); if (is_not_entrant()) { low_boundary += NativeJump::instruction_size; // %%% Note: On SPARC we patch only a 4-byte trap, not a full NativeJump. // (See comment above.) } { // Visit all immediate references that are embedded in the instruction stream. RelocIterator iter(this, low_boundary); while (iter.next()) { if (iter.type() == relocInfo::metadata_type ) { metadata_Relocation* r = iter.metadata_reloc(); // In this lmetadata, we must only follow those metadatas directly embedded in // the code. Other metadatas (oop_index>0) are seen as part of // the metadata section below. assert(1 == (r->metadata_is_immediate()) + (r->metadata_addr() >= metadata_begin() && r->metadata_addr() < metadata_end()), "metadata must be found in exactly one place"); if (r->metadata_is_immediate() && r->metadata_value() != NULL) { Metadata* md = r->metadata_value(); if (md != _method) f(md); } } else if (iter.type() == relocInfo::virtual_call_type) { // Check compiledIC holders associated with this nmethod CompiledIC *ic = CompiledIC_at(&iter); if (ic->is_icholder_call()) { CompiledICHolder* cichk = ic->cached_icholder(); f(cichk->holder_method()); f(cichk->holder_klass()); } else { Metadata* ic_oop = ic->cached_metadata(); if (ic_oop != NULL) { f(ic_oop); } } } } } // Visit the metadata section for (Metadata** p = metadata_begin(); p < metadata_end(); p++) { if (*p == Universe::non_oop_word() || *p == NULL) continue; // skip non-oops Metadata* md = *p; f(md); } // Call function Method*, not embedded in these other places. if (_method != NULL) f(_method); } you see that the above calls to f(...) correspond to the added mark_on_stack sections in nmethod.cpp. So the code is now duplicated and added to places where they don't really belong, and that breaks some of the current abstraction. This is done just to be able to skip having to do an extra pass of the expensive "for all nmethods { for all relocInfos {} }" code. If we could get the RelocIterator code to become much cheaper, then we could remove all that added code and just use nmethod::metadata_do instead. That would also enable us to clean up some of the code complexity that has been added to the codecache/nmethod cleaning code. thanks, StefanK > > Regards, > > Bertrand > > On 02/10/14 12:53, Stefan Karlsson wrote: >> Hi all, >> >> (The following patch changes HotSpot code in areas concerning GC, RT, >> and Compiler. So, it would be good to get reviews from all three teams.) >> >> Please, review this patch to optimize and parallelize the CodeCache part >> of MetadaOnStackMark. >> >> G1 performance measurements showed longer than expected remark times on >> an application using a lot of nmethods and Metadata. The cause for this >> performance regression was the call to >> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >> MetadataOnStackMark. This code path is only taken when class >> redefinition is used. Class redefinition is typically used in monitoring >> and diagnostic frameworks. >> >> With this patch we now: >> 1) Filter out duplicate Metadata* entries instead of storing a Metadata* >> per visited metadata reference. >> 2) Collect the set of Metadata* entries in parallel. The code >> piggy-backs on the parallel CodeCache cleaning task. >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8056240 >> >> Functional testing: >> JPRT, Kitchensink, parallel_class_unloading, unit tests >> >> Performance testing: >> CRM Fuse - where the regression was found >> >> The patch changes HotSpot code in areas concerning GC, RT, Compiler, and >> Serviceability. It would be good to get some reviews from the other >> teams, and not only from the GC team. >> >> thanks, >> StefanK > > From stefan.karlsson at oracle.com Fri Oct 3 13:39:59 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 03 Oct 2014 15:39:59 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <542EA6CA.5020502@oracle.com> References: <542D2EC1.5030303@oracle.com> <542E99BA.2000207@oracle.com> <542EA6CA.5020502@oracle.com> Message-ID: <542EA72F.6070104@oracle.com> On 2014-10-03 15:38, Stefan Karlsson wrote: > Hi Betrand, Sorry for misspelling your name, Bertrand. StefanK > > Thanks for taking the time to review this. > > On 2014-10-03 14:42, Bertrand Delsart wrote: >> Hi Stefan, >> >> I'll do a more in depth review next week but here are a few quick >> comments to keep us busy in between :-) >> >> -1- The fact that set_on_stack() is now implemented by just a >> atomic_try_set_bits seems dangerous. >> >> We could end up not setting the JVM_ACC_ON_STACK flag. >> >> In your case, you may be sure that the only concurrent operation that >> might happen is a setting of the same flag but this looks error prone >> with respect to future possible usages of that method (or new >> concurrent operations). > > OK. I see your point about future-proofing this. Is this currently > broken in that sense that two racing threads can both fail to set the > on_stack bit? > >> >> I would prefer to be sure the flag has really been set when exiting >> from set_on_stack(), as was the case before. >> >> More generally, the semantic of the new atomic_try_set_bits is IMHO >> dangerous. It returns false both if the bits were already set or if >> another flag was changed concurrently (in which case the bits may not >> be set). This should at least be clearly documented in the .hpp file. > >> >> >> An alternative would be for atomic_try_set_bits to return the current >> value when the cas failed or was not performed. It would be up to the >> caller to decide whether to loop or not (by checking whether the bits >> are set in the returned value). > > I can change the code to use a slightly altered version of > atomic_set_bit that returns 'true' if it was this thread that > succeeded in setting the bit. > >> >> -2- There is one part of the change that does not seem to be >> described in the RFR or the CR. You added something to keep alive >> some metadata in case of klass redefinition (the mark_on_stack stuff >> in nmethod.cpp, which for instance now marks the content of the >> CompiledICHolder). >> >> Did you just change when that marking was performed or is that a >> marking that we were not doing previously ? (sorry, cannot review it >> all currently and see whether that marking was indeed removed elsewhere) > > Before my change, this code was done by the call to: > CodeCache::alive_nmethods_do(nmethod::mark_on_stack); > > if you look at: > static void mark_on_stack(nmethod* nm) { > nm->metadata_do(Metadata::mark_on_stack); > } > > and then: > // Iterate over metadata calling this function. Used by RedefineClasses > void nmethod::metadata_do(void f(Metadata*)) { > address low_boundary = verified_entry_point(); > if (is_not_entrant()) { > low_boundary += NativeJump::instruction_size; > // %%% Note: On SPARC we patch only a 4-byte trap, not a full > NativeJump. > // (See comment above.) > } > { > // Visit all immediate references that are embedded in the > instruction stream. > RelocIterator iter(this, low_boundary); > while (iter.next()) { > if (iter.type() == relocInfo::metadata_type ) { > metadata_Relocation* r = iter.metadata_reloc(); > // In this lmetadata, we must only follow those metadatas > directly embedded in > // the code. Other metadatas (oop_index>0) are seen as part of > // the metadata section below. > assert(1 == (r->metadata_is_immediate()) + > (r->metadata_addr() >= metadata_begin() && > r->metadata_addr() < metadata_end()), > "metadata must be found in exactly one place"); > if (r->metadata_is_immediate() && r->metadata_value() != NULL) { > Metadata* md = r->metadata_value(); > if (md != _method) f(md); > } > } else if (iter.type() == relocInfo::virtual_call_type) { > // Check compiledIC holders associated with this nmethod > CompiledIC *ic = CompiledIC_at(&iter); > if (ic->is_icholder_call()) { > CompiledICHolder* cichk = ic->cached_icholder(); > f(cichk->holder_method()); > f(cichk->holder_klass()); > } else { > Metadata* ic_oop = ic->cached_metadata(); > if (ic_oop != NULL) { > f(ic_oop); > } > } > } > } > } > > // Visit the metadata section > for (Metadata** p = metadata_begin(); p < metadata_end(); p++) { > if (*p == Universe::non_oop_word() || *p == NULL) continue; // > skip non-oops > Metadata* md = *p; > f(md); > } > > // Call function Method*, not embedded in these other places. > if (_method != NULL) f(_method); > } > > you see that the above calls to f(...) correspond to the added > mark_on_stack sections in nmethod.cpp. > > So the code is now duplicated and added to places where they don't > really belong, and that breaks some of the current abstraction. This > is done just to be able to skip having to do an extra pass of the > expensive "for all nmethods { for all relocInfos {} }" code. If we > could get the RelocIterator code to become much cheaper, then we could > remove all that added code and just use nmethod::metadata_do instead. > That would also enable us to clean up some of the code complexity that > has been added to the codecache/nmethod cleaning code. > > thanks, > StefanK > >> >> Regards, >> >> Bertrand >> >> On 02/10/14 12:53, Stefan Karlsson wrote: >>> Hi all, >>> >>> (The following patch changes HotSpot code in areas concerning GC, RT, >>> and Compiler. So, it would be good to get reviews from all three >>> teams.) >>> >>> Please, review this patch to optimize and parallelize the CodeCache >>> part >>> of MetadaOnStackMark. >>> >>> G1 performance measurements showed longer than expected remark times on >>> an application using a lot of nmethods and Metadata. The cause for this >>> performance regression was the call to >>> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >>> MetadataOnStackMark. This code path is only taken when class >>> redefinition is used. Class redefinition is typically used in >>> monitoring >>> and diagnostic frameworks. >>> >>> With this patch we now: >>> 1) Filter out duplicate Metadata* entries instead of storing a >>> Metadata* >>> per visited metadata reference. >>> 2) Collect the set of Metadata* entries in parallel. The code >>> piggy-backs on the parallel CodeCache cleaning task. >>> >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8056240 >>> >>> Functional testing: >>> JPRT, Kitchensink, parallel_class_unloading, unit tests >>> >>> Performance testing: >>> CRM Fuse - where the regression was found >>> >>> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >>> and >>> Serviceability. It would be good to get some reviews from the other >>> teams, and not only from the GC team. >>> >>> thanks, >>> StefanK >> >> > From bertrand.delsart at oracle.com Fri Oct 3 14:37:35 2014 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Fri, 03 Oct 2014 16:37:35 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <542EA6CA.5020502@oracle.com> References: <542D2EC1.5030303@oracle.com> <542E99BA.2000207@oracle.com> <542EA6CA.5020502@oracle.com> Message-ID: <542EB4AF.3080002@oracle.com> On 03/10/14 15:38, Stefan Karlsson wrote: > Hi Betrand, > > Thanks for taking the time to review this. > > On 2014-10-03 14:42, Bertrand Delsart wrote: >> Hi Stefan, >> >> I'll do a more in depth review next week but here are a few quick >> comments to keep us busy in between :-) >> >> -1- The fact that set_on_stack() is now implemented by just a >> atomic_try_set_bits seems dangerous. >> >> We could end up not setting the JVM_ACC_ON_STACK flag. >> >> In your case, you may be sure that the only concurrent operation that >> might happen is a setting of the same flag but this looks error prone >> with respect to future possible usages of that method (or new >> concurrent operations). > > OK. I see your point about future-proofing this. Is this currently > broken in that sense that two racing threads can both fail to set the > on_stack bit? cmpxchg is supposed to be robust against spurious CAS failure. Hence, the only danger is if indeed one of our threads concurrently modifies the flags for another reason while someone is using MetadataOnStackMark This is not likely but IMHO, the gains of avoiding a loop may not be worth the risks. As stated in my following e-mail, I would also agree if you just add an assert(on_stack()) after the atomic_try_set_bits in set_on_stack. That would allow us to detect use cases we had not anticipated. >> >> I would prefer to be sure the flag has really been set when exiting >> from set_on_stack(), as was the case before. >> >> More generally, the semantic of the new atomic_try_set_bits is IMHO >> dangerous. It returns false both if the bits were already set or if >> another flag was changed concurrently (in which case the bits may not >> be set). This should at least be clearly documented in the .hpp file. > >> >> >> An alternative would be for atomic_try_set_bits to return the current >> value when the cas failed or was not performed. It would be up to the >> caller to decide whether to loop or not (by checking whether the bits >> are set in the returned value). > > I can change the code to use a slightly altered version of > atomic_set_bit that returns 'true' if it was this thread that succeeded > in setting the bit. > >> -2- There is one part of the change that does not seem to be described >> in the RFR or the CR. You added something to keep alive some metadata >> in case of klass redefinition (the mark_on_stack stuff in nmethod.cpp, >> which for instance now marks the content of the CompiledICHolder). >> >> Did you just change when that marking was performed or is that a >> marking that we were not doing previously ? (sorry, cannot review it >> all currently and see whether that marking was indeed removed elsewhere) > > Before my change, this code was done by the call to: > CodeCache::alive_nmethods_do(nmethod::mark_on_stack); > > if you look at: > static void mark_on_stack(nmethod* nm) { > nm->metadata_do(Metadata::mark_on_stack); > } > > and then: > // Iterate over metadata calling this function. Used by RedefineClasses > void nmethod::metadata_do(void f(Metadata*)) { > address low_boundary = verified_entry_point(); > if (is_not_entrant()) { > low_boundary += NativeJump::instruction_size; > // %%% Note: On SPARC we patch only a 4-byte trap, not a full > NativeJump. > // (See comment above.) > } > { > // Visit all immediate references that are embedded in the > instruction stream. > RelocIterator iter(this, low_boundary); > while (iter.next()) { > if (iter.type() == relocInfo::metadata_type ) { > metadata_Relocation* r = iter.metadata_reloc(); > // In this lmetadata, we must only follow those metadatas > directly embedded in > // the code. Other metadatas (oop_index>0) are seen as part of > // the metadata section below. > assert(1 == (r->metadata_is_immediate()) + > (r->metadata_addr() >= metadata_begin() && > r->metadata_addr() < metadata_end()), > "metadata must be found in exactly one place"); > if (r->metadata_is_immediate() && r->metadata_value() != NULL) { > Metadata* md = r->metadata_value(); > if (md != _method) f(md); > } > } else if (iter.type() == relocInfo::virtual_call_type) { > // Check compiledIC holders associated with this nmethod > CompiledIC *ic = CompiledIC_at(&iter); > if (ic->is_icholder_call()) { > CompiledICHolder* cichk = ic->cached_icholder(); > f(cichk->holder_method()); > f(cichk->holder_klass()); > } else { > Metadata* ic_oop = ic->cached_metadata(); > if (ic_oop != NULL) { > f(ic_oop); > } > } > } > } > } > > // Visit the metadata section > for (Metadata** p = metadata_begin(); p < metadata_end(); p++) { > if (*p == Universe::non_oop_word() || *p == NULL) continue; // > skip non-oops > Metadata* md = *p; > f(md); > } > > // Call function Method*, not embedded in these other places. > if (_method != NULL) f(_method); > } > > you see that the above calls to f(...) correspond to the added > mark_on_stack sections in nmethod.cpp. > > So the code is now duplicated and added to places where they don't > really belong, and that breaks some of the current abstraction. This is > done just to be able to skip having to do an extra pass of the expensive > "for all nmethods { for all relocInfos {} }" code. If we could get the > RelocIterator code to become much cheaper, then we could remove all that > added code and just use nmethod::metadata_do instead. That would also > enable us to clean up some of the code complexity that has been added to > the codecache/nmethod cleaning code. OK. Thanks for pointing me to the original code. I was surprised to see that we needed to mark both the holder_method() and the holder_klass(). There might be ways to mark only the klass but this is outside the scope of this RFR, where you should stick to what was done before. Anyway, the gains of removing one mark_on_stack may not be worth the risks. I'm not familiar enough with RedefinedKlass to know how the reclaimed space can be reused and be sure that the extra marking is useless. Hence, I'm OK with that part... but I'll continue my review next week. Bertrand. > > thanks, > StefanK > >> >> Regards, >> >> Bertrand >> >> On 02/10/14 12:53, Stefan Karlsson wrote: >>> Hi all, >>> >>> (The following patch changes HotSpot code in areas concerning GC, RT, >>> and Compiler. So, it would be good to get reviews from all three teams.) >>> >>> Please, review this patch to optimize and parallelize the CodeCache part >>> of MetadaOnStackMark. >>> >>> G1 performance measurements showed longer than expected remark times on >>> an application using a lot of nmethods and Metadata. The cause for this >>> performance regression was the call to >>> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >>> MetadataOnStackMark. This code path is only taken when class >>> redefinition is used. Class redefinition is typically used in monitoring >>> and diagnostic frameworks. >>> >>> With this patch we now: >>> 1) Filter out duplicate Metadata* entries instead of storing a Metadata* >>> per visited metadata reference. >>> 2) Collect the set of Metadata* entries in parallel. The code >>> piggy-backs on the parallel CodeCache cleaning task. >>> >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8056240 >>> >>> Functional testing: >>> JPRT, Kitchensink, parallel_class_unloading, unit tests >>> >>> Performance testing: >>> CRM Fuse - where the regression was found >>> >>> The patch changes HotSpot code in areas concerning GC, RT, Compiler, and >>> Serviceability. It would be good to get some reviews from the other >>> teams, and not only from the GC team. >>> >>> thanks, >>> StefanK >> >> > -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38334 Saint Ismier, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From frederic.parain at oracle.com Fri Oct 3 14:41:13 2014 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 03 Oct 2014 16:41:13 +0200 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <542E9C6F.6090800@oracle.com> References: <542AC0E8.9040409@oracle.com> <542B2841.2080401@oracle.com> <542C0689.8020106@oracle.com> <542E9C6F.6090800@oracle.com> Message-ID: <542EB589.2000109@oracle.com> Harold, Thank you for the review and your feedback. I didn't try to remove all dead code from JVM entries removal, just the most obvious dead code pieces. Thank you for spotting that JavaCalls::call_default_constructor() could be safely removed. I removed it in the new webrev. Regarding mapfiles, I played with JVM_DefineClassWithSources and DefineClassWithSourcesCond, and it seems that I didn't restore the mapfile correctly. This is now fixed. New HoSpot webrev: http://cr.openjdk.java.net/~fparain/8057777/hotspot_v02/ Thank you, Fred On 03/10/2014 14:54, harold seigel wrote: > Hi Fred, > > It's great to see all this code go away. > > Since JVM_AllocateNewObject() is getting removed, can > JavaCalls::call_default_constructor() also be removed? > > Also, why were JVM_DesiredAssertionStatus and JVM_DoPrivileged moved in > make/solaris/makefiles/mapfile-vers ? They are no longer in > alphabetical order. > > Thanks, Harold > > > On 10/1/2014 9:50 AM, Frederic Parain wrote: >> Thanks Coleen, >> >> Fred >> >> On 10/01/2014 12:01 AM, Coleen Phillimore wrote: >>> >>> Fred, >>> >>> I reviewed this change. It looks great. Some of the functions removed >>> seem to be not only unused but dangerous. Some of these I have made >>> changes to that I didn't realize that the JVM didn't use these >>> functions. Thank you for doing this! >>> >>> Coleen >>> >>> On 9/30/14, 10:40 AM, Frederic Parain wrote: >>>> Hi all, >>>> >>>> Please review changes for bug JDK-8057777 "Cleanup of old >>>> and unused VM interfaces" >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8057777 >>>> >>>> This is basically a big cleanup of VM interfaces that are >>>> not used anymore by the JDK but have been kept in our code >>>> base for historical reasons (HotSpot Express for instance). >>>> These changesets remove these interfaces from both the >>>> JDK and the HotSpot side, and also perform some cleanup >>>> on code that directly referenced the removed interfaces. >>>> >>>> These changes do not modify the behavior of the Java >>>> classes impacted by the cleanup. >>>> >>>> VM interfaces removal has been approved by CCC and >>>> a Release Note has been prepared that explicitly list >>>> all the removed interfaces. >>>> >>>> Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core >>>> >>>> Webrevs: >>>> http://cr.openjdk.java.net/~fparain/8057777/ >>>> >>>> Thank you, >>>> >>>> Fred >>>> >>> >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From harold.seigel at oracle.com Fri Oct 3 14:44:11 2014 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 03 Oct 2014 10:44:11 -0400 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <542EB589.2000109@oracle.com> References: <542AC0E8.9040409@oracle.com> <542B2841.2080401@oracle.com> <542C0689.8020106@oracle.com> <542E9C6F.6090800@oracle.com> <542EB589.2000109@oracle.com> Message-ID: <542EB63B.9070705@oracle.com> Hi Fred, It looks good! Thanks for making those changes. Harold On 10/3/2014 10:41 AM, Frederic Parain wrote: > Harold, > > Thank you for the review and your feedback. > > I didn't try to remove all dead code from JVM entries > removal, just the most obvious dead code pieces. > Thank you for spotting that JavaCalls::call_default_constructor() > could be safely removed. I removed it in the new webrev. > > Regarding mapfiles, I played with JVM_DefineClassWithSources > and DefineClassWithSourcesCond, and it seems that I didn't > restore the mapfile correctly. This is now fixed. > > New HoSpot webrev: > http://cr.openjdk.java.net/~fparain/8057777/hotspot_v02/ > > Thank you, > > Fred > > On 03/10/2014 14:54, harold seigel wrote: >> Hi Fred, >> >> It's great to see all this code go away. >> >> Since JVM_AllocateNewObject() is getting removed, can >> JavaCalls::call_default_constructor() also be removed? >> >> Also, why were JVM_DesiredAssertionStatus and JVM_DoPrivileged moved in >> make/solaris/makefiles/mapfile-vers ? They are no longer in >> alphabetical order. >> >> Thanks, Harold >> >> >> On 10/1/2014 9:50 AM, Frederic Parain wrote: >>> Thanks Coleen, >>> >>> Fred >>> >>> On 10/01/2014 12:01 AM, Coleen Phillimore wrote: >>>> >>>> Fred, >>>> >>>> I reviewed this change. It looks great. Some of the functions >>>> removed >>>> seem to be not only unused but dangerous. Some of these I have made >>>> changes to that I didn't realize that the JVM didn't use these >>>> functions. Thank you for doing this! >>>> >>>> Coleen >>>> >>>> On 9/30/14, 10:40 AM, Frederic Parain wrote: >>>>> Hi all, >>>>> >>>>> Please review changes for bug JDK-8057777 "Cleanup of old >>>>> and unused VM interfaces" >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8057777 >>>>> >>>>> This is basically a big cleanup of VM interfaces that are >>>>> not used anymore by the JDK but have been kept in our code >>>>> base for historical reasons (HotSpot Express for instance). >>>>> These changesets remove these interfaces from both the >>>>> JDK and the HotSpot side, and also perform some cleanup >>>>> on code that directly referenced the removed interfaces. >>>>> >>>>> These changes do not modify the behavior of the Java >>>>> classes impacted by the cleanup. >>>>> >>>>> VM interfaces removal has been approved by CCC and >>>>> a Release Note has been prepared that explicitly list >>>>> all the removed interfaces. >>>>> >>>>> Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core >>>>> >>>>> Webrevs: >>>>> http://cr.openjdk.java.net/~fparain/8057777/ >>>>> >>>>> Thank you, >>>>> >>>>> Fred >>>>> >>>> >>> >> > From frederic.parain at oracle.com Fri Oct 3 14:45:36 2014 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 03 Oct 2014 16:45:36 +0200 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <542EB63B.9070705@oracle.com> References: <542AC0E8.9040409@oracle.com> <542B2841.2080401@oracle.com> <542C0689.8020106@oracle.com> <542E9C6F.6090800@oracle.com> <542EB589.2000109@oracle.com> <542EB63B.9070705@oracle.com> Message-ID: <542EB690.3050300@oracle.com> Thank you Harold, Fred On 03/10/2014 16:44, harold seigel wrote: > Hi Fred, > > It looks good! Thanks for making those changes. > > Harold > > On 10/3/2014 10:41 AM, Frederic Parain wrote: >> Harold, >> >> Thank you for the review and your feedback. >> >> I didn't try to remove all dead code from JVM entries >> removal, just the most obvious dead code pieces. >> Thank you for spotting that JavaCalls::call_default_constructor() >> could be safely removed. I removed it in the new webrev. >> >> Regarding mapfiles, I played with JVM_DefineClassWithSources >> and DefineClassWithSourcesCond, and it seems that I didn't >> restore the mapfile correctly. This is now fixed. >> >> New HoSpot webrev: >> http://cr.openjdk.java.net/~fparain/8057777/hotspot_v02/ >> >> Thank you, >> >> Fred >> >> On 03/10/2014 14:54, harold seigel wrote: >>> Hi Fred, >>> >>> It's great to see all this code go away. >>> >>> Since JVM_AllocateNewObject() is getting removed, can >>> JavaCalls::call_default_constructor() also be removed? >>> >>> Also, why were JVM_DesiredAssertionStatus and JVM_DoPrivileged moved in >>> make/solaris/makefiles/mapfile-vers ? They are no longer in >>> alphabetical order. >>> >>> Thanks, Harold >>> >>> >>> On 10/1/2014 9:50 AM, Frederic Parain wrote: >>>> Thanks Coleen, >>>> >>>> Fred >>>> >>>> On 10/01/2014 12:01 AM, Coleen Phillimore wrote: >>>>> >>>>> Fred, >>>>> >>>>> I reviewed this change. It looks great. Some of the functions >>>>> removed >>>>> seem to be not only unused but dangerous. Some of these I have made >>>>> changes to that I didn't realize that the JVM didn't use these >>>>> functions. Thank you for doing this! >>>>> >>>>> Coleen >>>>> >>>>> On 9/30/14, 10:40 AM, Frederic Parain wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review changes for bug JDK-8057777 "Cleanup of old >>>>>> and unused VM interfaces" >>>>>> >>>>>> CR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8057777 >>>>>> >>>>>> This is basically a big cleanup of VM interfaces that are >>>>>> not used anymore by the JDK but have been kept in our code >>>>>> base for historical reasons (HotSpot Express for instance). >>>>>> These changesets remove these interfaces from both the >>>>>> JDK and the HotSpot side, and also perform some cleanup >>>>>> on code that directly referenced the removed interfaces. >>>>>> >>>>>> These changes do not modify the behavior of the Java >>>>>> classes impacted by the cleanup. >>>>>> >>>>>> VM interfaces removal has been approved by CCC and >>>>>> a Release Note has been prepared that explicitly list >>>>>> all the removed interfaces. >>>>>> >>>>>> Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core >>>>>> >>>>>> Webrevs: >>>>>> http://cr.openjdk.java.net/~fparain/8057777/ >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Fred >>>>>> >>>>> >>>> >>> >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From coleen.phillimore at oracle.com Fri Oct 3 15:18:39 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 03 Oct 2014 11:18:39 -0400 Subject: [9] RFR (S): 8059340: ConstantPool::_resolved_references is missing in heap dump In-Reply-To: <542971DC.2090803@oracle.com> References: <542971DC.2090803@oracle.com> Message-ID: <542EBE4F.7020309@oracle.com> I don't know the JDK code for hprof but the JVM code seems fine. I was considering adding the resolved_references array as a hidden field in java/lang/Class instances to give GC less to do, but this code can still act like we didn't do that. Coleen On 9/29/14, 10:51 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8059340/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8059340 > > VM heap dump doesn't contain ConstantPool::_resolved_references for > classes which have resolved references. > > ConstantPool::_resolved_references points to an Object[] holding > resolved constant pool entries (patches for VM anonymous classes, > linked CallSite & MethodType for invokedynamic instructions). > > I've decided to use reserved slot in HPROF class header format. > It requires an update in jhat to correctly display new info. > > The other approach I tried was to dump the reference as a fake static > field [1], but storing VM internal ConstantPool::_resolved_references > among user defined fields looks confusing. > > Testing: manual (verified that corresponding arrays are properly > linked in Nashorn heap dump). > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] http://cr.openjdk.java.net/~vlivanov/8059340/static From Alan.Bateman at oracle.com Fri Oct 3 15:19:43 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 Oct 2014 08:19:43 -0700 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <542AC0E8.9040409@oracle.com> References: <542AC0E8.9040409@oracle.com> Message-ID: <542EBE8F.5090800@oracle.com> On 30/09/2014 07:40, Frederic Parain wrote: > Hi all, > > Please review changes for bug JDK-8057777 "Cleanup of old > and unused VM interfaces" > > CR: > https://bugs.openjdk.java.net/browse/JDK-8057777 > > This is basically a big cleanup of VM interfaces that are > not used anymore by the JDK but have been kept in our code > base for historical reasons (HotSpot Express for instance). > These changesets remove these interfaces from both the > JDK and the HotSpot side, and also perform some cleanup > on code that directly referenced the removed interfaces. > > These changes do not modify the behavior of the Java > classes impacted by the cleanup. > > VM interfaces removal has been approved by CCC and > a Release Note has been prepared that explicitly list > all the removed interfaces. > > Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core > > Webrevs: > http://cr.openjdk.java.net/~fparain/8057777/ cc'ing core-libs-dev as part of this is clean-up in the library code too. I think we should deprecate java.lang.Compiler and the Runtime.traceXXX methods. They've been non-functional for a long time and having them in the API is a bit mis-leading to anyone reading the javadoc. I realize you are focused on the removing the old JVM_* functions so we can follow-up on that via other issues of course. Can ClassLoader#resolveClass0 can be removed completely? The null check can be done in ClassLoader#resolveClass. In the mapfile for libjava then the comment at line 281 says "ZipFile.c needs this one". As getLastErrorString is now exported for use by libzip then the comment should probably be updated. Otherwise this clean-up looks good to me and the jdk_core group of tests is the right group to exercise this area. -Alan From stefan.karlsson at oracle.com Fri Oct 3 15:13:49 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 03 Oct 2014 17:13:49 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <542EB4AF.3080002@oracle.com> References: <542D2EC1.5030303@oracle.com> <542E99BA.2000207@oracle.com> <542EA6CA.5020502@oracle.com> <542EB4AF.3080002@oracle.com> Message-ID: <542EBD2D.1070404@oracle.com> On 2014-10-03 16:37, Bertrand Delsart wrote: > On 03/10/14 15:38, Stefan Karlsson wrote: >> Hi Betrand, >> >> Thanks for taking the time to review this. >> >> On 2014-10-03 14:42, Bertrand Delsart wrote: >>> Hi Stefan, >>> >>> I'll do a more in depth review next week but here are a few quick >>> comments to keep us busy in between :-) >>> >>> -1- The fact that set_on_stack() is now implemented by just a >>> atomic_try_set_bits seems dangerous. >>> >>> We could end up not setting the JVM_ACC_ON_STACK flag. >>> >>> In your case, you may be sure that the only concurrent operation that >>> might happen is a setting of the same flag but this looks error prone >>> with respect to future possible usages of that method (or new >>> concurrent operations). >> >> OK. I see your point about future-proofing this. Is this currently >> broken in that sense that two racing threads can both fail to set the >> on_stack bit? > > cmpxchg is supposed to be robust against spurious CAS failure. Hence, > the only danger is if indeed one of our threads concurrently modifies > the flags for another reason while someone is using MetadataOnStackMark > > This is not likely but IMHO, the gains of avoiding a loop may not be > worth the risks. > > As stated in my following e-mail, I would also agree if you just add > an assert(on_stack()) after the atomic_try_set_bits in set_on_stack. > That would allow us to detect use cases we had not anticipated. > >>> >>> I would prefer to be sure the flag has really been set when exiting >>> from set_on_stack(), as was the case before. >>> >>> More generally, the semantic of the new atomic_try_set_bits is IMHO >>> dangerous. It returns false both if the bits were already set or if >>> another flag was changed concurrently (in which case the bits may not >>> be set). This should at least be clearly documented in the .hpp file. >> >>> >>> >>> An alternative would be for atomic_try_set_bits to return the current >>> value when the cas failed or was not performed. It would be up to the >>> caller to decide whether to loop or not (by checking whether the bits >>> are set in the returned value). >> >> I can change the code to use a slightly altered version of >> atomic_set_bit that returns 'true' if it was this thread that succeeded >> in setting the bit. > > >>> -2- There is one part of the change that does not seem to be described >>> in the RFR or the CR. You added something to keep alive some metadata >>> in case of klass redefinition (the mark_on_stack stuff in nmethod.cpp, >>> which for instance now marks the content of the CompiledICHolder). >>> >>> Did you just change when that marking was performed or is that a >>> marking that we were not doing previously ? (sorry, cannot review it >>> all currently and see whether that marking was indeed removed >>> elsewhere) >> >> Before my change, this code was done by the call to: >> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); >> >> if you look at: >> static void mark_on_stack(nmethod* nm) { >> nm->metadata_do(Metadata::mark_on_stack); >> } >> >> and then: >> // Iterate over metadata calling this function. Used by >> RedefineClasses >> void nmethod::metadata_do(void f(Metadata*)) { >> address low_boundary = verified_entry_point(); >> if (is_not_entrant()) { >> low_boundary += NativeJump::instruction_size; >> // %%% Note: On SPARC we patch only a 4-byte trap, not a full >> NativeJump. >> // (See comment above.) >> } >> { >> // Visit all immediate references that are embedded in the >> instruction stream. >> RelocIterator iter(this, low_boundary); >> while (iter.next()) { >> if (iter.type() == relocInfo::metadata_type ) { >> metadata_Relocation* r = iter.metadata_reloc(); >> // In this lmetadata, we must only follow those metadatas >> directly embedded in >> // the code. Other metadatas (oop_index>0) are seen as part of >> // the metadata section below. >> assert(1 == (r->metadata_is_immediate()) + >> (r->metadata_addr() >= metadata_begin() && >> r->metadata_addr() < metadata_end()), >> "metadata must be found in exactly one place"); >> if (r->metadata_is_immediate() && r->metadata_value() != >> NULL) { >> Metadata* md = r->metadata_value(); >> if (md != _method) f(md); >> } >> } else if (iter.type() == relocInfo::virtual_call_type) { >> // Check compiledIC holders associated with this nmethod >> CompiledIC *ic = CompiledIC_at(&iter); >> if (ic->is_icholder_call()) { >> CompiledICHolder* cichk = ic->cached_icholder(); >> f(cichk->holder_method()); >> f(cichk->holder_klass()); >> } else { >> Metadata* ic_oop = ic->cached_metadata(); >> if (ic_oop != NULL) { >> f(ic_oop); >> } >> } >> } >> } >> } >> >> // Visit the metadata section >> for (Metadata** p = metadata_begin(); p < metadata_end(); p++) { >> if (*p == Universe::non_oop_word() || *p == NULL) continue; // >> skip non-oops >> Metadata* md = *p; >> f(md); >> } >> >> // Call function Method*, not embedded in these other places. >> if (_method != NULL) f(_method); >> } >> >> you see that the above calls to f(...) correspond to the added >> mark_on_stack sections in nmethod.cpp. >> >> So the code is now duplicated and added to places where they don't >> really belong, and that breaks some of the current abstraction. This is >> done just to be able to skip having to do an extra pass of the expensive >> "for all nmethods { for all relocInfos {} }" code. If we could get the >> RelocIterator code to become much cheaper, then we could remove all that >> added code and just use nmethod::metadata_do instead. That would also >> enable us to clean up some of the code complexity that has been added to >> the codecache/nmethod cleaning code. > > OK. Thanks for pointing me to the original code. > > I was surprised to see that we needed to mark both the holder_method() > and the holder_klass(). There might be ways to mark only the klass but > this is outside the scope of this RFR, where you should stick to what > was done before. When calling mark_on_stack on a Klass we end up in the empty default implementation: void Metadata::set_on_stack(const bool value) { // nothing to set for most metadata // Can't inline because this materializes the vtable on some C++ compilers. } So this is a bit unnecessary ATM. I don't know if this will be used in the future or not. > > Anyway, the gains of removing one mark_on_stack may not be worth the > risks. I'm not familiar enough with RedefinedKlass to know how the > reclaimed space can be reused and be sure that the extra marking is > useless. > > Hence, I'm OK with that part... but I'll continue my review next week. OK. Thanks, StefanK > > Bertrand. > >> >> thanks, >> StefanK >> >>> >>> Regards, >>> >>> Bertrand >>> >>> On 02/10/14 12:53, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> (The following patch changes HotSpot code in areas concerning GC, RT, >>>> and Compiler. So, it would be good to get reviews from all three >>>> teams.) >>>> >>>> Please, review this patch to optimize and parallelize the CodeCache >>>> part >>>> of MetadaOnStackMark. >>>> >>>> G1 performance measurements showed longer than expected remark >>>> times on >>>> an application using a lot of nmethods and Metadata. The cause for >>>> this >>>> performance regression was the call to >>>> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >>>> MetadataOnStackMark. This code path is only taken when class >>>> redefinition is used. Class redefinition is typically used in >>>> monitoring >>>> and diagnostic frameworks. >>>> >>>> With this patch we now: >>>> 1) Filter out duplicate Metadata* entries instead of storing a >>>> Metadata* >>>> per visited metadata reference. >>>> 2) Collect the set of Metadata* entries in parallel. The code >>>> piggy-backs on the parallel CodeCache cleaning task. >>>> >>>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8056240 >>>> >>>> Functional testing: >>>> JPRT, Kitchensink, parallel_class_unloading, unit tests >>>> >>>> Performance testing: >>>> CRM Fuse - where the regression was found >>>> >>>> The patch changes HotSpot code in areas concerning GC, RT, >>>> Compiler, and >>>> Serviceability. It would be good to get some reviews from the other >>>> teams, and not only from the GC team. >>>> >>>> thanks, >>>> StefanK >>> >>> >> > > From frederic.parain at oracle.com Fri Oct 3 16:02:54 2014 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 03 Oct 2014 18:02:54 +0200 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <542EBE8F.5090800@oracle.com> References: <542AC0E8.9040409@oracle.com> <542EBE8F.5090800@oracle.com> Message-ID: <542EC8AE.90808@oracle.com> Alan, Thank you for your feedback, see my comments below. On 03/10/2014 17:19, Alan Bateman wrote: > On 30/09/2014 07:40, Frederic Parain wrote: >> Hi all, >> >> Please review changes for bug JDK-8057777 "Cleanup of old >> and unused VM interfaces" >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8057777 >> >> This is basically a big cleanup of VM interfaces that are >> not used anymore by the JDK but have been kept in our code >> base for historical reasons (HotSpot Express for instance). >> These changesets remove these interfaces from both the >> JDK and the HotSpot side, and also perform some cleanup >> on code that directly referenced the removed interfaces. >> >> These changes do not modify the behavior of the Java >> classes impacted by the cleanup. >> >> VM interfaces removal has been approved by CCC and >> a Release Note has been prepared that explicitly list >> all the removed interfaces. >> >> Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core >> >> Webrevs: >> http://cr.openjdk.java.net/~fparain/8057777/ > cc'ing core-libs-dev as part of this is clean-up in the library code too. > > I think we should deprecate java.lang.Compiler and the Runtime.traceXXX > methods. They've been non-functional for a long time and having them in > the API is a bit mis-leading to anyone reading the javadoc. I realize > you are focused on the removing the old JVM_* functions so we can > follow-up on that via other issues of course. Deprecating class and methods would require another CCC approval, so I'd prefer to post-pone this change to another changeset. > Can ClassLoader#resolveClass0 can be removed completely? The null check > can be done in ClassLoader#resolveClass. Done. > In the mapfile for libjava then the comment at line 281 says "ZipFile.c > needs this one". As getLastErrorString is now exported for use by libzip > then the comment should probably be updated. Done. > Otherwise this clean-up looks good to me and the jdk_core group of tests > is the right group to exercise this area. Thank you, the new jdk webrev is here: http://cr.openjdk.java.net/~fparain/8057777/jdk_v02/ Regards, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From vladimir.kozlov at oracle.com Fri Oct 3 17:00:42 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Oct 2014 10:00:42 -0700 Subject: [8u40] Request for approval: backport of JDK-8057165 In-Reply-To: <542E81C0.9000602@oracle.com> References: <542E8041.1010101@oracle.com> <542E81C0.9000602@oracle.com> Message-ID: <542ED63A.2050009@oracle.com> Looks good. Thanks, Vladimir On 10/3/14 4:00 AM, Boris Molodenkov wrote: > Sorry, > Latest webrev is http://cr.openjdk.java.net/~fzhinkin/bmoloden/8057165/webrev.01/ > > Boris > > On 10/03/2014 02:53 PM, Boris Molodenkov wrote: >> Hi All, >> >> I would like to backport fix for JDK-8057165 to 8u40. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8057165 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/bmoloden/8057165/webrev.00/ >> Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3a59d786378b >> Review thread for original fix: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-September/015514.html >> >> testing: jprt >> >> Thanks, >> Boris >> > From vladimir.kozlov at oracle.com Fri Oct 3 18:46:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Oct 2014 11:46:56 -0700 Subject: RFD: Add Linux/AArch64 to the set of supported OpenJDK platforms In-Reply-To: <542D7455.3020807@redhat.com> References: <542D7455.3020807@redhat.com> Message-ID: <542EEF20.2020309@oracle.com> On 10/2/14 8:50 AM, Andrew Haley wrote: > https://bugs.openjdk.java.net/browse/JDK-8044552 > http://openjdk.java.net/jeps/8044552 > > The AArch64 port has been complete for some time, and the rate of > churn has slowed to the point where I believe it is stable enough to > be moved into the mainline sources. It has passed the full JCK on JDK > 7 and 8, but as yet there is no JCK 9, so I can say nothing about > that. We are regularly testing using jtreg, Hadoop, and a bunch of > other tests, and our results are similar to the same tests on x86. > > I hope that this process will be less involved and require less effort > from approvers (at Oracle and elsewhere) than that for the Power PC > port. I believe this because there are few changes to shared code > beyond the trivial #ifdefs for header files which appear in many > places. In a few places we've had to #ifdef out code which is in > src/share but makes architectural assumptions which are not valid on > AArch64. > > So, our proposal as detailed in the JEP is to create a staging forest > which at the start will be a clone of the current JDK9. This staging > forest will have jcheck fully enabled (unlike the AArch64 development > repositories). We will then submit webrevs for approval to the > appropriate groups, and then check them in to the staging forest. > > I presume that for each webrev it will be necessary to create a Jira > Issue. Yes and please add 'AARCH64:' prefix to jbs Summary line, like next for ppc64: PPC64: (part 220): ConstantTableBase for calls between args and jvms > > A few questions arise: > > To which mailing lists should requests for approval be sent? I'm > guessing hotspot-dev for the HotSpot patches, and jdk9-dev for > everything else. Correct. > > What should the granularity of the webrevs be? I don't think that any > subset of the src/cpu/aarch64 directory would make sense, but it's a > big bite to chew. You can at least separate assembler/macroassembler+interpreter+runtime and c1+c2+stubs code. As I remember your shared changes are not big (mostly ifdefs) so it could be one. > > The JEP, which was based on that for the Power PC, talks about a more > detailed Integration Plan in the AArch64 Port OpenJDK Wiki Space, but I > have no plans beyond submitting webrevs for approval. > > Is there anything else we should do before creating issues and > submitting webrevs? Yes, I think the rest is our side. We need to create stage repo and assign our sponsor. Thanks, Vladimir > > Thanks, > Andrew. > From vladimir.kozlov at oracle.com Fri Oct 3 21:05:53 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Oct 2014 14:05:53 -0700 Subject: [8u40] RFR(S) 8059299: assert(adr_type != NULL) failed: expecting TypeKlassPtr Message-ID: <542F0FB1.1020303@oracle.com> Backport request. Changes was pushed into jdk9 yesterday. Nighties are fine (we did not catch the problem for a lot of years so I doubt we have old tests which are affected). Changes are applied cleanly to 8u sources except I had to remove changes in test/TEST.groups since we don't have JPRT jtreg testing for 8u. http://cr.openjdk.java.net/~kvn/8059299/webrev/ https://bugs.openjdk.java.net/browse/JDK-8059299 jdk9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4365e650350d Review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-October/015757.html Thanks, Vladimir From vladimir.kozlov at oracle.com Fri Oct 3 22:33:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Oct 2014 15:33:26 -0700 Subject: New staging repository for AArch64 open port Message-ID: <542F2436.7070608@oracle.com> Hi Iris, aarch64 (arm64) open port JEP is reviewed and endorsed: https://bugs.openjdk.java.net/browse/JDK-8044552 Could you, please, create jdk9 staging forest (including closed repos) for it? Something like: http://hg.openjdk.java.net/aarch64-port/stage It should be child of jdk9/dev forest. Push notifications for open changes could be sent to: aarch64-port-dev at openjdk.java.net Initial committers will be Andrew Haley (aph) and me, Vladimir Kozlov (kvn). We may add more committers later. Best regards, Vladimir From boris.molodenkov at oracle.com Fri Oct 3 10:53:53 2014 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Fri, 03 Oct 2014 14:53:53 +0400 Subject: [8u40] Request for approval: backport of JDK-8057165 Message-ID: <542E8041.1010101@oracle.com> Hi All, I would like to backport fix for JDK-8057165 to 8u40. Bug id: https://bugs.openjdk.java.net/browse/JDK-8057165 Webrev: http://cr.openjdk.java.net/~fzhinkin/bmoloden/8057165/webrev.00/ Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3a59d786378b Review thread for original fix: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-September/015514.html testing: jprt Thanks, Boris From xueming.shen at oracle.com Fri Oct 3 16:07:16 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 03 Oct 2014 09:07:16 -0700 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <542EBE8F.5090800@oracle.com> References: <542AC0E8.9040409@oracle.com> <542EBE8F.5090800@oracle.com> Message-ID: <542EC9B4.1050908@oracle.com> On 10/3/14 8:19 AM, Alan Bateman wrote: > On 30/09/2014 07:40, Hideric Parain wrote: >> Hi all, >> >> Please review changes for bug JDK-8057777 "Cleanup of old >> and unused VM interfaces" >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8057777 >> >> This is basically a big cleanup of VM interfaces that are >> not used anymore by the JDK but have been kept in our code >> base for historical reasons (HotSpot Express for instance). >> These changesets remove these interfaces from both the >> JDK and the HotSpot side, and also perform some cleanup >> on code that directly referenced the removed interfaces. >> >> These changes do not modify the behavior of the Java >> classes impacted by the cleanup. >> >> VM interfaces removal has been approved by CCC and >> a Release Note has been prepared that explicitly list >> all the removed interfaces. >> >> Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core >> >> Webrevs: >> http://cr.openjdk.java.net/~fparain/8057777/ > cc'ing core-libs-dev as part of this is clean-up in the library code too. > > I think we should deprecate java.lang.Compiler and the > Runtime.traceXXX methods. They've been non-functional for a long time > and having them in the API is a bit mis-leading to anyone reading the > javadoc. I realize you are focused on the removing the old JVM_* > functions so we can follow-up on that via other issues of course. > > Can ClassLoader#resolveClass0 can be removed completely? The null > check can be done in ClassLoader#resolveClass. > > In the mapfile for libjava then the comment at line 281 says > "ZipFile.c needs this one". As getLastErrorString is now exported for > use by libzip then the comment should probably be updated. > > Otherwise this clean-up looks good to me and the jdk_core group of > tests is the right group to exercise this area. > > -Alan > Hi, ZipFile.c expects the JVM_Open() to handle the JVM_O_DELETE, with explicit unlink on linux/solaris for example. I would assume the open from the c library does not handle it and we need to do it explicitly by ZipFile.c now? -Sherman From manuel.rigger at chello.at Sat Oct 4 14:22:40 2014 From: manuel.rigger at chello.at (Manuel Rigger) Date: Sat, 04 Oct 2014 16:22:40 +0200 Subject: Outdated documentation Message-ID: <543002B0.9030500@chello.at> Hi all, the HotSpot documentation [1] does not seem up-to-date in some points. The serviceability site was last updated in 2007 and contains many dead source code links [2]. It is also strange to see sentences such as "We are investigating the possibility of ? in JDK 7" when we are already past this version. The other sites refer to the permanent generation which was removed in JDK 8. Could someone with sufficient permission update these parts in the documentation? If not, it would at least be helpful to place a disclaimer that the documentation was written for the Java version X and might be outdated, and remove the dead links. Is this the right place to send such a request? Should I create a bug report for this? - Manuel [1] the four links listed under Documentation at http://openjdk.java.net/groups/hotspot/ [2] to http://opengrok.neojava.org/ From goetz.lindenmaier at sap.com Sat Oct 4 18:01:49 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 4 Oct 2014 18:01:49 +0000 Subject: RFR(M): 8059592: Recent bugfixes in ppc64 port. In-Reply-To: <542DA575.3040701@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF0AB1E@DEWDFEMB12A.global.corp.sap> <542DA575.3040701@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF0C41D@DEWDFEMB12A.global.corp.sap> Hi Vladimir, I don't know exactly what happened, Martin fixed that. We have test where we set very small code cache size to stress the code cache infrastructure, and that test failed. Martin, can you give more detail? Best regards, Goetz -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Thursday, October 02, 2014 9:20 PM To: hotspot-dev at openjdk.java.net Subject: Re: RFR(M): 8059592: Recent bugfixes in ppc64 port. Looks fine. One question is how you can have failing state during code generation?: if (Compile::current()->env()->failing()) { return; } // Code cache may be full. There should be bailout in opto/output.cpp when codecache is full. Did it happen because estimated buffer size was less then needed? Thanks, Vladimir On 10/2/14 1:06 AM, Lindenmaier, Goetz wrote: > Hi, > > This change contains some bugfixes in the ppc64 coding, and some minor > improvements. It only touches code used in the port. > http://cr.openjdk.java.net/~goetz/webrevs/8059592-ppc_bugs/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8059592 > > Please review and test this change. I please need a sponsor. > This change also should go to 8u40, please. > > Best regards, > Goetz. > > From goetz.lindenmaier at sap.com Sat Oct 4 19:50:02 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 4 Oct 2014 19:50:02 +0000 Subject: RFR(M): 8059592: Recent bugfixes in ppc64 port. In-Reply-To: <542DA575.3040701@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF0AB1E@DEWDFEMB12A.global.corp.sap> <542DA575.3040701@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF0D5FB@DEWDFEMB12A.global.corp.sap> Hi Vladimir, thanks for pushing both of them! Great you fixed the new operators for 8. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Thursday, October 02, 2014 9:20 PM To: hotspot-dev at openjdk.java.net Subject: Re: RFR(M): 8059592: Recent bugfixes in ppc64 port. Looks fine. One question is how you can have failing state during code generation?: if (Compile::current()->env()->failing()) { return; } // Code cache may be full. There should be bailout in opto/output.cpp when codecache is full. Did it happen because estimated buffer size was less then needed? Thanks, Vladimir On 10/2/14 1:06 AM, Lindenmaier, Goetz wrote: > Hi, > > This change contains some bugfixes in the ppc64 coding, and some minor > improvements. It only touches code used in the port. > http://cr.openjdk.java.net/~goetz/webrevs/8059592-ppc_bugs/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8059592 > > Please review and test this change. I please need a sponsor. > This change also should go to 8u40, please. > > Best regards, > Goetz. > > From igor.ignatyev at oracle.com Sun Oct 5 15:39:27 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sun, 05 Oct 2014 19:39:27 +0400 Subject: RFR(XXS) : 8059732 : improve hotspot_*test targets Message-ID: <5431662F.2040804@oracle.com> webrev: http://cr.openjdk.java.net/~iignatyev/8059732/webrev.00/ 33 lines changed: 20 ins; 9 del; 4 mod; Hi all, Please review changes in hotspot_*test targets: - common part is extracted as sanitytest target - flags to test are stored in TEST_FLAGS variable - tests fail if one of executions fail (not the last one, as it was before) jbs: https://bugs.openjdk.java.net/browse/JDK-8059732 testing: jprt -- Thanks Igor From igor.veresov at oracle.com Mon Oct 6 03:46:25 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Sun, 5 Oct 2014 20:46:25 -0700 Subject: [8u40] RFR(S): 8059621: JVM crashes with "unexpected index type" assert in LIRGenerator::do_UnsafeGetRaw Message-ID: <3F5372FD-C8F3-467D-8059-BA492B7BC8D9@oracle.com> Webrev: http://cr.openjdk.java.net/~iveresov/8059621/webrev.00 JBS: https://bugs.openjdk.java.net/browse/JDK-8059621 JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f4aadd8a5168 Thanks! igor From staffan.larsen at oracle.com Mon Oct 6 07:35:37 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 6 Oct 2014 09:35:37 +0200 Subject: [9] RFR (S): 8059340: ConstantPool::_resolved_references is missing in heap dump In-Reply-To: <542971DC.2090803@oracle.com> References: <542971DC.2090803@oracle.com> Message-ID: <24133E27-C024-41D8-80EF-B5707CFF0D0C@oracle.com> This looks like a good approach. However, there are a couple of more places that need to be updated. The hprof binary format is described in jdk/src/jdk.hprof.agent/share/native/libhprof/manual.html and needs to be updated. It?s also more formally specified in hprof_b_spec.h in the same directory. The hprof JVMTI agent in jdk/src/jdk.hprof.agent code would also need to be updated to show this field. Since this is a JVMTI agent it needs to be possible to find the resolved_refrences array via the JVMTI heap walking API. Perhaps that already works? - I haven?t looked. Finally, the Serviceability Agent implements yet another hprof binary dumper in hotspot/agent//src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java which also needs to write this reference. Thanks, /Staffan On 29 sep 2014, at 16:51, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8059340/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8059340 > > VM heap dump doesn't contain ConstantPool::_resolved_references for classes which have resolved references. > > ConstantPool::_resolved_references points to an Object[] holding resolved constant pool entries (patches for VM anonymous classes, linked CallSite & MethodType for invokedynamic instructions). > > I've decided to use reserved slot in HPROF class header format. > It requires an update in jhat to correctly display new info. > > The other approach I tried was to dump the reference as a fake static field [1], but storing VM internal ConstantPool::_resolved_references among user defined fields looks confusing. > > Testing: manual (verified that corresponding arrays are properly linked in Nashorn heap dump). > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] http://cr.openjdk.java.net/~vlivanov/8059340/static From martin.doerr at sap.com Mon Oct 6 08:43:33 2014 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 6 Oct 2014 08:43:33 +0000 Subject: RFR(M): 8059592: Recent bugfixes in ppc64 port. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF0C41D@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF0AB1E@DEWDFEMB12A.global.corp.sap> <542DA575.3040701@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF0C41D@DEWDFEMB12A.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB418116566ACD4424@DEWDFEMB19C.global.corp.sap> Hi Vladimir, we have call nodes which emit trampoline stubs. This may fail if the code cache is too full. In this case, the emit() function records out-of-memory and returns. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Samstag, 4. Oktober 2014 20:02 To: 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net' Cc: Doerr, Martin Subject: RE: RFR(M): 8059592: Recent bugfixes in ppc64 port. Hi Vladimir, I don't know exactly what happened, Martin fixed that. We have test where we set very small code cache size to stress the code cache infrastructure, and that test failed. Martin, can you give more detail? Best regards, Goetz -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Thursday, October 02, 2014 9:20 PM To: hotspot-dev at openjdk.java.net Subject: Re: RFR(M): 8059592: Recent bugfixes in ppc64 port. Looks fine. One question is how you can have failing state during code generation?: if (Compile::current()->env()->failing()) { return; } // Code cache may be full. There should be bailout in opto/output.cpp when codecache is full. Did it happen because estimated buffer size was less then needed? Thanks, Vladimir On 10/2/14 1:06 AM, Lindenmaier, Goetz wrote: > Hi, > > This change contains some bugfixes in the ppc64 coding, and some minor > improvements. It only touches code used in the port. > http://cr.openjdk.java.net/~goetz/webrevs/8059592-ppc_bugs/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8059592 > > Please review and test this change. I please need a sponsor. > This change also should go to 8u40, please. > > Best regards, > Goetz. > > From niclas.adlertz at oracle.com Mon Oct 6 11:25:34 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Mon, 06 Oct 2014 13:25:34 +0200 Subject: [8u40] RFR(XS): JDK-8055740 java -client -XX:ValueMapInitialSize=0 crashes Message-ID: <54327C2E.8000508@oracle.com> Hi, 8u40 backport request JDK-8055740, of original bug JDK-6883953. Patch(*) applies cleanly, no errors when running jprt. (*) http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b97166f236bd Kind Regards, Niclas Adlertz From frederic.parain at oracle.com Mon Oct 6 14:32:08 2014 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 06 Oct 2014 16:32:08 +0200 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <542EC9B4.1050908@oracle.com> References: <542AC0E8.9040409@oracle.com> <542EBE8F.5090800@oracle.com> <542EC9B4.1050908@oracle.com> Message-ID: <5432A7E8.5070601@oracle.com> Thank you very much for catching the JVM_O_DELETE issue. I moved the O_DELETE support into the ZipFile.c file (code was the same for all non-Windows platforms) and cleaned up the original code in HotSpot. The new webrevs: http://cr.openjdk.java.net/~fparain/8057777/jdk_v03/ http://cr.openjdk.java.net/~fparain/8057777/hotspot_v03/ Regards, Fred On 10/03/2014 06:07 PM, Xueming Shen wrote: > On 10/3/14 8:19 AM, Alan Bateman wrote: >> On 30/09/2014 07:40, Hideric Parain wrote: >>> Hi all, >>> >>> Please review changes for bug JDK-8057777 "Cleanup of old >>> and unused VM interfaces" >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8057777 >>> >>> This is basically a big cleanup of VM interfaces that are >>> not used anymore by the JDK but have been kept in our code >>> base for historical reasons (HotSpot Express for instance). >>> These changesets remove these interfaces from both the >>> JDK and the HotSpot side, and also perform some cleanup >>> on code that directly referenced the removed interfaces. >>> >>> These changes do not modify the behavior of the Java >>> classes impacted by the cleanup. >>> >>> VM interfaces removal has been approved by CCC and >>> a Release Note has been prepared that explicitly list >>> all the removed interfaces. >>> >>> Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~fparain/8057777/ >> cc'ing core-libs-dev as part of this is clean-up in the library code too. >> >> I think we should deprecate java.lang.Compiler and the >> Runtime.traceXXX methods. They've been non-functional for a long time >> and having them in the API is a bit mis-leading to anyone reading the >> javadoc. I realize you are focused on the removing the old JVM_* >> functions so we can follow-up on that via other issues of course. >> >> Can ClassLoader#resolveClass0 can be removed completely? The null >> check can be done in ClassLoader#resolveClass. >> >> In the mapfile for libjava then the comment at line 281 says >> "ZipFile.c needs this one". As getLastErrorString is now exported for >> use by libzip then the comment should probably be updated. >> >> Otherwise this clean-up looks good to me and the jdk_core group of >> tests is the right group to exercise this area. >> >> -Alan >> > > Hi, > > ZipFile.c expects the JVM_Open() to handle the JVM_O_DELETE, with > explicit unlink on linux/solaris for example. > I would assume the open from the c library does not handle it and we > need to do it explicitly by ZipFile.c now? > > -Sherman > > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From vladimir.kozlov at oracle.com Mon Oct 6 17:09:18 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Oct 2014 10:09:18 -0700 Subject: [8u40] RFR(XS): JDK-8055740 java -client -XX:ValueMapInitialSize=0 crashes In-Reply-To: <54327C2E.8000508@oracle.com> References: <54327C2E.8000508@oracle.com> Message-ID: <5432CCBE.9080100@oracle.com> Niclas, It looks good. Next time please include links to the bug report and original webrev. Thanks, Vladimir On 10/6/14 4:25 AM, Niclas Adlertz wrote: > Hi, > > 8u40 backport request JDK-8055740, of original bug JDK-6883953. > > Patch(*) applies cleanly, no errors when running jprt. > > (*) http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b97166f236bd > > Kind Regards, > Niclas Adlertz From vladimir.kozlov at oracle.com Mon Oct 6 17:17:09 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Oct 2014 10:17:09 -0700 Subject: [8u40] RFR(S): 8059621: JVM crashes with "unexpected index type" assert in LIRGenerator::do_UnsafeGetRaw In-Reply-To: <3F5372FD-C8F3-467D-8059-BA492B7BC8D9@oracle.com> References: <3F5372FD-C8F3-467D-8059-BA492B7BC8D9@oracle.com> Message-ID: <5432CE95.5040003@oracle.com> Looks good. thanks, Vladimir On 10/5/14 8:46 PM, Igor Veresov wrote: > Webrev: http://cr.openjdk.java.net/~iveresov/8059621/webrev.00 > JBS: https://bugs.openjdk.java.net/browse/JDK-8059621 > JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f4aadd8a5168 > > Thanks! > igor > From vladimir.kozlov at oracle.com Mon Oct 6 17:19:57 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Oct 2014 10:19:57 -0700 Subject: RFR(M): 8059592: Recent bugfixes in ppc64 port. In-Reply-To: <7C9B87B351A4BA4AA9EC95BB418116566ACD4424@DEWDFEMB19C.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF0AB1E@DEWDFEMB12A.global.corp.sap> <542DA575.3040701@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF0C41D@DEWDFEMB12A.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB418116566ACD4424@DEWDFEMB19C.global.corp.sap> Message-ID: <5432CF3D.8010201@oracle.com> Thank you, Martin, for explanation. Vladimir On 10/6/14 1:43 AM, Doerr, Martin wrote: > Hi Vladimir, > > we have call nodes which emit trampoline stubs. This may fail if the code cache is too full. > In this case, the emit() function records out-of-memory and returns. > > Best regards, > Martin > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Samstag, 4. Oktober 2014 20:02 > To: 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net' > Cc: Doerr, Martin > Subject: RE: RFR(M): 8059592: Recent bugfixes in ppc64 port. > > Hi Vladimir, > > I don't know exactly what happened, Martin fixed that. > We have test where we set very small code cache size to > stress the code cache infrastructure, and that test failed. > Martin, can you give more detail? > > Best regards, > Goetz > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Thursday, October 02, 2014 9:20 PM > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): 8059592: Recent bugfixes in ppc64 port. > > Looks fine. One question is how you can have failing state during code > generation?: > > if (Compile::current()->env()->failing()) { return; } // Code cache may > be full. > > There should be bailout in opto/output.cpp when codecache is full. > Did it happen because estimated buffer size was less then needed? > > Thanks, > Vladimir > > On 10/2/14 1:06 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> This change contains some bugfixes in the ppc64 coding, and some minor >> improvements. It only touches code used in the port. >> http://cr.openjdk.java.net/~goetz/webrevs/8059592-ppc_bugs/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8059592 >> >> Please review and test this change. I please need a sponsor. >> This change also should go to 8u40, please. >> >> Best regards, >> Goetz. >> >> From iris.clark at oracle.com Mon Oct 6 17:48:07 2014 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 6 Oct 2014 10:48:07 -0700 (PDT) Subject: New staging repository for AArch64 open port In-Reply-To: <542F2436.7070608@oracle.com> References: <542F2436.7070608@oracle.com> Message-ID: <5c11c4f0-8850-4b7f-a851-e969608976fb@default> Hi, Andrew. As the Lead of the AArch64 Project, do you approve of the request to create this staging forest? Do you want jcheck fully enabled (formatted changeset comment, Reviewers, etc.) so that you can preserve your history similar to what was done for the PPC/AIX Port? Assuming that you do, then I'm going to need to investigate how to handle that configuration. Minimally, if Vladimir needs to push he needs to be at least a Committer to the AArch64 Project. Who do you anticipate the changeset authors to be? They'd need to be at least Authors in both JDK 9 and AArch64. Thanks, iris -----Original Message----- From: Vladimir Kozlov Sent: Friday, October 03, 2014 3:33 PM To: Iris Clark Cc: aarch64-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; jdk9-dev at openjdk.java.net; Andrew Haley Subject: New staging repository for AArch64 open port Hi Iris, aarch64 (arm64) open port JEP is reviewed and endorsed: https://bugs.openjdk.java.net/browse/JDK-8044552 Could you, please, create jdk9 staging forest (including closed repos) for it? Something like: http://hg.openjdk.java.net/aarch64-port/stage It should be child of jdk9/dev forest. Push notifications for open changes could be sent to: aarch64-port-dev at openjdk.java.net Initial committers will be Andrew Haley (aph) and me, Vladimir Kozlov (kvn). We may add more committers later. Best regards, Vladimir From igor.veresov at oracle.com Mon Oct 6 18:34:51 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 6 Oct 2014 11:34:51 -0700 Subject: [8u40] RFR(S): 8059621: JVM crashes with "unexpected index type" assert in LIRGenerator::do_UnsafeGetRaw In-Reply-To: <5432CE95.5040003@oracle.com> References: <3F5372FD-C8F3-467D-8059-BA492B7BC8D9@oracle.com> <5432CE95.5040003@oracle.com> Message-ID: <2990705D-21F4-4EE5-8647-4CB2C7D9F743@oracle.com> Thanks, Vladimir! igor On Oct 6, 2014, at 10:17 AM, Vladimir Kozlov wrote: > Looks good. > > thanks, > Vladimir > > On 10/5/14 8:46 PM, Igor Veresov wrote: >> Webrev: http://cr.openjdk.java.net/~iveresov/8059621/webrev.00 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8059621 >> JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f4aadd8a5168 >> >> Thanks! >> igor >> From aph at redhat.com Mon Oct 6 18:41:47 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 06 Oct 2014 19:41:47 +0100 Subject: New staging repository for AArch64 open port In-Reply-To: <5c11c4f0-8850-4b7f-a851-e969608976fb@default> References: <542F2436.7070608@oracle.com> <5c11c4f0-8850-4b7f-a851-e969608976fb@default> Message-ID: <5432E26B.2070406@redhat.com> On 10/06/2014 06:48 PM, Iris Clark wrote: > > As the Lead of the AArch64 Project, do you approve of the request to > create this staging forest? Do you want jcheck fully enabled > (formatted changeset comment, Reviewers, etc.) so that you can > preserve your history similar to what was done for the PPC/AIX Port? Yes. I'm putting myself in the hands of Vladimir here, but I'm pretty sure we need jcheck. I know that our existing revision history is not jcheck-compliant, so it wouldn't be acceptable, but I am prepared to lose the history because I'll be submitting clean webrevs. The aarch64-project tree will always be there for the archaeologists. > Assuming that you do, then I'm going to need to investigate how to > handle that configuration. Minimally, if Vladimir needs to push he > needs to be at least a Committer to the AArch64 Project. Who do you > anticipate the changeset authors to be? They'd need to be at least > Authors in both JDK 9 and AArch64. I can't even remember if I am a JDK9 author, but at least me and Andrew Dinn. Edward Nevill is a major AArch64 contributor, but I don't think he is a JDK9 author. Thanks, Andrew. From vladimir.kozlov at oracle.com Mon Oct 6 19:47:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Oct 2014 12:47:35 -0700 Subject: New staging repository for AArch64 open port In-Reply-To: <5432E26B.2070406@redhat.com> References: <542F2436.7070608@oracle.com> <5c11c4f0-8850-4b7f-a851-e969608976fb@default> <5432E26B.2070406@redhat.com> Message-ID: <5432F1D7.4000001@oracle.com> On 10/6/14 11:41 AM, Andrew Haley wrote: > On 10/06/2014 06:48 PM, Iris Clark wrote: >> >> As the Lead of the AArch64 Project, do you approve of the request to >> create this staging forest? Do you want jcheck fully enabled >> (formatted changeset comment, Reviewers, etc.) so that you can >> preserve your history similar to what was done for the PPC/AIX Port? > > Yes. I'm putting myself in the hands of Vladimir here, but I'm pretty > sure we need jcheck. Yes, staging repo should have jcheck fully enabled. > I know that our existing revision history is not jcheck-compliant, so > it wouldn't be acceptable, but I am prepared to lose the history > because I'll be submitting clean webrevs. The aarch64-project tree > will always be there for the archaeologists. > >> Assuming that you do, then I'm going to need to investigate how to >> handle that configuration. Minimally, if Vladimir needs to push he >> needs to be at least a Committer to the AArch64 Project. Who do you Do I really need to be Committer to the AArch64 Project? Can jdk9 Committer status be enough? The staging forest is child of jdk9 forest. I may be not the only one from Oracle side who will help with sponsoring pushes. It would be nice if you allow any jdk9 committer to push into aarch64 stage forest. >> anticipate the changeset authors to be? They'd need to be at least >> Authors in both JDK 9 and AArch64. > > I can't even remember if I am a JDK9 author, but at least me and > Andrew Dinn. Edward Nevill is a major AArch64 contributor, but I > don't think he is a JDK9 author. http://openjdk.java.net/census Andrew, you are JDK9 Committer which includes Author status. So you can be author and you can push into the staging forest. Andrew Dinn and Edward Nevill are not JDK9 authors. They should be listed in "Contributed-by: ". Their changes have to be sponsored (pushed) by us, Oracle, or by you, Andrew. Thanks, Vladimir > > Thanks, > Andrew. > From iris.clark at oracle.com Mon Oct 6 20:18:49 2014 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 6 Oct 2014 13:18:49 -0700 (PDT) Subject: New staging repository for AArch64 open port In-Reply-To: <5432F1D7.4000001@oracle.com> References: <542F2436.7070608@oracle.com> <5c11c4f0-8850-4b7f-a851-e969608976fb@default> <5432E26B.2070406@redhat.com> <5432F1D7.4000001@oracle.com> Message-ID: Hi, Vladimir. >> Assuming that you do, then I'm going to need to investigate how to >> handle that configuration. Minimally, if Vladimir needs to push he >> needs to be at least a Committer to the AArch64 Project. Who do you > Do I really need to be Committer to the AArch64 Project? Can jdk9 Committer status be enough? The staging forest is child of jdk9 forest. I may be not the only one from Oracle side who will help with sponsoring pushes. It would be nice if you allow any jdk9 committer to push into aarch64 stage forest. Yes, you really need to be a AArch64 Committer. The AArch64 Project is the owner of the forest regardless of how it was originally created/cloned. I can create a limited-access forest as requested, but the people on that list (in this case Andrew Haley and you) must be a subset of the owning Project's Census entry. Any Oracle employee who wishes to push changes into the open portion of aarch64/stage must be an AArch64 Committer. Thanks, iris From vladimir.kozlov at oracle.com Mon Oct 6 21:02:10 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Oct 2014 14:02:10 -0700 Subject: New staging repository for AArch64 open port In-Reply-To: References: <542F2436.7070608@oracle.com> <5c11c4f0-8850-4b7f-a851-e969608976fb@default> <5432E26B.2070406@redhat.com> <5432F1D7.4000001@oracle.com> Message-ID: <54330352.2050900@oracle.com> Okay, thank you for clarifying it, Iris. Vladimir On 10/6/14 1:18 PM, Iris Clark wrote: > Hi, Vladimir. > >>> Assuming that you do, then I'm going to need to investigate how to >>> handle that configuration. Minimally, if Vladimir needs to push he >>> needs to be at least a Committer to the AArch64 Project. Who do you > >> Do I really need to be Committer to the AArch64 Project? Can jdk9 Committer status be enough? The staging forest is child of jdk9 forest. > I may be not the only one from Oracle side who will help with sponsoring pushes. It would be nice if you allow any jdk9 committer to push into > aarch64 stage forest. > > Yes, you really need to be a AArch64 Committer. The AArch64 Project is the owner of the forest regardless of how it was originally created/cloned. I can create a limited-access forest as requested, but the people on that list (in this case Andrew Haley and you) must be a subset of the owning Project's Census entry. Any Oracle employee who wishes to push changes into the open portion of aarch64/stage must be an AArch64 Committer. > > Thanks, > iris > From david.holmes at oracle.com Tue Oct 7 05:22:32 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Oct 2014 15:22:32 +1000 Subject: PPC64 doesn't define SUPPORTS_NATIVE_CX8 ? In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEC6BD4@DEWDFEMB12A.global.corp.sap> References: <538FA3A5.3020504@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEC6BD4@DEWDFEMB12A.global.corp.sap> Message-ID: <54337898.6010909@oracle.com> Hi Goetz, Apologies that my changes have not yet been pushed (something I hope to rectify in the very near future). I see you have now handled this yourself. David On 5/06/2014 5:06 PM, Lindenmaier, Goetz wrote: > Hi David, > > thanks for spotting this! Yes, this should be set. We also set it > in our internal VM, somehow it got lost in the port. > > It would be great if you could fix this along with your change. > > Best regards, > Goetz. > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes > Sent: Donnerstag, 5. Juni 2014 00:54 > To: ppc-aix-port-dev at openjdk.java.net > Cc: hotspot-dev developers > Subject: PPC64 doesn't define SUPPORTS_NATIVE_CX8 ? > > SUPPORTS_NATIVE_CX8 is used by platforms with full 64-bit CAS and > atomics capability to elide the lock-based Unsafe jlong atomic update > methods and avoid a runtime VM_Version::supports_cx8() check. I just > noticed this isn't set for PPC64. Can I assume that is just an > oversight? I have some changes to the lock-based code in the pipeline > and can update the PPC64 code at the same time if desired. > > Thanks, > David > From david.holmes at oracle.com Tue Oct 7 06:18:06 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Oct 2014 16:18:06 +1000 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <5432A7E8.5070601@oracle.com> References: <542AC0E8.9040409@oracle.com> <542EBE8F.5090800@oracle.com> <542EC9B4.1050908@oracle.com> <5432A7E8.5070601@oracle.com> Message-ID: <5433859E.7070706@oracle.com> Hi Fred, Looks okay to me too. But I wouldn't be surprised if there is some test somewhere that checks for things when PrintJVMWarnings is set :) David On 7/10/2014 12:32 AM, Frederic Parain wrote: > Thank you very much for catching the JVM_O_DELETE issue. > I moved the O_DELETE support into the ZipFile.c file > (code was the same for all non-Windows platforms) and > cleaned up the original code in HotSpot. > > The new webrevs: > > http://cr.openjdk.java.net/~fparain/8057777/jdk_v03/ > http://cr.openjdk.java.net/~fparain/8057777/hotspot_v03/ > > Regards, > > Fred > > On 10/03/2014 06:07 PM, Xueming Shen wrote: >> On 10/3/14 8:19 AM, Alan Bateman wrote: >>> On 30/09/2014 07:40, Hideric Parain wrote: >>>> Hi all, >>>> >>>> Please review changes for bug JDK-8057777 "Cleanup of old >>>> and unused VM interfaces" >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8057777 >>>> >>>> This is basically a big cleanup of VM interfaces that are >>>> not used anymore by the JDK but have been kept in our code >>>> base for historical reasons (HotSpot Express for instance). >>>> These changesets remove these interfaces from both the >>>> JDK and the HotSpot side, and also perform some cleanup >>>> on code that directly referenced the removed interfaces. >>>> >>>> These changes do not modify the behavior of the Java >>>> classes impacted by the cleanup. >>>> >>>> VM interfaces removal has been approved by CCC and >>>> a Release Note has been prepared that explicitly list >>>> all the removed interfaces. >>>> >>>> Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core >>>> >>>> Webrevs: >>>> http://cr.openjdk.java.net/~fparain/8057777/ >>> cc'ing core-libs-dev as part of this is clean-up in the library code >>> too. >>> >>> I think we should deprecate java.lang.Compiler and the >>> Runtime.traceXXX methods. They've been non-functional for a long time >>> and having them in the API is a bit mis-leading to anyone reading the >>> javadoc. I realize you are focused on the removing the old JVM_* >>> functions so we can follow-up on that via other issues of course. >>> >>> Can ClassLoader#resolveClass0 can be removed completely? The null >>> check can be done in ClassLoader#resolveClass. >>> >>> In the mapfile for libjava then the comment at line 281 says >>> "ZipFile.c needs this one". As getLastErrorString is now exported for >>> use by libzip then the comment should probably be updated. >>> >>> Otherwise this clean-up looks good to me and the jdk_core group of >>> tests is the right group to exercise this area. >>> >>> -Alan >>> >> >> Hi, >> >> ZipFile.c expects the JVM_Open() to handle the JVM_O_DELETE, with >> explicit unlink on linux/solaris for example. >> I would assume the open from the c library does not handle it and we >> need to do it explicitly by ZipFile.c now? >> >> -Sherman >> >> > From david.holmes at oracle.com Tue Oct 7 06:35:06 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Oct 2014 16:35:06 +1000 Subject: RFR(XXS) : 8059732 : improve hotspot_*test targets In-Reply-To: <5431662F.2040804@oracle.com> References: <5431662F.2040804@oracle.com> Message-ID: <5433899A.4040405@oracle.com> Hi Igor, Looks okay to me. Thanks, David On 6/10/2014 1:39 AM, Igor Ignatyev wrote: > webrev: http://cr.openjdk.java.net/~iignatyev/8059732/webrev.00/ > 33 lines changed: 20 ins; 9 del; 4 mod; > > Hi all, > > Please review changes in hotspot_*test targets: > - common part is extracted as sanitytest target > - flags to test are stored in TEST_FLAGS variable > - tests fail if one of executions fail (not the last one, as it was > before) > > jbs: https://bugs.openjdk.java.net/browse/JDK-8059732 > testing: jprt > From david.holmes at oracle.com Tue Oct 7 06:42:56 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Oct 2014 16:42:56 +1000 Subject: RFR: JDK-8059586: hs_err report should treat redirected core pattern. In-Reply-To: <542C8274.3010809@gmail.com> References: <542C8274.3010809@gmail.com> Message-ID: <54338B70.9080709@oracle.com> Hi Yasumasa, I'm sorry but I don't understand what you are proposing. When you say "treat" do you mean "create"? Otherwise what do you mean by "treated"? Thanks, David On 2/10/2014 8:38 AM, Yasumasa Suenaga wrote: > I'm in Hackergarten @ JavaOne :-) > > > Hi all, > > I would like to enhance the messages in hs_err report. > Modern Linux kernel can treat core dump with user process (e.g. ABRT) > However, hs_err report cannot detect it. > > I think that hs_err report should output messages as below: > ------------- > Failed to write core dump. Core dumps may be treated with "/usr/sbin/chroot /proc/%P/root /usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e" > ------------- > > I've uploaded webrev of this enhancement. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.00/ > > This patch works fine on Fedora20 x86_64. > > > > Thanks, > > Yasumasa > From goetz.lindenmaier at sap.com Tue Oct 7 07:59:10 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 7 Oct 2014 07:59:10 +0000 Subject: PPC64 doesn't define SUPPORTS_NATIVE_CX8 ? In-Reply-To: <54337898.6010909@oracle.com> References: <538FA3A5.3020504@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEC6BD4@DEWDFEMB12A.global.corp.sap> <54337898.6010909@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF0D8CB@DEWDFEMB12A.global.corp.sap> Hi David, sorry, I don't want to claim the merits for this. I had added and tested that define in my client where I collect minor fixes we do internally, and thought I would now submit it along with all of them to still catch 8u40. Thanks again for pointing this out. Best regards, Goetz -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 7. Oktober 2014 07:23 To: Lindenmaier, Goetz; ppc-aix-port-dev at openjdk.java.net Cc: hotspot-dev developers Subject: Re: PPC64 doesn't define SUPPORTS_NATIVE_CX8 ? Hi Goetz, Apologies that my changes have not yet been pushed (something I hope to rectify in the very near future). I see you have now handled this yourself. David On 5/06/2014 5:06 PM, Lindenmaier, Goetz wrote: > Hi David, > > thanks for spotting this! Yes, this should be set. We also set it > in our internal VM, somehow it got lost in the port. > > It would be great if you could fix this along with your change. > > Best regards, > Goetz. > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes > Sent: Donnerstag, 5. Juni 2014 00:54 > To: ppc-aix-port-dev at openjdk.java.net > Cc: hotspot-dev developers > Subject: PPC64 doesn't define SUPPORTS_NATIVE_CX8 ? > > SUPPORTS_NATIVE_CX8 is used by platforms with full 64-bit CAS and > atomics capability to elide the lock-based Unsafe jlong atomic update > methods and avoid a runtime VM_Version::supports_cx8() check. I just > noticed this isn't set for PPC64. Can I assume that is just an > oversight? I have some changes to the lock-based code in the pipeline > and can update the PPC64 code at the same time if desired. > > Thanks, > David > From yasuenag at gmail.com Tue Oct 7 10:48:53 2014 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 7 Oct 2014 19:48:53 +0900 Subject: RFR: JDK-8059586: hs_err report should treat redirected core pattern. In-Reply-To: <54338B70.9080709@oracle.com> References: <542C8274.3010809@gmail.com> <54338B70.9080709@oracle.com> Message-ID: Hi David, Sorry for my English. I want to propose that JVM should create message according to core pattern (/proc/sys/kernel/core_pattern) . So I filed it to JBS and created a patch. Thanks, Yasumasa 2014/10/07 15:43 "David Holmes" : > Hi Yasumasa, > > I'm sorry but I don't understand what you are proposing. When you say > "treat" do you mean "create"? Otherwise what do you mean by "treated"? > > Thanks, > David > > On 2/10/2014 8:38 AM, Yasumasa Suenaga wrote: > > I'm in Hackergarten @ JavaOne :-) > > > > > > Hi all, > > > > I would like to enhance the messages in hs_err report. > > Modern Linux kernel can treat core dump with user process (e.g. ABRT) > > However, hs_err report cannot detect it. > > > > I think that hs_err report should output messages as below: > > ------------- > > Failed to write core dump. Core dumps may be treated with > "/usr/sbin/chroot /proc/%P/root /usr/libexec/abrt-hook-ccpp %s %c %p %u %g > %t e" > > ------------- > > > > I've uploaded webrev of this enhancement. > > Could you review it? > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.00/ > > > > This patch works fine on Fedora20 x86_64. > > > > > > > > Thanks, > > > > Yasumasa > > > From Alan.Bateman at oracle.com Tue Oct 7 13:06:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Oct 2014 06:06:44 -0700 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <5432A7E8.5070601@oracle.com> References: <542AC0E8.9040409@oracle.com> <542EBE8F.5090800@oracle.com> <542EC9B4.1050908@oracle.com> <5432A7E8.5070601@oracle.com> Message-ID: <5433E564.8010402@oracle.com> On 06/10/2014 07:32, Frederic Parain wrote: > Thank you very much for catching the JVM_O_DELETE issue. > I moved the O_DELETE support into the ZipFile.c file > (code was the same for all non-Windows platforms) and > cleaned up the original code in HotSpot. > > The new webrevs: > > http://cr.openjdk.java.net/~fparain/8057777/jdk_v03/ > http://cr.openjdk.java.net/~fparain/8057777/hotspot_v03/ > Good spot by Sherman on the OPEN_DELETE issue, it makes me wonder what the test coverage is on this. The updated webrev addresses the points that I brought up and looks good (nice to see many of these functions going away). -Alan From coleen.phillimore at oracle.com Tue Oct 7 17:48:18 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 07 Oct 2014 13:48:18 -0400 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <5432A7E8.5070601@oracle.com> References: <542AC0E8.9040409@oracle.com> <542EBE8F.5090800@oracle.com> <542EC9B4.1050908@oracle.com> <5432A7E8.5070601@oracle.com> Message-ID: <54342762.9090304@oracle.com> Fred, The additional changes to these files looks fine to me also. Thanks! Coleen On 10/6/14, 10:32 AM, Frederic Parain wrote: > Thank you very much for catching the JVM_O_DELETE issue. > I moved the O_DELETE support into the ZipFile.c file > (code was the same for all non-Windows platforms) and > cleaned up the original code in HotSpot. > > The new webrevs: > > http://cr.openjdk.java.net/~fparain/8057777/jdk_v03/ > http://cr.openjdk.java.net/~fparain/8057777/hotspot_v03/ > > Regards, > > Fred > > On 10/03/2014 06:07 PM, Xueming Shen wrote: >> On 10/3/14 8:19 AM, Alan Bateman wrote: >>> On 30/09/2014 07:40, Hideric Parain wrote: >>>> Hi all, >>>> >>>> Please review changes for bug JDK-8057777 "Cleanup of old >>>> and unused VM interfaces" >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8057777 >>>> >>>> This is basically a big cleanup of VM interfaces that are >>>> not used anymore by the JDK but have been kept in our code >>>> base for historical reasons (HotSpot Express for instance). >>>> These changesets remove these interfaces from both the >>>> JDK and the HotSpot side, and also perform some cleanup >>>> on code that directly referenced the removed interfaces. >>>> >>>> These changes do not modify the behavior of the Java >>>> classes impacted by the cleanup. >>>> >>>> VM interfaces removal has been approved by CCC and >>>> a Release Note has been prepared that explicitly list >>>> all the removed interfaces. >>>> >>>> Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core >>>> >>>> Webrevs: >>>> http://cr.openjdk.java.net/~fparain/8057777/ >>> cc'ing core-libs-dev as part of this is clean-up in the library code >>> too. >>> >>> I think we should deprecate java.lang.Compiler and the >>> Runtime.traceXXX methods. They've been non-functional for a long time >>> and having them in the API is a bit mis-leading to anyone reading the >>> javadoc. I realize you are focused on the removing the old JVM_* >>> functions so we can follow-up on that via other issues of course. >>> >>> Can ClassLoader#resolveClass0 can be removed completely? The null >>> check can be done in ClassLoader#resolveClass. >>> >>> In the mapfile for libjava then the comment at line 281 says >>> "ZipFile.c needs this one". As getLastErrorString is now exported for >>> use by libzip then the comment should probably be updated. >>> >>> Otherwise this clean-up looks good to me and the jdk_core group of >>> tests is the right group to exercise this area. >>> >>> -Alan >>> >> >> Hi, >> >> ZipFile.c expects the JVM_Open() to handle the JVM_O_DELETE, with >> explicit unlink on linux/solaris for example. >> I would assume the open from the c library does not handle it and we >> need to do it explicitly by ZipFile.c now? >> >> -Sherman >> >> > From serguei.spitsyn at oracle.com Thu Oct 9 00:47:21 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 08 Oct 2014 17:47:21 -0700 Subject: RFR (XS) 8059904: libjvm_db.c warnings in solaris/sparc build with SS Message-ID: <5435DB19.7080005@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8059904 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8059904-jvmdb-warn.1/ Summary: Several warnings started to appear at compilation of the libjvm_db.c after the switch from Sun C++ 5.10 to 5.12. The fix is to cast the result of calloc() to the correct type. Testing: Running the adhoc pstack tests on Solaris sparcv9 and amd64 Thanks, Serguei From coleen.phillimore at oracle.com Thu Oct 9 01:55:01 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 08 Oct 2014 21:55:01 -0400 Subject: RFR (XS) 8059904: libjvm_db.c warnings in solaris/sparc build with SS In-Reply-To: <5435DB19.7080005@oracle.com> References: <5435DB19.7080005@oracle.com> Message-ID: <5435EAF5.7000903@oracle.com> Looks good, Serguei. Thank you for fixing it! Coleen On 10/8/14, 8:47 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8059904 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8059904-jvmdb-warn.1/ > > > > Summary: > > Several warnings started to appear at compilation of the libjvm_db.c > after the switch from Sun C++ 5.10 to 5.12. > The fix is to cast the result of calloc() to the correct type. > > > Testing: > Running the adhoc pstack tests on Solaris sparcv9 and amd64 > > > Thanks, > Serguei From david.holmes at oracle.com Thu Oct 9 04:18:41 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Oct 2014 14:18:41 +1000 Subject: RFR (XS) 8059904: libjvm_db.c warnings in solaris/sparc build with SS In-Reply-To: <5435DB19.7080005@oracle.com> References: <5435DB19.7080005@oracle.com> Message-ID: <54360CA1.1050608@oracle.com> On 9/10/2014 10:47 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8059904 Shouldn't the same fix be applied to the bsd version? Otherwise looks okay. Thanks, David > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8059904-jvmdb-warn.1/ > > > > Summary: > > Several warnings started to appear at compilation of the libjvm_db.c > after the switch from Sun C++ 5.10 to 5.12. > The fix is to cast the result of calloc() to the correct type. > > > Testing: > Running the adhoc pstack tests on Solaris sparcv9 and amd64 > > > Thanks, > Serguei From david.holmes at oracle.com Thu Oct 9 04:40:40 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Oct 2014 14:40:40 +1000 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: <542C58E7.7050907@oracle.com> References: <54124F11.8060100@oracle.com> <8E69D7A0-CD8D-4EC6-B708-5F2C0098B183@lnu.se> <54197E53.9030307@oracle.com> <542C58E7.7050907@oracle.com> Message-ID: <543611C8.2090807@oracle.com> Hi Erik, Sorry for the further delay on this. Not sure I like VM_HAS_SPECIALIZED_BYTE_CMPXCHG. Would like to hear opinions from others. (I also can't confirm the correctness of the assembler code nor the changes to the .il files, so other's need to weigh in here regardless.) With this approach does every arch need an entry in stubGenerator_.ccp of the form: StubRoutines::_atomic_cmpxchg_byte_entry = ; ? If we have to touch the code for each arch then maybe simply duplicating what is presently the shared implementation is a better way to go? In src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp you have: 126 #define VM_HAS_SPECIALIZED_BYTE_CMPXCHG and 220 #define VM_HAS_SPECIALIZED_BYTE_CMPXCHG Thanks, David ----- On 2/10/2014 5:41 AM, David Holmes wrote: > Hi Erik, > > Currently at JavaOne and then travelling back to Australia tomorrow. It > will be Tuesday (Holiday Monday) before I can take another look at this. > > Sorry. > > David > > On 2/10/2014 4:32 AM, Erik ?sterlund wrote: >> Hi, >> >> There is now a new webrev with my jbyte cmpxchg changes here: >> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01/ >> >> The change from last time is: >> 1. Fixed an issue where cmpxchgl was incorrectly emitted instead of >> cmpxchgb for one of the configurations as pointed out by Andrew Haley, >> cheers for finding that >> 2. Changed the "design" around a bit to make it easy to override the >> cmpxchgb for different platforms without having #if >> defined(PLATFORM_X) || defined(PLATFORMY) etc. in the headers.. If not >> explicitly overridden, the old general solution be used instead like >> normal and this should hence not break any of the different ports to >> other architectures not included in the main hotspot project. >> >> Jesper ran it through jprt and it was all green. Thanks for checking >> that! >> >> Would be nice if I could get some reviews. :) >> >> Thanks, >> Erik >> >> >> On 20 Sep 2014, at 23:53, Erik ?sterlund >> > wrote: >> >> I don't want to break the ported builds so I made a special variant of >> the third option where the x86 inline methods also have a #define next >> to them. >> The atomic.inline.hpp file then simply defines an inline >> Atomic::cmpxchg calling the general solution if there is no #define >> for an override. >> >> That way it's using variant three, but there is no need to write >> overrides for every platform port (which are sometimes in other repos) >> there is to simply run the default member function. >> We can add them one by one instead. :) >> >> Hope this seems satisfactory. >> >> Thanks, >> Erik >> >> On 17 Sep 2014, at 14:28, David Holmes >> > wrote: >> >> On 17/09/2014 9:13 PM, Erik ?sterlund wrote: >> I am back! Did you guys have time to do some thinking? I see three >> different solutions: >> >> 1. Good old class inheritance! Class Atomic is-a Atomic_YourArchHere >> is-a AtomicAbstract >> Using the CRTP (Curiously Recurring Template Pattern) for C++, this >> could be done without a virtual call where we want inlining. >> >> I would prefer this approach (here and elsewhere) but it is not a >> short-term option. >> >> 2. Similar except with the SFINAE idiom (Substitution Failure Is Not >> An Error) for C++, to pick the right overload based on statically >> determined constraints. >> E.g. define if Atomic::has_general_byte_CAS and based on whether this >> is defined or not, pick the general or specific overload variant of >> the CAS member function. >> >> Not sure what this one is but it sounds like a manual virtual dispatch >> - which seems not a good solution. >> >> 3. Simply make the current CAS a normal function which is called from >> billions of new inline method definitions that we have to create for >> every single architecture. >> >> I think the simple version of 3 is just move cmpxchg(jbtye) out of the >> shared code and define for each platform - there aren't that many and >> it is consistent with many of the other variants. >> >> What do we prefer here? Does anyone else have a better idea? Also, >> should I start a new thread or is it okay to post it here? >> >> Continuing this thread is fine by me. >> >> I think short-term the simple version of 3 is preferable. >> >> Thanks, >> David >> From frederic.parain at oracle.com Thu Oct 9 07:19:04 2014 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 09 Oct 2014 09:19:04 +0200 Subject: RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces In-Reply-To: <5433E564.8010402@oracle.com> References: <542AC0E8.9040409@oracle.com> <542EBE8F.5090800@oracle.com> <542EC9B4.1050908@oracle.com> <5432A7E8.5070601@oracle.com> <5433E564.8010402@oracle.com> Message-ID: <543636E8.9080802@oracle.com> Thank you Coleen, Harold, Alan and Sherman for your reviews. Fred On 07/10/2014 15:06, Alan Bateman wrote: > On 06/10/2014 07:32, Frederic Parain wrote: >> Thank you very much for catching the JVM_O_DELETE issue. >> I moved the O_DELETE support into the ZipFile.c file >> (code was the same for all non-Windows platforms) and >> cleaned up the original code in HotSpot. >> >> The new webrevs: >> >> http://cr.openjdk.java.net/~fparain/8057777/jdk_v03/ >> http://cr.openjdk.java.net/~fparain/8057777/hotspot_v03/ >> > Good spot by Sherman on the OPEN_DELETE issue, it makes me wonder what > the test coverage is on this. > > The updated webrev addresses the points that I brought up and looks good > (nice to see many of these functions going away). > > -Alan -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From serguei.spitsyn at oracle.com Thu Oct 9 08:30:24 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 09 Oct 2014 01:30:24 -0700 Subject: RFR (XS) 8059904: libjvm_db.c warnings in solaris/sparc build with SS In-Reply-To: <54360CA1.1050608@oracle.com> References: <5435DB19.7080005@oracle.com> <54360CA1.1050608@oracle.com> Message-ID: <543647A0.5000308@oracle.com> David, Thank you for review! I've applied the same fix to the bsd version as it exists (see the patch below). However, I do not think the libjvm_db.so is currently used by the pstack utility on bsd or Mac OSX. The pstack utility must be updated to get use of it. One more observation is that the libjvm_db.c has a minor difference on bsd: % diff bsd/dtrace/libjvm_db.c solaris/dtrace/libjvm_db.c 29c29 < // not available on macosx #include --- > #include 493c493 < err = find_symbol(J, "__1cNMethodG__vtbl_", &J->Method_vtbl); --- > err = find_symbol(J, "__1cGMethodG__vtbl_", &J->Method_vtbl); This difference came with the fix of 6964458. It looks like the mangling rules are different on bsd vs on solaris. Thanks, Serguei % hg diff diff -r 795fc0cef7c9 src/os/bsd/dtrace/libjvm_db.c --- a/src/os/bsd/dtrace/libjvm_db.c Fri Oct 03 13:56:18 2014 -0700 +++ b/src/os/bsd/dtrace/libjvm_db.c Thu Oct 09 00:55:34 2014 -0700 @@ -347,10 +347,10 @@ &J->Number_of_heaps, sizeof(J->Number_of_heaps)); /* Allocate memory for heap configurations */ - J->Heap_low = (jvm_agent_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); - J->Heap_high = (jvm_agent_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); - J->Heap_segmap_low = (jvm_agent_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); - J->Heap_segmap_high = (jvm_agent_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); + J->Heap_low = (uint64_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); + J->Heap_high = (uint64_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); + J->Heap_segmap_low = (uint64_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); + J->Heap_segmap_high = (uint64_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); /* Read code heap configurations */ for (i = 0; i < J->Number_of_heaps; ++i) { diff -r 795fc0cef7c9 src/os/solaris/dtrace/libjvm_db.c --- a/src/os/solaris/dtrace/libjvm_db.c Fri Oct 03 13:56:18 2014 -0700 +++ b/src/os/solaris/dtrace/libjvm_db.c Thu Oct 09 00:55:34 2014 -0700 @@ -347,10 +347,10 @@ &J->Number_of_heaps, sizeof(J->Number_of_heaps)); /* Allocate memory for heap configurations */ - J->Heap_low = (jvm_agent_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); - J->Heap_high = (jvm_agent_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); - J->Heap_segmap_low = (jvm_agent_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); - J->Heap_segmap_high = (jvm_agent_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); + J->Heap_low = (uint64_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); + J->Heap_high = (uint64_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); + J->Heap_segmap_low = (uint64_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); + J->Heap_segmap_high = (uint64_t*)calloc(J->Number_of_heaps, sizeof(uint64_t)); /* Read code heap configurations */ for (i = 0; i < J->Number_of_heaps; ++i) { On 10/8/14 9:18 PM, David Holmes wrote: > On 9/10/2014 10:47 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8059904 > > Shouldn't the same fix be applied to the bsd version? > > Otherwise looks okay. > > Thanks, > David > >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8059904-jvmdb-warn.1/ >> >> >> >> >> Summary: >> >> Several warnings started to appear at compilation of the libjvm_db.c >> after the switch from Sun C++ 5.10 to 5.12. >> The fix is to cast the result of calloc() to the correct type. >> >> >> Testing: >> Running the adhoc pstack tests on Solaris sparcv9 and amd64 >> >> >> Thanks, >> Serguei From erik.osterlund at lnu.se Thu Oct 9 09:13:04 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Thu, 9 Oct 2014 09:13:04 +0000 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: <543611C8.2090807@oracle.com> References: <54124F11.8060100@oracle.com> <8E69D7A0-CD8D-4EC6-B708-5F2C0098B183@lnu.se> <54197E53.9030307@oracle.com> <542C58E7.7050907@oracle.com> <543611C8.2090807@oracle.com> Message-ID: <00D9D39D-45FB-45B8-9B2C-6D24C2C0EA75@lnu.se> Hi David, On 09 Oct 2014, at 06:40, David Holmes wrote: > Hi Erik, > > Sorry for the further delay on this. No problem. > Not sure I like VM_HAS_SPECIALIZED_BYTE_CMPXCHG. Would like to hear opinions from others. (I also can't confirm the correctness of the assembler code nor the changes to the .il files, so other's need to weigh in here regardless.) Okay. I did this in order not to break the code for maintainers of ports outside of our repo. Did not want a performance optimization for x86 to be intrusive and break the code of all others. I'm open to suggestions if anyone else has a better solution to this (that does not need virtual calls). And if you want me to ruthlessly just define a jbyte Atomic::cmpxchg inline member function that forwards to the old solution for the platforms in our repo (and breaking the code for all others outside), I can do that too. > With this approach does every arch need an entry in stubGenerator_.ccp of the form: > > StubRoutines::_atomic_cmpxchg_byte_entry = ; > > ? If we have to touch the code for each arch then maybe simply duplicating what is presently the shared implementation is a better way to go? This is currently used only by very awkward configurations that have no compiler support to generate the machine code I want. Instead it is generated at runtime while bootstrapping the jbyte Atomic::cmpxchg member function. Other platforms need not care about defining such entry as it is not being used by them. Unless they actually want to use it of course. :) > In src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp you have: > > 126 #define VM_HAS_SPECIALIZED_BYTE_CMPXCHG > > and > > 220 #define VM_HAS_SPECIALIZED_BYTE_CMPXCHG I put the #define next to the Atomic::cmpxchg definitions, and Windows has two such definitions because of different possible configurations, that's why. One of the configurations generates a stub at runtime, the other one has compiler support. In case a configuration for Windows was added with no support for jbyte Atomic::cmpxchg, we would otherwise run into a bit of trouble. It won't be #defined twice for the same reason the member function is not defined twice. Thank you for having a look at this David! :) /Erik > > Thanks, > David > ----- > > On 2/10/2014 5:41 AM, David Holmes wrote: >> Hi Erik, >> >> Currently at JavaOne and then travelling back to Australia tomorrow. It >> will be Tuesday (Holiday Monday) before I can take another look at this. >> >> Sorry. >> >> David >> >> On 2/10/2014 4:32 AM, Erik ?sterlund wrote: >>> Hi, >>> >>> There is now a new webrev with my jbyte cmpxchg changes here: >>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01/ >>> >>> The change from last time is: >>> 1. Fixed an issue where cmpxchgl was incorrectly emitted instead of >>> cmpxchgb for one of the configurations as pointed out by Andrew Haley, >>> cheers for finding that >>> 2. Changed the "design" around a bit to make it easy to override the >>> cmpxchgb for different platforms without having #if >>> defined(PLATFORM_X) || defined(PLATFORMY) etc. in the headers.. If not >>> explicitly overridden, the old general solution be used instead like >>> normal and this should hence not break any of the different ports to >>> other architectures not included in the main hotspot project. >>> >>> Jesper ran it through jprt and it was all green. Thanks for checking >>> that! >>> >>> Would be nice if I could get some reviews. :) >>> >>> Thanks, >>> Erik >>> >>> >>> On 20 Sep 2014, at 23:53, Erik ?sterlund >>> > wrote: >>> >>> I don't want to break the ported builds so I made a special variant of >>> the third option where the x86 inline methods also have a #define next >>> to them. >>> The atomic.inline.hpp file then simply defines an inline >>> Atomic::cmpxchg calling the general solution if there is no #define >>> for an override. >>> >>> That way it's using variant three, but there is no need to write >>> overrides for every platform port (which are sometimes in other repos) >>> there is to simply run the default member function. >>> We can add them one by one instead. :) >>> >>> Hope this seems satisfactory. >>> >>> Thanks, >>> Erik >>> >>> On 17 Sep 2014, at 14:28, David Holmes >>> > wrote: >>> >>> On 17/09/2014 9:13 PM, Erik ?sterlund wrote: >>> I am back! Did you guys have time to do some thinking? I see three >>> different solutions: >>> >>> 1. Good old class inheritance! Class Atomic is-a Atomic_YourArchHere >>> is-a AtomicAbstract >>> Using the CRTP (Curiously Recurring Template Pattern) for C++, this >>> could be done without a virtual call where we want inlining. >>> >>> I would prefer this approach (here and elsewhere) but it is not a >>> short-term option. >>> >>> 2. Similar except with the SFINAE idiom (Substitution Failure Is Not >>> An Error) for C++, to pick the right overload based on statically >>> determined constraints. >>> E.g. define if Atomic::has_general_byte_CAS and based on whether this >>> is defined or not, pick the general or specific overload variant of >>> the CAS member function. >>> >>> Not sure what this one is but it sounds like a manual virtual dispatch >>> - which seems not a good solution. >>> >>> 3. Simply make the current CAS a normal function which is called from >>> billions of new inline method definitions that we have to create for >>> every single architecture. >>> >>> I think the simple version of 3 is just move cmpxchg(jbtye) out of the >>> shared code and define for each platform - there aren't that many and >>> it is consistent with many of the other variants. >>> >>> What do we prefer here? Does anyone else have a better idea? Also, >>> should I start a new thread or is it okay to post it here? >>> >>> Continuing this thread is fine by me. >>> >>> I think short-term the simple version of 3 is preferable. >>> >>> Thanks, >>> David >>> From david.holmes at oracle.com Thu Oct 9 11:25:35 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Oct 2014 21:25:35 +1000 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: <00D9D39D-45FB-45B8-9B2C-6D24C2C0EA75@lnu.se> References: <54124F11.8060100@oracle.com> <8E69D7A0-CD8D-4EC6-B708-5F2C0098B183@lnu.se> <54197E53.9030307@oracle.com> <542C58E7.7050907@oracle.com> <543611C8.2090807@oracle.com> <00D9D39D-45FB-45B8-9B2C-6D24C2C0EA75@lnu.se> Message-ID: <543670AF.5020106@oracle.com> On 9/10/2014 7:13 PM, Erik ?sterlund wrote: > Hi David, > > On 09 Oct 2014, at 06:40, David Holmes wrote: > >> Hi Erik, >> >> Sorry for the further delay on this. > > No problem. > >> Not sure I like VM_HAS_SPECIALIZED_BYTE_CMPXCHG. Would like to hear opinions from others. (I also can't confirm the correctness of the assembler code nor the changes to the .il files, so other's need to weigh in here regardless.) > > Okay. I did this in order not to break the code for maintainers of ports outside of our repo. Did not want a performance optimization for x86 to be intrusive and break the code of all others. I'm open to suggestions if anyone else has a better solution to this (that does not need virtual calls). And if you want me to ruthlessly just define a jbyte Atomic::cmpxchg inline member function that forwards to the old solution for the platforms in our repo (and breaking the code for all others outside), I can do that too. > >> With this approach does every arch need an entry in stubGenerator_.ccp of the form: >> >> StubRoutines::_atomic_cmpxchg_byte_entry = ; >> >> ? If we have to touch the code for each arch then maybe simply duplicating what is presently the shared implementation is a better way to go? > > This is currently used only by very awkward configurations that have no compiler support to generate the machine code I want. Instead it is generated at runtime while bootstrapping the jbyte Atomic::cmpxchg member function. Some platforms need to dynamically adjust the runtime code based on the actual version of the platform in use. > Other platforms need not care about defining such entry as it is not being used by them. Unless they actually want to use it of course. :) So I'm not sure if the answer to my question is yes, no, or maybe :) >> In src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp you have: >> >> 126 #define VM_HAS_SPECIALIZED_BYTE_CMPXCHG >> >> and >> >> 220 #define VM_HAS_SPECIALIZED_BYTE_CMPXCHG > > I put the #define next to the Atomic::cmpxchg definitions, and Windows has two such definitions because of different possible configurations, that's why. One of the configurations generates a stub at runtime, the other one has compiler support. In case a configuration for Windows was added with no support for jbyte Atomic::cmpxchg, we would otherwise run into a bit of trouble. It won't be #defined twice for the same reason the member function is not defined twice. I looked for, but missed the #ifdef AMD64. Must admit I don't understand why the 32-bit and 64-bit windows code is different for these atomic functions. David > Thank you for having a look at this David! :) > > /Erik > >> >> Thanks, >> David >> ----- >> >> On 2/10/2014 5:41 AM, David Holmes wrote: >>> Hi Erik, >>> >>> Currently at JavaOne and then travelling back to Australia tomorrow. It >>> will be Tuesday (Holiday Monday) before I can take another look at this. >>> >>> Sorry. >>> >>> David >>> >>> On 2/10/2014 4:32 AM, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> There is now a new webrev with my jbyte cmpxchg changes here: >>>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01/ >>>> >>>> The change from last time is: >>>> 1. Fixed an issue where cmpxchgl was incorrectly emitted instead of >>>> cmpxchgb for one of the configurations as pointed out by Andrew Haley, >>>> cheers for finding that >>>> 2. Changed the "design" around a bit to make it easy to override the >>>> cmpxchgb for different platforms without having #if >>>> defined(PLATFORM_X) || defined(PLATFORMY) etc. in the headers.. If not >>>> explicitly overridden, the old general solution be used instead like >>>> normal and this should hence not break any of the different ports to >>>> other architectures not included in the main hotspot project. >>>> >>>> Jesper ran it through jprt and it was all green. Thanks for checking >>>> that! >>>> >>>> Would be nice if I could get some reviews. :) >>>> >>>> Thanks, >>>> Erik >>>> >>>> >>>> On 20 Sep 2014, at 23:53, Erik ?sterlund >>>> > wrote: >>>> >>>> I don't want to break the ported builds so I made a special variant of >>>> the third option where the x86 inline methods also have a #define next >>>> to them. >>>> The atomic.inline.hpp file then simply defines an inline >>>> Atomic::cmpxchg calling the general solution if there is no #define >>>> for an override. >>>> >>>> That way it's using variant three, but there is no need to write >>>> overrides for every platform port (which are sometimes in other repos) >>>> there is to simply run the default member function. >>>> We can add them one by one instead. :) >>>> >>>> Hope this seems satisfactory. >>>> >>>> Thanks, >>>> Erik >>>> >>>> On 17 Sep 2014, at 14:28, David Holmes >>>> > wrote: >>>> >>>> On 17/09/2014 9:13 PM, Erik ?sterlund wrote: >>>> I am back! Did you guys have time to do some thinking? I see three >>>> different solutions: >>>> >>>> 1. Good old class inheritance! Class Atomic is-a Atomic_YourArchHere >>>> is-a AtomicAbstract >>>> Using the CRTP (Curiously Recurring Template Pattern) for C++, this >>>> could be done without a virtual call where we want inlining. >>>> >>>> I would prefer this approach (here and elsewhere) but it is not a >>>> short-term option. >>>> >>>> 2. Similar except with the SFINAE idiom (Substitution Failure Is Not >>>> An Error) for C++, to pick the right overload based on statically >>>> determined constraints. >>>> E.g. define if Atomic::has_general_byte_CAS and based on whether this >>>> is defined or not, pick the general or specific overload variant of >>>> the CAS member function. >>>> >>>> Not sure what this one is but it sounds like a manual virtual dispatch >>>> - which seems not a good solution. >>>> >>>> 3. Simply make the current CAS a normal function which is called from >>>> billions of new inline method definitions that we have to create for >>>> every single architecture. >>>> >>>> I think the simple version of 3 is just move cmpxchg(jbtye) out of the >>>> shared code and define for each platform - there aren't that many and >>>> it is consistent with many of the other variants. >>>> >>>> What do we prefer here? Does anyone else have a better idea? Also, >>>> should I start a new thread or is it okay to post it here? >>>> >>>> Continuing this thread is fine by me. >>>> >>>> I think short-term the simple version of 3 is preferable. >>>> >>>> Thanks, >>>> David >>>> > From andreas.eriksson at oracle.com Thu Oct 9 13:21:05 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Thu, 09 Oct 2014 15:21:05 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform Message-ID: <54368BC1.3000905@oracle.com> Hi all, Please review this patch to RedefineClasses to allow type annotations to be preserved. Summary: During redefine / retransform class the constant pool indexes can change. Since annotations have indexes into the constant pool these indexes need to be rewritten. This is already done for regular annotations, but not for type annotations. This patch adds code to add this rewriting for the type annotations as well. The patch also contains minor changes to ClassFileReconstituter, to make sure that type annotations are preserved during a redefine / retransform class operation. It also has a test that uses asm to change constant pool indexes through a retransform, and then verifies that type annotations are preserved. Detail: A type annotation struct consists of some target information and a type path, followed by a regular annotation struct. Constant pool indexes are only present in the regular annotation struct. The added code skips over the type annotation specific parts, then calls previously existing code to rewrite constant pool indexes in the regular annotation struct. Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info about the type annotation struct. JPRT with the new test passes without failures on all platforms. Webrev: http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8057043 Regards Andreas From thomas.stuefe at gmail.com Fri Oct 10 08:38:27 2014 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 10 Oct 2014 10:38:27 +0200 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux Message-ID: Hi all, I'd like to contribute implementations for os::set_native_thread_name() on Windows and Linux. We have added this feature to the SAP JVM and it has been useful for debugging. http://cr.openjdk.java.net/~simonis/webrevs/7102541/ Associated request: https://bugs.openjdk.java.net/browse/JDK-7102541 On Windows, it uses the method described here: http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx On Linux, it uses pthread_setname_np(2). Notes for the windows implementation: - os::set_native_thread_name() only has any effect if there is a debugger attached to the process at the time of the function call. The reason is that the debugger must observe the raised exception. This means that this method works fine if the VM is being debugged right from the start; for cases where the debugger attaches during VM life, threads started before the attach will show default names. - This was tested using Visual Studio 2013 and Windbg. Notes for the Linux implementation: - pthread_setname_np(2) needs glibc 2.12 or newer. The change loads the function dynamically. - Thread names are truncated to 15 characters. - We can see the thread names with ps (eg " ps H -p 1234 -o 'pid tid comm' ") or with gdb >= 4.7 Note that not all threads show names. os::set_native_thread_name() was only called for JavaThread* children before this change, this change adds the VM thread, but there are some threads for which this function is not yet called; they appear with their default names. --- Note that when I was doing this change, I worked first on https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware that Gerard Ziemski had done a lot of the same work before. But it looks like his changes did not appear in the hotspot? Either that or I looked at the wrong place... Anyway, I hope either his or my changes make it into the hotspot, because the feature is quite useful. Kind Regards, Thomas From david.holmes at oracle.com Fri Oct 10 09:06:44 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Oct 2014 19:06:44 +1000 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: References: Message-ID: <5437A1A4.1060100@oracle.com> Hi Thomas, Based on the bug report Gerard's work stalled because of solaris issues. We've covered a lot of ground regarding this in the past. Personally I'm unhappy about a few things - the windows situations seem not that useful; the linux 15 character limit also renders this useless for many cases. Then there is the issue of whether this can only be applied by the current thread to itself, or by any thread to any thread. I concede there is some value in some cases but there are enough warts on this to make me cringe about putting it in. (As I cringed with the original OSX version.) That's not to say I'm going to oppose it, but I certainly don't champion it. :) Cheers, David On 10/10/2014 6:38 PM, Thomas St?fe wrote: > Hi all, > > I'd like to contribute implementations for os::set_native_thread_name() on > Windows and Linux. We have added this feature to the SAP JVM and it has > been useful for debugging. > > http://cr.openjdk.java.net/~simonis/webrevs/7102541/ > > Associated request: > https://bugs.openjdk.java.net/browse/JDK-7102541 > > On Windows, it uses the method described here: > http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx > On Linux, it uses pthread_setname_np(2). > > Notes for the windows implementation: > - os::set_native_thread_name() only has any effect if there is a debugger > attached to the process at the time of the function call. The reason is > that the debugger must observe the raised exception. This means that this > method works fine if the VM is being debugged right from the start; for > cases where the debugger attaches during VM life, threads started before > the attach will show default names. > - This was tested using Visual Studio 2013 and Windbg. > > > Notes for the Linux implementation: > - pthread_setname_np(2) needs glibc 2.12 or newer. The change loads the > function dynamically. > - Thread names are truncated to 15 characters. > - We can see the thread names with ps (eg " ps H -p 1234 -o 'pid tid comm' > ") or with gdb >= 4.7 > > > Note that not all threads show names. os::set_native_thread_name() was only > called for JavaThread* children before this change, this change adds the VM > thread, but there are some threads for which this function is not yet > called; they appear with their default names. > > --- > > Note that when I was doing this change, I worked first on > https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware that > Gerard Ziemski had done a lot of the same work before. But it looks like > his changes did not appear in the hotspot? Either that or I looked at the > wrong place... Anyway, I hope either his or my changes make it into the > hotspot, because the feature is quite useful. > > Kind Regards, > > Thomas > From staffan.larsen at oracle.com Fri Oct 10 10:54:51 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 10 Oct 2014 12:54:51 +0200 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: <5437A1A4.1060100@oracle.com> References: <5437A1A4.1060100@oracle.com> Message-ID: Thomas, I?m happy to see this being worked on and I think the code looks good. We had similar implementations of this in JRockit and very often found them useful. I don?t share David?s concerns. That we can?t do this on solaris is not a good reason not do it on other platforms. The windows limitation that a debugger has to be attached is a limitation, but the feature is worth a lot when you /do/ have a debugger attached. The 15 character limitation is too bad, but again, better something than nothing. Thanks, /Staffan On 10 okt 2014, at 11:06, David Holmes wrote: > Hi Thomas, > > Based on the bug report Gerard's work stalled because of solaris issues. We've covered a lot of ground regarding this in the past. Personally I'm unhappy about a few things - the windows situations seem not that useful; the linux 15 character limit also renders this useless for many cases. Then there is the issue of whether this can only be applied by the current thread to itself, or by any thread to any thread. > > I concede there is some value in some cases but there are enough warts on this to make me cringe about putting it in. (As I cringed with the original OSX version.) > > That's not to say I'm going to oppose it, but I certainly don't champion it. :) > > Cheers, > David > > On 10/10/2014 6:38 PM, Thomas St?fe wrote: >> Hi all, >> >> I'd like to contribute implementations for os::set_native_thread_name() on >> Windows and Linux. We have added this feature to the SAP JVM and it has >> been useful for debugging. >> >> http://cr.openjdk.java.net/~simonis/webrevs/7102541/ >> >> Associated request: >> https://bugs.openjdk.java.net/browse/JDK-7102541 >> >> On Windows, it uses the method described here: >> http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx >> On Linux, it uses pthread_setname_np(2). >> >> Notes for the windows implementation: >> - os::set_native_thread_name() only has any effect if there is a debugger >> attached to the process at the time of the function call. The reason is >> that the debugger must observe the raised exception. This means that this >> method works fine if the VM is being debugged right from the start; for >> cases where the debugger attaches during VM life, threads started before >> the attach will show default names. >> - This was tested using Visual Studio 2013 and Windbg. >> >> >> Notes for the Linux implementation: >> - pthread_setname_np(2) needs glibc 2.12 or newer. The change loads the >> function dynamically. >> - Thread names are truncated to 15 characters. >> - We can see the thread names with ps (eg " ps H -p 1234 -o 'pid tid comm' >> ") or with gdb >= 4.7 >> >> >> Note that not all threads show names. os::set_native_thread_name() was only >> called for JavaThread* children before this change, this change adds the VM >> thread, but there are some threads for which this function is not yet >> called; they appear with their default names. >> >> --- >> >> Note that when I was doing this change, I worked first on >> https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware that >> Gerard Ziemski had done a lot of the same work before. But it looks like >> his changes did not appear in the hotspot? Either that or I looked at the >> wrong place... Anyway, I hope either his or my changes make it into the >> hotspot, because the feature is quite useful. >> >> Kind Regards, >> >> Thomas >> From christian.tornqvist at oracle.com Fri Oct 10 11:06:25 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 10 Oct 2014 07:06:25 -0400 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: References: <5437A1A4.1060100@oracle.com> Message-ID: <001b01cfe47a$3c1e1060$b45a3120$@oracle.com> Hi Thomas, I agree with Staffan. The platform specific limitations are unfortunate but it shouldn't stop us from doing this. I'd be happy to see the thread names when debugging on Windows :) The code looks good. Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Staffan Larsen Sent: Friday, October 10, 2014 6:55 AM To: David Holmes Cc: hotspot-dev at openjdk.java.net Developers Subject: Re: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux Thomas, I?m happy to see this being worked on and I think the code looks good. We had similar implementations of this in JRockit and very often found them useful. I don?t share David?s concerns. That we can?t do this on solaris is not a good reason not do it on other platforms. The windows limitation that a debugger has to be attached is a limitation, but the feature is worth a lot when you /do/ have a debugger attached. The 15 character limitation is too bad, but again, better something than nothing. Thanks, /Staffan On 10 okt 2014, at 11:06, David Holmes wrote: > Hi Thomas, > > Based on the bug report Gerard's work stalled because of solaris issues. We've covered a lot of ground regarding this in the past. Personally I'm unhappy about a few things - the windows situations seem not that useful; the linux 15 character limit also renders this useless for many cases. Then there is the issue of whether this can only be applied by the current thread to itself, or by any thread to any thread. > > I concede there is some value in some cases but there are enough warts > on this to make me cringe about putting it in. (As I cringed with the > original OSX version.) > > That's not to say I'm going to oppose it, but I certainly don't > champion it. :) > > Cheers, > David > > On 10/10/2014 6:38 PM, Thomas St?fe wrote: >> Hi all, >> >> I'd like to contribute implementations for >> os::set_native_thread_name() on Windows and Linux. We have added this >> feature to the SAP JVM and it has been useful for debugging. >> >> http://cr.openjdk.java.net/~simonis/webrevs/7102541/ >> >> Associated request: >> https://bugs.openjdk.java.net/browse/JDK-7102541 >> >> On Windows, it uses the method described here: >> http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx >> On Linux, it uses pthread_setname_np(2). >> >> Notes for the windows implementation: >> - os::set_native_thread_name() only has any effect if there is a >> debugger attached to the process at the time of the function call. >> The reason is that the debugger must observe the raised exception. >> This means that this method works fine if the VM is being debugged >> right from the start; for cases where the debugger attaches during VM >> life, threads started before the attach will show default names. >> - This was tested using Visual Studio 2013 and Windbg. >> >> >> Notes for the Linux implementation: >> - pthread_setname_np(2) needs glibc 2.12 or newer. The change loads >> the function dynamically. >> - Thread names are truncated to 15 characters. >> - We can see the thread names with ps (eg " ps H -p 1234 -o 'pid tid comm' >> ") or with gdb >= 4.7 >> >> >> Note that not all threads show names. os::set_native_thread_name() >> was only called for JavaThread* children before this change, this >> change adds the VM thread, but there are some threads for which this >> function is not yet called; they appear with their default names. >> >> --- >> >> Note that when I was doing this change, I worked first on >> https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware >> that Gerard Ziemski had done a lot of the same work before. But it >> looks like his changes did not appear in the hotspot? Either that or >> I looked at the wrong place... Anyway, I hope either his or my >> changes make it into the hotspot, because the feature is quite useful. >> >> Kind Regards, >> >> Thomas >> From daniel.daugherty at oracle.com Fri Oct 10 13:18:54 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 10 Oct 2014 07:18:54 -0600 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: References: <5437A1A4.1060100@oracle.com> Message-ID: <5437DCBE.5030304@oracle.com> I started this architectural inconsistency when I shepherded in the os::set_native_thread_name() API with the MacOS X port so our current state of affairs is that we are inconsistent across the platforms today. If I remember our very old discussions, our choices were: 1) remove os::set_native_thread_name() since it cannot be done consistently across platforms 2) allow differing implementations of os::set_native_thread_name() to be added as they are developed by interested parties 3) define a Lowest-Common-Denominator (LCD) version of the API and add platform implementations that adhere to the LCD; in other words, we hobble implementations that can do more for the sake of consistency I don't like #1 or #3. I'm OK with #2 and there's precedent for platform specific limitations, e.g., filename and pathname length differences between the various platforms... Dan On 10/10/14 4:54 AM, Staffan Larsen wrote: > Thomas, > > I?m happy to see this being worked on and I think the code looks good. We had similar implementations of this in JRockit and very often found them useful. > > I don?t share David?s concerns. That we can?t do this on solaris is not a good reason not do it on other platforms. The windows limitation that a debugger has to be attached is a limitation, but the feature is worth a lot when you /do/ have a debugger attached. The 15 character limitation is too bad, but again, better something than nothing. > > Thanks, > /Staffan > > On 10 okt 2014, at 11:06, David Holmes wrote: > >> Hi Thomas, >> >> Based on the bug report Gerard's work stalled because of solaris issues. We've covered a lot of ground regarding this in the past. Personally I'm unhappy about a few things - the windows situations seem not that useful; the linux 15 character limit also renders this useless for many cases. Then there is the issue of whether this can only be applied by the current thread to itself, or by any thread to any thread. >> >> I concede there is some value in some cases but there are enough warts on this to make me cringe about putting it in. (As I cringed with the original OSX version.) >> >> That's not to say I'm going to oppose it, but I certainly don't champion it. :) >> >> Cheers, >> David >> >> On 10/10/2014 6:38 PM, Thomas St?fe wrote: >>> Hi all, >>> >>> I'd like to contribute implementations for os::set_native_thread_name() on >>> Windows and Linux. We have added this feature to the SAP JVM and it has >>> been useful for debugging. >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/7102541/ >>> >>> Associated request: >>> https://bugs.openjdk.java.net/browse/JDK-7102541 >>> >>> On Windows, it uses the method described here: >>> http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx >>> On Linux, it uses pthread_setname_np(2). >>> >>> Notes for the windows implementation: >>> - os::set_native_thread_name() only has any effect if there is a debugger >>> attached to the process at the time of the function call. The reason is >>> that the debugger must observe the raised exception. This means that this >>> method works fine if the VM is being debugged right from the start; for >>> cases where the debugger attaches during VM life, threads started before >>> the attach will show default names. >>> - This was tested using Visual Studio 2013 and Windbg. >>> >>> >>> Notes for the Linux implementation: >>> - pthread_setname_np(2) needs glibc 2.12 or newer. The change loads the >>> function dynamically. >>> - Thread names are truncated to 15 characters. >>> - We can see the thread names with ps (eg " ps H -p 1234 -o 'pid tid comm' >>> ") or with gdb >= 4.7 >>> >>> >>> Note that not all threads show names. os::set_native_thread_name() was only >>> called for JavaThread* children before this change, this change adds the VM >>> thread, but there are some threads for which this function is not yet >>> called; they appear with their default names. >>> >>> --- >>> >>> Note that when I was doing this change, I worked first on >>> https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware that >>> Gerard Ziemski had done a lot of the same work before. But it looks like >>> his changes did not appear in the hotspot? Either that or I looked at the >>> wrong place... Anyway, I hope either his or my changes make it into the >>> hotspot, because the feature is quite useful. >>> >>> Kind Regards, >>> >>> Thomas >>> From volker.simonis at gmail.com Fri Oct 10 13:58:06 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 10 Oct 2014 15:58:06 +0200 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: <5437DCBE.5030304@oracle.com> References: <5437A1A4.1060100@oracle.com> <5437DCBE.5030304@oracle.com> Message-ID: Hi, I totally agree with Staffan. This change simply improves the current situation on Linux and Windows. And it has no drawbacks on other platforms. Can somebody please sponsor this change? And please don't forget to add a "Contributed-by: thomas.stuefe at sap.com" as he's no author until now - but he's covered by the general SAP OCA. Thank you and best regards, Volker On Fri, Oct 10, 2014 at 3:18 PM, Daniel D. Daugherty wrote: > I started this architectural inconsistency when I shepherded in > the os::set_native_thread_name() API with the MacOS X port so > our current state of affairs is that we are inconsistent across > the platforms today. > > If I remember our very old discussions, our choices were: > > 1) remove os::set_native_thread_name() since it cannot be done > consistently across platforms > 2) allow differing implementations of os::set_native_thread_name() > to be added as they are developed by interested parties > 3) define a Lowest-Common-Denominator (LCD) version of the API > and add platform implementations that adhere to the LCD; in > other words, we hobble implementations that can do more for > the sake of consistency > > I don't like #1 or #3. I'm OK with #2 and there's precedent for > platform specific limitations, e.g., filename and pathname length > differences between the various platforms... > > Dan > > > > On 10/10/14 4:54 AM, Staffan Larsen wrote: >> >> Thomas, >> >> I?m happy to see this being worked on and I think the code looks good. We >> had similar implementations of this in JRockit and very often found them >> useful. >> >> I don?t share David?s concerns. That we can?t do this on solaris is not a >> good reason not do it on other platforms. The windows limitation that a >> debugger has to be attached is a limitation, but the feature is worth a lot >> when you /do/ have a debugger attached. The 15 character limitation is too >> bad, but again, better something than nothing. >> >> Thanks, >> /Staffan >> >> On 10 okt 2014, at 11:06, David Holmes wrote: >> >>> Hi Thomas, >>> >>> Based on the bug report Gerard's work stalled because of solaris issues. >>> We've covered a lot of ground regarding this in the past. Personally I'm >>> unhappy about a few things - the windows situations seem not that useful; >>> the linux 15 character limit also renders this useless for many cases. Then >>> there is the issue of whether this can only be applied by the current thread >>> to itself, or by any thread to any thread. >>> >>> I concede there is some value in some cases but there are enough warts on >>> this to make me cringe about putting it in. (As I cringed with the original >>> OSX version.) >>> >>> That's not to say I'm going to oppose it, but I certainly don't champion >>> it. :) >>> >>> Cheers, >>> David >>> >>> On 10/10/2014 6:38 PM, Thomas St?fe wrote: >>>> >>>> Hi all, >>>> >>>> I'd like to contribute implementations for os::set_native_thread_name() >>>> on >>>> Windows and Linux. We have added this feature to the SAP JVM and it has >>>> been useful for debugging. >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/7102541/ >>>> >>>> Associated request: >>>> https://bugs.openjdk.java.net/browse/JDK-7102541 >>>> >>>> On Windows, it uses the method described here: >>>> http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx >>>> On Linux, it uses pthread_setname_np(2). >>>> >>>> Notes for the windows implementation: >>>> - os::set_native_thread_name() only has any effect if there is a >>>> debugger >>>> attached to the process at the time of the function call. The reason is >>>> that the debugger must observe the raised exception. This means that >>>> this >>>> method works fine if the VM is being debugged right from the start; for >>>> cases where the debugger attaches during VM life, threads started before >>>> the attach will show default names. >>>> - This was tested using Visual Studio 2013 and Windbg. >>>> >>>> >>>> Notes for the Linux implementation: >>>> - pthread_setname_np(2) needs glibc 2.12 or newer. The change loads >>>> the >>>> function dynamically. >>>> - Thread names are truncated to 15 characters. >>>> - We can see the thread names with ps (eg " ps H -p 1234 -o 'pid tid >>>> comm' >>>> ") or with gdb >= 4.7 >>>> >>>> >>>> Note that not all threads show names. os::set_native_thread_name() was >>>> only >>>> called for JavaThread* children before this change, this change adds the >>>> VM >>>> thread, but there are some threads for which this function is not yet >>>> called; they appear with their default names. >>>> >>>> --- >>>> >>>> Note that when I was doing this change, I worked first on >>>> https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware >>>> that >>>> Gerard Ziemski had done a lot of the same work before. But it looks like >>>> his changes did not appear in the hotspot? Either that or I looked at >>>> the >>>> wrong place... Anyway, I hope either his or my changes make it into the >>>> hotspot, because the feature is quite useful. >>>> >>>> Kind Regards, >>>> >>>> Thomas >>>> > From coleen.phillimore at oracle.com Fri Oct 10 14:48:07 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Oct 2014 10:48:07 -0400 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <54368BC1.3000905@oracle.com> References: <54368BC1.3000905@oracle.com> Message-ID: <5437F1A7.7010600@oracle.com> Andreas, This is excellent work! It looks really good. Some comments. http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html + u1 target_type = type_annotations_typeArray->at(byte_i_ref); + byte_i_ref += 1; + RC_TRACE_WITH_THREAD(0x02000000, THREAD, ("target_type=0x%.2x", target_type)); + RC_TRACE_WITH_THREAD(0x02000000, THREAD, ("location=%s", location_mesg)); + + // Skip over target_info + switch (target_type) { + case 0x00: + // kind: type parameter declaration of generic class or interface + // location: ClassFile + case 0x01: + // kind: type parameter declaration of generic method or constructor + // location: method_info Are there any #defines that make these numbers into some symbolic values? These comments are good in case there aren't. + case 0x17: + // kind: type in throws clause of method or constructor + // location: method_info I can't find anything wrong. I don't really understand the test that well so hopefully someone that knows type annotations can look at it also. Maybe include lang tools and Joel and Eric? This code is needed because we don't replace the InstanceKlass when redefining classes and rewrite the constant pool. If we were able to replace the InstanceKlass instead, we wouldn't need to do all this work. We're evaluating this at the moment, but have no real progress, so thank you for fixing this! Thanks, Coleen On 10/9/14, 9:21 AM, Andreas Eriksson wrote: > Hi all, > > Please review this patch to RedefineClasses to allow type annotations > to be preserved. > > Summary: > During redefine / retransform class the constant pool indexes can change. > Since annotations have indexes into the constant pool these indexes > need to be rewritten. > This is already done for regular annotations, but not for type > annotations. > This patch adds code to add this rewriting for the type annotations as > well. > The patch also contains minor changes to ClassFileReconstituter, to > make sure that type annotations are preserved during a redefine / > retransform class operation. > It also has a test that uses asm to change constant pool indexes > through a retransform, and then verifies that type annotations are > preserved. > > Detail: > A type annotation struct consists of some target information and a > type path, followed by a regular annotation struct. > Constant pool indexes are only present in the regular annotation struct. > The added code skips over the type annotation specific parts, then > calls previously existing code to rewrite constant pool indexes in the > regular annotation struct. > Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info > about the type annotation struct. > > JPRT with the new test passes without failures on all platforms. > > Webrev: > http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8057043 > > Regards > Andreas From david.holmes at oracle.com Fri Oct 10 15:15:37 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 11 Oct 2014 01:15:37 +1000 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: References: <5437A1A4.1060100@oracle.com> <5437DCBE.5030304@oracle.com> Message-ID: <5437F819.6020909@oracle.com> We should wait for Gerard to catch up with this before any commit is done. He had also already proposed code changes in the bug report. We also need to determine where these different platform limitations are to be documented. Otherwise we will get bug reports (as I'm sure I've mentioned in previous discussions) regarding missing names (because setName was not called by the current thread on itself) and duplicate names (because of the 15 char limit). On the issue of current thread versus any thread, is pthread_setname_np restricted to use by the current thread on itself? It is used that way in this patch, but possibly only to match the restriction that OSX had introduced. That restriction should be removed on platforms where it can be removed. Thanks, David On 10/10/2014 11:58 PM, Volker Simonis wrote: > Hi, > > I totally agree with Staffan. This change simply improves the current > situation on Linux and Windows. And it has no drawbacks on other > platforms. > > Can somebody please sponsor this change? And please don't forget to > add a "Contributed-by: thomas.stuefe at sap.com" as he's no author until > now - but he's covered by the general SAP OCA. > > Thank you and best regards, > Volker > > > On Fri, Oct 10, 2014 at 3:18 PM, Daniel D. Daugherty > wrote: >> I started this architectural inconsistency when I shepherded in >> the os::set_native_thread_name() API with the MacOS X port so >> our current state of affairs is that we are inconsistent across >> the platforms today. >> >> If I remember our very old discussions, our choices were: >> >> 1) remove os::set_native_thread_name() since it cannot be done >> consistently across platforms >> 2) allow differing implementations of os::set_native_thread_name() >> to be added as they are developed by interested parties >> 3) define a Lowest-Common-Denominator (LCD) version of the API >> and add platform implementations that adhere to the LCD; in >> other words, we hobble implementations that can do more for >> the sake of consistency >> >> I don't like #1 or #3. I'm OK with #2 and there's precedent for >> platform specific limitations, e.g., filename and pathname length >> differences between the various platforms... >> >> Dan >> >> >> >> On 10/10/14 4:54 AM, Staffan Larsen wrote: >>> >>> Thomas, >>> >>> I?m happy to see this being worked on and I think the code looks good. We >>> had similar implementations of this in JRockit and very often found them >>> useful. >>> >>> I don?t share David?s concerns. That we can?t do this on solaris is not a >>> good reason not do it on other platforms. The windows limitation that a >>> debugger has to be attached is a limitation, but the feature is worth a lot >>> when you /do/ have a debugger attached. The 15 character limitation is too >>> bad, but again, better something than nothing. >>> >>> Thanks, >>> /Staffan >>> >>> On 10 okt 2014, at 11:06, David Holmes wrote: >>> >>>> Hi Thomas, >>>> >>>> Based on the bug report Gerard's work stalled because of solaris issues. >>>> We've covered a lot of ground regarding this in the past. Personally I'm >>>> unhappy about a few things - the windows situations seem not that useful; >>>> the linux 15 character limit also renders this useless for many cases. Then >>>> there is the issue of whether this can only be applied by the current thread >>>> to itself, or by any thread to any thread. >>>> >>>> I concede there is some value in some cases but there are enough warts on >>>> this to make me cringe about putting it in. (As I cringed with the original >>>> OSX version.) >>>> >>>> That's not to say I'm going to oppose it, but I certainly don't champion >>>> it. :) >>>> >>>> Cheers, >>>> David >>>> >>>> On 10/10/2014 6:38 PM, Thomas St?fe wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I'd like to contribute implementations for os::set_native_thread_name() >>>>> on >>>>> Windows and Linux. We have added this feature to the SAP JVM and it has >>>>> been useful for debugging. >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/7102541/ >>>>> >>>>> Associated request: >>>>> https://bugs.openjdk.java.net/browse/JDK-7102541 >>>>> >>>>> On Windows, it uses the method described here: >>>>> http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx >>>>> On Linux, it uses pthread_setname_np(2). >>>>> >>>>> Notes for the windows implementation: >>>>> - os::set_native_thread_name() only has any effect if there is a >>>>> debugger >>>>> attached to the process at the time of the function call. The reason is >>>>> that the debugger must observe the raised exception. This means that >>>>> this >>>>> method works fine if the VM is being debugged right from the start; for >>>>> cases where the debugger attaches during VM life, threads started before >>>>> the attach will show default names. >>>>> - This was tested using Visual Studio 2013 and Windbg. >>>>> >>>>> >>>>> Notes for the Linux implementation: >>>>> - pthread_setname_np(2) needs glibc 2.12 or newer. The change loads >>>>> the >>>>> function dynamically. >>>>> - Thread names are truncated to 15 characters. >>>>> - We can see the thread names with ps (eg " ps H -p 1234 -o 'pid tid >>>>> comm' >>>>> ") or with gdb >= 4.7 >>>>> >>>>> >>>>> Note that not all threads show names. os::set_native_thread_name() was >>>>> only >>>>> called for JavaThread* children before this change, this change adds the >>>>> VM >>>>> thread, but there are some threads for which this function is not yet >>>>> called; they appear with their default names. >>>>> >>>>> --- >>>>> >>>>> Note that when I was doing this change, I worked first on >>>>> https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware >>>>> that >>>>> Gerard Ziemski had done a lot of the same work before. But it looks like >>>>> his changes did not appear in the hotspot? Either that or I looked at >>>>> the >>>>> wrong place... Anyway, I hope either his or my changes make it into the >>>>> hotspot, because the feature is quite useful. >>>>> >>>>> Kind Regards, >>>>> >>>>> Thomas >>>>> >> From thomas.stuefe at gmail.com Fri Oct 10 16:46:39 2014 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 10 Oct 2014 18:46:39 +0200 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: <5437F819.6020909@oracle.com> References: <5437A1A4.1060100@oracle.com> <5437DCBE.5030304@oracle.com> <5437F819.6020909@oracle.com> Message-ID: Thank you all for the positive feedback; I really think the feature would be useful. Right now I am looking at a core on Linux from a Tomcat run and it is nice to see the thread names in a list instead of having to manually go thru all threads and examine the stack to guess at the function. I agree with David that the solution is not complete, but I think it would be a step in the right direction. Sure it would be nice to have all platforms; however, 3 out of 5 is not bad. On AIX, I am investigating whether we can add the feature some other way. The limitation to the current thread is not a hard limitation; Linux and Windows implementations work with other threads too. I did not test Mac OS. I do not think the restriction on Windows is that bad; it is still helpful. You want thread names, just run the VM in a debugger from the start on. I even looked for a way to re-establish thread names after the windows debugger attaches; but seems to be no way to get informed when a debugger attaches. Theoretically one could add a function which iterates over all threads, calling os::set_native_thread_name() on them (provided we make it work for other threads than the current one), and call that function manually within the Debugger. But I think that would be over engineered. As for Linux, I think one could even dynamically probe for the largest allowed thread name at the start of the VM (calling pthread_setname_np with ever-smaller names until it stops saying ERANGE). That way we could retain downward compatibility while still profit from larger names should the glibc people decide to enlarge that name buffer. But again, that may be over engineered. As for missing documentation, this should be already a problem now, as the function is implemented on one platform and the other platforms are stubbed out? I don't see how the change would change that. Thomas On Fri, Oct 10, 2014 at 5:15 PM, David Holmes wrote: > We should wait for Gerard to catch up with this before any commit is done. > He had also already proposed code changes in the bug report. > > We also need to determine where these different platform limitations are > to be documented. Otherwise we will get bug reports (as I'm sure I've > mentioned in previous discussions) regarding missing names (because setName > was not called by the current thread on itself) and duplicate names > (because of the 15 char limit). > > On the issue of current thread versus any thread, is pthread_setname_np > restricted to use by the current thread on itself? It is used that way in > this patch, but possibly only to match the restriction that OSX had > introduced. That restriction should be removed on platforms where it can be > removed. > > Thanks, > David > > > On 10/10/2014 11:58 PM, Volker Simonis wrote: > >> Hi, >> >> I totally agree with Staffan. This change simply improves the current >> situation on Linux and Windows. And it has no drawbacks on other >> platforms. >> >> Can somebody please sponsor this change? And please don't forget to >> add a "Contributed-by: thomas.stuefe at sap.com" as he's no author until >> now - but he's covered by the general SAP OCA. >> >> Thank you and best regards, >> Volker >> >> >> On Fri, Oct 10, 2014 at 3:18 PM, Daniel D. Daugherty >> wrote: >> >>> I started this architectural inconsistency when I shepherded in >>> the os::set_native_thread_name() API with the MacOS X port so >>> our current state of affairs is that we are inconsistent across >>> the platforms today. >>> >>> If I remember our very old discussions, our choices were: >>> >>> 1) remove os::set_native_thread_name() since it cannot be done >>> consistently across platforms >>> 2) allow differing implementations of os::set_native_thread_name() >>> to be added as they are developed by interested parties >>> 3) define a Lowest-Common-Denominator (LCD) version of the API >>> and add platform implementations that adhere to the LCD; in >>> other words, we hobble implementations that can do more for >>> the sake of consistency >>> >>> I don't like #1 or #3. I'm OK with #2 and there's precedent for >>> platform specific limitations, e.g., filename and pathname length >>> differences between the various platforms... >>> >>> Dan >>> >>> >>> >>> On 10/10/14 4:54 AM, Staffan Larsen wrote: >>> >>>> >>>> Thomas, >>>> >>>> I?m happy to see this being worked on and I think the code looks good. >>>> We >>>> had similar implementations of this in JRockit and very often found them >>>> useful. >>>> >>>> I don?t share David?s concerns. That we can?t do this on solaris is not >>>> a >>>> good reason not do it on other platforms. The windows limitation that a >>>> debugger has to be attached is a limitation, but the feature is worth a >>>> lot >>>> when you /do/ have a debugger attached. The 15 character limitation is >>>> too >>>> bad, but again, better something than nothing. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 10 okt 2014, at 11:06, David Holmes wrote: >>>> >>>> Hi Thomas, >>>>> >>>>> Based on the bug report Gerard's work stalled because of solaris >>>>> issues. >>>>> We've covered a lot of ground regarding this in the past. Personally >>>>> I'm >>>>> unhappy about a few things - the windows situations seem not that >>>>> useful; >>>>> the linux 15 character limit also renders this useless for many cases. >>>>> Then >>>>> there is the issue of whether this can only be applied by the current >>>>> thread >>>>> to itself, or by any thread to any thread. >>>>> >>>>> I concede there is some value in some cases but there are enough warts >>>>> on >>>>> this to make me cringe about putting it in. (As I cringed with the >>>>> original >>>>> OSX version.) >>>>> >>>>> That's not to say I'm going to oppose it, but I certainly don't >>>>> champion >>>>> it. :) >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 10/10/2014 6:38 PM, Thomas St?fe wrote: >>>>> >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'd like to contribute implementations for >>>>>> os::set_native_thread_name() >>>>>> on >>>>>> Windows and Linux. We have added this feature to the SAP JVM and it >>>>>> has >>>>>> been useful for debugging. >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/7102541/ >>>>>> >>>>>> Associated request: >>>>>> https://bugs.openjdk.java.net/browse/JDK-7102541 >>>>>> >>>>>> On Windows, it uses the method described here: >>>>>> http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx >>>>>> On Linux, it uses pthread_setname_np(2). >>>>>> >>>>>> Notes for the windows implementation: >>>>>> - os::set_native_thread_name() only has any effect if there is a >>>>>> debugger >>>>>> attached to the process at the time of the function call. The reason >>>>>> is >>>>>> that the debugger must observe the raised exception. This means that >>>>>> this >>>>>> method works fine if the VM is being debugged right from the start; >>>>>> for >>>>>> cases where the debugger attaches during VM life, threads started >>>>>> before >>>>>> the attach will show default names. >>>>>> - This was tested using Visual Studio 2013 and Windbg. >>>>>> >>>>>> >>>>>> Notes for the Linux implementation: >>>>>> - pthread_setname_np(2) needs glibc 2.12 or newer. The change loads >>>>>> the >>>>>> function dynamically. >>>>>> - Thread names are truncated to 15 characters. >>>>>> - We can see the thread names with ps (eg " ps H -p 1234 -o 'pid >>>>>> tid >>>>>> comm' >>>>>> ") or with gdb >= 4.7 >>>>>> >>>>>> >>>>>> Note that not all threads show names. os::set_native_thread_name() was >>>>>> only >>>>>> called for JavaThread* children before this change, this change adds >>>>>> the >>>>>> VM >>>>>> thread, but there are some threads for which this function is not yet >>>>>> called; they appear with their default names. >>>>>> >>>>>> --- >>>>>> >>>>>> Note that when I was doing this change, I worked first on >>>>>> https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware >>>>>> that >>>>>> Gerard Ziemski had done a lot of the same work before. But it looks >>>>>> like >>>>>> his changes did not appear in the hotspot? Either that or I looked at >>>>>> the >>>>>> wrong place... Anyway, I hope either his or my changes make it into >>>>>> the >>>>>> hotspot, because the feature is quite useful. >>>>>> >>>>>> Kind Regards, >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>> From gerard.ziemski at oracle.com Fri Oct 10 20:47:37 2014 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 10 Oct 2014 15:47:37 -0500 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: References: <5437A1A4.1060100@oracle.com> <5437DCBE.5030304@oracle.com> <5437F819.6020909@oracle.com> Message-ID: <543845E9.9030602@oracle.com> I'm in the process of reviewing and making sure it all still works on Mac OS X... On 10/10/2014 11:46 AM, Thomas St?fe wrote: > Thank you all for the positive feedback; I really think the feature would > be useful. Right now I am looking at a core on Linux from a Tomcat run and > it is nice to see the thread names in a list instead of having to manually > go thru all threads and examine the stack to guess at the function. > > I agree with David that the solution is not complete, but I think it would > be a step in the right direction. Sure it would be nice to have all > platforms; however, 3 out of 5 is not bad. On AIX, I am investigating > whether we can add the feature some other way. > > The limitation to the current thread is not a hard limitation; Linux and > Windows implementations work with other threads too. I did not test Mac OS. > > I do not think the restriction on Windows is that bad; it is still helpful. > You want thread names, just run the VM in a debugger from the start on. > > I even looked for a way to re-establish thread names after the windows > debugger attaches; but seems to be no way to get informed when a debugger > attaches. Theoretically one could add a function which iterates over all > threads, calling os::set_native_thread_name() on them (provided we make it > work for other threads than the current one), and call that function > manually within the Debugger. But I think that would be over engineered. > > As for Linux, I think one could even dynamically probe for the largest > allowed thread name at the start of the VM (calling pthread_setname_np with > ever-smaller names until it stops saying ERANGE). That way we could retain > downward compatibility while still profit from larger names should the > glibc people decide to enlarge that name buffer. But again, that may be > over engineered. > > As for missing documentation, this should be already a problem now, as the > function is implemented on one platform and the other platforms are stubbed > out? I don't see how the change would change that. > > Thomas > > > On Fri, Oct 10, 2014 at 5:15 PM, David Holmes > wrote: > >> We should wait for Gerard to catch up with this before any commit is done. >> He had also already proposed code changes in the bug report. >> >> We also need to determine where these different platform limitations are >> to be documented. Otherwise we will get bug reports (as I'm sure I've >> mentioned in previous discussions) regarding missing names (because setName >> was not called by the current thread on itself) and duplicate names >> (because of the 15 char limit). >> >> On the issue of current thread versus any thread, is pthread_setname_np >> restricted to use by the current thread on itself? It is used that way in >> this patch, but possibly only to match the restriction that OSX had >> introduced. That restriction should be removed on platforms where it can be >> removed. >> >> Thanks, >> David >> >> >> On 10/10/2014 11:58 PM, Volker Simonis wrote: >> >>> Hi, >>> >>> I totally agree with Staffan. This change simply improves the current >>> situation on Linux and Windows. And it has no drawbacks on other >>> platforms. >>> >>> Can somebody please sponsor this change? And please don't forget to >>> add a "Contributed-by: thomas.stuefe at sap.com" as he's no author until >>> now - but he's covered by the general SAP OCA. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> On Fri, Oct 10, 2014 at 3:18 PM, Daniel D. Daugherty >>> wrote: >>> >>>> I started this architectural inconsistency when I shepherded in >>>> the os::set_native_thread_name() API with the MacOS X port so >>>> our current state of affairs is that we are inconsistent across >>>> the platforms today. >>>> >>>> If I remember our very old discussions, our choices were: >>>> >>>> 1) remove os::set_native_thread_name() since it cannot be done >>>> consistently across platforms >>>> 2) allow differing implementations of os::set_native_thread_name() >>>> to be added as they are developed by interested parties >>>> 3) define a Lowest-Common-Denominator (LCD) version of the API >>>> and add platform implementations that adhere to the LCD; in >>>> other words, we hobble implementations that can do more for >>>> the sake of consistency >>>> >>>> I don't like #1 or #3. I'm OK with #2 and there's precedent for >>>> platform specific limitations, e.g., filename and pathname length >>>> differences between the various platforms... >>>> >>>> Dan >>>> >>>> >>>> >>>> On 10/10/14 4:54 AM, Staffan Larsen wrote: >>>> >>>>> Thomas, >>>>> >>>>> I?m happy to see this being worked on and I think the code looks good. >>>>> We >>>>> had similar implementations of this in JRockit and very often found them >>>>> useful. >>>>> >>>>> I don?t share David?s concerns. That we can?t do this on solaris is not >>>>> a >>>>> good reason not do it on other platforms. The windows limitation that a >>>>> debugger has to be attached is a limitation, but the feature is worth a >>>>> lot >>>>> when you /do/ have a debugger attached. The 15 character limitation is >>>>> too >>>>> bad, but again, better something than nothing. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 10 okt 2014, at 11:06, David Holmes wrote: >>>>> >>>>> Hi Thomas, >>>>>> Based on the bug report Gerard's work stalled because of solaris >>>>>> issues. >>>>>> We've covered a lot of ground regarding this in the past. Personally >>>>>> I'm >>>>>> unhappy about a few things - the windows situations seem not that >>>>>> useful; >>>>>> the linux 15 character limit also renders this useless for many cases. >>>>>> Then >>>>>> there is the issue of whether this can only be applied by the current >>>>>> thread >>>>>> to itself, or by any thread to any thread. >>>>>> >>>>>> I concede there is some value in some cases but there are enough warts >>>>>> on >>>>>> this to make me cringe about putting it in. (As I cringed with the >>>>>> original >>>>>> OSX version.) >>>>>> >>>>>> That's not to say I'm going to oppose it, but I certainly don't >>>>>> champion >>>>>> it. :) >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> On 10/10/2014 6:38 PM, Thomas St?fe wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I'd like to contribute implementations for >>>>>>> os::set_native_thread_name() >>>>>>> on >>>>>>> Windows and Linux. We have added this feature to the SAP JVM and it >>>>>>> has >>>>>>> been useful for debugging. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/7102541/ >>>>>>> >>>>>>> Associated request: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-7102541 >>>>>>> >>>>>>> On Windows, it uses the method described here: >>>>>>> http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx >>>>>>> On Linux, it uses pthread_setname_np(2). >>>>>>> >>>>>>> Notes for the windows implementation: >>>>>>> - os::set_native_thread_name() only has any effect if there is a >>>>>>> debugger >>>>>>> attached to the process at the time of the function call. The reason >>>>>>> is >>>>>>> that the debugger must observe the raised exception. This means that >>>>>>> this >>>>>>> method works fine if the VM is being debugged right from the start; >>>>>>> for >>>>>>> cases where the debugger attaches during VM life, threads started >>>>>>> before >>>>>>> the attach will show default names. >>>>>>> - This was tested using Visual Studio 2013 and Windbg. >>>>>>> >>>>>>> >>>>>>> Notes for the Linux implementation: >>>>>>> - pthread_setname_np(2) needs glibc 2.12 or newer. The change loads >>>>>>> the >>>>>>> function dynamically. >>>>>>> - Thread names are truncated to 15 characters. >>>>>>> - We can see the thread names with ps (eg " ps H -p 1234 -o 'pid >>>>>>> tid >>>>>>> comm' >>>>>>> ") or with gdb >= 4.7 >>>>>>> >>>>>>> >>>>>>> Note that not all threads show names. os::set_native_thread_name() was >>>>>>> only >>>>>>> called for JavaThread* children before this change, this change adds >>>>>>> the >>>>>>> VM >>>>>>> thread, but there are some threads for which this function is not yet >>>>>>> called; they appear with their default names. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Note that when I was doing this change, I worked first on >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware >>>>>>> that >>>>>>> Gerard Ziemski had done a lot of the same work before. But it looks >>>>>>> like >>>>>>> his changes did not appear in the hotspot? Either that or I looked at >>>>>>> the >>>>>>> wrong place... Anyway, I hope either his or my changes make it into >>>>>>> the >>>>>>> hotspot, because the feature is quite useful. >>>>>>> >>>>>>> Kind Regards, >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> > From coleen.phillimore at oracle.com Fri Oct 10 20:54:03 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Oct 2014 16:54:03 -0400 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <542D2EC1.5030303@oracle.com> References: <542D2EC1.5030303@oracle.com> Message-ID: <5438476B.1060003@oracle.com> Hi Stefan, Thank you for your patience. Some review comments: http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/classfile/metadataOnStackMark.hpp.udiff.html Why is there all this code here? In order to make this parallel, can you just not have simply a GrowableArray per thread? I don't see the purpose of all this complexity in this place. Is it trying to add as chunked list? Can we add a utility for this instead of tying it to the MetadataOnStackMark functionality? In this file, what is _doit and why? This looks really strange. Can you add a comment why sometimes doit is false and sometimes doit is true? Is there a way to encapsulate this in a function as it's supposed to be a scoped object. The MetadataOnStackMark object needs to go around the calls to purge_previous_versions and free_deallocate_list. It doesn't have to be around the whole walk of the CLDG, it just started out that way and has gotten more complicated. If you add it to the end like: void ClassLoaderDataGraph::clean_metaspaces() { // mark metadata seen on the stack and code cache so we can delete unneeded entries. bool has_redefined_a_class = JvmtiExport::has_redefined_a_class(); MetadataOnStackMark md_on_stack(has_redefined_a_class); if (has_redefined_a_class) { // purge_previous_versions also cleans weak method links. Because // one method's MDO can reference another method from another // class loader, we need to first clean weak method links for all // class loaders here. Below, we can then free redefined methods // for all class loaders. for (ClassLoaderData* data = _head; data != NULL; data = data->next()) { data->classes_do(InstanceKlass::purge_previous_versions); } } // Need two loops. for (ClassLoaderData* data = _head; data != NULL; data = data->next()) { data->free_deallocate_list(); } } And only call it at the end of do_unloading this would work (I've tested this) if (has_metadata_to_deallocate) { clean_metaspaces(); } has_metadata_to_deallocate is generally true because of lambda constant pools. http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html + if (JvmtiExport::has_redefined_a_class()) { + InstanceKlass::purge_previous_versions(ik); + } purge previous versions requires the on_stack bits to be set. Is this true here? It seems very far away from the other code to me to be able to tell. Why can't this go in the same place as the free_deallocate_lists? http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/code/nmethod.cpp.udiff.html I really don't like that the on-stack bit marks are done at the same time as clean_ic_if_metadata_is_dead. They are for different purposes. Also, this seems to mark metadata for methods that are unloaded as well as ones that survive unloading. I guess this wouldn't prevent methods from being unloaded but seems unnecessary callbacks to mark_on_stack. Maybe I'm not reading this right though. I thought you couldn't do the unloading walk with the mark-on-stack walk? Also, we actually only have to mark OLD methods in the code cache which would greatly reduce the callbacks. I could make this in a separate change as I have this change in a private repository. I think you should have a compiler reviewer comment on the nmethod code though. http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/utilities/accessFlags.cpp.udiff.html I don't know why this needs to be different than the atomic_set_bits function. I should have made on_stack be a flag in Method* rather than in access flags. There's a lot here. I'm glad it helps performance and making the code cache walk parallel is a really good change. Thanks, Coleen On 10/2/14, 6:53 AM, Stefan Karlsson wrote: > Hi all, > > (The following patch changes HotSpot code in areas concerning GC, RT, > and Compiler. So, it would be good to get reviews from all three teams.) > > Please, review this patch to optimize and parallelize the CodeCache > part of MetadaOnStackMark. > > G1 performance measurements showed longer than expected remark times > on an application using a lot of nmethods and Metadata. The cause for > this performance regression was the call to > CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in > MetadataOnStackMark. This code path is only taken when class > redefinition is used. Class redefinition is typically used in > monitoring and diagnostic frameworks. > > With this patch we now: > 1) Filter out duplicate Metadata* entries instead of storing a > Metadata* per visited metadata reference. > 2) Collect the set of Metadata* entries in parallel. The code > piggy-backs on the parallel CodeCache cleaning task. > > http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8056240 > > Functional testing: > JPRT, Kitchensink, parallel_class_unloading, unit tests > > Performance testing: > CRM Fuse - where the regression was found > > The patch changes HotSpot code in areas concerning GC, RT, Compiler, > and Serviceability. It would be good to get some reviews from the > other teams, and not only from the GC team. > > thanks, > StefanK From coleen.phillimore at oracle.com Fri Oct 10 22:09:59 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Oct 2014 18:09:59 -0400 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <5438476B.1060003@oracle.com> References: <542D2EC1.5030303@oracle.com> <5438476B.1060003@oracle.com> Message-ID: <54385937.1020408@oracle.com> In nmethod.cpp how is this change related? ie. the added function and call. Was it a cleanup? nmethod::unload_if_dead_at() thanks, Coleen On 10/10/14, 4:54 PM, Coleen Phillimore wrote: > > Hi Stefan, > > Thank you for your patience. Some review comments: > > http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/classfile/metadataOnStackMark.hpp.udiff.html > > > Why is there all this code here? In order to make this parallel, can > you just not have simply a GrowableArray per thread? I don't see the > purpose of all this complexity in this place. Is it trying to add as > chunked list? Can we add a utility for this instead of tying it to > the MetadataOnStackMark functionality? > > In this file, what is _doit and why? This looks really strange. Can > you add a comment why sometimes doit is false and sometimes doit is > true? Is there a way to encapsulate this in a function as it's > supposed to be a scoped object. > > The MetadataOnStackMark object needs to go around the calls to > purge_previous_versions and free_deallocate_list. It doesn't have to > be around the whole walk of the CLDG, it just started out that way and > has gotten more complicated. If you add it to the end like: > > void ClassLoaderDataGraph::clean_metaspaces() { > // mark metadata seen on the stack and code cache so we can delete > unneeded entries. > bool has_redefined_a_class = JvmtiExport::has_redefined_a_class(); > MetadataOnStackMark md_on_stack(has_redefined_a_class); > if (has_redefined_a_class) { > // purge_previous_versions also cleans weak method links. Because > // one method's MDO can reference another method from another > // class loader, we need to first clean weak method links for all > // class loaders here. Below, we can then free redefined methods > // for all class loaders. > for (ClassLoaderData* data = _head; data != NULL; data = > data->next()) { > data->classes_do(InstanceKlass::purge_previous_versions); > } > } > // Need two loops. > for (ClassLoaderData* data = _head; data != NULL; data = > data->next()) { > data->free_deallocate_list(); > } > } > > And only call it at the end of do_unloading this would work (I've > tested this) > > if (has_metadata_to_deallocate) { > clean_metaspaces(); > } > > has_metadata_to_deallocate is generally true because of lambda > constant pools. > > http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html > > > + if (JvmtiExport::has_redefined_a_class()) { > + InstanceKlass::purge_previous_versions(ik); > + } > > > purge previous versions requires the on_stack bits to be set. Is this > true here? It seems very far away from the other code to me to be > able to tell. Why can't this go in the same place as the > free_deallocate_lists? > > http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/code/nmethod.cpp.udiff.html > > > I really don't like that the on-stack bit marks are done at the same > time as clean_ic_if_metadata_is_dead. They are for different > purposes. Also, this seems to mark metadata for methods that are > unloaded as well as ones that survive unloading. I guess this > wouldn't prevent methods from being unloaded but seems unnecessary > callbacks to mark_on_stack. Maybe I'm not reading this right > though. I thought you couldn't do the unloading walk with the > mark-on-stack walk? Also, we actually only have to mark OLD methods > in the code cache which would greatly reduce the callbacks. I could > make this in a separate change as I have this change in a private > repository. > > I think you should have a compiler reviewer comment on the nmethod > code though. > > http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/utilities/accessFlags.cpp.udiff.html > > > I don't know why this needs to be different than the atomic_set_bits > function. I should have made on_stack be a flag in Method* rather > than in access flags. > > There's a lot here. I'm glad it helps performance and making the code > cache walk parallel is a really good change. > > Thanks, > Coleen > > > On 10/2/14, 6:53 AM, Stefan Karlsson wrote: >> Hi all, >> >> (The following patch changes HotSpot code in areas concerning GC, RT, >> and Compiler. So, it would be good to get reviews from all three teams.) >> >> Please, review this patch to optimize and parallelize the CodeCache >> part of MetadaOnStackMark. >> >> G1 performance measurements showed longer than expected remark times >> on an application using a lot of nmethods and Metadata. The cause for >> this performance regression was the call to >> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >> MetadataOnStackMark. This code path is only taken when class >> redefinition is used. Class redefinition is typically used in >> monitoring and diagnostic frameworks. >> >> With this patch we now: >> 1) Filter out duplicate Metadata* entries instead of storing a >> Metadata* per visited metadata reference. >> 2) Collect the set of Metadata* entries in parallel. The code >> piggy-backs on the parallel CodeCache cleaning task. >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8056240 >> >> Functional testing: >> JPRT, Kitchensink, parallel_class_unloading, unit tests >> >> Performance testing: >> CRM Fuse - where the regression was found >> >> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >> and Serviceability. It would be good to get some reviews from the >> other teams, and not only from the GC team. >> >> thanks, >> StefanK > From gerard.ziemski at oracle.com Fri Oct 10 22:22:53 2014 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 10 Oct 2014 17:22:53 -0500 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: References: <5437A1A4.1060100@oracle.com> <5437DCBE.5030304@oracle.com> <5437F819.6020909@oracle.com> Message-ID: <54385C3D.3080706@oracle.com> hi Thomas. Thank you very much for your contribution. With your changes even the Mac OS X platform seems to benefit - we now get more named threads on Mac (ie. "Thread 13 Java: VM Thread" and "Thread 24 Java: VM Perdiodic Task Thread"). I do wonder what all those remainding threads are those, but that's another question... Please consider this reviewed, though with a small "r". All we need now is Solaris implementation... cheers On 10/10/2014 11:46 AM, Thomas St?fe wrote: > Thank you all for the positive feedback; I really think the feature would > be useful. Right now I am looking at a core on Linux from a Tomcat run and > it is nice to see the thread names in a list instead of having to manually > go thru all threads and examine the stack to guess at the function. > > I agree with David that the solution is not complete, but I think it would > be a step in the right direction. Sure it would be nice to have all > platforms; however, 3 out of 5 is not bad. On AIX, I am investigating > whether we can add the feature some other way. > > The limitation to the current thread is not a hard limitation; Linux and > Windows implementations work with other threads too. I did not test Mac OS. > > I do not think the restriction on Windows is that bad; it is still helpful. > You want thread names, just run the VM in a debugger from the start on. > > I even looked for a way to re-establish thread names after the windows > debugger attaches; but seems to be no way to get informed when a debugger > attaches. Theoretically one could add a function which iterates over all > threads, calling os::set_native_thread_name() on them (provided we make it > work for other threads than the current one), and call that function > manually within the Debugger. But I think that would be over engineered. > > As for Linux, I think one could even dynamically probe for the largest > allowed thread name at the start of the VM (calling pthread_setname_np with > ever-smaller names until it stops saying ERANGE). That way we could retain > downward compatibility while still profit from larger names should the > glibc people decide to enlarge that name buffer. But again, that may be > over engineered. > > As for missing documentation, this should be already a problem now, as the > function is implemented on one platform and the other platforms are stubbed > out? I don't see how the change would change that. > > Thomas > > > On Fri, Oct 10, 2014 at 5:15 PM, David Holmes > wrote: > >> We should wait for Gerard to catch up with this before any commit is done. >> He had also already proposed code changes in the bug report. >> >> We also need to determine where these different platform limitations are >> to be documented. Otherwise we will get bug reports (as I'm sure I've >> mentioned in previous discussions) regarding missing names (because setName >> was not called by the current thread on itself) and duplicate names >> (because of the 15 char limit). >> >> On the issue of current thread versus any thread, is pthread_setname_np >> restricted to use by the current thread on itself? It is used that way in >> this patch, but possibly only to match the restriction that OSX had >> introduced. That restriction should be removed on platforms where it can be >> removed. >> >> Thanks, >> David >> >> >> On 10/10/2014 11:58 PM, Volker Simonis wrote: >> >>> Hi, >>> >>> I totally agree with Staffan. This change simply improves the current >>> situation on Linux and Windows. And it has no drawbacks on other >>> platforms. >>> >>> Can somebody please sponsor this change? And please don't forget to >>> add a "Contributed-by: thomas.stuefe at sap.com" as he's no author until >>> now - but he's covered by the general SAP OCA. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> On Fri, Oct 10, 2014 at 3:18 PM, Daniel D. Daugherty >>> wrote: >>> >>>> I started this architectural inconsistency when I shepherded in >>>> the os::set_native_thread_name() API with the MacOS X port so >>>> our current state of affairs is that we are inconsistent across >>>> the platforms today. >>>> >>>> If I remember our very old discussions, our choices were: >>>> >>>> 1) remove os::set_native_thread_name() since it cannot be done >>>> consistently across platforms >>>> 2) allow differing implementations of os::set_native_thread_name() >>>> to be added as they are developed by interested parties >>>> 3) define a Lowest-Common-Denominator (LCD) version of the API >>>> and add platform implementations that adhere to the LCD; in >>>> other words, we hobble implementations that can do more for >>>> the sake of consistency >>>> >>>> I don't like #1 or #3. I'm OK with #2 and there's precedent for >>>> platform specific limitations, e.g., filename and pathname length >>>> differences between the various platforms... >>>> >>>> Dan >>>> >>>> >>>> >>>> On 10/10/14 4:54 AM, Staffan Larsen wrote: >>>> >>>>> Thomas, >>>>> >>>>> I?m happy to see this being worked on and I think the code looks good. >>>>> We >>>>> had similar implementations of this in JRockit and very often found them >>>>> useful. >>>>> >>>>> I don?t share David?s concerns. That we can?t do this on solaris is not >>>>> a >>>>> good reason not do it on other platforms. The windows limitation that a >>>>> debugger has to be attached is a limitation, but the feature is worth a >>>>> lot >>>>> when you /do/ have a debugger attached. The 15 character limitation is >>>>> too >>>>> bad, but again, better something than nothing. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 10 okt 2014, at 11:06, David Holmes wrote: >>>>> >>>>> Hi Thomas, >>>>>> Based on the bug report Gerard's work stalled because of solaris >>>>>> issues. >>>>>> We've covered a lot of ground regarding this in the past. Personally >>>>>> I'm >>>>>> unhappy about a few things - the windows situations seem not that >>>>>> useful; >>>>>> the linux 15 character limit also renders this useless for many cases. >>>>>> Then >>>>>> there is the issue of whether this can only be applied by the current >>>>>> thread >>>>>> to itself, or by any thread to any thread. >>>>>> >>>>>> I concede there is some value in some cases but there are enough warts >>>>>> on >>>>>> this to make me cringe about putting it in. (As I cringed with the >>>>>> original >>>>>> OSX version.) >>>>>> >>>>>> That's not to say I'm going to oppose it, but I certainly don't >>>>>> champion >>>>>> it. :) >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> On 10/10/2014 6:38 PM, Thomas St?fe wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I'd like to contribute implementations for >>>>>>> os::set_native_thread_name() >>>>>>> on >>>>>>> Windows and Linux. We have added this feature to the SAP JVM and it >>>>>>> has >>>>>>> been useful for debugging. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/7102541/ >>>>>>> >>>>>>> Associated request: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-7102541 >>>>>>> >>>>>>> On Windows, it uses the method described here: >>>>>>> http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx >>>>>>> On Linux, it uses pthread_setname_np(2). >>>>>>> >>>>>>> Notes for the windows implementation: >>>>>>> - os::set_native_thread_name() only has any effect if there is a >>>>>>> debugger >>>>>>> attached to the process at the time of the function call. The reason >>>>>>> is >>>>>>> that the debugger must observe the raised exception. This means that >>>>>>> this >>>>>>> method works fine if the VM is being debugged right from the start; >>>>>>> for >>>>>>> cases where the debugger attaches during VM life, threads started >>>>>>> before >>>>>>> the attach will show default names. >>>>>>> - This was tested using Visual Studio 2013 and Windbg. >>>>>>> >>>>>>> >>>>>>> Notes for the Linux implementation: >>>>>>> - pthread_setname_np(2) needs glibc 2.12 or newer. The change loads >>>>>>> the >>>>>>> function dynamically. >>>>>>> - Thread names are truncated to 15 characters. >>>>>>> - We can see the thread names with ps (eg " ps H -p 1234 -o 'pid >>>>>>> tid >>>>>>> comm' >>>>>>> ") or with gdb >= 4.7 >>>>>>> >>>>>>> >>>>>>> Note that not all threads show names. os::set_native_thread_name() was >>>>>>> only >>>>>>> called for JavaThread* children before this change, this change adds >>>>>>> the >>>>>>> VM >>>>>>> thread, but there are some threads for which this function is not yet >>>>>>> called; they appear with their default names. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Note that when I was doing this change, I worked first on >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware >>>>>>> that >>>>>>> Gerard Ziemski had done a lot of the same work before. But it looks >>>>>>> like >>>>>>> his changes did not appear in the hotspot? Either that or I looked at >>>>>>> the >>>>>>> wrong place... Anyway, I hope either his or my changes make it into >>>>>>> the >>>>>>> hotspot, because the feature is quite useful. >>>>>>> >>>>>>> Kind Regards, >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> > From david.holmes at oracle.com Fri Oct 10 22:33:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 11 Oct 2014 08:33:42 +1000 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: References: <5437A1A4.1060100@oracle.com> <5437DCBE.5030304@oracle.com> <5437F819.6020909@oracle.com> Message-ID: <54385EC6.1010803@oracle.com> On 11/10/2014 2:46 AM, Thomas St?fe wrote: > Thank you all for the positive feedback; I really think the feature > would be useful. Right now I am looking at a core on Linux from a Tomcat > run and it is nice to see the thread names in a list instead of having > to manually go thru all threads and examine the stack to guess at the > function. > > I agree with David that the solution is not complete, but I think it > would be a step in the right direction. Sure it would be nice to have > all platforms; however, 3 out of 5 is not bad. On AIX, I am > investigating whether we can add the feature some other way. > > The limitation to the current thread is not a hard limitation; Linux and > Windows implementations work with other threads too. I did not test Mac OS. > > I do not think the restriction on Windows is that bad; it is still > helpful. You want thread names, just run the VM in a debugger from the > start on. > > I even looked for a way to re-establish thread names after the windows > debugger attaches; but seems to be no way to get informed when a > debugger attaches. Theoretically one could add a function which iterates > over all threads, calling os::set_native_thread_name() on them (provided > we make it work for other threads than the current one), and call that > function manually within the Debugger. But I think that would be over > engineered. > > As for Linux, I think one could even dynamically probe for the largest > allowed thread name at the start of the VM (calling pthread_setname_np > with ever-smaller names until it stops saying ERANGE). That way we could > retain downward compatibility while still profit from larger names > should the glibc people decide to enlarge that name buffer. But again, > that may be over engineered. This is likely to be a discrete range rather than a continuous one - I don't expect to find different linux versions each choosing a different value. My main concern is that some very commonly used threading libraries will encounter this 15 char limit eg: ForkJoinPool.commonPool-worker- pool--thread- and custom Executors and FJPools tend to use even longer name. > As for missing documentation, this should be already a problem now, as > the function is implemented on one platform and the other platforms are > stubbed out? I don't see how the change would change that. At the moment the missing documentation concerns only one platform. Now it concerns three platforms that all (potentially) behave differently; with a fourth and fifth potentially on the way. So I think the documentation issue needs to resolved. Thanks, David > Thomas > > > On Fri, Oct 10, 2014 at 5:15 PM, David Holmes > wrote: > > We should wait for Gerard to catch up with this before any commit is > done. He had also already proposed code changes in the bug report. > > We also need to determine where these different platform limitations > are to be documented. Otherwise we will get bug reports (as I'm sure > I've mentioned in previous discussions) regarding missing names > (because setName was not called by the current thread on itself) and > duplicate names (because of the 15 char limit). > > On the issue of current thread versus any thread, is > pthread_setname_np restricted to use by the current thread on > itself? It is used that way in this patch, but possibly only to > match the restriction that OSX had introduced. That restriction > should be removed on platforms where it can be removed. > > Thanks, > David > > > On 10/10/2014 11:58 PM, Volker Simonis wrote: > > Hi, > > I totally agree with Staffan. This change simply improves the > current > situation on Linux and Windows. And it has no drawbacks on other > platforms. > > Can somebody please sponsor this change? And please don't forget to > add a "Contributed-by: thomas.stuefe at sap.com > " as he's no author until > now - but he's covered by the general SAP OCA. > > Thank you and best regards, > Volker > > > On Fri, Oct 10, 2014 at 3:18 PM, Daniel D. Daugherty > > wrote: > > I started this architectural inconsistency when I shepherded in > the os::set_native_thread_name() API with the MacOS X port so > our current state of affairs is that we are inconsistent across > the platforms today. > > If I remember our very old discussions, our choices were: > > 1) remove os::set_native_thread_name() since it cannot be done > consistently across platforms > 2) allow differing implementations of > os::set_native_thread_name() > to be added as they are developed by interested parties > 3) define a Lowest-Common-Denominator (LCD) version of the API > and add platform implementations that adhere to the LCD; in > other words, we hobble implementations that can do more for > the sake of consistency > > I don't like #1 or #3. I'm OK with #2 and there's precedent for > platform specific limitations, e.g., filename and pathname > length > differences between the various platforms... > > Dan > > > > On 10/10/14 4:54 AM, Staffan Larsen wrote: > > > Thomas, > > I?m happy to see this being worked on and I think the > code looks good. We > had similar implementations of this in JRockit and very > often found them > useful. > > I don?t share David?s concerns. That we can?t do this on > solaris is not a > good reason not do it on other platforms. The windows > limitation that a > debugger has to be attached is a limitation, but the > feature is worth a lot > when you /do/ have a debugger attached. The 15 character > limitation is too > bad, but again, better something than nothing. > > Thanks, > /Staffan > > On 10 okt 2014, at 11:06, David Holmes > > wrote: > > Hi Thomas, > > Based on the bug report Gerard's work stalled > because of solaris issues. > We've covered a lot of ground regarding this in the > past. Personally I'm > unhappy about a few things - the windows situations > seem not that useful; > the linux 15 character limit also renders this > useless for many cases. Then > there is the issue of whether this can only be > applied by the current thread > to itself, or by any thread to any thread. > > I concede there is some value in some cases but > there are enough warts on > this to make me cringe about putting it in. (As I > cringed with the original > OSX version.) > > That's not to say I'm going to oppose it, but I > certainly don't champion > it. :) > > Cheers, > David > > On 10/10/2014 6:38 PM, Thomas St?fe wrote: > > > Hi all, > > I'd like to contribute implementations for > os::set_native_thread_name() > on > Windows and Linux. We have added this feature to > the SAP JVM and it has > been useful for debugging. > > http://cr.openjdk.java.net/~__simonis/webrevs/7102541/ > > > Associated request: > https://bugs.openjdk.java.net/__browse/JDK-7102541 > > > On Windows, it uses the method described here: > http://msdn.microsoft.com/en-__us/library/xcb2z8hs.aspx > > On Linux, it uses pthread_setname_np(2). > > Notes for the windows implementation: > - os::set_native_thread_name() only has any > effect if there is a > debugger > attached to the process at the time of the > function call. The reason is > that the debugger must observe the raised > exception. This means that > this > method works fine if the VM is being debugged > right from the start; for > cases where the debugger attaches during VM > life, threads started before > the attach will show default names. > - This was tested using Visual Studio 2013 > and Windbg. > > > Notes for the Linux implementation: > - pthread_setname_np(2) needs glibc 2.12 or > newer. The change loads > the > function dynamically. > - Thread names are truncated to 15 characters. > - We can see the thread names with ps (eg " > ps H -p 1234 -o 'pid tid > comm' > ") or with gdb >= 4.7 > > > Note that not all threads show names. > os::set_native_thread_name() was > only > called for JavaThread* children before this > change, this change adds the > VM > thread, but there are some threads for which > this function is not yet > called; they appear with their default names. > > --- > > Note that when I was doing this change, I worked > first on > https://bugs.openjdk.java.net/__browse/JDK-8060033 > , > so I was not aware > that > Gerard Ziemski had done a lot of the same work > before. But it looks like > his changes did not appear in the hotspot? > Either that or I looked at > the > wrong place... Anyway, I hope either his or my > changes make it into the > hotspot, because the feature is quite useful. > > Kind Regards, > > Thomas > > > From serguei.spitsyn at oracle.com Sat Oct 11 01:59:42 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 10 Oct 2014 18:59:42 -0700 Subject: RFR (XS) 8059904: libjvm_db.c warnings in solaris/sparc build with SS In-Reply-To: <5435EAF5.7000903@oracle.com> References: <5435DB19.7080005@oracle.com> <5435EAF5.7000903@oracle.com> Message-ID: <54388F0E.10805@oracle.com> Hi Coleen, Thank you a lot for the review! Somehow, I overlooked your review in my email box, and so, integrated the fix without credit for you. Sorry! Thanks, Serguei On 10/8/14 6:55 PM, Coleen Phillimore wrote: > > Looks good, Serguei. Thank you for fixing it! > Coleen > > On 10/8/14, 8:47 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8059904 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8059904-jvmdb-warn.1/ >> >> >> >> Summary: >> >> Several warnings started to appear at compilation of the libjvm_db.c >> after the switch from Sun C++ 5.10 to 5.12. >> The fix is to cast the result of calloc() to the correct type. >> >> >> Testing: >> Running the adhoc pstack tests on Solaris sparcv9 and amd64 >> >> >> Thanks, >> Serguei > From serguei.spitsyn at oracle.com Sat Oct 11 10:37:08 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 11 Oct 2014 03:37:08 -0700 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <54368BC1.3000905@oracle.com> References: <54368BC1.3000905@oracle.com> Message-ID: <54390854.1090109@oracle.com> Hi Andreas, Thank you for fixing this issue! The fix looks nice, I do not see any logical issues. Only minor comments... src/share/vm/prims/jvmtiRedefineClasses.cpp 2281 } // end rewrite_cp_refs_in_class_type_annotations( 2315 } // end rewrite_cp_refs_in_fields_type_annotations( 2345 } // end rewrite_cp_refs_in_methods_type_annotations() 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray 2443 } // end rewrite_cp_refs_in_type_annotation_struct 2785 } // end skip_type_annotation_target 2844 } // end skip_type_annotation_type_path The ')' is missed at 2281, 2315. The 2397-2844 are inconsistent with the 2345 and other function-end comments in the file. 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, 2336 byte_i, "method_info", THREAD)) { . . . 2378 if (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, 2379 byte_i_ref, location_mesg, THREAD)) { . . . 2427 if (!skip_type_annotation_target(type_annotations_typeArray, 2428 byte_i_ref, location_mesg, THREAD)) { 2429 return false; 2430 } 2431 2432 if (!skip_type_annotation_type_path(type_annotations_typeArray, 2433 byte_i_ref, THREAD)) { 2434 return false; 2435 } 2436 2437 if (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, 2438 byte_i_ref, THREAD)) { 2439 return false; Wrong indent at 2336, 2379, etc. I also concur with Coleen that it would be good to define and use symbolic names for the hexa-decimal constants used in the fix. test/runtime/RedefineTests/RedefineAnnotations.java Java indent must be 4, not 2. 253 @TestAnn(site="returnTypeAnnotation") Class typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") TypeAnnotatedTestClass arg) The line is too long. 143 } 144 public static void main(String argv[]) { . . . 209 } 210 private static void checkAnnotations(AnnotatedType p) { 211 checkAnnotations(p.getAnnotations()); 212 } 213 private static void checkAnnotations(AnnotatedType[] annoTypes) { 214 for (AnnotatedType p : annoTypes) checkAnnotations(p.getAnnotations()); 215 } 216 private static void checkAnnotations(Class c) { . . . 257 } 258 public void run() {} Adding empty lines between method definitions would improve readability. Thanks, Serguei On 10/9/14 6:21 AM, Andreas Eriksson wrote: > Hi all, > > Please review this patch to RedefineClasses to allow type annotations > to be preserved. > > Summary: > During redefine / retransform class the constant pool indexes can change. > Since annotations have indexes into the constant pool these indexes > need to be rewritten. > This is already done for regular annotations, but not for type > annotations. > This patch adds code to add this rewriting for the type annotations as > well. > The patch also contains minor changes to ClassFileReconstituter, to > make sure that type annotations are preserved during a redefine / > retransform class operation. > It also has a test that uses asm to change constant pool indexes > through a retransform, and then verifies that type annotations are > preserved. > > Detail: > A type annotation struct consists of some target information and a > type path, followed by a regular annotation struct. > Constant pool indexes are only present in the regular annotation struct. > The added code skips over the type annotation specific parts, then > calls previously existing code to rewrite constant pool indexes in the > regular annotation struct. > Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info > about the type annotation struct. > > JPRT with the new test passes without failures on all platforms. > > Webrev: > http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8057043 > > Regards > Andreas From thomas.stuefe at gmail.com Sun Oct 12 08:40:35 2014 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 12 Oct 2014 10:40:35 +0200 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: <54385C3D.3080706@oracle.com> References: <5437A1A4.1060100@oracle.com> <5437DCBE.5030304@oracle.com> <5437F819.6020909@oracle.com> <54385C3D.3080706@oracle.com> Message-ID: On Sat, Oct 11, 2014 at 12:22 AM, Gerard Ziemski wrote: > > With your changes even the Mac OS X platform seems to benefit - we now get > more named threads on Mac (ie. "Thread 13 Java: VM Thread" and "Thread 24 > Java: VM Perdiodic Task Thread"). I do wonder what all those remainding > threads are those, but that's another question... > I think the primordial thread is missing, the java main thread, NMT worker thread and of course the n GC threads. They should be easy to add, though. From thomas.stuefe at gmail.com Sun Oct 12 09:15:19 2014 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 12 Oct 2014 11:15:19 +0200 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: <54385EC6.1010803@oracle.com> References: <5437A1A4.1060100@oracle.com> <5437DCBE.5030304@oracle.com> <5437F819.6020909@oracle.com> <54385EC6.1010803@oracle.com> Message-ID: > > As for Linux, I think one could even dynamically probe for the largest >> allowed thread name at the start of the VM (calling pthread_setname_np >> with ever-smaller names until it stops saying ERANGE). That way we could >> retain downward compatibility while still profit from larger names >> should the glibc people decide to enlarge that name buffer. But again, >> that may be over engineered. >> > > This is likely to be a discrete range rather than a continuous one - I > don't expect to find different linux versions each choosing a different > value. The same binary could run on both old and new Linux machines with different task name length limits. It would be nice to have the VM automatically adapt to future improvements while retaining downward compatibility. After reading up a bit on Gerards glibc feature request https://sourceware.org/bugzilla/show_bug.cgi?format=multiple&id=16578, it seems that pthread lib on Linux implements thread naming by using kernel task names; task names are limited by TASK_COMM_LEN. It is possible to increase that define, but there are bug reports out that increasing TASK_COMM_LEN caused memory corruptions. So I concede that while it is possible that the pthread name length may change, it is not probable. > My main concern is that some very commonly used threading libraries will > encounter this 15 char limit eg: > > ForkJoinPool.commonPool-worker- > pool--thread- > > and custom Executors and FJPools tend to use even longer name. > > This is true and you are right. I think the feature is still useful enough, not so much for java developers but for OpenJDK developers, who are much more likely to debug natively and for whom a common case is to quickly identify OpenJDK special threads (Vm Thread, GC threads etc) in a forest of common java threads. It is also useful for cases where the libjvm.so is embedded into another launcher as "just another library", and you want to tell apart jvm threads from threads which have nothing to do with the jvm. > As for missing documentation, this should be already a problem now, as >> the function is implemented on one platform and the other platforms are >> stubbed out? I don't see how the change would change that. >> > > At the moment the missing documentation concerns only one platform. Now it > concerns three platforms that all (potentially) behave differently; with a > fourth and fifth potentially on the way. So I think the documentation issue > needs to resolved. > > I agree with you and if you tell me the format and/or where to put it, I can write a short documentation. Thanks, Thomas From david.holmes at oracle.com Mon Oct 13 00:19:24 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Oct 2014 10:19:24 +1000 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: References: <5437A1A4.1060100@oracle.com> <5437DCBE.5030304@oracle.com> <5437F819.6020909@oracle.com> <54385EC6.1010803@oracle.com> Message-ID: <543B1A8C.4080800@oracle.com> On 12/10/2014 7:15 PM, Thomas St?fe wrote: > As for Linux, I think one could even dynamically probe for the > largest > allowed thread name at the start of the VM (calling > pthread_setname_np > with ever-smaller names until it stops saying ERANGE). That way > we could > retain downward compatibility while still profit from larger names > should the glibc people decide to enlarge that name buffer. But > again, > that may be over engineered. > > > This is likely to be a discrete range rather than a continuous one - > I don't expect to find different linux versions each choosing a > different value. > > > The same binary could run on both old and new Linux machines with > different task name length limits. It would be nice to have the VM > automatically adapt to future improvements while retaining downward > compatibility. > > After reading up a bit on Gerards glibc feature request > https://sourceware.org/bugzilla/show_bug.cgi?format=multiple&id=16578, > it seems that pthread lib on Linux implements thread naming by using > kernel task names; task names are limited by TASK_COMM_LEN. It is > possible to increase that define, but there are bug reports out that > increasing TASK_COMM_LEN caused memory corruptions. So I concede that > while it is possible that the pthread name length may change, it is not > probable. > > My main concern is that some very commonly used threading libraries > will encounter this 15 char limit eg: > > ForkJoinPool.commonPool-__worker- > pool--thread- > > and custom Executors and FJPools tend to use even longer name. > > > This is true and you are right. I think the feature is still useful > enough, not so much for java developers but for OpenJDK developers, who > are much more likely to debug natively and for whom a common case is to > quickly identify OpenJDK special threads (Vm Thread, GC threads etc) in > a forest of common java threads. > > It is also useful for cases where the libjvm.so is embedded into another > launcher as "just another library", and you want to tell apart jvm > threads from threads which have nothing to do with the jvm. > > As for missing documentation, this should be already a problem > now, as > the function is implemented on one platform and the other > platforms are > stubbed out? I don't see how the change would change that. > > > At the moment the missing documentation concerns only one platform. > Now it concerns three platforms that all (potentially) behave > differently; with a fourth and fifth potentially on the way. So I > think the documentation issue needs to resolved. > > > I agree with you and if you tell me the format and/or where to put it, I > can write a short documentation. I would like to see a release note entry; though that is an Oracle specific entity :( Not sure where else this can be readily documented - suggestions welcome. Thanks, David > Thanks, Thomas From david.holmes at oracle.com Mon Oct 13 00:41:58 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Oct 2014 10:41:58 +1000 Subject: RFR: JDK-8059586: hs_err report should treat redirected core pattern. In-Reply-To: References: <542C8274.3010809@gmail.com> <54338B70.9080709@oracle.com> Message-ID: <543B1FD6.3000200@oracle.com> Hi Yasumasa, On 7/10/2014 8:48 PM, Yasumasa Suenaga wrote: > Hi David, > > Sorry for my English. > > I want to propose that JVM should create message according to core > pattern (/proc/sys/kernel/core_pattern) . > So I filed it to JBS and created a patch. So I've had a quick look at this core_pattern business and it seems to me that there are two aspects to this. First, without the leading |, the entry in the core_pattern file is a naming pattern for the core file. In which case that should be handled by the linux specific get_core_path() function. Though that in itself can't fully report the expected name, as part of it is provided in the shared code in os::check_or_create_dump. Fixing this means changing all the os_posix using platforms. But your patch is not about this part. :) Second, with a leading | the core_pattern is actually the name of a program to execute when the program is about to core dump, and that is what you report with your patch. Though I'm unclear whether it both invokes the program and creates a core dump file; or just invokes the program? So with regards to this second part your patch seems functionally ok. I do dislike having a big chunk of linux specific code in this "posix" support file but ... A few style nits - you need spaces around keywords and before braces eg: if(x){ should be if (x) { I also suggest saying "Core dumps may be processed with ..." rather than "treated". And as you don't do anything in the non-redirect case I suggest collapsing this: 83 is_redirect = core_pattern[0] == '|'; 84 } 85 86 if(is_redirect){ 87 jio_snprintf(buffer, bufferSize, 88 "Core dumps may be treated with \"%s\"", &core_pattern[1]); 89 } to just 83 if (core_pattern[0] == '|') { // redirect 84 jio_snprintf(buffer, bufferSize, "Core dumps may be processed with \"%s\"", &core_pattern[1]); 85 } 86 } Comments from other runtime folk appreciated. Thanks, David > Thanks, > > Yasumasa > > 2014/10/07 15:43 "David Holmes" >: > > Hi Yasumasa, > > I'm sorry but I don't understand what you are proposing. When you say > "treat" do you mean "create"? Otherwise what do you mean by "treated"? > > Thanks, > David > > On 2/10/2014 8:38 AM, Yasumasa Suenaga wrote: > > I'm in Hackergarten @ JavaOne :-) > > > > > > Hi all, > > > > I would like to enhance the messages in hs_err report. > > Modern Linux kernel can treat core dump with user process (e.g. ABRT) > > However, hs_err report cannot detect it. > > > > I think that hs_err report should output messages as below: > > ------------- > > Failed to write core dump. Core dumps may be treated with > "/usr/sbin/chroot /proc/%P/root /usr/libexec/abrt-hook-ccpp %s %c %p > %u %g %t e" > > ------------- > > > > I've uploaded webrev of this enhancement. > > Could you review it? > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.00/ > > > > This patch works fine on Fedora20 x86_64. > > > > > > > > Thanks, > > > > Yasumasa > > > From stefan.karlsson at oracle.com Mon Oct 13 09:15:48 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 13 Oct 2014 11:15:48 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <5438476B.1060003@oracle.com> References: <542D2EC1.5030303@oracle.com> <5438476B.1060003@oracle.com> Message-ID: <543B9844.1070003@oracle.com> Hi Coleen, On 2014-10-10 22:54, Coleen Phillimore wrote: > > Hi Stefan, > > Thank you for your patience. Some review comments: > > http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/classfile/metadataOnStackMark.hpp.udiff.html > > > Why is there all this code here? It's a 45 lines data structure to collect marked Metadata pointers. > In order to make this parallel, can you just not have simply a > GrowableArray per thread? I wouldn't be able to easily reuse the memory, since the sizes of the GrowableArrays could be varying. Having a chunked list, makes this much easier. > I don't see the purpose of all this complexity in this place. I guess you are opposing code in metadataOnStackMark, rather than saying that this is complicated code? > Is it trying to add as chunked list? Yes. > Can we add a utility for this instead of tying it to the > MetadataOnStackMark functionality? We could. That would make it possible to reuse the code, but the code would be a tiny bit more non-obvious. I can try to implement this as a generic template data structure. > > In this file, what is _doit and why? This looks really strange. Can > you add a comment why sometimes doit is false and sometimes doit is > true? Is there a way to encapsulate this in a function as it's > supposed to be a scoped object. There is a code path where I need to not use the MetadataOnStackMark. Since it is a scoped object, I can't just use something like this to turn off the MetadataOnStackMark:: { if (mark_on_stack) { MetadataOnStackMark m; } // Execute the code in ClassLoaderDataGraph::do_unloading } I need to do: { MetadataOnStackMark m(mark_on_stack): // Execute the code in ClassLoaderDataGraph::do_unloading } This is what _doit is used for. The alternatives I saw was: 1) Do what I did 2) Restructure ClassLoaderDataGraph::do_unloading 3) Stop using MetadataOnStackMark as a scoped object. I thought (1) was the least intrusive change. I can change to whatever you want here. I can rename _doit to _enabled, if you think that's a better name. > > The MetadataOnStackMark object needs to go around the calls to > purge_previous_versions and free_deallocate_list. It doesn't have to > be around the whole walk of the CLDG, it just started out that way and > has gotten more complicated. If you add it to the end like: > > void ClassLoaderDataGraph::clean_metaspaces() { > // mark metadata seen on the stack and code cache so we can delete > unneeded entries. > bool has_redefined_a_class = JvmtiExport::has_redefined_a_class(); > MetadataOnStackMark md_on_stack(has_redefined_a_class); > if (has_redefined_a_class) { > // purge_previous_versions also cleans weak method links. Because > // one method's MDO can reference another method from another > // class loader, we need to first clean weak method links for all > // class loaders here. Below, we can then free redefined methods > // for all class loaders. > for (ClassLoaderData* data = _head; data != NULL; data = > data->next()) { > data->classes_do(InstanceKlass::purge_previous_versions); > } > } > // Need two loops. > for (ClassLoaderData* data = _head; data != NULL; data = > data->next()) { > data->free_deallocate_list(); > } > } > > And only call it at the end of do_unloading this would work (I've > tested this) > > if (has_metadata_to_deallocate) { > clean_metaspaces(); > } > > has_metadata_to_deallocate is generally true because of lambda > constant pools. Sounds good to me. Should has_metadata_to_deallocate always be true in the current code? I don't want to add code to check if Metadata has been allocated. I think that should be handled as a separate RFE. > > http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html > > > + if (JvmtiExport::has_redefined_a_class()) { > + InstanceKlass::purge_previous_versions(ik); > + } > > > purge previous versions requires the on_stack bits to be set. Is this > true here? Yes, that's what the MetadataOnStackMark in ConcurrentMark::weakRefsWorkParallelPart (concurrentMark.cpp) is used for. > It seems very far away from the other code to me to be able to tell. Yes, I agree. It's non-obvious, but I couldn't figure out a good way to solve it. In similar situations, I've passed down the instance of the class, in this case MetadataOnStackMark, to the code that uses it. Just to ensure that we have an instance setup when calling the code. We've discussed that approach a couple of years ago, but you didn't like it then. We have similar problems with ResourceMarks and HandleMarks, but code using Handles or Resource allocated memory asserts that those are in place. Maybe we should do the same for on_stack? > Why can't this go in the same place as the free_deallocate_lists? Because purge_previous_versions can be called in parallel, whereas free_deallocate_lists needs to be called when we are sure that all calls to purge_previous_versions have been called. So, free_deallocate_lists was added as a separate phase after the parallel unloading code. I can add comments about this. > > http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/code/nmethod.cpp.udiff.html > > > I really don't like that the on-stack bit marks are done at the same > time as clean_ic_if_metadata_is_dead. They are for different purposes. Yes, I agree. It's an abstraction violation, but I've done so that we don't have to execute the expensive reloc iter lookup code more than once. Maybe I should use a callback instead, so that we don't hard-wire the MetadataOnStackMark code into the clean_ic_if_metadata_is_dead function? > Also, this seems to mark metadata for methods that are unloaded as > well as ones that survive unloading. I guess this wouldn't prevent > methods from being unloaded but seems unnecessary callbacks to > mark_on_stack. Maybe I'm not reading this right though. I think you are right. On the other hand, previously we visited all Metadata in the entire code cache, and we didn't do this separation. I'd like this to be changes as a follow-up fix, so that I don't introduce a regression here. > I thought you couldn't do the unloading walk with the mark-on-stack > walk? There are two separate phases of the unloading walk and a barrier in between those phases. The mark-on-stack walk happens in the first phase, and the purge_previous_version happens in the second phase. The free_deallocate_lists is called in a serial phase after that. > Also, we actually only have to mark OLD methods in the code cache > which would greatly reduce the callbacks. I could make this in a > separate change as I have this change in a private repository. Sounds good. You mean OLD as in a previous version plus the Methods that were put on the deallocate_free_list? > > I think you should have a compiler reviewer comment on the nmethod > code though. > > http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/utilities/accessFlags.cpp.udiff.html > > > I don't know why this needs to be different than the atomic_set_bits > function. Previously, we didn't care if the Metadata had already been marked. They were just blindly recorded by MetadataOnStackMark. That caused the number of stored elements to be orders of magnitude larger than they had to be. To fix this, I only record Metadata if they have not already been added. I need this new function to tell if the current call, by the current thread, was setting the mark bit. The thread that succeeds with this marking, will be the one that records the Metadata in the array (or now, chunked list). Bertrand had comments about the usage of atomic_try_set_bits, so I have a version that uses a slightly altered copy of AccessFlags::atomic_set_bits. > I should have made on_stack be a flag in Method* rather than in access > flags. Sounds like a good follow-up fix. > > There's a lot here. I'm glad it helps performance and making the code > cache walk parallel is a really good change. Thanks Coleen. StefanK > > Thanks, > Coleen > > > On 10/2/14, 6:53 AM, Stefan Karlsson wrote: >> Hi all, >> >> (The following patch changes HotSpot code in areas concerning GC, RT, >> and Compiler. So, it would be good to get reviews from all three teams.) >> >> Please, review this patch to optimize and parallelize the CodeCache >> part of MetadaOnStackMark. >> >> G1 performance measurements showed longer than expected remark times >> on an application using a lot of nmethods and Metadata. The cause for >> this performance regression was the call to >> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >> MetadataOnStackMark. This code path is only taken when class >> redefinition is used. Class redefinition is typically used in >> monitoring and diagnostic frameworks. >> >> With this patch we now: >> 1) Filter out duplicate Metadata* entries instead of storing a >> Metadata* per visited metadata reference. >> 2) Collect the set of Metadata* entries in parallel. The code >> piggy-backs on the parallel CodeCache cleaning task. >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8056240 >> >> Functional testing: >> JPRT, Kitchensink, parallel_class_unloading, unit tests >> >> Performance testing: >> CRM Fuse - where the regression was found >> >> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >> and Serviceability. It would be good to get some reviews from the >> other teams, and not only from the GC team. >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Mon Oct 13 09:28:43 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 13 Oct 2014 11:28:43 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <54385937.1020408@oracle.com> References: <542D2EC1.5030303@oracle.com> <5438476B.1060003@oracle.com> <54385937.1020408@oracle.com> Message-ID: <543B9B4B.7070800@oracle.com> On 2014-10-11 00:09, Coleen Phillimore wrote: > > In nmethod.cpp how is this change related? ie. the added function and > call. Was it a cleanup? > > nmethod::unload_if_dead_at() I had to introduce the mark on stack code in the relocInfo::metadata_type. And instead of writing it inline in the RelocIterator loop, I opted for putting it in a function. To make the code clearer I also moved the code in relocInfo::oop_type to a new function. The code now looks like: 1951 case relocInfo::oop_type: 1952 if (!is_unloaded) { 1953 is_unloaded = unload_if_dead_at(&iter, is_alive, unloading_occurred); 1954 } 1955 break; 1956 1957 case relocInfo::metadata_type: 1958 if (mark_metadata_on_stack) { 1959 mark_metadata_on_stack_at(&iter); 1960 } instead of having nitty-gritty relocation code in the loop. thanks, StefanK > > thanks, > Coleen > > On 10/10/14, 4:54 PM, Coleen Phillimore wrote: >> >> Hi Stefan, >> >> Thank you for your patience. Some review comments: >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/classfile/metadataOnStackMark.hpp.udiff.html >> >> >> Why is there all this code here? In order to make this parallel, can >> you just not have simply a GrowableArray per thread? I don't see the >> purpose of all this complexity in this place. Is it trying to add as >> chunked list? Can we add a utility for this instead of tying it to >> the MetadataOnStackMark functionality? >> >> In this file, what is _doit and why? This looks really strange. Can >> you add a comment why sometimes doit is false and sometimes doit is >> true? Is there a way to encapsulate this in a function as it's >> supposed to be a scoped object. >> >> The MetadataOnStackMark object needs to go around the calls to >> purge_previous_versions and free_deallocate_list. It doesn't have to >> be around the whole walk of the CLDG, it just started out that way >> and has gotten more complicated. If you add it to the end like: >> >> void ClassLoaderDataGraph::clean_metaspaces() { >> // mark metadata seen on the stack and code cache so we can delete >> unneeded entries. >> bool has_redefined_a_class = JvmtiExport::has_redefined_a_class(); >> MetadataOnStackMark md_on_stack(has_redefined_a_class); >> if (has_redefined_a_class) { >> // purge_previous_versions also cleans weak method links. Because >> // one method's MDO can reference another method from another >> // class loader, we need to first clean weak method links for all >> // class loaders here. Below, we can then free redefined methods >> // for all class loaders. >> for (ClassLoaderData* data = _head; data != NULL; data = >> data->next()) { >> data->classes_do(InstanceKlass::purge_previous_versions); >> } >> } >> // Need two loops. >> for (ClassLoaderData* data = _head; data != NULL; data = >> data->next()) { >> data->free_deallocate_list(); >> } >> } >> >> And only call it at the end of do_unloading this would work (I've >> tested this) >> >> if (has_metadata_to_deallocate) { >> clean_metaspaces(); >> } >> >> has_metadata_to_deallocate is generally true because of lambda >> constant pools. >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html >> >> >> + if (JvmtiExport::has_redefined_a_class()) { >> + InstanceKlass::purge_previous_versions(ik); >> + } >> >> >> purge previous versions requires the on_stack bits to be set. Is this >> true here? It seems very far away from the other code to me to be >> able to tell. Why can't this go in the same place as the >> free_deallocate_lists? >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/code/nmethod.cpp.udiff.html >> >> >> I really don't like that the on-stack bit marks are done at the same >> time as clean_ic_if_metadata_is_dead. They are for different >> purposes. Also, this seems to mark metadata for methods that are >> unloaded as well as ones that survive unloading. I guess this >> wouldn't prevent methods from being unloaded but seems unnecessary >> callbacks to mark_on_stack. Maybe I'm not reading this right though. >> I thought you couldn't do the unloading walk with the mark-on-stack >> walk? Also, we actually only have to mark OLD methods in the code >> cache which would greatly reduce the callbacks. I could make this in >> a separate change as I have this change in a private repository. >> >> I think you should have a compiler reviewer comment on the nmethod >> code though. >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/utilities/accessFlags.cpp.udiff.html >> >> >> I don't know why this needs to be different than the atomic_set_bits >> function. I should have made on_stack be a flag in Method* rather >> than in access flags. >> >> There's a lot here. I'm glad it helps performance and making the >> code cache walk parallel is a really good change. >> >> Thanks, >> Coleen >> >> >> On 10/2/14, 6:53 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> (The following patch changes HotSpot code in areas concerning GC, >>> RT, and Compiler. So, it would be good to get reviews from all three >>> teams.) >>> >>> Please, review this patch to optimize and parallelize the CodeCache >>> part of MetadaOnStackMark. >>> >>> G1 performance measurements showed longer than expected remark times >>> on an application using a lot of nmethods and Metadata. The cause >>> for this performance regression was the call to >>> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >>> MetadataOnStackMark. This code path is only taken when class >>> redefinition is used. Class redefinition is typically used in >>> monitoring and diagnostic frameworks. >>> >>> With this patch we now: >>> 1) Filter out duplicate Metadata* entries instead of storing a >>> Metadata* per visited metadata reference. >>> 2) Collect the set of Metadata* entries in parallel. The code >>> piggy-backs on the parallel CodeCache cleaning task. >>> >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8056240 >>> >>> Functional testing: >>> JPRT, Kitchensink, parallel_class_unloading, unit tests >>> >>> Performance testing: >>> CRM Fuse - where the regression was found >>> >>> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >>> and Serviceability. It would be good to get some reviews from the >>> other teams, and not only from the GC team. >>> >>> thanks, >>> StefanK >> > From andreas.eriksson at oracle.com Mon Oct 13 10:03:59 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Mon, 13 Oct 2014 12:03:59 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <5437F1A7.7010600@oracle.com> References: <54368BC1.3000905@oracle.com> <5437F1A7.7010600@oracle.com> Message-ID: <543BA38F.10509@oracle.com> Hi Coleen, thanks for looking at this! See answers inline. On 2014-10-10 16:48, Coleen Phillimore wrote: > > Andreas, > This is excellent work! It looks really good. Some comments. > > http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html > > > + u1 target_type = type_annotations_typeArray->at(byte_i_ref); > + byte_i_ref += 1; > + RC_TRACE_WITH_THREAD(0x02000000, THREAD, ("target_type=0x%.2x", > target_type)); > + RC_TRACE_WITH_THREAD(0x02000000, THREAD, ("location=%s", > location_mesg)); > + > + // Skip over target_info > + switch (target_type) { > + case 0x00: > + // kind: type parameter declaration of generic class or interface > + // location: ClassFile > + case 0x01: > + // kind: type parameter declaration of generic method or constructor > + // location: method_info > > Are there any #defines that make these numbers into some symbolic values? > > These comments are good in case there aren't. > Unfortunately, there are no #defines for these numbers that I could find. I don't think creating symbolic names is worth it either, since the only unique way they are referred to in the VM spec is this verbose 'kind' field that I have included in the comments. Location combined with target_info is unique for 0x00 to 0x17, but not for 0x40 and up. One could maybe create a define by combining location name, target_info name and parts of the kind text, but I'm not sure this would increase readability. I think having these comments is better. > + case 0x17: > + // kind: type in throws clause of method or constructor > + // location: method_info > > > I can't find anything wrong. I don't really understand the test that > well so hopefully someone that knows type annotations can look at it > also. Maybe include lang tools and Joel and Eric? > Joel has been looking at this review, and he gave me some feedback on the test offline. I'll rewrite parts of it and send out a new review when I'm done. Thanks, Andreas > This code is needed because we don't replace the InstanceKlass when > redefining classes and rewrite the constant pool. If we were able to > replace the InstanceKlass instead, we wouldn't need to do all this > work. We're evaluating this at the moment, but have no real progress, > so thank you for fixing this! > > Thanks, > Coleen > > On 10/9/14, 9:21 AM, Andreas Eriksson wrote: >> Hi all, >> >> Please review this patch to RedefineClasses to allow type annotations >> to be preserved. >> >> Summary: >> During redefine / retransform class the constant pool indexes can >> change. >> Since annotations have indexes into the constant pool these indexes >> need to be rewritten. >> This is already done for regular annotations, but not for type >> annotations. >> This patch adds code to add this rewriting for the type annotations >> as well. >> The patch also contains minor changes to ClassFileReconstituter, to >> make sure that type annotations are preserved during a redefine / >> retransform class operation. >> It also has a test that uses asm to change constant pool indexes >> through a retransform, and then verifies that type annotations are >> preserved. >> >> Detail: >> A type annotation struct consists of some target information and a >> type path, followed by a regular annotation struct. >> Constant pool indexes are only present in the regular annotation struct. >> The added code skips over the type annotation specific parts, then >> calls previously existing code to rewrite constant pool indexes in >> the regular annotation struct. >> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info >> about the type annotation struct. >> >> JPRT with the new test passes without failures on all platforms. >> >> Webrev: >> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8057043 >> >> Regards >> Andreas > From andreas.eriksson at oracle.com Mon Oct 13 10:09:31 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Mon, 13 Oct 2014 12:09:31 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <54390854.1090109@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> Message-ID: <543BA4DB.3000104@oracle.com> Hi Serguei, thanks for looking at this! I'll make sure to fix the style problems. For the symbolic names / #defines, please see my answer to Coleen. Regards, Andreas On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: > Hi Andreas, > > > Thank you for fixing this issue! > The fix looks nice, I do not see any logical issues. > > > Only minor comments... > > > src/share/vm/prims/jvmtiRedefineClasses.cpp > > 2281 } // end rewrite_cp_refs_in_class_type_annotations( > 2315 } // end rewrite_cp_refs_in_fields_type_annotations( > 2345 } // end rewrite_cp_refs_in_methods_type_annotations() > 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray > 2443 } // end rewrite_cp_refs_in_type_annotation_struct > 2785 } // end skip_type_annotation_target > 2844 } // end skip_type_annotation_type_path > > The ')' is missed at 2281, 2315. > The 2397-2844 are inconsistent with the 2345 and other function-end > comments in the file. > > > 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, > 2336 byte_i, "method_info", THREAD)) { > . . . > 2378 if (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, > 2379 byte_i_ref, location_mesg, THREAD)) { > . . . > 2427 if (!skip_type_annotation_target(type_annotations_typeArray, > 2428 byte_i_ref, location_mesg, THREAD)) { > 2429 return false; > 2430 } > 2431 > 2432 if (!skip_type_annotation_type_path(type_annotations_typeArray, > 2433 byte_i_ref, THREAD)) { > 2434 return false; > 2435 } > 2436 > 2437 if (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, > 2438 byte_i_ref, THREAD)) { > 2439 return false; > Wrong indent at 2336, 2379, etc. > > > I also concur with Coleen that it would be good to define and use > symbolic names for the hexa-decimal constants used in the fix. > > > > test/runtime/RedefineTests/RedefineAnnotations.java > > Java indent must be 4, not 2. > > 253 @TestAnn(site="returnTypeAnnotation") Class typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") TypeAnnotatedTestClass arg) > > The line is too long. > > > 143 } > 144 public static void main(String argv[]) { > . . . > 209 } > 210 private static void checkAnnotations(AnnotatedType p) { > 211 checkAnnotations(p.getAnnotations()); > 212 } > 213 private static void checkAnnotations(AnnotatedType[] annoTypes) { > 214 for (AnnotatedType p : annoTypes) checkAnnotations(p.getAnnotations()); > 215 } > 216 private static void checkAnnotations(Class c) { > . . . > 257 } > 258 public void run() {} > > Adding empty lines between method definitions would improve > readability. > > > Thanks, > Serguei > > > On 10/9/14 6:21 AM, Andreas Eriksson wrote: >> Hi all, >> >> Please review this patch to RedefineClasses to allow type annotations >> to be preserved. >> >> Summary: >> During redefine / retransform class the constant pool indexes can >> change. >> Since annotations have indexes into the constant pool these indexes >> need to be rewritten. >> This is already done for regular annotations, but not for type >> annotations. >> This patch adds code to add this rewriting for the type annotations >> as well. >> The patch also contains minor changes to ClassFileReconstituter, to >> make sure that type annotations are preserved during a redefine / >> retransform class operation. >> It also has a test that uses asm to change constant pool indexes >> through a retransform, and then verifies that type annotations are >> preserved. >> >> Detail: >> A type annotation struct consists of some target information and a >> type path, followed by a regular annotation struct. >> Constant pool indexes are only present in the regular annotation struct. >> The added code skips over the type annotation specific parts, then >> calls previously existing code to rewrite constant pool indexes in >> the regular annotation struct. >> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info >> about the type annotation struct. >> >> JPRT with the new test passes without failures on all platforms. >> >> Webrev: >> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8057043 >> >> Regards >> Andreas > From stefan.karlsson at oracle.com Mon Oct 13 13:11:34 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 13 Oct 2014 15:11:34 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <542D2EC1.5030303@oracle.com> References: <542D2EC1.5030303@oracle.com> Message-ID: <543BCF86.7000706@oracle.com> Hi again, Latest changes after comments from Bertrand and Coleen: http://cr.openjdk.java.net/~stefank/8056240/webrev.01 http://cr.openjdk.java.net/~stefank/8056240/webrev.01.delta 1) Updated AccessFlags:set_on_stack to use a looping cmpxchg implementation. 2) Remove MetadataOnStackMark::_doit and restructure ClassLoaderDataGraph::do_unloading instead. 3) Move MetadataOnStackBuffer and make it a utility class named ChunkedList. thanks, StefanK On 2014-10-02 12:53, Stefan Karlsson wrote: > Hi all, > > (The following patch changes HotSpot code in areas concerning GC, RT, > and Compiler. So, it would be good to get reviews from all three teams.) > > Please, review this patch to optimize and parallelize the CodeCache > part of MetadaOnStackMark. > > G1 performance measurements showed longer than expected remark times > on an application using a lot of nmethods and Metadata. The cause for > this performance regression was the call to > CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in > MetadataOnStackMark. This code path is only taken when class > redefinition is used. Class redefinition is typically used in > monitoring and diagnostic frameworks. > > With this patch we now: > 1) Filter out duplicate Metadata* entries instead of storing a > Metadata* per visited metadata reference. > 2) Collect the set of Metadata* entries in parallel. The code > piggy-backs on the parallel CodeCache cleaning task. > > http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8056240 > > Functional testing: > JPRT, Kitchensink, parallel_class_unloading, unit tests > > Performance testing: > CRM Fuse - where the regression was found > > The patch changes HotSpot code in areas concerning GC, RT, Compiler, > and Serviceability. It would be good to get some reviews from the > other teams, and not only from the GC team. > > thanks, > StefanK From staffan.larsen at oracle.com Mon Oct 13 15:51:33 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 13 Oct 2014 08:51:33 -0700 Subject: RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux In-Reply-To: <543B1A8C.4080800@oracle.com> References: <5437A1A4.1060100@oracle.com> <5437DCBE.5030304@oracle.com> <5437F819.6020909@oracle.com> <54385EC6.1010803@oracle.com> <543B1A8C.4080800@oracle.com> Message-ID: <7C8F79C7-969E-4C8B-8F3F-AB4A0C1E4D54@oracle.com> I?ve tagged the bug to add a release note - just need to provide the text for it. Thomas: I can sponsor the fix if you send me a ?hg export? changeset with the correct check-in comments. Thanks, /Staffan On 12 okt 2014, at 17:19, David Holmes wrote: > On 12/10/2014 7:15 PM, Thomas St?fe wrote: >> As for Linux, I think one could even dynamically probe for the >> largest >> allowed thread name at the start of the VM (calling >> pthread_setname_np >> with ever-smaller names until it stops saying ERANGE). That way >> we could >> retain downward compatibility while still profit from larger names >> should the glibc people decide to enlarge that name buffer. But >> again, >> that may be over engineered. >> >> >> This is likely to be a discrete range rather than a continuous one - >> I don't expect to find different linux versions each choosing a >> different value. >> >> >> The same binary could run on both old and new Linux machines with >> different task name length limits. It would be nice to have the VM >> automatically adapt to future improvements while retaining downward >> compatibility. >> >> After reading up a bit on Gerards glibc feature request >> https://sourceware.org/bugzilla/show_bug.cgi?format=multiple&id=16578, >> it seems that pthread lib on Linux implements thread naming by using >> kernel task names; task names are limited by TASK_COMM_LEN. It is >> possible to increase that define, but there are bug reports out that >> increasing TASK_COMM_LEN caused memory corruptions. So I concede that >> while it is possible that the pthread name length may change, it is not >> probable. >> >> My main concern is that some very commonly used threading libraries >> will encounter this 15 char limit eg: >> >> ForkJoinPool.commonPool-__worker- >> pool--thread- >> >> and custom Executors and FJPools tend to use even longer name. >> >> >> This is true and you are right. I think the feature is still useful >> enough, not so much for java developers but for OpenJDK developers, who >> are much more likely to debug natively and for whom a common case is to >> quickly identify OpenJDK special threads (Vm Thread, GC threads etc) in >> a forest of common java threads. >> >> It is also useful for cases where the libjvm.so is embedded into another >> launcher as "just another library", and you want to tell apart jvm >> threads from threads which have nothing to do with the jvm. >> >> As for missing documentation, this should be already a problem >> now, as >> the function is implemented on one platform and the other >> platforms are >> stubbed out? I don't see how the change would change that. >> >> >> At the moment the missing documentation concerns only one platform. >> Now it concerns three platforms that all (potentially) behave >> differently; with a fourth and fifth potentially on the way. So I >> think the documentation issue needs to resolved. >> >> >> I agree with you and if you tell me the format and/or where to put it, I >> can write a short documentation. > > I would like to see a release note entry; though that is an Oracle specific entity :( Not sure where else this can be readily documented - suggestions welcome. > > Thanks, > David > >> Thanks, Thomas From bertrand.delsart at oracle.com Mon Oct 13 16:09:24 2014 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Mon, 13 Oct 2014 18:09:24 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <543BCF86.7000706@oracle.com> References: <542D2EC1.5030303@oracle.com> <543BCF86.7000706@oracle.com> Message-ID: <543BF934.4020605@oracle.com> Thanks Stefan, Code looks cleaner and safer from a runtime point of view. Just a few minor points (feel free to ignore them) and a few typos. First, note that there is no loop in ConstantPool::set_on_stack when the CAS fails but this seems OK. This should not lead to any regression since the previous version was not thread safe. Hence, this works if you are sure that no other change that setting _on_stack can happen concurrently in your new use case. To be safer, I would add an assert: int result = Atomic::cmpxchg(new_flags, &_flags, old_flags); if (result == old_flags) { // Succeeded. MetadataOnStackMark::record(this, Thread::current()); } else { + assert((result & _on_stack) != 0, "Expected only on_stack to be set concurrently"); } Another minor point: in classLoaderData.cpp, your new free_deallocate_list loop at the end of ClassLoaderDataGraph::clean_metaspaces could be replaced by a call to your new ClassLoaderDataGraph::free_deallocate_lists(), which performs exactly the same work. Last minor point: the retire_buffer_for_thread(Thread::current()) at the end of work_first_pass looks sufficient. However, to stress your change and improve the robustness against future changes, should we assert that the buffer for the current thread is NULL at the end of G1ParallelCleaningTask::work ? This assert would detect any late marking (which would be useless and might also disturb the next GC cycle). If we are paranoid, we can also add the same assert at the beginning of G1ParallelCleaningTask::work. I'll let you see whether this is worth it since this impacts only GC code. For similar reason, I was wondering whether we should assert that _used_buffers is NULL at the beginning of MetadataOnStackMark constructor. This would allow to detect any marking done out of a MetadataOnStackBuffer section. Such marking would look suspicious to me. If you have any doubt, we can let Coleen add the assert later. Except for that, there are a few typos in the comments. Will let a native English speaker make an additional pass over them. Here are the ones that stood out when I reviewed the code changes: concurrentMark.cpp: + // In this lmetadata, we must only follow those metadatas directly embedded in g1CollectedHeap.cpp + // The nmethod cleaning helps out an does the CodeCache part of MetadataOnStackMark. Regards, Bertrand (not a Reviewer). On 13/10/14 15:11, Stefan Karlsson wrote: > Hi again, > > Latest changes after comments from Bertrand and Coleen: > http://cr.openjdk.java.net/~stefank/8056240/webrev.01 > http://cr.openjdk.java.net/~stefank/8056240/webrev.01.delta > > 1) Updated AccessFlags:set_on_stack to use a looping cmpxchg > implementation. > 2) Remove MetadataOnStackMark::_doit and restructure > ClassLoaderDataGraph::do_unloading instead. > 3) Move MetadataOnStackBuffer and make it a utility class named > ChunkedList. > > thanks, > StefanK > > On 2014-10-02 12:53, Stefan Karlsson wrote: >> Hi all, >> >> (The following patch changes HotSpot code in areas concerning GC, RT, >> and Compiler. So, it would be good to get reviews from all three teams.) >> >> Please, review this patch to optimize and parallelize the CodeCache >> part of MetadaOnStackMark. >> >> G1 performance measurements showed longer than expected remark times >> on an application using a lot of nmethods and Metadata. The cause for >> this performance regression was the call to >> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >> MetadataOnStackMark. This code path is only taken when class >> redefinition is used. Class redefinition is typically used in >> monitoring and diagnostic frameworks. >> >> With this patch we now: >> 1) Filter out duplicate Metadata* entries instead of storing a >> Metadata* per visited metadata reference. >> 2) Collect the set of Metadata* entries in parallel. The code >> piggy-backs on the parallel CodeCache cleaning task. >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8056240 >> >> Functional testing: >> JPRT, Kitchensink, parallel_class_unloading, unit tests >> >> Performance testing: >> CRM Fuse - where the regression was found >> >> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >> and Serviceability. It would be good to get some reviews from the >> other teams, and not only from the GC team. >> >> thanks, >> StefanK > -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38334 Saint Ismier, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From george.triantafillou at oracle.com Mon Oct 13 20:26:36 2014 From: george.triantafillou at oracle.com (George Triantafillou) Date: Mon, 13 Oct 2014 16:26:36 -0400 Subject: RFR: 8058606 Detailed Native Memory Tracking (NMT) data is not output at VM exit Message-ID: <543C357C.9050009@oracle.com> NOTE: The original webrev for this issue has been modified as a result of the fix for https://bugs.openjdk.java.net/browse/JDK-8059100. Please review this fix for JDK-8058606. As a result of the fix for JDK-8059100, the output from the -XX:NativeMemoryTracking=detail option now outputs detailed tracking information at VM exit. Previously, only summary tracking information was output. The modified test now verifies the output from both summary and detail tracking options. Bug: https://bugs.openjdk.java.net/browse/JDK-8058606 Webrev: http://cr.openjdk.java.net/~gtriantafill/JDK-8058606/webrev/ The fix was tested locally on Linux with jtreg and the JPRT hotspot testset. -George From serguei.spitsyn at oracle.com Mon Oct 13 21:29:05 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 13 Oct 2014 14:29:05 -0700 Subject: RFR (XS) 8060245: update bsd version of jhelper.d to be in sync with the fix of 8009204 on solaris Message-ID: <543C4421.2070604@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8060245 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8060245-dtrace.1/ Summary: The fix of 8009204 for jhelper.d was applied to the Solaris version only but the bsd version must match it too. Testing: N/A: The jhelper.d is not used on bsd yet Thanks, Serguei From yasuenag at gmail.com Tue Oct 14 10:05:07 2014 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 14 Oct 2014 19:05:07 +0900 Subject: RFR: JDK-8059586: hs_err report should treat redirected core pattern. In-Reply-To: <543B1FD6.3000200@oracle.com> References: <542C8274.3010809@gmail.com> <54338B70.9080709@oracle.com> <543B1FD6.3000200@oracle.com> Message-ID: <543CF553.80601@gmail.com> Hi David, Thank you for comments! I've uploaded new webrev. Could you review it again? http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.01/ I am an author of jdk9. So I cannot commit it. Could you be a sponsor for this enhancement? > In which case that should be handled by the linux specific get_core_path() function. Agree. So I implemented it in os_linux.cpp . But part of format characters (%P: global pid, %s: signal, %t dump time) are not processed in this function because I think these parameters are difficult to handle in it. %P: I could not find API for this. %s: We have to change arguments of get_core_path() . %t: This parameter means timestamp of coredump. It is decided in Kernel. > Fixing this means changing all the os_posix using platforms. But your patch is not about this part. :) I moved os::check_or_create_dump() to each OS implementations (AIX, BSD, Solaris, Linux) . So I can write Linux specific code to check_or_create_dump() . As a result, I could remove "#ifdef LINUX" from os_posix.cpp :-) > Though I'm unclear whether it both invokes the program and creates a core dump file; or just invokes the program? If '|' is set, Linux kernel will just redirect core image to user process. Kernel documentation says as below: ------------ . If the first character of the pattern is a '|', the kernel will treat the rest of the pattern as a command to run. The core dump will be written to the standard input of that program instead of to a file. ------------ And implementation of coredump (do_coredump()) follows to it. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/coredump.c In case of ABRT, ABRT dumps core image to default location (/core.) if user set unlimited to resource limit of core (ulimit -c) . https://github.com/abrt/abrt/blob/master/src/hooks/abrt-hook-ccpp.c > A few style nits - you need spaces around keywords and before braces > I also suggest saying "Core dumps may be processed with ..." rather than "treated". > And as you don't do anything in the non-redirect case I suggest collapsing this: I've fixed them. Thanks, Yasumasa (2014/10/13 9:41), David Holmes wrote: > Hi Yasumasa, > > On 7/10/2014 8:48 PM, Yasumasa Suenaga wrote: >> Hi David, >> >> Sorry for my English. >> >> I want to propose that JVM should create message according to core >> pattern (/proc/sys/kernel/core_pattern) . >> So I filed it to JBS and created a patch. > > So I've had a quick look at this core_pattern business and it seems to me that there are two aspects to this. > > First, without the leading |, the entry in the core_pattern file is a naming pattern for the core file. In which case that should be handled by the linux specific get_core_path() function. Though that in itself can't fully report the expected name, as part of it is provided in the shared code in os::check_or_create_dump. Fixing this means changing all the os_posix using platforms. But your patch is not about this part. :) > > Second, with a leading | the core_pattern is actually the name of a program to execute when the program is about to core dump, and that is what you report with your patch. Though I'm unclear whether it both invokes the program and creates a core dump file; or just invokes the program? > > So with regards to this second part your patch seems functionally ok. I do dislike having a big chunk of linux specific code in this "posix" support file but ... > > A few style nits - you need spaces around keywords and before braces eg: > > if(x){ > > should be > > if (x) { > > I also suggest saying "Core dumps may be processed with ..." rather than "treated". > > And as you don't do anything in the non-redirect case I suggest collapsing this: > > 83 is_redirect = core_pattern[0] == '|'; > 84 } > 85 > 86 if(is_redirect){ > 87 jio_snprintf(buffer, bufferSize, > 88 "Core dumps may be treated with \"%s\"", &core_pattern[1]); > 89 } > > to just > > 83 if (core_pattern[0] == '|') { // redirect > 84 jio_snprintf(buffer, bufferSize, "Core dumps may be processed with \"%s\"", &core_pattern[1]); > 85 } > 86 } > > Comments from other runtime folk appreciated. > > Thanks, > David > >> Thanks, >> >> Yasumasa >> >> 2014/10/07 15:43 "David Holmes" > >: >> >> Hi Yasumasa, >> >> I'm sorry but I don't understand what you are proposing. When you say >> "treat" do you mean "create"? Otherwise what do you mean by "treated"? >> >> Thanks, >> David >> >> On 2/10/2014 8:38 AM, Yasumasa Suenaga wrote: >> > I'm in Hackergarten @ JavaOne :-) >> > >> > >> > Hi all, >> > >> > I would like to enhance the messages in hs_err report. >> > Modern Linux kernel can treat core dump with user process (e.g. ABRT) >> > However, hs_err report cannot detect it. >> > >> > I think that hs_err report should output messages as below: >> > ------------- >> > Failed to write core dump. Core dumps may be treated with >> "/usr/sbin/chroot /proc/%P/root /usr/libexec/abrt-hook-ccpp %s %c %p >> %u %g %t e" >> > ------------- >> > >> > I've uploaded webrev of this enhancement. >> > Could you review it? >> > >> > http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.00/ >> > >> > This patch works fine on Fedora20 x86_64. >> > >> > >> > >> > Thanks, >> > >> > Yasumasa >> > >> From mikael.gerdin at oracle.com Tue Oct 14 12:41:47 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 14 Oct 2014 14:41:47 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <543BCF86.7000706@oracle.com> References: <542D2EC1.5030303@oracle.com> <543BCF86.7000706@oracle.com> Message-ID: <543D1A0B.4060703@oracle.com> Stefan, On 2014-10-13 15:11, Stefan Karlsson wrote: > Hi again, > > Latest changes after comments from Bertrand and Coleen: > http://cr.openjdk.java.net/~stefank/8056240/webrev.01 chunkedList.hpp 902 + // Don't clear the next pointers since that would interfer Typo: interfer -> interfere thread.hpp Can't you forward-declare MetadataOnStackBuffer instead of #including it? You only do simple manipulation on the pointers so it should work. Ideally, it would be nice to not have the MetadataOnStackBuffer* in Thread but in one of its subclasses. Unfortunately it's used by both WorkerThread and VMThread so I don't have a good solution for that. I just find the pollution of the Thread superclass somewhat unfortunate. classLoaderData.hpp Why is clean_metaspaces public? nmethod.cpp 381 + // In this lmetadata, we must only follow those metadatas directly embedded in Typo: lmetadata -> metadata 401 + // Call function Method*, not embedded in these other places. In the above comment you talk about "visiting metadata", can you change these comments to use consistent terminology? Otherwise the change looks ok. /Mikael > http://cr.openjdk.java.net/~stefank/8056240/webrev.01.delta > > 1) Updated AccessFlags:set_on_stack to use a looping cmpxchg > implementation. > 2) Remove MetadataOnStackMark::_doit and restructure > ClassLoaderDataGraph::do_unloading instead. > 3) Move MetadataOnStackBuffer and make it a utility class named > ChunkedList. > > thanks, > StefanK > > On 2014-10-02 12:53, Stefan Karlsson wrote: >> Hi all, >> >> (The following patch changes HotSpot code in areas concerning GC, RT, >> and Compiler. So, it would be good to get reviews from all three teams.) >> >> Please, review this patch to optimize and parallelize the CodeCache >> part of MetadaOnStackMark. >> >> G1 performance measurements showed longer than expected remark times >> on an application using a lot of nmethods and Metadata. The cause for >> this performance regression was the call to >> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >> MetadataOnStackMark. This code path is only taken when class >> redefinition is used. Class redefinition is typically used in >> monitoring and diagnostic frameworks. >> >> With this patch we now: >> 1) Filter out duplicate Metadata* entries instead of storing a >> Metadata* per visited metadata reference. >> 2) Collect the set of Metadata* entries in parallel. The code >> piggy-backs on the parallel CodeCache cleaning task. >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8056240 >> >> Functional testing: >> JPRT, Kitchensink, parallel_class_unloading, unit tests >> >> Performance testing: >> CRM Fuse - where the regression was found >> >> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >> and Serviceability. It would be good to get some reviews from the >> other teams, and not only from the GC team. >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Tue Oct 14 12:39:13 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 14 Oct 2014 14:39:13 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <543BF934.4020605@oracle.com> References: <542D2EC1.5030303@oracle.com> <543BCF86.7000706@oracle.com> <543BF934.4020605@oracle.com> Message-ID: <543D1971.8060807@oracle.com> On 2014-10-13 18:09, Bertrand Delsart wrote: > Thanks Stefan, > > Code looks cleaner and safer from a runtime point of view. > > Just a few minor points (feel free to ignore them) and a few typos. > > First, note that there is no loop in ConstantPool::set_on_stack when > the CAS fails but this seems OK. This should not lead to any > regression since the previous version was not thread safe. Hence, this > works if you are sure that no other change that setting _on_stack can > happen concurrently in your new use case. To be safer, I would add an > assert: > int result = Atomic::cmpxchg(new_flags, &_flags, old_flags); > > if (result == old_flags) { > // Succeeded. > MetadataOnStackMark::record(this, Thread::current()); > } else { > + assert((result & _on_stack) != 0, "Expected only on_stack to > be set concurrently"); > } Done. I added a loop. > > Another minor point: in classLoaderData.cpp, your new > free_deallocate_list loop at the end of > ClassLoaderDataGraph::clean_metaspaces could be replaced by a call to > your new ClassLoaderDataGraph::free_deallocate_lists(), which performs > exactly the same work. Done. > > Last minor point: the retire_buffer_for_thread(Thread::current()) at > the end of work_first_pass looks sufficient. However, to stress your > change and improve the robustness against future changes, should we > assert that the buffer for the current thread is NULL at the end of > G1ParallelCleaningTask::work ? This assert would detect any late > marking (which would be useless and might also disturb the next GC > cycle). If we are paranoid, we can also add the same assert at the > beginning of G1ParallelCleaningTask::work. I'll let you see whether > this is worth it since this impacts only GC code. Done. > > For similar reason, I was wondering whether we should assert that > _used_buffers is NULL at the beginning of MetadataOnStackMark > constructor. This would allow to detect any marking done out of a > MetadataOnStackBuffer section. Such marking would look suspicious to > me. If you have any doubt, we can let Coleen add the assert later. Done. > > Except for that, there are a few typos in the comments. Will let a > native English speaker make an additional pass over them. Here are the > ones that stood out when I reviewed the code changes: > > concurrentMark.cpp: > + // In this lmetadata, we must only follow those metadatas directly > embedded in This wasn't written by me. It comes from the comment in nmethod::metadata_do. :) I've removed the l from lmetdata, but I haven't change the wording of that comment. > > g1CollectedHeap.cpp > + // The nmethod cleaning helps out an does the CodeCache part of > MetadataOnStackMark. I changed an => and. I'll send out a new webrev after I've taken care of Mikael's comments. thanks, StefanK > > Regards, > > Bertrand (not a Reviewer). > > > On 13/10/14 15:11, Stefan Karlsson wrote: >> Hi again, >> >> Latest changes after comments from Bertrand and Coleen: >> http://cr.openjdk.java.net/~stefank/8056240/webrev.01 >> http://cr.openjdk.java.net/~stefank/8056240/webrev.01.delta >> >> 1) Updated AccessFlags:set_on_stack to use a looping cmpxchg >> implementation. >> 2) Remove MetadataOnStackMark::_doit and restructure >> ClassLoaderDataGraph::do_unloading instead. >> 3) Move MetadataOnStackBuffer and make it a utility class named >> ChunkedList. >> >> thanks, >> StefanK >> >> On 2014-10-02 12:53, Stefan Karlsson wrote: >>> Hi all, >>> >>> (The following patch changes HotSpot code in areas concerning GC, RT, >>> and Compiler. So, it would be good to get reviews from all three >>> teams.) >>> >>> Please, review this patch to optimize and parallelize the CodeCache >>> part of MetadaOnStackMark. >>> >>> G1 performance measurements showed longer than expected remark times >>> on an application using a lot of nmethods and Metadata. The cause for >>> this performance regression was the call to >>> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >>> MetadataOnStackMark. This code path is only taken when class >>> redefinition is used. Class redefinition is typically used in >>> monitoring and diagnostic frameworks. >>> >>> With this patch we now: >>> 1) Filter out duplicate Metadata* entries instead of storing a >>> Metadata* per visited metadata reference. >>> 2) Collect the set of Metadata* entries in parallel. The code >>> piggy-backs on the parallel CodeCache cleaning task. >>> >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8056240 >>> >>> Functional testing: >>> JPRT, Kitchensink, parallel_class_unloading, unit tests >>> >>> Performance testing: >>> CRM Fuse - where the regression was found >>> >>> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >>> and Serviceability. It would be good to get some reviews from the >>> other teams, and not only from the GC team. >>> >>> thanks, >>> StefanK >> > > From stefan.karlsson at oracle.com Tue Oct 14 13:02:04 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 14 Oct 2014 15:02:04 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <543D1A0B.4060703@oracle.com> References: <542D2EC1.5030303@oracle.com> <543BCF86.7000706@oracle.com> <543D1A0B.4060703@oracle.com> Message-ID: <543D1ECC.50305@oracle.com> On 2014-10-14 14:41, Mikael Gerdin wrote: > Stefan, > > On 2014-10-13 15:11, Stefan Karlsson wrote: >> Hi again, >> >> Latest changes after comments from Bertrand and Coleen: >> http://cr.openjdk.java.net/~stefank/8056240/webrev.01 > > chunkedList.hpp > 902 + // Don't clear the next pointers since that would interfer > Typo: interfer -> interfere Done. > > thread.hpp > Can't you forward-declare MetadataOnStackBuffer instead of #including it? > You only do simple manipulation on the pointers so it should work. Done. I tried to do it earlier but couldn't get it to work. The following seems to work: class Metadata; template class ChunkedList; typedef ChunkedList MetadataOnStackBuffer; > > Ideally, it would be nice to not have the MetadataOnStackBuffer* in > Thread but in one of its subclasses. Unfortunately it's used by both > WorkerThread and VMThread so I don't have a good solution for that. I > just find the pollution of the Thread superclass somewhat unfortunate. I had the same thoughts. > > classLoaderData.hpp > Why is clean_metaspaces public? I moved it to the private section. > > nmethod.cpp > 381 + // In this lmetadata, we must only follow those metadatas > directly embedded in > Typo: lmetadata -> metadata Done. > > 401 + // Call function Method*, not embedded in these other places. > In the above comment you talk about "visiting metadata", can you > change these comments to use consistent terminology? Done. I also fixed the place where I copied this comment from. > > Otherwise the change looks ok. thanks, StefanK > > /Mikael > > >> http://cr.openjdk.java.net/~stefank/8056240/webrev.01.delta >> >> 1) Updated AccessFlags:set_on_stack to use a looping cmpxchg >> implementation. >> 2) Remove MetadataOnStackMark::_doit and restructure >> ClassLoaderDataGraph::do_unloading instead. >> 3) Move MetadataOnStackBuffer and make it a utility class named >> ChunkedList. >> >> thanks, >> StefanK >> >> On 2014-10-02 12:53, Stefan Karlsson wrote: >>> Hi all, >>> >>> (The following patch changes HotSpot code in areas concerning GC, RT, >>> and Compiler. So, it would be good to get reviews from all three >>> teams.) >>> >>> Please, review this patch to optimize and parallelize the CodeCache >>> part of MetadaOnStackMark. >>> >>> G1 performance measurements showed longer than expected remark times >>> on an application using a lot of nmethods and Metadata. The cause for >>> this performance regression was the call to >>> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >>> MetadataOnStackMark. This code path is only taken when class >>> redefinition is used. Class redefinition is typically used in >>> monitoring and diagnostic frameworks. >>> >>> With this patch we now: >>> 1) Filter out duplicate Metadata* entries instead of storing a >>> Metadata* per visited metadata reference. >>> 2) Collect the set of Metadata* entries in parallel. The code >>> piggy-backs on the parallel CodeCache cleaning task. >>> >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8056240 >>> >>> Functional testing: >>> JPRT, Kitchensink, parallel_class_unloading, unit tests >>> >>> Performance testing: >>> CRM Fuse - where the regression was found >>> >>> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >>> and Serviceability. It would be good to get some reviews from the >>> other teams, and not only from the GC team. >>> >>> thanks, >>> StefanK >> From mikael.gerdin at oracle.com Tue Oct 14 13:44:42 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 14 Oct 2014 15:44:42 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <543D1ECC.50305@oracle.com> References: <542D2EC1.5030303@oracle.com> <543BCF86.7000706@oracle.com> <543D1A0B.4060703@oracle.com> <543D1ECC.50305@oracle.com> Message-ID: <543D28CA.6020000@oracle.com> Stefan, On 2014-10-14 15:02, Stefan Karlsson wrote: > > On 2014-10-14 14:41, Mikael Gerdin wrote: >> Stefan, >> >> On 2014-10-13 15:11, Stefan Karlsson wrote: >>> Hi again, >>> >>> Latest changes after comments from Bertrand and Coleen: >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.01 >> >> chunkedList.hpp >> 902 + // Don't clear the next pointers since that would interfer >> Typo: interfer -> interfere > > Done. > >> >> thread.hpp >> Can't you forward-declare MetadataOnStackBuffer instead of #including it? >> You only do simple manipulation on the pointers so it should work. > > Done. > > I tried to do it earlier but couldn't get it to work. The following > seems to work: > class Metadata; > template class ChunkedList; > typedef ChunkedList MetadataOnStackBuffer; I still prefer this variant even though it's not particularly pretty. > >> >> Ideally, it would be nice to not have the MetadataOnStackBuffer* in >> Thread but in one of its subclasses. Unfortunately it's used by both >> WorkerThread and VMThread so I don't have a good solution for that. I >> just find the pollution of the Thread superclass somewhat unfortunate. > > I had the same thoughts. > >> >> classLoaderData.hpp >> Why is clean_metaspaces public? > > I moved it to the private section. > >> >> nmethod.cpp >> 381 + // In this lmetadata, we must only follow those metadatas >> directly embedded in >> Typo: lmetadata -> metadata > > Done. > >> >> 401 + // Call function Method*, not embedded in these other places. >> In the above comment you talk about "visiting metadata", can you >> change these comments to use consistent terminology? > > Done. I also fixed the place where I copied this comment from. > >> >> Otherwise the change looks ok. > > thanks, Thanks for fixing this Stefan. /Mikael > StefanK > >> >> /Mikael >> >> >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.01.delta >>> >>> 1) Updated AccessFlags:set_on_stack to use a looping cmpxchg >>> implementation. >>> 2) Remove MetadataOnStackMark::_doit and restructure >>> ClassLoaderDataGraph::do_unloading instead. >>> 3) Move MetadataOnStackBuffer and make it a utility class named >>> ChunkedList. >>> >>> thanks, >>> StefanK >>> >>> On 2014-10-02 12:53, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> (The following patch changes HotSpot code in areas concerning GC, RT, >>>> and Compiler. So, it would be good to get reviews from all three >>>> teams.) >>>> >>>> Please, review this patch to optimize and parallelize the CodeCache >>>> part of MetadaOnStackMark. >>>> >>>> G1 performance measurements showed longer than expected remark times >>>> on an application using a lot of nmethods and Metadata. The cause for >>>> this performance regression was the call to >>>> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >>>> MetadataOnStackMark. This code path is only taken when class >>>> redefinition is used. Class redefinition is typically used in >>>> monitoring and diagnostic frameworks. >>>> >>>> With this patch we now: >>>> 1) Filter out duplicate Metadata* entries instead of storing a >>>> Metadata* per visited metadata reference. >>>> 2) Collect the set of Metadata* entries in parallel. The code >>>> piggy-backs on the parallel CodeCache cleaning task. >>>> >>>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8056240 >>>> >>>> Functional testing: >>>> JPRT, Kitchensink, parallel_class_unloading, unit tests >>>> >>>> Performance testing: >>>> CRM Fuse - where the regression was found >>>> >>>> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >>>> and Serviceability. It would be good to get some reviews from the >>>> other teams, and not only from the GC team. >>>> >>>> thanks, >>>> StefanK >>> > From coleen.phillimore at oracle.com Tue Oct 14 13:45:14 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Oct 2014 09:45:14 -0400 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543BA38F.10509@oracle.com> References: <54368BC1.3000905@oracle.com> <5437F1A7.7010600@oracle.com> <543BA38F.10509@oracle.com> Message-ID: <543D28EA.7040703@oracle.com> Andreas, This is ok about the case numbers then. I agree it's not worth creating new enum type for them since they are all commented. (sorry for top-posting but this is my only comment). You have my code review. Thank you for adding this. Coleen On 10/13/14, 6:03 AM, Andreas Eriksson wrote: > Hi Coleen, thanks for looking at this! > See answers inline. > > On 2014-10-10 16:48, Coleen Phillimore wrote: >> >> Andreas, >> This is excellent work! It looks really good. Some comments. >> >> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >> >> >> + u1 target_type = type_annotations_typeArray->at(byte_i_ref); >> + byte_i_ref += 1; >> + RC_TRACE_WITH_THREAD(0x02000000, THREAD, ("target_type=0x%.2x", >> target_type)); >> + RC_TRACE_WITH_THREAD(0x02000000, THREAD, ("location=%s", >> location_mesg)); >> + >> + // Skip over target_info >> + switch (target_type) { >> + case 0x00: >> + // kind: type parameter declaration of generic class or interface >> + // location: ClassFile >> + case 0x01: >> + // kind: type parameter declaration of generic method or >> constructor >> + // location: method_info >> >> Are there any #defines that make these numbers into some symbolic >> values? >> >> These comments are good in case there aren't. >> > > Unfortunately, there are no #defines for these numbers that I could find. > I don't think creating symbolic names is worth it either, since the > only unique way they are referred to in the VM spec is this verbose > 'kind' field that I have included in the comments. > Location combined with target_info is unique for 0x00 to 0x17, but not > for 0x40 and up. One could maybe create a define by combining location > name, target_info name and parts of the kind text, but I'm not sure > this would increase readability. I think having these comments is better. > >> + case 0x17: >> + // kind: type in throws clause of method or constructor >> + // location: method_info >> >> >> I can't find anything wrong. I don't really understand the test that >> well so hopefully someone that knows type annotations can look at it >> also. Maybe include lang tools and Joel and Eric? >> > > Joel has been looking at this review, and he gave me some feedback on > the test offline. I'll rewrite parts of it and send out a new review > when I'm done. > > Thanks, > Andreas > >> This code is needed because we don't replace the InstanceKlass when >> redefining classes and rewrite the constant pool. If we were able to >> replace the InstanceKlass instead, we wouldn't need to do all this >> work. We're evaluating this at the moment, but have no real >> progress, so thank you for fixing this! >> >> Thanks, >> Coleen >> >> On 10/9/14, 9:21 AM, Andreas Eriksson wrote: >>> Hi all, >>> >>> Please review this patch to RedefineClasses to allow type >>> annotations to be preserved. >>> >>> Summary: >>> During redefine / retransform class the constant pool indexes can >>> change. >>> Since annotations have indexes into the constant pool these indexes >>> need to be rewritten. >>> This is already done for regular annotations, but not for type >>> annotations. >>> This patch adds code to add this rewriting for the type annotations >>> as well. >>> The patch also contains minor changes to ClassFileReconstituter, to >>> make sure that type annotations are preserved during a redefine / >>> retransform class operation. >>> It also has a test that uses asm to change constant pool indexes >>> through a retransform, and then verifies that type annotations are >>> preserved. >>> >>> Detail: >>> A type annotation struct consists of some target information and a >>> type path, followed by a regular annotation struct. >>> Constant pool indexes are only present in the regular annotation >>> struct. >>> The added code skips over the type annotation specific parts, then >>> calls previously existing code to rewrite constant pool indexes in >>> the regular annotation struct. >>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info >>> about the type annotation struct. >>> >>> JPRT with the new test passes without failures on all platforms. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>> >>> Regards >>> Andreas >> > From stefan.karlsson at oracle.com Tue Oct 14 14:42:42 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 14 Oct 2014 16:42:42 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <543BCF86.7000706@oracle.com> References: <542D2EC1.5030303@oracle.com> <543BCF86.7000706@oracle.com> Message-ID: <543D3662.3070008@oracle.com> Hi, Here are the latest changes based on comments from Bertrand and Mikael: http://cr.openjdk.java.net/~stefank/8056240/webrev.02 http://cr.openjdk.java.net/~stefank/8056240/webrev.02.delta thanks, StefanK On 2014-10-13 15:11, Stefan Karlsson wrote: > Hi again, > > Latest changes after comments from Bertrand and Coleen: > http://cr.openjdk.java.net/~stefank/8056240/webrev.01 > http://cr.openjdk.java.net/~stefank/8056240/webrev.01.delta > > 1) Updated AccessFlags:set_on_stack to use a looping cmpxchg > implementation. > 2) Remove MetadataOnStackMark::_doit and restructure > ClassLoaderDataGraph::do_unloading instead. > 3) Move MetadataOnStackBuffer and make it a utility class named > ChunkedList. > > thanks, > StefanK > > On 2014-10-02 12:53, Stefan Karlsson wrote: >> Hi all, >> >> (The following patch changes HotSpot code in areas concerning GC, RT, >> and Compiler. So, it would be good to get reviews from all three teams.) >> >> Please, review this patch to optimize and parallelize the CodeCache >> part of MetadaOnStackMark. >> >> G1 performance measurements showed longer than expected remark times >> on an application using a lot of nmethods and Metadata. The cause for >> this performance regression was the call to >> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >> MetadataOnStackMark. This code path is only taken when class >> redefinition is used. Class redefinition is typically used in >> monitoring and diagnostic frameworks. >> >> With this patch we now: >> 1) Filter out duplicate Metadata* entries instead of storing a >> Metadata* per visited metadata reference. >> 2) Collect the set of Metadata* entries in parallel. The code >> piggy-backs on the parallel CodeCache cleaning task. >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8056240 >> >> Functional testing: >> JPRT, Kitchensink, parallel_class_unloading, unit tests >> >> Performance testing: >> CRM Fuse - where the regression was found >> >> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >> and Serviceability. It would be good to get some reviews from the >> other teams, and not only from the GC team. >> >> thanks, >> StefanK > From mikael.gerdin at oracle.com Tue Oct 14 15:00:44 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 14 Oct 2014 17:00:44 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <543D3662.3070008@oracle.com> References: <542D2EC1.5030303@oracle.com> <543BCF86.7000706@oracle.com> <543D3662.3070008@oracle.com> Message-ID: <543D3A9C.5020402@oracle.com> Stefan, On 2014-10-14 16:42, Stefan Karlsson wrote: > Hi, > > Here are the latest changes based on comments from Bertrand and Mikael: > http://cr.openjdk.java.net/~stefank/8056240/webrev.02 > http://cr.openjdk.java.net/~stefank/8056240/webrev.02.delta Looks good to me. /Mikael > > thanks, > StefanK > > On 2014-10-13 15:11, Stefan Karlsson wrote: >> Hi again, >> >> Latest changes after comments from Bertrand and Coleen: >> http://cr.openjdk.java.net/~stefank/8056240/webrev.01 >> http://cr.openjdk.java.net/~stefank/8056240/webrev.01.delta >> >> 1) Updated AccessFlags:set_on_stack to use a looping cmpxchg >> implementation. >> 2) Remove MetadataOnStackMark::_doit and restructure >> ClassLoaderDataGraph::do_unloading instead. >> 3) Move MetadataOnStackBuffer and make it a utility class named >> ChunkedList. >> >> thanks, >> StefanK >> >> On 2014-10-02 12:53, Stefan Karlsson wrote: >>> Hi all, >>> >>> (The following patch changes HotSpot code in areas concerning GC, RT, >>> and Compiler. So, it would be good to get reviews from all three teams.) >>> >>> Please, review this patch to optimize and parallelize the CodeCache >>> part of MetadaOnStackMark. >>> >>> G1 performance measurements showed longer than expected remark times >>> on an application using a lot of nmethods and Metadata. The cause for >>> this performance regression was the call to >>> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >>> MetadataOnStackMark. This code path is only taken when class >>> redefinition is used. Class redefinition is typically used in >>> monitoring and diagnostic frameworks. >>> >>> With this patch we now: >>> 1) Filter out duplicate Metadata* entries instead of storing a >>> Metadata* per visited metadata reference. >>> 2) Collect the set of Metadata* entries in parallel. The code >>> piggy-backs on the parallel CodeCache cleaning task. >>> >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8056240 >>> >>> Functional testing: >>> JPRT, Kitchensink, parallel_class_unloading, unit tests >>> >>> Performance testing: >>> CRM Fuse - where the regression was found >>> >>> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >>> and Serviceability. It would be good to get some reviews from the >>> other teams, and not only from the GC team. >>> >>> thanks, >>> StefanK >> > From bertrand.delsart at oracle.com Tue Oct 14 16:16:04 2014 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 14 Oct 2014 18:16:04 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <543D3A9C.5020402@oracle.com> References: <542D2EC1.5030303@oracle.com> <543BCF86.7000706@oracle.com> <543D3662.3070008@oracle.com> <543D3A9C.5020402@oracle.com> Message-ID: <543D4C44.7070105@oracle.com> Looks good to me too. Thanks for fixing it. Bertrand (not a Reviewer). On 14/10/14 17:00, Mikael Gerdin wrote: > Stefan, > > On 2014-10-14 16:42, Stefan Karlsson wrote: >> Hi, >> >> Here are the latest changes based on comments from Bertrand and Mikael: >> http://cr.openjdk.java.net/~stefank/8056240/webrev.02 >> http://cr.openjdk.java.net/~stefank/8056240/webrev.02.delta > > Looks good to me. > /Mikael > >> >> thanks, >> StefanK >> >> On 2014-10-13 15:11, Stefan Karlsson wrote: >>> Hi again, >>> >>> Latest changes after comments from Bertrand and Coleen: >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.01 >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.01.delta >>> >>> 1) Updated AccessFlags:set_on_stack to use a looping cmpxchg >>> implementation. >>> 2) Remove MetadataOnStackMark::_doit and restructure >>> ClassLoaderDataGraph::do_unloading instead. >>> 3) Move MetadataOnStackBuffer and make it a utility class named >>> ChunkedList. >>> >>> thanks, >>> StefanK >>> >>> On 2014-10-02 12:53, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> (The following patch changes HotSpot code in areas concerning GC, RT, >>>> and Compiler. So, it would be good to get reviews from all three >>>> teams.) >>>> >>>> Please, review this patch to optimize and parallelize the CodeCache >>>> part of MetadaOnStackMark. >>>> >>>> G1 performance measurements showed longer than expected remark times >>>> on an application using a lot of nmethods and Metadata. The cause for >>>> this performance regression was the call to >>>> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >>>> MetadataOnStackMark. This code path is only taken when class >>>> redefinition is used. Class redefinition is typically used in >>>> monitoring and diagnostic frameworks. >>>> >>>> With this patch we now: >>>> 1) Filter out duplicate Metadata* entries instead of storing a >>>> Metadata* per visited metadata reference. >>>> 2) Collect the set of Metadata* entries in parallel. The code >>>> piggy-backs on the parallel CodeCache cleaning task. >>>> >>>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8056240 >>>> >>>> Functional testing: >>>> JPRT, Kitchensink, parallel_class_unloading, unit tests >>>> >>>> Performance testing: >>>> CRM Fuse - where the regression was found >>>> >>>> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >>>> and Serviceability. It would be good to get some reviews from the >>>> other teams, and not only from the GC team. >>>> >>>> thanks, >>>> StefanK >>> >> -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38334 Saint Ismier, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From paul.hohensee at gmail.com Tue Oct 14 18:25:26 2014 From: paul.hohensee at gmail.com (Paul Hohensee) Date: Tue, 14 Oct 2014 14:25:26 -0400 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms Message-ID: David Holmes asked me to take a look at this >>>> There is now a new webrev with my jbyte cmpxchg changes here: >>>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01 and comment, so... The approach is good if you're going to stay with the current framework, except that I'd get rid of VM_HAS_SPECIALIZED_BYTE_CMPXCHG (#ifdef's are the devil). Just call cmpxchg_general (which should be named cmpxchgb_general or maybe cmpxchgb_unspecialized, btw) from an os_cpu file as needed. I.e., no change to atomic.inline.hpp needed. Another way to look at it is, cmpxchgb_general/unspecialized is the implementation of another specialized version of cmpxchgb, on the same abstraction level as the asm versions. If a rewrite is possible, I'd do it the way David suggests with an AbstractAtomic class from which per-platform Atomic classes are derived. That's the way VM_Version and ICache are defined. Paul From coleen.phillimore at oracle.com Tue Oct 14 18:31:09 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Oct 2014 14:31:09 -0400 Subject: RFR: 8058606 Detailed Native Memory Tracking (NMT) data is not output at VM exit In-Reply-To: <543C357C.9050009@oracle.com> References: <543C357C.9050009@oracle.com> Message-ID: <543D6BED.6010205@oracle.com> The new test code looks good. Thank you! Coleen On 10/13/14, 4:26 PM, George Triantafillou wrote: > NOTE: The original webrev for this issue has been modified as a result > of the fix for https://bugs.openjdk.java.net/browse/JDK-8059100. > > Please review this fix for JDK-8058606. As a result of the fix for > JDK-8059100, the output from the -XX:NativeMemoryTracking=detail > option now outputs detailed tracking information at VM exit. > Previously, only summary tracking information was output. The > modified test now verifies the output from both summary and detail > tracking options. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8058606 > Webrev: http://cr.openjdk.java.net/~gtriantafill/JDK-8058606/webrev/ > > > The fix was tested locally on Linux with jtreg and the JPRT hotspot > testset. > > -George From coleen.phillimore at oracle.com Tue Oct 14 18:41:11 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Oct 2014 14:41:11 -0400 Subject: RFR (XS) 8060245: update bsd version of jhelper.d to be in sync with the fix of 8009204 on solaris In-Reply-To: <543C4421.2070604@oracle.com> References: <543C4421.2070604@oracle.com> Message-ID: <543D6E47.1080002@oracle.com> Serguei, Could the jhelper.d files be put in src/os/posix/dtrace since they only differ by the mangled name for Method::vtable? Thanks, Coleen On 10/13/14, 5:29 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8060245 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8060245-dtrace.1/ > > > > Summary: > > The fix of 8009204 for jhelper.d was applied to the Solaris > version only but the bsd version must match it too. > > > Testing: > N/A: The jhelper.d is not used on bsd yet > > > Thanks, > Serguei From george.triantafillou at oracle.com Tue Oct 14 20:15:45 2014 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 14 Oct 2014 16:15:45 -0400 Subject: RFR: 8058606 Detailed Native Memory Tracking (NMT) data is not output at VM exit In-Reply-To: <543D6BED.6010205@oracle.com> References: <543C357C.9050009@oracle.com> <543D6BED.6010205@oracle.com> Message-ID: <543D8471.4080002@oracle.com> Thanks Coleen. -George On 10/14/2014 2:31 PM, Coleen Phillimore wrote: > > The new test code looks good. Thank you! > Coleen > > On 10/13/14, 4:26 PM, George Triantafillou wrote: >> NOTE: The original webrev for this issue has been modified as a >> result of the fix for https://bugs.openjdk.java.net/browse/JDK-8059100. >> >> Please review this fix for JDK-8058606. As a result of the fix for >> JDK-8059100, the output from the -XX:NativeMemoryTracking=detail >> option now outputs detailed tracking information at VM exit. >> Previously, only summary tracking information was output. The >> modified test now verifies the output from both summary and detail >> tracking options. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8058606 >> Webrev: http://cr.openjdk.java.net/~gtriantafill/JDK-8058606/webrev/ >> >> >> The fix was tested locally on Linux with jtreg and the JPRT hotspot >> testset. >> >> -George > From harold.seigel at oracle.com Tue Oct 14 20:52:07 2014 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 14 Oct 2014 16:52:07 -0400 Subject: RFR: 8058606 Detailed Native Memory Tracking (NMT) data is not output at VM exit In-Reply-To: <543D6BED.6010205@oracle.com> References: <543C357C.9050009@oracle.com> <543D6BED.6010205@oracle.com> Message-ID: <543D8CF7.3020205@oracle.com> Hi George, Your change looks good to me, also. Harold On 10/14/2014 2:31 PM, Coleen Phillimore wrote: > > The new test code looks good. Thank you! > Coleen > > On 10/13/14, 4:26 PM, George Triantafillou wrote: >> NOTE: The original webrev for this issue has been modified as a >> result of the fix for https://bugs.openjdk.java.net/browse/JDK-8059100. >> >> Please review this fix for JDK-8058606. As a result of the fix for >> JDK-8059100, the output from the -XX:NativeMemoryTracking=detail >> option now outputs detailed tracking information at VM exit. >> Previously, only summary tracking information was output. The >> modified test now verifies the output from both summary and detail >> tracking options. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8058606 >> Webrev: http://cr.openjdk.java.net/~gtriantafill/JDK-8058606/webrev/ >> >> >> The fix was tested locally on Linux with jtreg and the JPRT hotspot >> testset. >> >> -George > From coleen.phillimore at oracle.com Tue Oct 14 21:00:34 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Oct 2014 17:00:34 -0400 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <543B9844.1070003@oracle.com> References: <542D2EC1.5030303@oracle.com> <5438476B.1060003@oracle.com> <543B9844.1070003@oracle.com> Message-ID: <543D8EF2.8040007@oracle.com> Stefan, I've reviewed the new version of the code (02) and have some comments. Thank you for all the work resolving my concerns. The comments are inline. On 10/13/14, 5:15 AM, Stefan Karlsson wrote: > Hi Coleen, > > On 2014-10-10 22:54, Coleen Phillimore wrote: >> >> Hi Stefan, >> >> Thank you for your patience. Some review comments: >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/classfile/metadataOnStackMark.hpp.udiff.html >> >> ... > I guess you are opposing code in metadataOnStackMark, rather than > saying that this is complicated code? Well, both, but yes. I want to think about MetadataOnStackMark in this file. Thank you for adding chunkedList. It seems like it could be generally useful. > >> Is it trying to add as chunked list? > > Yes. > >> Can we add a utility for this instead of tying it to the >> MetadataOnStackMark functionality? > > We could. That would make it possible to reuse the code, but the code > would be a tiny bit more non-obvious. I can try to implement this as a > generic template data structure. > >> >> In this file, what is _doit and why? This looks really strange. Can >> you add a comment why sometimes doit is false and sometimes doit is >> true? Is there a way to encapsulate this in a function as it's >> supposed to be a scoped object. > > ... > Sounds good to me. Should has_metadata_to_deallocate always be true in > the current code? I don't want to add code to check if Metadata has > been allocated. I think that should be handled as a separate RFE. Thank you for adding this code this way. I think conditional on clean_alive is fine. > >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html >> >> >> + if (JvmtiExport::has_redefined_a_class()) { >> + InstanceKlass::purge_previous_versions(ik); >> + } >> >> >> purge previous versions requires the on_stack bits to be set. Is this >> true here? > > Yes, that's what the MetadataOnStackMark in > ConcurrentMark::weakRefsWorkParallelPart (concurrentMark.cpp) is used > for. > >> It seems very far away from the other code to me to be able to tell. > > Yes, I agree. It's non-obvious, but I couldn't figure out a good way > to solve it. In similar situations, I've passed down the instance of > the class, in this case MetadataOnStackMark, to the code that uses it. > Just to ensure that we have an instance setup when calling the code. > We've discussed that approach a couple of years ago, but you didn't > like it then. We have similar problems with ResourceMarks and > HandleMarks, but code using Handles or Resource allocated memory > asserts that those are in place. Maybe we should do the same for > on_stack? Yes, I remember some other code from the past. I don't think it's worth having a metadata-on-stack-mark assert. It's just far away. We'll have to see how hard this is to maintain going forward. > >> Why can't this go in the same place as the free_deallocate_lists? > > Because purge_previous_versions can be called in parallel, whereas > free_deallocate_lists needs to be called when we are sure that all > calls to purge_previous_versions have been called. So, > free_deallocate_lists was added as a separate phase after the parallel > unloading code. I can add comments about this. If you did purge_previous_versions and free_deallocate lists together in clean_metaspaces() would it really hurt performance? > >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/code/nmethod.cpp.udiff.html >> >> >> I really don't like that the on-stack bit marks are done at the same >> time as clean_ic_if_metadata_is_dead. They are for different purposes. > > Yes, I agree. It's an abstraction violation, but I've done so that we > don't have to execute the expensive reloc iter lookup code more than > once. Maybe I should use a callback instead, so that we don't > hard-wire the MetadataOnStackMark code into the > clean_ic_if_metadata_is_dead function? > >> Also, this seems to mark metadata for methods that are unloaded as >> well as ones that survive unloading. I guess this wouldn't prevent >> methods from being unloaded but seems unnecessary callbacks to >> mark_on_stack. Maybe I'm not reading this right though. > > I think you are right. On the other hand, previously we visited all > Metadata in the entire code cache, and we didn't do this separation. > I'd like this to be changes as a follow-up fix, so that I don't > introduce a regression here. I think since the abstraction has been broken that metadata_do() should be rewritten so that it shares the code that duplicates the walks in nmethod::mark_metadata_on_stack_at nmethod::mark_metadata_on_stack_non_relocs() Rather than sharing code with CheckClass, which we didn't like because it had to have a static _is_alive. Then it would be easier to check that only old methods are marked here. I can file this bug and fix it, since I have multiple bugs in this right now to fix. > >> I thought you couldn't do the unloading walk with the mark-on-stack >> walk? > > There are two separate phases of the unloading walk and a barrier in > between those phases. The mark-on-stack walk happens in the first > phase, and the purge_previous_version happens in the second phase. The > free_deallocate_lists is called in a serial phase after that. > >> Also, we actually only have to mark OLD methods in the code cache >> which would greatly reduce the callbacks. I could make this in a >> separate change as I have this change in a private repository. > > Sounds good. You mean OLD as in a previous version plus the Methods > that were put on the deallocate_free_list? No, OLD is only methods that are redefined. You can get other methods on the deallocate_list from relocating jsr/ret from ancient classfiles. Also there are constant pools on the deallocate_list from lambdas. Perhaps it would be good to separate these things. > >> >> I think you should have a compiler reviewer comment on the nmethod >> code though. >> >> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/utilities/accessFlags.cpp.udiff.html >> >> >> I don't know why this needs to be different than the atomic_set_bits >> function. > > Previously, we didn't care if the Metadata had already been marked. > They were just blindly recorded by MetadataOnStackMark. That caused > the number of stored elements to be orders of magnitude larger than > they had to be. To fix this, I only record Metadata if they have not > already been added. I need this new function to tell if the current > call, by the current thread, was setting the mark bit. The thread that > succeeds with this marking, will be the one that records the Metadata > in the array (or now, chunked list). > > Bertrand had comments about the usage of atomic_try_set_bits, so I > have a version that uses a slightly altered copy of > AccessFlags::atomic_set_bits. > >> I should have made on_stack be a flag in Method* rather than in >> access flags. > > Sounds like a good follow-up fix. Yes, I'll file a bug for that also so I can clean this up. The only comment I had was to do purge_previous_versions with free_deallocate_list. But if it's shown to have bad performance, I'm fine with the way it is. I think purge_previous_versions does work that could be done earlier in class redefinition, which could be a third RFE from this. If we could make purge_previous_versions do little or nothing, these could go together, right? Thanks for the code changes and comments. Coleen > >> >> There's a lot here. I'm glad it helps performance and making the >> code cache walk parallel is a really good change. > > Thanks Coleen. > > StefanK > >> >> Thanks, >> Coleen >> >> >> On 10/2/14, 6:53 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> (The following patch changes HotSpot code in areas concerning GC, >>> RT, and Compiler. So, it would be good to get reviews from all three >>> teams.) >>> >>> Please, review this patch to optimize and parallelize the CodeCache >>> part of MetadaOnStackMark. >>> >>> G1 performance measurements showed longer than expected remark times >>> on an application using a lot of nmethods and Metadata. The cause >>> for this performance regression was the call to >>> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >>> MetadataOnStackMark. This code path is only taken when class >>> redefinition is used. Class redefinition is typically used in >>> monitoring and diagnostic frameworks. >>> >>> With this patch we now: >>> 1) Filter out duplicate Metadata* entries instead of storing a >>> Metadata* per visited metadata reference. >>> 2) Collect the set of Metadata* entries in parallel. The code >>> piggy-backs on the parallel CodeCache cleaning task. >>> >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8056240 >>> >>> Functional testing: >>> JPRT, Kitchensink, parallel_class_unloading, unit tests >>> >>> Performance testing: >>> CRM Fuse - where the regression was found >>> >>> The patch changes HotSpot code in areas concerning GC, RT, Compiler, >>> and Serviceability. It would be good to get some reviews from the >>> other teams, and not only from the GC team. >>> >>> thanks, >>> StefanK >> > From george.triantafillou at oracle.com Wed Oct 15 00:34:47 2014 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 14 Oct 2014 20:34:47 -0400 Subject: RFR: 8058606 Detailed Native Memory Tracking (NMT) data is not output at VM exit In-Reply-To: <543D8CF7.3020205@oracle.com> References: <543C357C.9050009@oracle.com> <543D6BED.6010205@oracle.com> <543D8CF7.3020205@oracle.com> Message-ID: <543DC127.3040902@oracle.com> Thanks Harold. -George On 10/14/2014 4:52 PM, harold seigel wrote: > Hi George, > > Your change looks good to me, also. > > Harold > On 10/14/2014 2:31 PM, Coleen Phillimore wrote: >> >> The new test code looks good. Thank you! >> Coleen >> >> On 10/13/14, 4:26 PM, George Triantafillou wrote: >>> NOTE: The original webrev for this issue has been modified as a >>> result of the fix for https://bugs.openjdk.java.net/browse/JDK-8059100. >>> >>> Please review this fix for JDK-8058606. As a result of the fix for >>> JDK-8059100, the output from the -XX:NativeMemoryTracking=detail >>> option now outputs detailed tracking information at VM exit. >>> Previously, only summary tracking information was output. The >>> modified test now verifies the output from both summary and detail >>> tracking options. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8058606 >>> Webrev: http://cr.openjdk.java.net/~gtriantafill/JDK-8058606/webrev/ >>> >>> >>> The fix was tested locally on Linux with jtreg and the JPRT hotspot >>> testset. >>> >>> -George >> > From david.holmes at oracle.com Wed Oct 15 00:41:35 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Oct 2014 10:41:35 +1000 Subject: RFR: JDK-8059586: hs_err report should treat redirected core pattern. In-Reply-To: <543CF553.80601@gmail.com> References: <542C8274.3010809@gmail.com> <54338B70.9080709@oracle.com> <543B1FD6.3000200@oracle.com> <543CF553.80601@gmail.com> Message-ID: <543DC2BF.9050407@oracle.com> On 14/10/2014 8:05 PM, Yasumasa Suenaga wrote: > Hi David, > > Thank you for comments! > I've uploaded new webrev. Could you review it again? > http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.01/ > > I am an author of jdk9. So I cannot commit it. > Could you be a sponsor for this enhancement? > > >> In which case that should be handled by the linux specific >> get_core_path() function. > > Agree. > So I implemented it in os_linux.cpp . > But part of format characters (%P: global pid, %s: signal, %t dump time) > are not processed > in this function because I think these parameters are difficult to > handle in it. > > %P: I could not find API for this. > %s: We have to change arguments of get_core_path() . > %t: This parameter means timestamp of coredump. It is decided in Kernel. > > >> Fixing this means changing all the os_posix using platforms. But your >> patch is not about this part. :) > > I moved os::check_or_create_dump() to each OS implementations (AIX, BSD, > Solaris, Linux) . > So I can write Linux specific code to check_or_create_dump() . > As a result, I could remove "#ifdef LINUX" from os_posix.cpp :-) I wasn't suggesting that you make such a change though because it is large and disruptive. The simple handling of the | part of core_pattern was basically ok. Expanding the get_core_path in os_linux.cpp to handle the core_pattern may be okay (but I don't know enough about it to validate everything). Unfactoring check_or_create_dump is a step backwards in terms of code sharing. Sorry this has grown too large for me to deal with right now. David ----- > >> Though I'm unclear whether it both invokes the program and creates a >> core dump file; or just invokes the program? > > If '|' is set, Linux kernel will just redirect core image to user process. > Kernel documentation says as below: > ------------ > . If the first character of the pattern is a '|', the kernel will treat > the rest of the pattern as a command to run. The core dump will be > written to the standard input of that program instead of to a file. > ------------ > > And implementation of coredump (do_coredump()) follows to it. > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/coredump.c > > > In case of ABRT, ABRT dumps core image to default location > (/core.) > if user set unlimited to resource limit of core (ulimit -c) . > https://github.com/abrt/abrt/blob/master/src/hooks/abrt-hook-ccpp.c > > >> A few style nits - you need spaces around keywords and before braces >> I also suggest saying "Core dumps may be processed with ..." rather >> than "treated". >> And as you don't do anything in the non-redirect case I suggest >> collapsing this: > > I've fixed them. > > > Thanks, > > Yasumasa > > > (2014/10/13 9:41), David Holmes wrote: >> Hi Yasumasa, >> >> On 7/10/2014 8:48 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> Sorry for my English. >>> >>> I want to propose that JVM should create message according to core >>> pattern (/proc/sys/kernel/core_pattern) . >>> So I filed it to JBS and created a patch. >> >> So I've had a quick look at this core_pattern business and it seems to >> me that there are two aspects to this. >> >> First, without the leading |, the entry in the core_pattern file is a >> naming pattern for the core file. In which case that should be handled >> by the linux specific get_core_path() function. Though that in itself >> can't fully report the expected name, as part of it is provided in the >> shared code in os::check_or_create_dump. Fixing this means changing >> all the os_posix using platforms. But your patch is not about this >> part. :) >> >> Second, with a leading | the core_pattern is actually the name of a >> program to execute when the program is about to core dump, and that is >> what you report with your patch. Though I'm unclear whether it both >> invokes the program and creates a core dump file; or just invokes the >> program? >> >> So with regards to this second part your patch seems functionally ok. >> I do dislike having a big chunk of linux specific code in this "posix" >> support file but ... >> >> A few style nits - you need spaces around keywords and before braces eg: >> >> if(x){ >> >> should be >> >> if (x) { >> >> I also suggest saying "Core dumps may be processed with ..." rather >> than "treated". >> >> And as you don't do anything in the non-redirect case I suggest >> collapsing this: >> >> 83 is_redirect = core_pattern[0] == '|'; >> 84 } >> 85 >> 86 if(is_redirect){ >> 87 jio_snprintf(buffer, bufferSize, >> 88 "Core dumps may be treated with \"%s\"", >> &core_pattern[1]); >> 89 } >> >> to just >> >> 83 if (core_pattern[0] == '|') { // redirect >> 84 jio_snprintf(buffer, bufferSize, "Core dumps may be >> processed with \"%s\"", &core_pattern[1]); >> 85 } >> 86 } >> >> Comments from other runtime folk appreciated. >> >> Thanks, >> David >> >>> Thanks, >>> >>> Yasumasa >>> >>> 2014/10/07 15:43 "David Holmes" >> >: >>> >>> Hi Yasumasa, >>> >>> I'm sorry but I don't understand what you are proposing. When you >>> say >>> "treat" do you mean "create"? Otherwise what do you mean by >>> "treated"? >>> >>> Thanks, >>> David >>> >>> On 2/10/2014 8:38 AM, Yasumasa Suenaga wrote: >>> > I'm in Hackergarten @ JavaOne :-) >>> > >>> > >>> > Hi all, >>> > >>> > I would like to enhance the messages in hs_err report. >>> > Modern Linux kernel can treat core dump with user process >>> (e.g. ABRT) >>> > However, hs_err report cannot detect it. >>> > >>> > I think that hs_err report should output messages as below: >>> > ------------- >>> > Failed to write core dump. Core dumps may be treated with >>> "/usr/sbin/chroot /proc/%P/root /usr/libexec/abrt-hook-ccpp %s %c %p >>> %u %g %t e" >>> > ------------- >>> > >>> > I've uploaded webrev of this enhancement. >>> > Could you review it? >>> > >>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.00/ >>> > >>> > This patch works fine on Fedora20 x86_64. >>> > >>> > >>> > >>> > Thanks, >>> > >>> > Yasumasa >>> > >>> From serguei.spitsyn at oracle.com Wed Oct 15 05:00:38 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Oct 2014 22:00:38 -0700 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543BA4DB.3000104@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> Message-ID: <543DFF76.80605@oracle.com> Hi Andreas, Sorry I did not reply on this early. I assumed, it is a thumbs up from me. Just wanted make it clean now. :) Thanks, Serguei On 10/13/14 3:09 AM, Andreas Eriksson wrote: > Hi Serguei, thanks for looking at this! > > I'll make sure to fix the style problems. > For the symbolic names / #defines, please see my answer to Coleen. > > Regards, > Andreas > > On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >> Hi Andreas, >> >> >> Thank you for fixing this issue! >> The fix looks nice, I do not see any logical issues. >> >> >> Only minor comments... >> >> >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> >> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >> 2785 } // end skip_type_annotation_target >> 2844 } // end skip_type_annotation_type_path >> >> The ')' is missed at 2281, 2315. >> The 2397-2844 are inconsistent with the 2345 and other function-end >> comments in the file. >> >> >> 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >> 2336 byte_i, "method_info", THREAD)) { >> . . . >> 2378 if (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >> 2379 byte_i_ref, location_mesg, THREAD)) { >> . . . >> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >> 2428 byte_i_ref, location_mesg, THREAD)) { >> 2429 return false; >> 2430 } >> 2431 >> 2432 if (!skip_type_annotation_type_path(type_annotations_typeArray, >> 2433 byte_i_ref, THREAD)) { >> 2434 return false; >> 2435 } >> 2436 >> 2437 if (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >> 2438 byte_i_ref, THREAD)) { >> 2439 return false; >> Wrong indent at 2336, 2379, etc. >> >> >> I also concur with Coleen that it would be good to define and use >> symbolic names for the hexa-decimal constants used in the fix. >> >> >> >> test/runtime/RedefineTests/RedefineAnnotations.java >> >> Java indent must be 4, not 2. >> >> 253 @TestAnn(site="returnTypeAnnotation") Class typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") TypeAnnotatedTestClass arg) >> >> The line is too long. >> >> >> 143 } >> 144 public static void main(String argv[]) { >> . . . >> 209 } >> 210 private static void checkAnnotations(AnnotatedType p) { >> 211 checkAnnotations(p.getAnnotations()); >> 212 } >> 213 private static void checkAnnotations(AnnotatedType[] annoTypes) { >> 214 for (AnnotatedType p : annoTypes) checkAnnotations(p.getAnnotations()); >> 215 } >> 216 private static void checkAnnotations(Class c) { >> . . . >> 257 } >> 258 public void run() {} >> >> Adding empty lines between method definitions would improve >> readability. >> >> >> Thanks, >> Serguei >> >> >> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>> Hi all, >>> >>> Please review this patch to RedefineClasses to allow type >>> annotations to be preserved. >>> >>> Summary: >>> During redefine / retransform class the constant pool indexes can >>> change. >>> Since annotations have indexes into the constant pool these indexes >>> need to be rewritten. >>> This is already done for regular annotations, but not for type >>> annotations. >>> This patch adds code to add this rewriting for the type annotations >>> as well. >>> The patch also contains minor changes to ClassFileReconstituter, to >>> make sure that type annotations are preserved during a redefine / >>> retransform class operation. >>> It also has a test that uses asm to change constant pool indexes >>> through a retransform, and then verifies that type annotations are >>> preserved. >>> >>> Detail: >>> A type annotation struct consists of some target information and a >>> type path, followed by a regular annotation struct. >>> Constant pool indexes are only present in the regular annotation >>> struct. >>> The added code skips over the type annotation specific parts, then >>> calls previously existing code to rewrite constant pool indexes in >>> the regular annotation struct. >>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info >>> about the type annotation struct. >>> >>> JPRT with the new test passes without failures on all platforms. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>> >>> Regards >>> Andreas >> > From serguei.spitsyn at oracle.com Wed Oct 15 05:48:30 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Oct 2014 22:48:30 -0700 Subject: RFR (XS) 8060245: update bsd version of jhelper.d to be in sync with the fix of 8009204 on solaris In-Reply-To: <543D6E47.1080002@oracle.com> References: <543C4421.2070604@oracle.com> <543D6E47.1080002@oracle.com> Message-ID: <543E0AAE.2060705@oracle.com> Hi Coleen, Thank you for looking at it! Do you mean to move the jhelper.d + deps from bsd to posix? I don't know how to answer your question. What I understand is the jhelper.d has never been tested on bsd platform. It can be a reason why there is almost no difference with solaris yet. In order to use the jhelper.d the dtrace framework on bsd (or posix) must support helpers in a similar way as it is done on solaris and implement jstack action. I'd do as minimal as possible here until any commitment is seen in this area. It is not clear why the jhelper.d was ported on bsd in the first place. Please, let me know what is your opinion. Thanks, Serguei In general, I have a question On 10/14/14 11:41 AM, Coleen Phillimore wrote: > > Serguei, > > Could the jhelper.d files be put in src/os/posix/dtrace since they > only differ by the mangled name for Method::vtable? > > Thanks, > Coleen > > > On 10/13/14, 5:29 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8060245 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8060245-dtrace.1/ >> >> >> >> Summary: >> >> The fix of 8009204 for jhelper.d was applied to the Solaris >> version only but the bsd version must match it too. >> >> >> Testing: >> N/A: The jhelper.d is not used on bsd yet >> >> >> Thanks, >> Serguei > From vladimir.x.ivanov at oracle.com Wed Oct 15 11:18:39 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 15 Oct 2014 15:18:39 +0400 Subject: [8u40] Bulk backport request: 8058825, 8059556, 8058828 Message-ID: <543E580F.3020207@oracle.com> This is a bulk request to backport the following changes into 8u40. They were integrated into 9 and cleanly apply to 8u-dev. (1) 8058825: EA: ConnectionGraph::split_unique_types does incorrect scalar replacement https://bugs.openjdk.java.net/browse/JDK-8058825 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/19c71767e456 (2) 8059556: C2: crash while inlining MethodHandle invocation w/ null receiver https://bugs.openjdk.java.net/browse/JDK-8059556 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9c4780bccc23 (3) 8058828: Wrong ciConstant type for arrays from ConstantPool::_resolved_reference https://bugs.openjdk.java.net/browse/JDK-8058828 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/677d7ff6a1cf Best regards, Vladimir Ivanov From andreas.eriksson at oracle.com Wed Oct 15 11:20:56 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 15 Oct 2014 13:20:56 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543D28EA.7040703@oracle.com> References: <54368BC1.3000905@oracle.com> <5437F1A7.7010600@oracle.com> <543BA38F.10509@oracle.com> <543D28EA.7040703@oracle.com> Message-ID: <543E5898.2010702@oracle.com> Great, thanks! /Andreas On 2014-10-14 15:45, Coleen Phillimore wrote: > > Andreas, This is ok about the case numbers then. I agree it's not > worth creating new enum type for them since they are all commented. > (sorry for top-posting but this is my only comment). > > You have my code review. Thank you for adding this. > > Coleen > > On 10/13/14, 6:03 AM, Andreas Eriksson wrote: >> Hi Coleen, thanks for looking at this! >> See answers inline. >> >> On 2014-10-10 16:48, Coleen Phillimore wrote: >>> >>> Andreas, >>> This is excellent work! It looks really good. Some comments. >>> >>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >>> >>> >>> + u1 target_type = type_annotations_typeArray->at(byte_i_ref); >>> + byte_i_ref += 1; >>> + RC_TRACE_WITH_THREAD(0x02000000, THREAD, ("target_type=0x%.2x", >>> target_type)); >>> + RC_TRACE_WITH_THREAD(0x02000000, THREAD, ("location=%s", >>> location_mesg)); >>> + >>> + // Skip over target_info >>> + switch (target_type) { >>> + case 0x00: >>> + // kind: type parameter declaration of generic class or interface >>> + // location: ClassFile >>> + case 0x01: >>> + // kind: type parameter declaration of generic method or >>> constructor >>> + // location: method_info >>> >>> Are there any #defines that make these numbers into some symbolic >>> values? >>> >>> These comments are good in case there aren't. >>> >> >> Unfortunately, there are no #defines for these numbers that I could >> find. >> I don't think creating symbolic names is worth it either, since the >> only unique way they are referred to in the VM spec is this verbose >> 'kind' field that I have included in the comments. >> Location combined with target_info is unique for 0x00 to 0x17, but >> not for 0x40 and up. One could maybe create a define by combining >> location name, target_info name and parts of the kind text, but I'm >> not sure this would increase readability. I think having these >> comments is better. >> >>> + case 0x17: >>> + // kind: type in throws clause of method or constructor >>> + // location: method_info >>> >>> >>> I can't find anything wrong. I don't really understand the test >>> that well so hopefully someone that knows type annotations can look >>> at it also. Maybe include lang tools and Joel and Eric? >>> >> >> Joel has been looking at this review, and he gave me some feedback on >> the test offline. I'll rewrite parts of it and send out a new review >> when I'm done. >> >> Thanks, >> Andreas >> >>> This code is needed because we don't replace the InstanceKlass when >>> redefining classes and rewrite the constant pool. If we were able >>> to replace the InstanceKlass instead, we wouldn't need to do all >>> this work. We're evaluating this at the moment, but have no real >>> progress, so thank you for fixing this! >>> >>> Thanks, >>> Coleen >>> >>> On 10/9/14, 9:21 AM, Andreas Eriksson wrote: >>>> Hi all, >>>> >>>> Please review this patch to RedefineClasses to allow type >>>> annotations to be preserved. >>>> >>>> Summary: >>>> During redefine / retransform class the constant pool indexes can >>>> change. >>>> Since annotations have indexes into the constant pool these indexes >>>> need to be rewritten. >>>> This is already done for regular annotations, but not for type >>>> annotations. >>>> This patch adds code to add this rewriting for the type annotations >>>> as well. >>>> The patch also contains minor changes to ClassFileReconstituter, to >>>> make sure that type annotations are preserved during a redefine / >>>> retransform class operation. >>>> It also has a test that uses asm to change constant pool indexes >>>> through a retransform, and then verifies that type annotations are >>>> preserved. >>>> >>>> Detail: >>>> A type annotation struct consists of some target information and a >>>> type path, followed by a regular annotation struct. >>>> Constant pool indexes are only present in the regular annotation >>>> struct. >>>> The added code skips over the type annotation specific parts, then >>>> calls previously existing code to rewrite constant pool indexes in >>>> the regular annotation struct. >>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info >>>> about the type annotation struct. >>>> >>>> JPRT with the new test passes without failures on all platforms. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>> >>>> Regards >>>> Andreas >>> >> > From andreas.eriksson at oracle.com Wed Oct 15 11:22:50 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 15 Oct 2014 13:22:50 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543DFF76.80605@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> Message-ID: <543E590A.4020304@oracle.com> Thanks Serguei. I have a question about the if-blocks that had the wrong indent: 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, 2336 byte_i, "method_info", THREAD)) { How should I indent them? /Andreas On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: > Hi Andreas, > > Sorry I did not reply on this early. > I assumed, it is a thumbs up from me. > Just wanted make it clean now. :) > > Thanks, > Serguei > > On 10/13/14 3:09 AM, Andreas Eriksson wrote: >> Hi Serguei, thanks for looking at this! >> >> I'll make sure to fix the style problems. >> For the symbolic names / #defines, please see my answer to Coleen. >> >> Regards, >> Andreas >> >> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>> Hi Andreas, >>> >>> >>> Thank you for fixing this issue! >>> The fix looks nice, I do not see any logical issues. >>> >>> >>> Only minor comments... >>> >>> >>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>> >>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>> 2785 } // end skip_type_annotation_target >>> 2844 } // end skip_type_annotation_type_path >>> >>> The ')' is missed at 2281, 2315. >>> The 2397-2844 are inconsistent with the 2345 and other function-end >>> comments in the file. >>> >>> >>> 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>> 2336 byte_i, "method_info", THREAD)) { >>> . . . >>> 2378 if (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>> 2379 byte_i_ref, location_mesg, THREAD)) { >>> . . . >>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>> 2428 byte_i_ref, location_mesg, THREAD)) { >>> 2429 return false; >>> 2430 } >>> 2431 >>> 2432 if (!skip_type_annotation_type_path(type_annotations_typeArray, >>> 2433 byte_i_ref, THREAD)) { >>> 2434 return false; >>> 2435 } >>> 2436 >>> 2437 if (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>> 2438 byte_i_ref, THREAD)) { >>> 2439 return false; >>> Wrong indent at 2336, 2379, etc. >>> >>> >>> I also concur with Coleen that it would be good to define and use >>> symbolic names for the hexa-decimal constants used in the fix. >>> >>> >>> >>> test/runtime/RedefineTests/RedefineAnnotations.java >>> >>> Java indent must be 4, not 2. >>> >>> 253 @TestAnn(site="returnTypeAnnotation") Class typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") TypeAnnotatedTestClass arg) >>> >>> The line is too long. >>> >>> >>> 143 } >>> 144 public static void main(String argv[]) { >>> . . . >>> 209 } >>> 210 private static void checkAnnotations(AnnotatedType p) { >>> 211 checkAnnotations(p.getAnnotations()); >>> 212 } >>> 213 private static void checkAnnotations(AnnotatedType[] annoTypes) { >>> 214 for (AnnotatedType p : annoTypes) checkAnnotations(p.getAnnotations()); >>> 215 } >>> 216 private static void checkAnnotations(Class c) { >>> . . . >>> 257 } >>> 258 public void run() {} >>> >>> Adding empty lines between method definitions would improve >>> readability. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>> Hi all, >>>> >>>> Please review this patch to RedefineClasses to allow type >>>> annotations to be preserved. >>>> >>>> Summary: >>>> During redefine / retransform class the constant pool indexes can >>>> change. >>>> Since annotations have indexes into the constant pool these indexes >>>> need to be rewritten. >>>> This is already done for regular annotations, but not for type >>>> annotations. >>>> This patch adds code to add this rewriting for the type annotations >>>> as well. >>>> The patch also contains minor changes to ClassFileReconstituter, to >>>> make sure that type annotations are preserved during a redefine / >>>> retransform class operation. >>>> It also has a test that uses asm to change constant pool indexes >>>> through a retransform, and then verifies that type annotations are >>>> preserved. >>>> >>>> Detail: >>>> A type annotation struct consists of some target information and a >>>> type path, followed by a regular annotation struct. >>>> Constant pool indexes are only present in the regular annotation >>>> struct. >>>> The added code skips over the type annotation specific parts, then >>>> calls previously existing code to rewrite constant pool indexes in >>>> the regular annotation struct. >>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info >>>> about the type annotation struct. >>>> >>>> JPRT with the new test passes without failures on all platforms. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>> >>>> Regards >>>> Andreas >>> >> > From stefan.karlsson at oracle.com Wed Oct 15 12:08:33 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 15 Oct 2014 14:08:33 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <543D8EF2.8040007@oracle.com> References: <542D2EC1.5030303@oracle.com> <5438476B.1060003@oracle.com> <543B9844.1070003@oracle.com> <543D8EF2.8040007@oracle.com> Message-ID: <543E63C1.2030905@oracle.com> Hi Coleen, On 2014-10-14 23:00, Coleen Phillimore wrote: > > Stefan, I've reviewed the new version of the code (02) and have some > comments. Thank you for all the work resolving my concerns. > > The comments are inline. > > On 10/13/14, 5:15 AM, Stefan Karlsson wrote: >> Hi Coleen, >> >> On 2014-10-10 22:54, Coleen Phillimore wrote: >>> >>> Hi Stefan, >>> >>> Thank you for your patience. Some review comments: >>> >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/classfile/metadataOnStackMark.hpp.udiff.html >>> >>> > ... >> I guess you are opposing code in metadataOnStackMark, rather than >> saying that this is complicated code? > > Well, both, but yes. I want to think about MetadataOnStackMark in > this file. Thank you for adding chunkedList. It seems like it could > be generally useful. > >> >>> Is it trying to add as chunked list? >> >> Yes. >> >>> Can we add a utility for this instead of tying it to the >>> MetadataOnStackMark functionality? >> >> We could. That would make it possible to reuse the code, but the code >> would be a tiny bit more non-obvious. I can try to implement this as >> a generic template data structure. >> >>> >>> In this file, what is _doit and why? This looks really strange. >>> Can you add a comment why sometimes doit is false and sometimes doit >>> is true? Is there a way to encapsulate this in a function as it's >>> supposed to be a scoped object. >> >> > ... >> Sounds good to me. Should has_metadata_to_deallocate always be true >> in the current code? I don't want to add code to check if Metadata >> has been allocated. I think that should be handled as a separate RFE. > > Thank you for adding this code this way. I think conditional on > clean_alive is fine. >> >>> >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html >>> >>> >>> + if (JvmtiExport::has_redefined_a_class()) { >>> + InstanceKlass::purge_previous_versions(ik); >>> + } >>> >>> >>> purge previous versions requires the on_stack bits to be set. Is >>> this true here? >> >> Yes, that's what the MetadataOnStackMark in >> ConcurrentMark::weakRefsWorkParallelPart (concurrentMark.cpp) is used >> for. >> >>> It seems very far away from the other code to me to be able to tell. >> >> Yes, I agree. It's non-obvious, but I couldn't figure out a good way >> to solve it. In similar situations, I've passed down the instance of >> the class, in this case MetadataOnStackMark, to the code that uses >> it. Just to ensure that we have an instance setup when calling the >> code. We've discussed that approach a couple of years ago, but you >> didn't like it then. We have similar problems with ResourceMarks and >> HandleMarks, but code using Handles or Resource allocated memory >> asserts that those are in place. Maybe we should do the same for >> on_stack? > > Yes, I remember some other code from the past. I don't think it's > worth having a metadata-on-stack-mark assert. It's just far away. > We'll have to see how hard this is to maintain going forward. >> >>> Why can't this go in the same place as the free_deallocate_lists? >> >> Because purge_previous_versions can be called in parallel, whereas >> free_deallocate_lists needs to be called when we are sure that all >> calls to purge_previous_versions have been called. So, >> free_deallocate_lists was added as a separate phase after the >> parallel unloading code. I can add comments about this. > > If you did purge_previous_versions and free_deallocate lists together > in clean_metaspaces() would it really hurt performance? I can redo that investigation after this change has been pushed. > >> >>> >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/code/nmethod.cpp.udiff.html >>> >>> >>> I really don't like that the on-stack bit marks are done at the same >>> time as clean_ic_if_metadata_is_dead. They are for different >>> purposes. >> >> Yes, I agree. It's an abstraction violation, but I've done so that we >> don't have to execute the expensive reloc iter lookup code more than >> once. Maybe I should use a callback instead, so that we don't >> hard-wire the MetadataOnStackMark code into the >> clean_ic_if_metadata_is_dead function? >> >>> Also, this seems to mark metadata for methods that are unloaded as >>> well as ones that survive unloading. I guess this wouldn't prevent >>> methods from being unloaded but seems unnecessary callbacks to >>> mark_on_stack. Maybe I'm not reading this right though. >> >> I think you are right. On the other hand, previously we visited all >> Metadata in the entire code cache, and we didn't do this separation. >> I'd like this to be changes as a follow-up fix, so that I don't >> introduce a regression here. > > I think since the abstraction has been broken that metadata_do() > should be rewritten so that it shares the code that duplicates the > walks in > nmethod::mark_metadata_on_stack_at > nmethod::mark_metadata_on_stack_non_relocs() You mean something like this?: http://cr.openjdk.java.net/~stefank/8056240/webrev.02.do_metadata.delta http://cr.openjdk.java.net/~stefank/8056240/webrev.02.do_metadata > > > Rather than sharing code with CheckClass, which we didn't like because > it had to have a static _is_alive. We used the static is_alive because nmethod::method_do takes a function pointer. We wouldn't need to do that if nmethod::method_do took a MetadataClosure, that could hold the _is_alive instance. > > Then it would be easier to check that only old methods are marked here. > > I can file this bug and fix it, since I have multiple bugs in this > right now to fix. OK. >> >>> I thought you couldn't do the unloading walk with the >>> mark-on-stack walk? >> >> There are two separate phases of the unloading walk and a barrier in >> between those phases. The mark-on-stack walk happens in the first >> phase, and the purge_previous_version happens in the second phase. >> The free_deallocate_lists is called in a serial phase after that. >> >>> Also, we actually only have to mark OLD methods in the code cache >>> which would greatly reduce the callbacks. I could make this in a >>> separate change as I have this change in a private repository. >> >> Sounds good. You mean OLD as in a previous version plus the Methods >> that were put on the deallocate_free_list? > > No, OLD is only methods that are redefined. You can get other methods > on the deallocate_list from relocating jsr/ret from ancient > classfiles. Also there are constant pools on the deallocate_list from > lambdas. Perhaps it would be good to separate these things. OK. >> >>> >>> I think you should have a compiler reviewer comment on the nmethod >>> code though. >>> >>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/src/share/vm/utilities/accessFlags.cpp.udiff.html >>> >>> >>> I don't know why this needs to be different than the atomic_set_bits >>> function. >> >> Previously, we didn't care if the Metadata had already been marked. >> They were just blindly recorded by MetadataOnStackMark. That caused >> the number of stored elements to be orders of magnitude larger than >> they had to be. To fix this, I only record Metadata if they have not >> already been added. I need this new function to tell if the current >> call, by the current thread, was setting the mark bit. The thread >> that succeeds with this marking, will be the one that records the >> Metadata in the array (or now, chunked list). >> >> Bertrand had comments about the usage of atomic_try_set_bits, so I >> have a version that uses a slightly altered copy of >> AccessFlags::atomic_set_bits. >> >>> I should have made on_stack be a flag in Method* rather than in >>> access flags. >> >> Sounds like a good follow-up fix. > > Yes, I'll file a bug for that also so I can clean this up. > > The only comment I had was to do purge_previous_versions with > free_deallocate_list. But if it's shown to have bad performance, I'm > fine with the way it is. OK. I'll leave it as it is, and then I can investigate this more in a separate cleanup CR. > > I think purge_previous_versions does work that could be done earlier > in class redefinition, which could be a third RFE from this. If we > could make purge_previous_versions do little or nothing, these could > go together, right? Sounds reasonable. > > Thanks for the code changes and comments. Thanks for reviewing. StefanK > > Coleen > > >> >>> >>> There's a lot here. I'm glad it helps performance and making the >>> code cache walk parallel is a really good change. >> >> Thanks Coleen. >> >> StefanK >> >>> >>> Thanks, >>> Coleen >>> >>> >>> On 10/2/14, 6:53 AM, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> (The following patch changes HotSpot code in areas concerning GC, >>>> RT, and Compiler. So, it would be good to get reviews from all >>>> three teams.) >>>> >>>> Please, review this patch to optimize and parallelize the CodeCache >>>> part of MetadaOnStackMark. >>>> >>>> G1 performance measurements showed longer than expected remark >>>> times on an application using a lot of nmethods and Metadata. The >>>> cause for this performance regression was the call to >>>> CodeCache::alive_nmethods_do(nmethod::mark_on_stack); in >>>> MetadataOnStackMark. This code path is only taken when class >>>> redefinition is used. Class redefinition is typically used in >>>> monitoring and diagnostic frameworks. >>>> >>>> With this patch we now: >>>> 1) Filter out duplicate Metadata* entries instead of storing a >>>> Metadata* per visited metadata reference. >>>> 2) Collect the set of Metadata* entries in parallel. The code >>>> piggy-backs on the parallel CodeCache cleaning task. >>>> >>>> http://cr.openjdk.java.net/~stefank/8056240/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8056240 >>>> >>>> Functional testing: >>>> JPRT, Kitchensink, parallel_class_unloading, unit tests >>>> >>>> Performance testing: >>>> CRM Fuse - where the regression was found >>>> >>>> The patch changes HotSpot code in areas concerning GC, RT, >>>> Compiler, and Serviceability. It would be good to get some reviews >>>> from the other teams, and not only from the GC team. >>>> >>>> thanks, >>>> StefanK >>> >> > From daniel.daugherty at oracle.com Wed Oct 15 13:02:07 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Oct 2014 07:02:07 -0600 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543E590A.4020304@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> Message-ID: <543E704F.8020905@oracle.com> On 10/15/14 5:22 AM, Andreas Eriksson wrote: > Thanks Serguei. > > I have a question about the if-blocks that had the wrong indent: > > 2335 if > (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, > 2336 byte_i, "method_info", THREAD)) { The above should be indented like this: 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, 2335 byte_i, "method_info", 2336 THREAD)) { Dan > > How should I indent them? > > /Andreas > > On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >> Hi Andreas, >> >> Sorry I did not reply on this early. >> I assumed, it is a thumbs up from me. >> Just wanted make it clean now. :) >> >> Thanks, >> Serguei >> >> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>> Hi Serguei, thanks for looking at this! >>> >>> I'll make sure to fix the style problems. >>> For the symbolic names / #defines, please see my answer to Coleen. >>> >>> Regards, >>> Andreas >>> >>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>> Hi Andreas, >>>> >>>> >>>> Thank you for fixing this issue! >>>> The fix looks nice, I do not see any logical issues. >>>> >>>> >>>> Only minor comments... >>>> >>>> >>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>> >>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>> 2785 } // end skip_type_annotation_target >>>> 2844 } // end skip_type_annotation_type_path >>>> >>>> The ')' is missed at 2281, 2315. >>>> The 2397-2844 are inconsistent with the 2345 and other function-end >>>> comments in the file. >>>> >>>> >>>> 2335 if >>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>> >>>> 2336 byte_i, "method_info", THREAD)) { >>>> . . . >>>> 2378 if >>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>> >>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>> . . . >>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>> 2429 return false; >>>> 2430 } >>>> 2431 >>>> 2432 if (!skip_type_annotation_type_path(type_annotations_typeArray, >>>> 2433 byte_i_ref, THREAD)) { >>>> 2434 return false; >>>> 2435 } >>>> 2436 >>>> 2437 if >>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>> 2438 byte_i_ref, THREAD)) { >>>> 2439 return false; >>>> Wrong indent at 2336, 2379, etc. >>>> >>>> >>>> I also concur with Coleen that it would be good to define and use >>>> symbolic names for the hexa-decimal constants used in the fix. >>>> >>>> >>>> >>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>> >>>> Java indent must be 4, not 2. >>>> >>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>> TypeAnnotatedTestClass arg) >>>> >>>> The line is too long. >>>> >>>> >>>> 143 } >>>> 144 public static void main(String argv[]) { >>>> . . . >>>> 209 } >>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>> 211 checkAnnotations(p.getAnnotations()); >>>> 212 } >>>> 213 private static void checkAnnotations(AnnotatedType[] >>>> annoTypes) { >>>> 214 for (AnnotatedType p : annoTypes) >>>> checkAnnotations(p.getAnnotations()); >>>> 215 } >>>> 216 private static void >>>> checkAnnotations(Class c) { >>>> . . . >>>> 257 } >>>> 258 public void run() {} >>>> >>>> Adding empty lines between method definitions would improve >>>> readability. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch to RedefineClasses to allow type >>>>> annotations to be preserved. >>>>> >>>>> Summary: >>>>> During redefine / retransform class the constant pool indexes can >>>>> change. >>>>> Since annotations have indexes into the constant pool these >>>>> indexes need to be rewritten. >>>>> This is already done for regular annotations, but not for type >>>>> annotations. >>>>> This patch adds code to add this rewriting for the type >>>>> annotations as well. >>>>> The patch also contains minor changes to ClassFileReconstituter, >>>>> to make sure that type annotations are preserved during a redefine >>>>> / retransform class operation. >>>>> It also has a test that uses asm to change constant pool indexes >>>>> through a retransform, and then verifies that type annotations are >>>>> preserved. >>>>> >>>>> Detail: >>>>> A type annotation struct consists of some target information and a >>>>> type path, followed by a regular annotation struct. >>>>> Constant pool indexes are only present in the regular annotation >>>>> struct. >>>>> The added code skips over the type annotation specific parts, then >>>>> calls previously existing code to rewrite constant pool indexes in >>>>> the regular annotation struct. >>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info >>>>> about the type annotation struct. >>>>> >>>>> JPRT with the new test passes without failures on all platforms. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>> >>>>> Regards >>>>> Andreas >>>> >>> >> > From daniel.daugherty at oracle.com Wed Oct 15 13:03:01 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Oct 2014 07:03:01 -0600 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543E704F.8020905@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E704F.8020905@oracle.com> Message-ID: <543E7085.90404@oracle.com> On 10/15/14 7:02 AM, Daniel D. Daugherty wrote: > On 10/15/14 5:22 AM, Andreas Eriksson wrote: >> Thanks Serguei. >> >> I have a question about the if-blocks that had the wrong indent: >> >> 2335 if >> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >> 2336 byte_i, "method_info", THREAD)) { > > The above should be indented like this: > > 2335 if > (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, > 2335 byte_i, "method_info", > 2336 THREAD)) { Wow. Thunderbird ate all the white space indenting that I did... Dan > > Dan > > >> >> How should I indent them? >> >> /Andreas >> >> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>> Hi Andreas, >>> >>> Sorry I did not reply on this early. >>> I assumed, it is a thumbs up from me. >>> Just wanted make it clean now. :) >>> >>> Thanks, >>> Serguei >>> >>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>> Hi Serguei, thanks for looking at this! >>>> >>>> I'll make sure to fix the style problems. >>>> For the symbolic names / #defines, please see my answer to Coleen. >>>> >>>> Regards, >>>> Andreas >>>> >>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>> Hi Andreas, >>>>> >>>>> >>>>> Thank you for fixing this issue! >>>>> The fix looks nice, I do not see any logical issues. >>>>> >>>>> >>>>> Only minor comments... >>>>> >>>>> >>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>> >>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>> 2785 } // end skip_type_annotation_target >>>>> 2844 } // end skip_type_annotation_type_path >>>>> >>>>> The ')' is missed at 2281, 2315. >>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>> function-end comments in the file. >>>>> >>>>> >>>>> 2335 if >>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>> >>>>> 2336 byte_i, "method_info", THREAD)) { >>>>> . . . >>>>> 2378 if >>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>> >>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>> . . . >>>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>> 2429 return false; >>>>> 2430 } >>>>> 2431 >>>>> 2432 if >>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>> 2433 byte_i_ref, THREAD)) { >>>>> 2434 return false; >>>>> 2435 } >>>>> 2436 >>>>> 2437 if >>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>> 2438 byte_i_ref, THREAD)) { >>>>> 2439 return false; >>>>> Wrong indent at 2336, 2379, etc. >>>>> >>>>> >>>>> I also concur with Coleen that it would be good to define and use >>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>> >>>>> >>>>> >>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>> >>>>> Java indent must be 4, not 2. >>>>> >>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>>> TypeAnnotatedTestClass arg) >>>>> >>>>> The line is too long. >>>>> >>>>> >>>>> 143 } >>>>> 144 public static void main(String argv[]) { >>>>> . . . >>>>> 209 } >>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>> 211 checkAnnotations(p.getAnnotations()); >>>>> 212 } >>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>> annoTypes) { >>>>> 214 for (AnnotatedType p : annoTypes) >>>>> checkAnnotations(p.getAnnotations()); >>>>> 215 } >>>>> 216 private static void >>>>> checkAnnotations(Class c) { >>>>> . . . >>>>> 257 } >>>>> 258 public void run() {} >>>>> >>>>> Adding empty lines between method definitions would improve >>>>> readability. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this patch to RedefineClasses to allow type >>>>>> annotations to be preserved. >>>>>> >>>>>> Summary: >>>>>> During redefine / retransform class the constant pool indexes can >>>>>> change. >>>>>> Since annotations have indexes into the constant pool these >>>>>> indexes need to be rewritten. >>>>>> This is already done for regular annotations, but not for type >>>>>> annotations. >>>>>> This patch adds code to add this rewriting for the type >>>>>> annotations as well. >>>>>> The patch also contains minor changes to ClassFileReconstituter, >>>>>> to make sure that type annotations are preserved during a >>>>>> redefine / retransform class operation. >>>>>> It also has a test that uses asm to change constant pool indexes >>>>>> through a retransform, and then verifies that type annotations >>>>>> are preserved. >>>>>> >>>>>> Detail: >>>>>> A type annotation struct consists of some target information and >>>>>> a type path, followed by a regular annotation struct. >>>>>> Constant pool indexes are only present in the regular annotation >>>>>> struct. >>>>>> The added code skips over the type annotation specific parts, >>>>>> then calls previously existing code to rewrite constant pool >>>>>> indexes in the regular annotation struct. >>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more >>>>>> info about the type annotation struct. >>>>>> >>>>>> JPRT with the new test passes without failures on all platforms. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>> >>>>>> Regards >>>>>> Andreas >>>>> >>>> >>> >> > From daniel.daugherty at oracle.com Wed Oct 15 13:05:49 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Oct 2014 07:05:49 -0600 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543E590A.4020304@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> Message-ID: <543E712D.90900@oracle.com> On 10/15/14 5:22 AM, Andreas Eriksson wrote: > Thanks Serguei. > > I have a question about the if-blocks that had the wrong indent: > > 2335 if > (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, > 2336 byte_i, "method_info", THREAD)) { > > How should I indent them? Trying again without the line numbers... if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, byte_i, "method_info", THREAD)) { Just in case, TB messes with the spacing again, the "byte_i" line and "THREAD" lines are aligned under "method_type_annotations". Dan > > /Andreas > > On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >> Hi Andreas, >> >> Sorry I did not reply on this early. >> I assumed, it is a thumbs up from me. >> Just wanted make it clean now. :) >> >> Thanks, >> Serguei >> >> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>> Hi Serguei, thanks for looking at this! >>> >>> I'll make sure to fix the style problems. >>> For the symbolic names / #defines, please see my answer to Coleen. >>> >>> Regards, >>> Andreas >>> >>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>> Hi Andreas, >>>> >>>> >>>> Thank you for fixing this issue! >>>> The fix looks nice, I do not see any logical issues. >>>> >>>> >>>> Only minor comments... >>>> >>>> >>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>> >>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>> 2785 } // end skip_type_annotation_target >>>> 2844 } // end skip_type_annotation_type_path >>>> >>>> The ')' is missed at 2281, 2315. >>>> The 2397-2844 are inconsistent with the 2345 and other function-end >>>> comments in the file. >>>> >>>> >>>> 2335 if >>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>> >>>> 2336 byte_i, "method_info", THREAD)) { >>>> . . . >>>> 2378 if >>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>> >>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>> . . . >>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>> 2429 return false; >>>> 2430 } >>>> 2431 >>>> 2432 if (!skip_type_annotation_type_path(type_annotations_typeArray, >>>> 2433 byte_i_ref, THREAD)) { >>>> 2434 return false; >>>> 2435 } >>>> 2436 >>>> 2437 if >>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>> 2438 byte_i_ref, THREAD)) { >>>> 2439 return false; >>>> Wrong indent at 2336, 2379, etc. >>>> >>>> >>>> I also concur with Coleen that it would be good to define and use >>>> symbolic names for the hexa-decimal constants used in the fix. >>>> >>>> >>>> >>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>> >>>> Java indent must be 4, not 2. >>>> >>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>> TypeAnnotatedTestClass arg) >>>> >>>> The line is too long. >>>> >>>> >>>> 143 } >>>> 144 public static void main(String argv[]) { >>>> . . . >>>> 209 } >>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>> 211 checkAnnotations(p.getAnnotations()); >>>> 212 } >>>> 213 private static void checkAnnotations(AnnotatedType[] >>>> annoTypes) { >>>> 214 for (AnnotatedType p : annoTypes) >>>> checkAnnotations(p.getAnnotations()); >>>> 215 } >>>> 216 private static void >>>> checkAnnotations(Class c) { >>>> . . . >>>> 257 } >>>> 258 public void run() {} >>>> >>>> Adding empty lines between method definitions would improve >>>> readability. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch to RedefineClasses to allow type >>>>> annotations to be preserved. >>>>> >>>>> Summary: >>>>> During redefine / retransform class the constant pool indexes can >>>>> change. >>>>> Since annotations have indexes into the constant pool these >>>>> indexes need to be rewritten. >>>>> This is already done for regular annotations, but not for type >>>>> annotations. >>>>> This patch adds code to add this rewriting for the type >>>>> annotations as well. >>>>> The patch also contains minor changes to ClassFileReconstituter, >>>>> to make sure that type annotations are preserved during a redefine >>>>> / retransform class operation. >>>>> It also has a test that uses asm to change constant pool indexes >>>>> through a retransform, and then verifies that type annotations are >>>>> preserved. >>>>> >>>>> Detail: >>>>> A type annotation struct consists of some target information and a >>>>> type path, followed by a regular annotation struct. >>>>> Constant pool indexes are only present in the regular annotation >>>>> struct. >>>>> The added code skips over the type annotation specific parts, then >>>>> calls previously existing code to rewrite constant pool indexes in >>>>> the regular annotation struct. >>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info >>>>> about the type annotation struct. >>>>> >>>>> JPRT with the new test passes without failures on all platforms. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>> >>>>> Regards >>>>> Andreas >>>> >>> >> > From coleen.phillimore at oracle.com Wed Oct 15 13:20:43 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 15 Oct 2014 09:20:43 -0400 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <543E63C1.2030905@oracle.com> References: <542D2EC1.5030303@oracle.com> <5438476B.1060003@oracle.com> <543B9844.1070003@oracle.com> <543D8EF2.8040007@oracle.com> <543E63C1.2030905@oracle.com> Message-ID: <543E74AB.9080000@oracle.com> On 10/15/14, 8:08 AM, Stefan Karlsson wrote: >> >> I think since the abstraction has been broken that metadata_do() >> should be rewritten so that it shares the code that duplicates the >> walks in >> nmethod::mark_metadata_on_stack_at >> nmethod::mark_metadata_on_stack_non_relocs() > > You mean something like this?: > http://cr.openjdk.java.net/~stefank/8056240/webrev.02.do_metadata.delta > http://cr.openjdk.java.net/~stefank/8056240/webrev.02.do_metadata > No, I meant more like not having do_metadata() and just calling mark_on_stack directly like you did in your new functions and removing metadata_do(). The only other use is in CheckClass and we could have the copy of metadata walking there too. So there would be 2 copies of the walk but they didn't generalize well anyway. And there is too much indirection. I'll file an RFE (if you haven't already). Coleen From stefan.karlsson at oracle.com Wed Oct 15 13:12:53 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 15 Oct 2014 15:12:53 +0200 Subject: RFR: 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse In-Reply-To: <543E74AB.9080000@oracle.com> References: <542D2EC1.5030303@oracle.com> <5438476B.1060003@oracle.com> <543B9844.1070003@oracle.com> <543D8EF2.8040007@oracle.com> <543E63C1.2030905@oracle.com> <543E74AB.9080000@oracle.com> Message-ID: <543E72D5.1030509@oracle.com> On 2014-10-15 15:20, Coleen Phillimore wrote: > > On 10/15/14, 8:08 AM, Stefan Karlsson wrote: >>> >>> I think since the abstraction has been broken that metadata_do() >>> should be rewritten so that it shares the code that duplicates the >>> walks in >>> nmethod::mark_metadata_on_stack_at >>> nmethod::mark_metadata_on_stack_non_relocs() >> >> You mean something like this?: >> http://cr.openjdk.java.net/~stefank/8056240/webrev.02.do_metadata.delta >> http://cr.openjdk.java.net/~stefank/8056240/webrev.02.do_metadata >> > > No, I meant more like not having do_metadata() and just calling > mark_on_stack directly like you did in your new functions and removing > metadata_do(). The only other use is in CheckClass and we could have > the copy of metadata walking there too. So there would be 2 copies of > the walk but they didn't generalize well anyway. And there is too > much indirection. > > I'll file an RFE (if you haven't already). OK. StefanK > > Coleen From coleen.phillimore at oracle.com Wed Oct 15 13:34:02 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 15 Oct 2014 09:34:02 -0400 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543E712D.90900@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> Message-ID: <543E77CA.3090806@oracle.com> There are lots of other rewrite_cp_refs_in* function calls. Please indent your function like them, not differently. Coleen On 10/15/14, 9:05 AM, Daniel D. Daugherty wrote: > On 10/15/14 5:22 AM, Andreas Eriksson wrote: >> Thanks Serguei. >> >> I have a question about the if-blocks that had the wrong indent: >> >> 2335 if >> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >> 2336 byte_i, "method_info", THREAD)) { >> >> How should I indent them? > > Trying again without the line numbers... > > if > (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, > byte_i, > "method_info", > THREAD)) { > > Just in case, TB messes with the spacing again, the "byte_i" line and > "THREAD" lines are aligned under "method_type_annotations". > > Dan > > >> >> /Andreas >> >> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>> Hi Andreas, >>> >>> Sorry I did not reply on this early. >>> I assumed, it is a thumbs up from me. >>> Just wanted make it clean now. :) >>> >>> Thanks, >>> Serguei >>> >>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>> Hi Serguei, thanks for looking at this! >>>> >>>> I'll make sure to fix the style problems. >>>> For the symbolic names / #defines, please see my answer to Coleen. >>>> >>>> Regards, >>>> Andreas >>>> >>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>> Hi Andreas, >>>>> >>>>> >>>>> Thank you for fixing this issue! >>>>> The fix looks nice, I do not see any logical issues. >>>>> >>>>> >>>>> Only minor comments... >>>>> >>>>> >>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>> >>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>> 2785 } // end skip_type_annotation_target >>>>> 2844 } // end skip_type_annotation_type_path >>>>> >>>>> The ')' is missed at 2281, 2315. >>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>> function-end comments in the file. >>>>> >>>>> >>>>> 2335 if >>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>> >>>>> 2336 byte_i, "method_info", THREAD)) { >>>>> . . . >>>>> 2378 if >>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>> >>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>> . . . >>>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>> 2429 return false; >>>>> 2430 } >>>>> 2431 >>>>> 2432 if >>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>> 2433 byte_i_ref, THREAD)) { >>>>> 2434 return false; >>>>> 2435 } >>>>> 2436 >>>>> 2437 if >>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>> 2438 byte_i_ref, THREAD)) { >>>>> 2439 return false; >>>>> Wrong indent at 2336, 2379, etc. >>>>> >>>>> >>>>> I also concur with Coleen that it would be good to define and use >>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>> >>>>> >>>>> >>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>> >>>>> Java indent must be 4, not 2. >>>>> >>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>>> TypeAnnotatedTestClass arg) >>>>> >>>>> The line is too long. >>>>> >>>>> >>>>> 143 } >>>>> 144 public static void main(String argv[]) { >>>>> . . . >>>>> 209 } >>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>> 211 checkAnnotations(p.getAnnotations()); >>>>> 212 } >>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>> annoTypes) { >>>>> 214 for (AnnotatedType p : annoTypes) >>>>> checkAnnotations(p.getAnnotations()); >>>>> 215 } >>>>> 216 private static void >>>>> checkAnnotations(Class c) { >>>>> . . . >>>>> 257 } >>>>> 258 public void run() {} >>>>> >>>>> Adding empty lines between method definitions would improve >>>>> readability. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this patch to RedefineClasses to allow type >>>>>> annotations to be preserved. >>>>>> >>>>>> Summary: >>>>>> During redefine / retransform class the constant pool indexes can >>>>>> change. >>>>>> Since annotations have indexes into the constant pool these >>>>>> indexes need to be rewritten. >>>>>> This is already done for regular annotations, but not for type >>>>>> annotations. >>>>>> This patch adds code to add this rewriting for the type >>>>>> annotations as well. >>>>>> The patch also contains minor changes to ClassFileReconstituter, >>>>>> to make sure that type annotations are preserved during a >>>>>> redefine / retransform class operation. >>>>>> It also has a test that uses asm to change constant pool indexes >>>>>> through a retransform, and then verifies that type annotations >>>>>> are preserved. >>>>>> >>>>>> Detail: >>>>>> A type annotation struct consists of some target information and >>>>>> a type path, followed by a regular annotation struct. >>>>>> Constant pool indexes are only present in the regular annotation >>>>>> struct. >>>>>> The added code skips over the type annotation specific parts, >>>>>> then calls previously existing code to rewrite constant pool >>>>>> indexes in the regular annotation struct. >>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more >>>>>> info about the type annotation struct. >>>>>> >>>>>> JPRT with the new test passes without failures on all platforms. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>> >>>>>> Regards >>>>>> Andreas >>>>> >>>> >>> >> > From erik.osterlund at lnu.se Wed Oct 15 13:47:50 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Wed, 15 Oct 2014 13:47:50 +0000 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: References: Message-ID: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> Hi Paul, Thank you for the reply. I like the idea of using inheritance too. I tried a new solution which is similar to the one proposed and I would like to hear your comment if this is okay so we are all happy. The core idea is to have a general AtomicBase class which implements the old unspecialized cmpxchg (and possibly other stuff to come), then allow platforms to /optionally/ define their own AtomicPlatform base classes in the hierarchy that derive from AtomicBase. Then the last step in the hierarchy is Atomic which inherits from AtomicPlatform if it is defined and otherwise AtomicBase. It picks the superclass using SFINAE. The reason for this is that other ports will not be broken by this performance fix and the definition of such AtomicPlatform class is completely optional. :) Benefits: * Uses inheritance and looks nice like the inheritance based solution proposed * Does not break ports outside of the main repo * Does not require refactoring of everything (moving all methods from Atomic to AbstractAtomic for all platforms) * Changes are local to only the platforms that want to add this functionality * Flexible for supporting the future demands In a bit more detail, it looks like this: atomic.hpp: class AtomicBase : AllStatic { protected: static jbyte cmpxchg_unspecialized(jbyte exchange_value, volatile jbyte* dest, jbyte compare_value); public: inline static jbyte cmpxchg (jbyte exchange_value, volatile jbyte* dest, jbyte compare_value) { return cmpxchg_unspecialized(exchange_value, dest, compare_value); } }; // Linux #ifdef TARGET_OS_ARCH_linux_x86 # include "atomic_linux_x86.hpp" #endif // BSD #ifdef TARGET_OS_ARCH_bsd_x86 # include "atomic_bsd_x86.hpp" #endif // ... and the other platforms that benefit from specialized AtomicPlatform ... class AtomicPlatform; // Forward declaration to avoid compiler error when it is not defined // Based on some SFINAE stuff I made and will contribute if you like it. AtomicSuper will be AtomicPlatform if defined in a platform specific atomic_os_arch.hpp file, otherwise AtomicBase will be used typedef base_class::type AtomicSuper; // AtomicSuper is now the base class of Atomic, and contains the cmpxchgb implementation class Atomic : public AtomicSuper { // ... inline static jbyte cmpxchg (jbyte exchange_value, volatile jbyte* dest, jbyte compare_value) { // Just call super class implementation return AtomicSuper::cmpxchg(exchange_value, dest, compare_value); } // ... }; A new atomic_os_arch.hpp file looks like this (for platforms that support this): class AtomicPlatform : public AtomicBase { public: static jbyte cmpxchg(jbyte exchange_value, volatile jbyte* dest, jbyte compare_value); }; And atomic_os_arch.inline.hpp contains the implementation like before, but as members of AtomicPlatform instead of Atomic For the curious reader, the SFINAE stuff for base_class looks like this: template struct is_base_of_host { operator Base*() const; operator Derived*(); }; // Statically check if two types are related in a class hierarchy template struct is_base_of { typedef char yes[1]; typedef char no[2]; template static yes &check(Derived*, T); static no &check(Base*, int); static const bool value = sizeof(check(is_base_of_host(), int())) == sizeof(yes); }; // The ::type of this struct will be the Desired type if it was defined // and a subtype of Fallback, otherwise it will be Fallback. // This is useful when optionally inheriting from a specialized subtype. template struct base_class { template struct check_inheritance { typedef T type; }; template struct check_inheritance { typedef U type; }; typedef typename check_inheritance::value, Fallback, Desired>::type type; }; If everyone is happy with this solution, then I will prepare another webrev and send the patch. :) Thanks for taking the time to read through this change. /Erik On 14 Oct 2014, at 19:25, Paul Hohensee wrote: > David Holmes asked me to take a look at this > >>>>> There is now a new webrev with my jbyte cmpxchg changes here: >>>>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01 > > and comment, so... > > The approach is good if you're going to stay with the current framework, > except that I'd get rid of VM_HAS_SPECIALIZED_BYTE_CMPXCHG (#ifdef's are > the devil). Just call cmpxchg_general (which should be named > cmpxchgb_general or maybe cmpxchgb_unspecialized, btw) from an os_cpu file > as needed. I.e., no change to atomic.inline.hpp needed. Another way to > look at it is, cmpxchgb_general/unspecialized is the implementation of > another specialized version of cmpxchgb, on the same abstraction level as > the asm versions. > > If a rewrite is possible, I'd do it the way David suggests with an > AbstractAtomic class from which per-platform Atomic classes are derived. > That's the way VM_Version and ICache are defined. > > Paul From daniel.daugherty at oracle.com Wed Oct 15 13:47:52 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Oct 2014 07:47:52 -0600 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543E77CA.3090806@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> <543E77CA.3090806@oracle.com> Message-ID: <543E7B08.8040305@oracle.com> On 10/15/14 7:34 AM, Coleen Phillimore wrote: > > There are lots of other rewrite_cp_refs_in* function calls. Please > indent your function like them, not differently. The above implies that my answer below was made without sufficient context... my apologies for that. The general rule is to follow the existing style in the file so if there are rewrite_cp_refs_in* function calls in the file, then please follow that style. Unless, of course, you want to fix all of them to follow the HotSpot style guideline: https://wiki.openjdk.java.net/display/HotSpot/StyleGuide > Use good taste to break lines and align corresponding tokens > on adjacent lines. but that may cause Coleen some heartburn :-) Dan > > Coleen > > On 10/15/14, 9:05 AM, Daniel D. Daugherty wrote: >> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>> Thanks Serguei. >>> >>> I have a question about the if-blocks that had the wrong indent: >>> >>> 2335 if >>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>> >>> 2336 byte_i, "method_info", THREAD)) { >>> >>> How should I indent them? >> >> Trying again without the line numbers... >> >> if >> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >> byte_i, >> "method_info", >> THREAD)) { >> >> Just in case, TB messes with the spacing again, the "byte_i" line and >> "THREAD" lines are aligned under "method_type_annotations". >> >> Dan >> >> >>> >>> /Andreas >>> >>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>> Hi Andreas, >>>> >>>> Sorry I did not reply on this early. >>>> I assumed, it is a thumbs up from me. >>>> Just wanted make it clean now. :) >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>> Hi Serguei, thanks for looking at this! >>>>> >>>>> I'll make sure to fix the style problems. >>>>> For the symbolic names / #defines, please see my answer to Coleen. >>>>> >>>>> Regards, >>>>> Andreas >>>>> >>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Andreas, >>>>>> >>>>>> >>>>>> Thank you for fixing this issue! >>>>>> The fix looks nice, I do not see any logical issues. >>>>>> >>>>>> >>>>>> Only minor comments... >>>>>> >>>>>> >>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>> >>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>> 2785 } // end skip_type_annotation_target >>>>>> 2844 } // end skip_type_annotation_type_path >>>>>> >>>>>> The ')' is missed at 2281, 2315. >>>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>>> function-end comments in the file. >>>>>> >>>>>> >>>>>> 2335 if >>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>> >>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>> . . . >>>>>> 2378 if >>>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>> >>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>> . . . >>>>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>> 2429 return false; >>>>>> 2430 } >>>>>> 2431 >>>>>> 2432 if >>>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>> 2433 byte_i_ref, THREAD)) { >>>>>> 2434 return false; >>>>>> 2435 } >>>>>> 2436 >>>>>> 2437 if >>>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>> 2438 byte_i_ref, THREAD)) { >>>>>> 2439 return false; >>>>>> Wrong indent at 2336, 2379, etc. >>>>>> >>>>>> >>>>>> I also concur with Coleen that it would be good to define and use >>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>> >>>>>> >>>>>> >>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>> >>>>>> Java indent must be 4, not 2. >>>>>> >>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") TypeAnnotatedTestClass >>>>>> arg) >>>>>> >>>>>> The line is too long. >>>>>> >>>>>> >>>>>> 143 } >>>>>> 144 public static void main(String argv[]) { >>>>>> . . . >>>>>> 209 } >>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>> 212 } >>>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>>> annoTypes) { >>>>>> 214 for (AnnotatedType p : annoTypes) >>>>>> checkAnnotations(p.getAnnotations()); >>>>>> 215 } >>>>>> 216 private static void >>>>>> checkAnnotations(Class c) { >>>>>> . . . >>>>>> 257 } >>>>>> 258 public void run() {} >>>>>> >>>>>> Adding empty lines between method definitions would improve >>>>>> readability. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this patch to RedefineClasses to allow type >>>>>>> annotations to be preserved. >>>>>>> >>>>>>> Summary: >>>>>>> During redefine / retransform class the constant pool indexes >>>>>>> can change. >>>>>>> Since annotations have indexes into the constant pool these >>>>>>> indexes need to be rewritten. >>>>>>> This is already done for regular annotations, but not for type >>>>>>> annotations. >>>>>>> This patch adds code to add this rewriting for the type >>>>>>> annotations as well. >>>>>>> The patch also contains minor changes to ClassFileReconstituter, >>>>>>> to make sure that type annotations are preserved during a >>>>>>> redefine / retransform class operation. >>>>>>> It also has a test that uses asm to change constant pool indexes >>>>>>> through a retransform, and then verifies that type annotations >>>>>>> are preserved. >>>>>>> >>>>>>> Detail: >>>>>>> A type annotation struct consists of some target information and >>>>>>> a type path, followed by a regular annotation struct. >>>>>>> Constant pool indexes are only present in the regular annotation >>>>>>> struct. >>>>>>> The added code skips over the type annotation specific parts, >>>>>>> then calls previously existing code to rewrite constant pool >>>>>>> indexes in the regular annotation struct. >>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more >>>>>>> info about the type annotation struct. >>>>>>> >>>>>>> JPRT with the new test passes without failures on all platforms. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>> >>>>>>> Regards >>>>>>> Andreas >>>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Wed Oct 15 13:59:43 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Oct 2014 06:59:43 -0700 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543E590A.4020304@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> Message-ID: <543E7DCF.20903@oracle.com> Hi Andreas, On 10/15/14 4:22 AM, Andreas Eriksson wrote: > Thanks Serguei. > > I have a question about the if-blocks that had the wrong indent: > > 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, > 2336 byte_i, "method_info", THREAD)) { > How should I indent them? Normal indent is: 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, 2336 byte_i, "method_info", THREAD)) { Thanks, Serguei > > /Andreas > > On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >> Hi Andreas, >> >> Sorry I did not reply on this early. >> I assumed, it is a thumbs up from me. >> Just wanted make it clean now. :) >> >> Thanks, >> Serguei >> >> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>> Hi Serguei, thanks for looking at this! >>> >>> I'll make sure to fix the style problems. >>> For the symbolic names / #defines, please see my answer to Coleen. >>> >>> Regards, >>> Andreas >>> >>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>> Hi Andreas, >>>> >>>> >>>> Thank you for fixing this issue! >>>> The fix looks nice, I do not see any logical issues. >>>> >>>> >>>> Only minor comments... >>>> >>>> >>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>> >>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>> 2785 } // end skip_type_annotation_target >>>> 2844 } // end skip_type_annotation_type_path >>>> >>>> The ')' is missed at 2281, 2315. >>>> The 2397-2844 are inconsistent with the 2345 and other function-end >>>> comments in the file. >>>> >>>> >>>> 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>> 2336 byte_i, "method_info", THREAD)) { >>>> . . . >>>> 2378 if (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>> . . . >>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>> 2429 return false; >>>> 2430 } >>>> 2431 >>>> 2432 if (!skip_type_annotation_type_path(type_annotations_typeArray, >>>> 2433 byte_i_ref, THREAD)) { >>>> 2434 return false; >>>> 2435 } >>>> 2436 >>>> 2437 if (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>> 2438 byte_i_ref, THREAD)) { >>>> 2439 return false; >>>> Wrong indent at 2336, 2379, etc. >>>> >>>> >>>> I also concur with Coleen that it would be good to define and use >>>> symbolic names for the hexa-decimal constants used in the fix. >>>> >>>> >>>> >>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>> >>>> Java indent must be 4, not 2. >>>> >>>> 253 @TestAnn(site="returnTypeAnnotation") Class typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") TypeAnnotatedTestClass arg) >>>> >>>> The line is too long. >>>> >>>> >>>> 143 } >>>> 144 public static void main(String argv[]) { >>>> . . . >>>> 209 } >>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>> 211 checkAnnotations(p.getAnnotations()); >>>> 212 } >>>> 213 private static void checkAnnotations(AnnotatedType[] annoTypes) { >>>> 214 for (AnnotatedType p : annoTypes) checkAnnotations(p.getAnnotations()); >>>> 215 } >>>> 216 private static void checkAnnotations(Class c) { >>>> . . . >>>> 257 } >>>> 258 public void run() {} >>>> >>>> Adding empty lines between method definitions would improve >>>> readability. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch to RedefineClasses to allow type >>>>> annotations to be preserved. >>>>> >>>>> Summary: >>>>> During redefine / retransform class the constant pool indexes can >>>>> change. >>>>> Since annotations have indexes into the constant pool these >>>>> indexes need to be rewritten. >>>>> This is already done for regular annotations, but not for type >>>>> annotations. >>>>> This patch adds code to add this rewriting for the type >>>>> annotations as well. >>>>> The patch also contains minor changes to ClassFileReconstituter, >>>>> to make sure that type annotations are preserved during a redefine >>>>> / retransform class operation. >>>>> It also has a test that uses asm to change constant pool indexes >>>>> through a retransform, and then verifies that type annotations are >>>>> preserved. >>>>> >>>>> Detail: >>>>> A type annotation struct consists of some target information and a >>>>> type path, followed by a regular annotation struct. >>>>> Constant pool indexes are only present in the regular annotation >>>>> struct. >>>>> The added code skips over the type annotation specific parts, then >>>>> calls previously existing code to rewrite constant pool indexes in >>>>> the regular annotation struct. >>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info >>>>> about the type annotation struct. >>>>> >>>>> JPRT with the new test passes without failures on all platforms. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>> >>>>> Regards >>>>> Andreas >>>> >>> >> > From serguei.spitsyn at oracle.com Wed Oct 15 14:00:46 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Oct 2014 07:00:46 -0700 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543E7085.90404@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E704F.8020905@oracle.com> <543E7085.90404@oracle.com> Message-ID: <543E7E0E.9020002@oracle.com> On 10/15/14 6:03 AM, Daniel D. Daugherty wrote: > > On 10/15/14 7:02 AM, Daniel D. Daugherty wrote: >> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>> Thanks Serguei. >>> >>> I have a question about the if-blocks that had the wrong indent: >>> >>> 2335 if >>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>> >>> 2336 byte_i, "method_info", THREAD)) { >> >> The above should be indented like this: >> >> 2335 if >> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >> 2335 byte_i, "method_info", >> 2336 THREAD)) { > > Wow. Thunderbird ate all the white space indenting that I did... Funny. :) Thanks, Serguei > > Dan > > >> >> Dan >> >> >>> >>> How should I indent them? >>> >>> /Andreas >>> >>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>> Hi Andreas, >>>> >>>> Sorry I did not reply on this early. >>>> I assumed, it is a thumbs up from me. >>>> Just wanted make it clean now. :) >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>> Hi Serguei, thanks for looking at this! >>>>> >>>>> I'll make sure to fix the style problems. >>>>> For the symbolic names / #defines, please see my answer to Coleen. >>>>> >>>>> Regards, >>>>> Andreas >>>>> >>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Andreas, >>>>>> >>>>>> >>>>>> Thank you for fixing this issue! >>>>>> The fix looks nice, I do not see any logical issues. >>>>>> >>>>>> >>>>>> Only minor comments... >>>>>> >>>>>> >>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>> >>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>> 2785 } // end skip_type_annotation_target >>>>>> 2844 } // end skip_type_annotation_type_path >>>>>> >>>>>> The ')' is missed at 2281, 2315. >>>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>>> function-end comments in the file. >>>>>> >>>>>> >>>>>> 2335 if >>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>> >>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>> . . . >>>>>> 2378 if >>>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>> >>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>> . . . >>>>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>> 2429 return false; >>>>>> 2430 } >>>>>> 2431 >>>>>> 2432 if >>>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>> 2433 byte_i_ref, THREAD)) { >>>>>> 2434 return false; >>>>>> 2435 } >>>>>> 2436 >>>>>> 2437 if >>>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>> 2438 byte_i_ref, THREAD)) { >>>>>> 2439 return false; >>>>>> Wrong indent at 2336, 2379, etc. >>>>>> >>>>>> >>>>>> I also concur with Coleen that it would be good to define and use >>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>> >>>>>> >>>>>> >>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>> >>>>>> Java indent must be 4, not 2. >>>>>> >>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") TypeAnnotatedTestClass >>>>>> arg) >>>>>> >>>>>> The line is too long. >>>>>> >>>>>> >>>>>> 143 } >>>>>> 144 public static void main(String argv[]) { >>>>>> . . . >>>>>> 209 } >>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>> 212 } >>>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>>> annoTypes) { >>>>>> 214 for (AnnotatedType p : annoTypes) >>>>>> checkAnnotations(p.getAnnotations()); >>>>>> 215 } >>>>>> 216 private static void >>>>>> checkAnnotations(Class c) { >>>>>> . . . >>>>>> 257 } >>>>>> 258 public void run() {} >>>>>> >>>>>> Adding empty lines between method definitions would improve >>>>>> readability. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this patch to RedefineClasses to allow type >>>>>>> annotations to be preserved. >>>>>>> >>>>>>> Summary: >>>>>>> During redefine / retransform class the constant pool indexes >>>>>>> can change. >>>>>>> Since annotations have indexes into the constant pool these >>>>>>> indexes need to be rewritten. >>>>>>> This is already done for regular annotations, but not for type >>>>>>> annotations. >>>>>>> This patch adds code to add this rewriting for the type >>>>>>> annotations as well. >>>>>>> The patch also contains minor changes to ClassFileReconstituter, >>>>>>> to make sure that type annotations are preserved during a >>>>>>> redefine / retransform class operation. >>>>>>> It also has a test that uses asm to change constant pool indexes >>>>>>> through a retransform, and then verifies that type annotations >>>>>>> are preserved. >>>>>>> >>>>>>> Detail: >>>>>>> A type annotation struct consists of some target information and >>>>>>> a type path, followed by a regular annotation struct. >>>>>>> Constant pool indexes are only present in the regular annotation >>>>>>> struct. >>>>>>> The added code skips over the type annotation specific parts, >>>>>>> then calls previously existing code to rewrite constant pool >>>>>>> indexes in the regular annotation struct. >>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more >>>>>>> info about the type annotation struct. >>>>>>> >>>>>>> JPRT with the new test passes without failures on all platforms. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>> >>>>>>> Regards >>>>>>> Andreas >>>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Wed Oct 15 14:03:06 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Oct 2014 07:03:06 -0700 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543E712D.90900@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> Message-ID: <543E7E9A.7050804@oracle.com> On 10/15/14 6:05 AM, Daniel D. Daugherty wrote: > On 10/15/14 5:22 AM, Andreas Eriksson wrote: >> Thanks Serguei. >> >> I have a question about the if-blocks that had the wrong indent: >> >> 2335 if >> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >> 2336 byte_i, "method_info", THREAD)) { >> >> How should I indent them? > > Trying again without the line numbers... > > if > (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, > byte_i, "method_info", > THREAD)) { Agreed. This is even better. Thanks, Serguei > > Just in case, TB messes with the spacing again, the "byte_i" line and > "THREAD" lines are aligned under "method_type_annotations". > > Dan > > >> >> /Andreas >> >> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>> Hi Andreas, >>> >>> Sorry I did not reply on this early. >>> I assumed, it is a thumbs up from me. >>> Just wanted make it clean now. :) >>> >>> Thanks, >>> Serguei >>> >>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>> Hi Serguei, thanks for looking at this! >>>> >>>> I'll make sure to fix the style problems. >>>> For the symbolic names / #defines, please see my answer to Coleen. >>>> >>>> Regards, >>>> Andreas >>>> >>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>> Hi Andreas, >>>>> >>>>> >>>>> Thank you for fixing this issue! >>>>> The fix looks nice, I do not see any logical issues. >>>>> >>>>> >>>>> Only minor comments... >>>>> >>>>> >>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>> >>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>> 2785 } // end skip_type_annotation_target >>>>> 2844 } // end skip_type_annotation_type_path >>>>> >>>>> The ')' is missed at 2281, 2315. >>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>> function-end comments in the file. >>>>> >>>>> >>>>> 2335 if >>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>> >>>>> 2336 byte_i, "method_info", THREAD)) { >>>>> . . . >>>>> 2378 if >>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>> >>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>> . . . >>>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>> 2429 return false; >>>>> 2430 } >>>>> 2431 >>>>> 2432 if >>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>> 2433 byte_i_ref, THREAD)) { >>>>> 2434 return false; >>>>> 2435 } >>>>> 2436 >>>>> 2437 if >>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>> 2438 byte_i_ref, THREAD)) { >>>>> 2439 return false; >>>>> Wrong indent at 2336, 2379, etc. >>>>> >>>>> >>>>> I also concur with Coleen that it would be good to define and use >>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>> >>>>> >>>>> >>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>> >>>>> Java indent must be 4, not 2. >>>>> >>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>>> TypeAnnotatedTestClass arg) >>>>> >>>>> The line is too long. >>>>> >>>>> >>>>> 143 } >>>>> 144 public static void main(String argv[]) { >>>>> . . . >>>>> 209 } >>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>> 211 checkAnnotations(p.getAnnotations()); >>>>> 212 } >>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>> annoTypes) { >>>>> 214 for (AnnotatedType p : annoTypes) >>>>> checkAnnotations(p.getAnnotations()); >>>>> 215 } >>>>> 216 private static void >>>>> checkAnnotations(Class c) { >>>>> . . . >>>>> 257 } >>>>> 258 public void run() {} >>>>> >>>>> Adding empty lines between method definitions would improve >>>>> readability. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this patch to RedefineClasses to allow type >>>>>> annotations to be preserved. >>>>>> >>>>>> Summary: >>>>>> During redefine / retransform class the constant pool indexes can >>>>>> change. >>>>>> Since annotations have indexes into the constant pool these >>>>>> indexes need to be rewritten. >>>>>> This is already done for regular annotations, but not for type >>>>>> annotations. >>>>>> This patch adds code to add this rewriting for the type >>>>>> annotations as well. >>>>>> The patch also contains minor changes to ClassFileReconstituter, >>>>>> to make sure that type annotations are preserved during a >>>>>> redefine / retransform class operation. >>>>>> It also has a test that uses asm to change constant pool indexes >>>>>> through a retransform, and then verifies that type annotations >>>>>> are preserved. >>>>>> >>>>>> Detail: >>>>>> A type annotation struct consists of some target information and >>>>>> a type path, followed by a regular annotation struct. >>>>>> Constant pool indexes are only present in the regular annotation >>>>>> struct. >>>>>> The added code skips over the type annotation specific parts, >>>>>> then calls previously existing code to rewrite constant pool >>>>>> indexes in the regular annotation struct. >>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more >>>>>> info about the type annotation struct. >>>>>> >>>>>> JPRT with the new test passes without failures on all platforms. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>> >>>>>> Regards >>>>>> Andreas >>>>> >>>> >>> >> > From andreas.eriksson at oracle.com Wed Oct 15 14:08:38 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 15 Oct 2014 16:08:38 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543E7E9A.7050804@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> <543E7E9A.7050804@oracle.com> Message-ID: <543E7FE6.6040107@oracle.com> On 2014-10-15 16:03, serguei.spitsyn at oracle.com wrote: > On 10/15/14 6:05 AM, Daniel D. Daugherty wrote: >> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>> Thanks Serguei. >>> >>> I have a question about the if-blocks that had the wrong indent: >>> >>> 2335 if >>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>> >>> 2336 byte_i, "method_info", THREAD)) { >>> >>> How should I indent them? >> >> Trying again without the line numbers... >> >> if >> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >> byte_i, "method_info", >> THREAD)) { > > Agreed. This is even better. Alright, I'll go with this style then. Thanks Serguei and Daniel. /Andreas > > Thanks, > Serguei > >> >> Just in case, TB messes with the spacing again, the "byte_i" line and >> "THREAD" lines are aligned under "method_type_annotations". >> >> Dan >> >> >>> >>> /Andreas >>> >>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>> Hi Andreas, >>>> >>>> Sorry I did not reply on this early. >>>> I assumed, it is a thumbs up from me. >>>> Just wanted make it clean now. :) >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>> Hi Serguei, thanks for looking at this! >>>>> >>>>> I'll make sure to fix the style problems. >>>>> For the symbolic names / #defines, please see my answer to Coleen. >>>>> >>>>> Regards, >>>>> Andreas >>>>> >>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Andreas, >>>>>> >>>>>> >>>>>> Thank you for fixing this issue! >>>>>> The fix looks nice, I do not see any logical issues. >>>>>> >>>>>> >>>>>> Only minor comments... >>>>>> >>>>>> >>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>> >>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>> 2785 } // end skip_type_annotation_target >>>>>> 2844 } // end skip_type_annotation_type_path >>>>>> >>>>>> The ')' is missed at 2281, 2315. >>>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>>> function-end comments in the file. >>>>>> >>>>>> >>>>>> 2335 if >>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>> >>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>> . . . >>>>>> 2378 if >>>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>> >>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>> . . . >>>>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>> 2429 return false; >>>>>> 2430 } >>>>>> 2431 >>>>>> 2432 if >>>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>> 2433 byte_i_ref, THREAD)) { >>>>>> 2434 return false; >>>>>> 2435 } >>>>>> 2436 >>>>>> 2437 if >>>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>> 2438 byte_i_ref, THREAD)) { >>>>>> 2439 return false; >>>>>> Wrong indent at 2336, 2379, etc. >>>>>> >>>>>> >>>>>> I also concur with Coleen that it would be good to define and use >>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>> >>>>>> >>>>>> >>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>> >>>>>> Java indent must be 4, not 2. >>>>>> >>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") TypeAnnotatedTestClass >>>>>> arg) >>>>>> >>>>>> The line is too long. >>>>>> >>>>>> >>>>>> 143 } >>>>>> 144 public static void main(String argv[]) { >>>>>> . . . >>>>>> 209 } >>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>> 212 } >>>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>>> annoTypes) { >>>>>> 214 for (AnnotatedType p : annoTypes) >>>>>> checkAnnotations(p.getAnnotations()); >>>>>> 215 } >>>>>> 216 private static void >>>>>> checkAnnotations(Class c) { >>>>>> . . . >>>>>> 257 } >>>>>> 258 public void run() {} >>>>>> >>>>>> Adding empty lines between method definitions would improve >>>>>> readability. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this patch to RedefineClasses to allow type >>>>>>> annotations to be preserved. >>>>>>> >>>>>>> Summary: >>>>>>> During redefine / retransform class the constant pool indexes >>>>>>> can change. >>>>>>> Since annotations have indexes into the constant pool these >>>>>>> indexes need to be rewritten. >>>>>>> This is already done for regular annotations, but not for type >>>>>>> annotations. >>>>>>> This patch adds code to add this rewriting for the type >>>>>>> annotations as well. >>>>>>> The patch also contains minor changes to ClassFileReconstituter, >>>>>>> to make sure that type annotations are preserved during a >>>>>>> redefine / retransform class operation. >>>>>>> It also has a test that uses asm to change constant pool indexes >>>>>>> through a retransform, and then verifies that type annotations >>>>>>> are preserved. >>>>>>> >>>>>>> Detail: >>>>>>> A type annotation struct consists of some target information and >>>>>>> a type path, followed by a regular annotation struct. >>>>>>> Constant pool indexes are only present in the regular annotation >>>>>>> struct. >>>>>>> The added code skips over the type annotation specific parts, >>>>>>> then calls previously existing code to rewrite constant pool >>>>>>> indexes in the regular annotation struct. >>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more >>>>>>> info about the type annotation struct. >>>>>>> >>>>>>> JPRT with the new test passes without failures on all platforms. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>> >>>>>>> Regards >>>>>>> Andreas >>>>>> >>>>> >>>> >>> >> > From yasuenag at gmail.com Wed Oct 15 14:13:12 2014 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 15 Oct 2014 23:13:12 +0900 Subject: RFR: JDK-8059586: hs_err report should treat redirected core pattern. In-Reply-To: <543DC2BF.9050407@oracle.com> References: <542C8274.3010809@gmail.com> <54338B70.9080709@oracle.com> <543B1FD6.3000200@oracle.com> <543CF553.80601@gmail.com> <543DC2BF.9050407@oracle.com> Message-ID: <543E80F8.3080204@gmail.com> Hi David, I've uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.02/ > I wasn't suggesting that you make such a change though because it is large and disruptive. > Unfactoring check_or_create_dump is a step backwards in terms of code sharing. I restored check_or_create_dump() to os_posix.cpp . And I changed get_core_path() to create message which represents core dump path (including filename) in each OS. > Expanding the get_core_path in os_linux.cpp to handle the core_pattern may be okay (but I don't know enough about it to validate everything). I implemented all parameters in Linux kernel documentation: https://www.kernel.org/doc/Documentation/sysctl/kernel.txt So I think that parameters which are processed are enough. Thanks, Yasumasa (2014/10/15 9:41), David Holmes wrote: > On 14/10/2014 8:05 PM, Yasumasa Suenaga wrote: >> Hi David, >> >> Thank you for comments! >> I've uploaded new webrev. Could you review it again? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.01/ >> >> I am an author of jdk9. So I cannot commit it. >> Could you be a sponsor for this enhancement? >> >> >>> In which case that should be handled by the linux specific >>> get_core_path() function. >> >> Agree. >> So I implemented it in os_linux.cpp . >> But part of format characters (%P: global pid, %s: signal, %t dump time) >> are not processed >> in this function because I think these parameters are difficult to >> handle in it. >> >> %P: I could not find API for this. >> %s: We have to change arguments of get_core_path() . >> %t: This parameter means timestamp of coredump. It is decided in Kernel. >> >> >>> Fixing this means changing all the os_posix using platforms. But your >>> patch is not about this part. :) >> >> I moved os::check_or_create_dump() to each OS implementations (AIX, BSD, >> Solaris, Linux) . >> So I can write Linux specific code to check_or_create_dump() . >> As a result, I could remove "#ifdef LINUX" from os_posix.cpp :-) > > I wasn't suggesting that you make such a change though because it is large and disruptive. The simple handling of the | part of core_pattern was basically ok. Expanding the get_core_path in os_linux.cpp to handle the core_pattern may be okay (but I don't know enough about it to validate everything). Unfactoring check_or_create_dump is a step backwards in terms of code sharing. > > Sorry this has grown too large for me to deal with right now. > > David > ----- > >> >>> Though I'm unclear whether it both invokes the program and creates a >>> core dump file; or just invokes the program? >> >> If '|' is set, Linux kernel will just redirect core image to user process. >> Kernel documentation says as below: >> ------------ >> . If the first character of the pattern is a '|', the kernel will treat >> the rest of the pattern as a command to run. The core dump will be >> written to the standard input of that program instead of to a file. >> ------------ >> >> And implementation of coredump (do_coredump()) follows to it. >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/coredump.c >> >> >> In case of ABRT, ABRT dumps core image to default location >> (/core.) >> if user set unlimited to resource limit of core (ulimit -c) . >> https://github.com/abrt/abrt/blob/master/src/hooks/abrt-hook-ccpp.c >> >> >>> A few style nits - you need spaces around keywords and before braces >>> I also suggest saying "Core dumps may be processed with ..." rather >>> than "treated". >>> And as you don't do anything in the non-redirect case I suggest >>> collapsing this: >> >> I've fixed them. >> >> >> Thanks, >> >> Yasumasa >> >> >> (2014/10/13 9:41), David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 7/10/2014 8:48 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> Sorry for my English. >>>> >>>> I want to propose that JVM should create message according to core >>>> pattern (/proc/sys/kernel/core_pattern) . >>>> So I filed it to JBS and created a patch. >>> >>> So I've had a quick look at this core_pattern business and it seems to >>> me that there are two aspects to this. >>> >>> First, without the leading |, the entry in the core_pattern file is a >>> naming pattern for the core file. In which case that should be handled >>> by the linux specific get_core_path() function. Though that in itself >>> can't fully report the expected name, as part of it is provided in the >>> shared code in os::check_or_create_dump. Fixing this means changing >>> all the os_posix using platforms. But your patch is not about this >>> part. :) >>> >>> Second, with a leading | the core_pattern is actually the name of a >>> program to execute when the program is about to core dump, and that is >>> what you report with your patch. Though I'm unclear whether it both >>> invokes the program and creates a core dump file; or just invokes the >>> program? >>> >>> So with regards to this second part your patch seems functionally ok. >>> I do dislike having a big chunk of linux specific code in this "posix" >>> support file but ... >>> >>> A few style nits - you need spaces around keywords and before braces eg: >>> >>> if(x){ >>> >>> should be >>> >>> if (x) { >>> >>> I also suggest saying "Core dumps may be processed with ..." rather >>> than "treated". >>> >>> And as you don't do anything in the non-redirect case I suggest >>> collapsing this: >>> >>> 83 is_redirect = core_pattern[0] == '|'; >>> 84 } >>> 85 >>> 86 if(is_redirect){ >>> 87 jio_snprintf(buffer, bufferSize, >>> 88 "Core dumps may be treated with \"%s\"", >>> &core_pattern[1]); >>> 89 } >>> >>> to just >>> >>> 83 if (core_pattern[0] == '|') { // redirect >>> 84 jio_snprintf(buffer, bufferSize, "Core dumps may be >>> processed with \"%s\"", &core_pattern[1]); >>> 85 } >>> 86 } >>> >>> Comments from other runtime folk appreciated. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> 2014/10/07 15:43 "David Holmes" >>> >: >>>> >>>> Hi Yasumasa, >>>> >>>> I'm sorry but I don't understand what you are proposing. When you >>>> say >>>> "treat" do you mean "create"? Otherwise what do you mean by >>>> "treated"? >>>> >>>> Thanks, >>>> David >>>> >>>> On 2/10/2014 8:38 AM, Yasumasa Suenaga wrote: >>>> > I'm in Hackergarten @ JavaOne :-) >>>> > >>>> > >>>> > Hi all, >>>> > >>>> > I would like to enhance the messages in hs_err report. >>>> > Modern Linux kernel can treat core dump with user process >>>> (e.g. ABRT) >>>> > However, hs_err report cannot detect it. >>>> > >>>> > I think that hs_err report should output messages as below: >>>> > ------------- >>>> > Failed to write core dump. Core dumps may be treated with >>>> "/usr/sbin/chroot /proc/%P/root /usr/libexec/abrt-hook-ccpp %s %c %p >>>> %u %g %t e" >>>> > ------------- >>>> > >>>> > I've uploaded webrev of this enhancement. >>>> > Could you review it? >>>> > >>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.00/ >>>> > >>>> > This patch works fine on Fedora20 x86_64. >>>> > >>>> > >>>> > >>>> > Thanks, >>>> > >>>> > Yasumasa >>>> > >>>> From serguei.spitsyn at oracle.com Wed Oct 15 14:50:08 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Oct 2014 07:50:08 -0700 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543E7FE6.6040107@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> <543E7E9A.7050804@oracle.com> <543E7FE6.6040107@oracle.com> Message-ID: <543E89A0.2080303@oracle.com> On 10/15/14 7:08 AM, Andreas Eriksson wrote: > > On 2014-10-15 16:03, serguei.spitsyn at oracle.com wrote: >> On 10/15/14 6:05 AM, Daniel D. Daugherty wrote: >>> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>>> Thanks Serguei. >>>> >>>> I have a question about the if-blocks that had the wrong indent: >>>> >>>> 2335 if >>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>> >>>> 2336 byte_i, "method_info", THREAD)) { >>>> >>>> How should I indent them? >>> >>> Trying again without the line numbers... >>> >>> if >>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>> >>> byte_i, "method_info", >>> THREAD)) { >> >> Agreed. This is even better. > > Alright, I'll go with this style then. > Thanks Serguei and Daniel. Sorry, Andreas. My suggestion was wrong. I've replied automatically and overlooked that fact the function arguments are being indented. Forgot to drink enough coffee in the morning. :) Dan's suggestion is right. Thanks, Serguei > > /Andreas > >> >> Thanks, >> Serguei >> >>> >>> Just in case, TB messes with the spacing again, the "byte_i" line and >>> "THREAD" lines are aligned under "method_type_annotations". >>> >>> Dan >>> >>> >>>> >>>> /Andreas >>>> >>>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>>> Hi Andreas, >>>>> >>>>> Sorry I did not reply on this early. >>>>> I assumed, it is a thumbs up from me. >>>>> Just wanted make it clean now. :) >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>>> Hi Serguei, thanks for looking at this! >>>>>> >>>>>> I'll make sure to fix the style problems. >>>>>> For the symbolic names / #defines, please see my answer to Coleen. >>>>>> >>>>>> Regards, >>>>>> Andreas >>>>>> >>>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Andreas, >>>>>>> >>>>>>> >>>>>>> Thank you for fixing this issue! >>>>>>> The fix looks nice, I do not see any logical issues. >>>>>>> >>>>>>> >>>>>>> Only minor comments... >>>>>>> >>>>>>> >>>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>>> >>>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>>> 2785 } // end skip_type_annotation_target >>>>>>> 2844 } // end skip_type_annotation_type_path >>>>>>> >>>>>>> The ')' is missed at 2281, 2315. >>>>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>>>> function-end comments in the file. >>>>>>> >>>>>>> >>>>>>> 2335 if >>>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>> >>>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>>> . . . >>>>>>> 2378 if >>>>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>>> >>>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>>> . . . >>>>>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>>> 2429 return false; >>>>>>> 2430 } >>>>>>> 2431 >>>>>>> 2432 if >>>>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>>> 2433 byte_i_ref, THREAD)) { >>>>>>> 2434 return false; >>>>>>> 2435 } >>>>>>> 2436 >>>>>>> 2437 if >>>>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>>> 2438 byte_i_ref, THREAD)) { >>>>>>> 2439 return false; >>>>>>> Wrong indent at 2336, 2379, etc. >>>>>>> >>>>>>> >>>>>>> I also concur with Coleen that it would be good to define and use >>>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>>> >>>>>>> >>>>>>> >>>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>>> >>>>>>> Java indent must be 4, not 2. >>>>>>> >>>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>>>>> TypeAnnotatedTestClass arg) >>>>>>> >>>>>>> The line is too long. >>>>>>> >>>>>>> >>>>>>> 143 } >>>>>>> 144 public static void main(String argv[]) { >>>>>>> . . . >>>>>>> 209 } >>>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>>> 212 } >>>>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>>>> annoTypes) { >>>>>>> 214 for (AnnotatedType p : annoTypes) >>>>>>> checkAnnotations(p.getAnnotations()); >>>>>>> 215 } >>>>>>> 216 private static void >>>>>>> checkAnnotations(Class c) { >>>>>>> . . . >>>>>>> 257 } >>>>>>> 258 public void run() {} >>>>>>> >>>>>>> Adding empty lines between method definitions would improve >>>>>>> readability. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review this patch to RedefineClasses to allow type >>>>>>>> annotations to be preserved. >>>>>>>> >>>>>>>> Summary: >>>>>>>> During redefine / retransform class the constant pool indexes >>>>>>>> can change. >>>>>>>> Since annotations have indexes into the constant pool these >>>>>>>> indexes need to be rewritten. >>>>>>>> This is already done for regular annotations, but not for type >>>>>>>> annotations. >>>>>>>> This patch adds code to add this rewriting for the type >>>>>>>> annotations as well. >>>>>>>> The patch also contains minor changes to >>>>>>>> ClassFileReconstituter, to make sure that type annotations are >>>>>>>> preserved during a redefine / retransform class operation. >>>>>>>> It also has a test that uses asm to change constant pool >>>>>>>> indexes through a retransform, and then verifies that type >>>>>>>> annotations are preserved. >>>>>>>> >>>>>>>> Detail: >>>>>>>> A type annotation struct consists of some target information >>>>>>>> and a type path, followed by a regular annotation struct. >>>>>>>> Constant pool indexes are only present in the regular >>>>>>>> annotation struct. >>>>>>>> The added code skips over the type annotation specific parts, >>>>>>>> then calls previously existing code to rewrite constant pool >>>>>>>> indexes in the regular annotation struct. >>>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more >>>>>>>> info about the type annotation struct. >>>>>>>> >>>>>>>> JPRT with the new test passes without failures on all platforms. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>>> >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>>> >>>>>>>> Regards >>>>>>>> Andreas >>>>>>> >>>>>> >>>>> >>>> >>> >> > From andreas.eriksson at oracle.com Wed Oct 15 16:01:55 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 15 Oct 2014 18:01:55 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543E89A0.2080303@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> <543E7E9A.7050804@oracle.com> <543E7FE6.6040107@oracle.com> <543E89A0.2080303@oracle.com> Message-ID: <543E9A73.3040304@oracle.com> On 2014-10-15 16:50, serguei.spitsyn at oracle.com wrote: > On 10/15/14 7:08 AM, Andreas Eriksson wrote: >> >> On 2014-10-15 16:03, serguei.spitsyn at oracle.com wrote: >>> On 10/15/14 6:05 AM, Daniel D. Daugherty wrote: >>>> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>>>> Thanks Serguei. >>>>> >>>>> I have a question about the if-blocks that had the wrong indent: >>>>> >>>>> 2335 if >>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>> >>>>> 2336 byte_i, "method_info", THREAD)) { >>>>> >>>>> How should I indent them? >>>> >>>> Trying again without the line numbers... >>>> >>>> if >>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>> >>>> byte_i, "method_info", >>>> THREAD)) { >>> >>> Agreed. This is even better. >> >> Alright, I'll go with this style then. >> Thanks Serguei and Daniel. > > Sorry, Andreas. My suggestion was wrong. > I've replied automatically and overlooked that fact the function > arguments are being indented. > Forgot to drink enough coffee in the morning. :) > Dan's suggestion is right. No problem. :) > > > Thanks, > Serguei > >> >> /Andreas >> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Just in case, TB messes with the spacing again, the "byte_i" line and >>>> "THREAD" lines are aligned under "method_type_annotations". >>>> >>>> Dan >>>> >>>> >>>>> >>>>> /Andreas >>>>> >>>>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Andreas, >>>>>> >>>>>> Sorry I did not reply on this early. >>>>>> I assumed, it is a thumbs up from me. >>>>>> Just wanted make it clean now. :) >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>>>> Hi Serguei, thanks for looking at this! >>>>>>> >>>>>>> I'll make sure to fix the style problems. >>>>>>> For the symbolic names / #defines, please see my answer to Coleen. >>>>>>> >>>>>>> Regards, >>>>>>> Andreas >>>>>>> >>>>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Andreas, >>>>>>>> >>>>>>>> >>>>>>>> Thank you for fixing this issue! >>>>>>>> The fix looks nice, I do not see any logical issues. >>>>>>>> >>>>>>>> >>>>>>>> Only minor comments... >>>>>>>> >>>>>>>> >>>>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>>>> >>>>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>>>> 2785 } // end skip_type_annotation_target >>>>>>>> 2844 } // end skip_type_annotation_type_path >>>>>>>> >>>>>>>> The ')' is missed at 2281, 2315. >>>>>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>>>>> function-end comments in the file. >>>>>>>> >>>>>>>> >>>>>>>> 2335 if >>>>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>>> >>>>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>>>> . . . >>>>>>>> 2378 if >>>>>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>>>> >>>>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>>>> . . . >>>>>>>> 2427 if >>>>>>>> (!skip_type_annotation_target(type_annotations_typeArray, >>>>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>>>> 2429 return false; >>>>>>>> 2430 } >>>>>>>> 2431 >>>>>>>> 2432 if >>>>>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>>>> 2433 byte_i_ref, THREAD)) { >>>>>>>> 2434 return false; >>>>>>>> 2435 } >>>>>>>> 2436 >>>>>>>> 2437 if >>>>>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>>>> 2438 byte_i_ref, THREAD)) { >>>>>>>> 2439 return false; >>>>>>>> Wrong indent at 2336, 2379, etc. >>>>>>>> >>>>>>>> >>>>>>>> I also concur with Coleen that it would be good to define and use >>>>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>>>> >>>>>>>> Java indent must be 4, not 2. >>>>>>>> >>>>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>>>>>> TypeAnnotatedTestClass arg) >>>>>>>> >>>>>>>> The line is too long. >>>>>>>> >>>>>>>> >>>>>>>> 143 } >>>>>>>> 144 public static void main(String argv[]) { >>>>>>>> . . . >>>>>>>> 209 } >>>>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>>>> 212 } >>>>>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>>>>> annoTypes) { >>>>>>>> 214 for (AnnotatedType p : annoTypes) >>>>>>>> checkAnnotations(p.getAnnotations()); >>>>>>>> 215 } >>>>>>>> 216 private static void >>>>>>>> checkAnnotations(Class c) { >>>>>>>> . . . >>>>>>>> 257 } >>>>>>>> 258 public void run() {} >>>>>>>> >>>>>>>> Adding empty lines between method definitions would improve >>>>>>>> readability. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review this patch to RedefineClasses to allow type >>>>>>>>> annotations to be preserved. >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> During redefine / retransform class the constant pool indexes >>>>>>>>> can change. >>>>>>>>> Since annotations have indexes into the constant pool these >>>>>>>>> indexes need to be rewritten. >>>>>>>>> This is already done for regular annotations, but not for type >>>>>>>>> annotations. >>>>>>>>> This patch adds code to add this rewriting for the type >>>>>>>>> annotations as well. >>>>>>>>> The patch also contains minor changes to >>>>>>>>> ClassFileReconstituter, to make sure that type annotations are >>>>>>>>> preserved during a redefine / retransform class operation. >>>>>>>>> It also has a test that uses asm to change constant pool >>>>>>>>> indexes through a retransform, and then verifies that type >>>>>>>>> annotations are preserved. >>>>>>>>> >>>>>>>>> Detail: >>>>>>>>> A type annotation struct consists of some target information >>>>>>>>> and a type path, followed by a regular annotation struct. >>>>>>>>> Constant pool indexes are only present in the regular >>>>>>>>> annotation struct. >>>>>>>>> The added code skips over the type annotation specific parts, >>>>>>>>> then calls previously existing code to rewrite constant pool >>>>>>>>> indexes in the regular annotation struct. >>>>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more >>>>>>>>> info about the type annotation struct. >>>>>>>>> >>>>>>>>> JPRT with the new test passes without failures on all platforms. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>>>> >>>>>>>>> Bug: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Andreas >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From david.r.chase at oracle.com Wed Oct 15 16:53:29 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 15 Oct 2014 12:53:29 -0400 Subject: [8u40] RFR(S) 8059299: assert(adr_type != NULL) failed: expecting TypeKlassPtr In-Reply-To: <542F0FB1.1020303@oracle.com> References: <542F0FB1.1020303@oracle.com> Message-ID: Is there an error in your test? I see what looks like a repeated check, where you intended to compare to counter0 at line 73: 70 if (counter1 != 0) { 71 throw new RuntimeException("Failed: counter1(" + counter1 + ") != 0"); 72 } 73 if (counter2 != counter) { 74 throw new RuntimeException("Failed: counter2(" + counter2 + ") != counter0(" + counter0 + ")"); 75 } 76 if (counter2 != counter) { 77 throw new RuntimeException("Failed: counter2(" + counter2 + ") != counter(" + counter + ")"); 78 } 79 System.out.println("TEST PASSED"); 80 } Other than that, to the best of my ability to make sense of what is going on, it looks good. David On 2014-10-03, at 5:05 PM, Vladimir Kozlov wrote: > Backport request. Changes was pushed into jdk9 yesterday. Nighties are fine (we did not catch the problem for a lot of years so I doubt we have old tests which are affected). > Changes are applied cleanly to 8u sources except I had to remove changes in test/TEST.groups since we don't have JPRT jtreg testing for 8u. > > http://cr.openjdk.java.net/~kvn/8059299/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8059299 > > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4365e650350d > > Review thread: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-October/015757.html > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Oct 15 19:35:47 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Oct 2014 12:35:47 -0700 Subject: [8u40] RFR(S) 8059299: assert(adr_type != NULL) failed: expecting TypeKlassPtr In-Reply-To: References: <542F0FB1.1020303@oracle.com> Message-ID: <543ECC93.4050903@oracle.com> On 10/15/14 9:53 AM, David Chase wrote: > Is there an error in your test? I see what looks like a repeated check, where you intended to compare to counter0 at line 73: Yes, it is typo. Should be counter2 != counter0 I will fix the test for backport and will push additional fix for jdk9. Thanks, Vladimir > > 70 if (counter1 != 0) { > 71 throw new RuntimeException("Failed: counter1(" + counter1 + ") != 0"); > 72 } > 73 if (counter2 != counter) { > 74 throw new RuntimeException("Failed: counter2(" + counter2 + ") != counter0(" + counter0 + ")"); > 75 } > 76 if (counter2 != counter) { > 77 throw new RuntimeException("Failed: counter2(" + counter2 + ") != counter(" + counter + ")"); > 78 } > 79 System.out.println("TEST PASSED"); > 80 } > > Other than that, to the best of my ability to make sense of what is going on, it looks good. > > David > > > On 2014-10-03, at 5:05 PM, Vladimir Kozlov wrote: > >> Backport request. Changes was pushed into jdk9 yesterday. Nighties are fine (we did not catch the problem for a lot of years so I doubt we have old tests which are affected). >> Changes are applied cleanly to 8u sources except I had to remove changes in test/TEST.groups since we don't have JPRT jtreg testing for 8u. >> >> http://cr.openjdk.java.net/~kvn/8059299/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8059299 >> >> jdk9 changeset: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4365e650350d >> >> Review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-October/015757.html >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Wed Oct 15 19:44:02 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Oct 2014 12:44:02 -0700 Subject: [8u40] Bulk backport request: 8058825, 8059556, 8058828 In-Reply-To: <543E580F.3020207@oracle.com> References: <543E580F.3020207@oracle.com> Message-ID: <543ECE82.4000309@oracle.com> Looks good. Thanks, Vladimir On 10/15/14 4:18 AM, Vladimir Ivanov wrote: > This is a bulk request to backport the following changes into 8u40. They > were integrated into 9 and cleanly apply to 8u-dev. > > (1) 8058825: EA: ConnectionGraph::split_unique_types does incorrect > scalar replacement > https://bugs.openjdk.java.net/browse/JDK-8058825 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/19c71767e456 > > (2) 8059556: C2: crash while inlining MethodHandle invocation w/ null > receiver > https://bugs.openjdk.java.net/browse/JDK-8059556 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9c4780bccc23 > > (3) 8058828: Wrong ciConstant type for arrays from > ConstantPool::_resolved_reference > https://bugs.openjdk.java.net/browse/JDK-8058828 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/677d7ff6a1cf > > Best regards, > Vladimir Ivanov From calvin.cheung at oracle.com Wed Oct 15 21:19:35 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 15 Oct 2014 14:19:35 -0700 Subject: [8u40] request for approval: 8035650: Exclude AIX from VS.NET make/windows/projectcreator.make Message-ID: <543EE4E7.40806@oracle.com> Please approve this 8u40 backport request. Without this fix, one cannot build the jdk8u/hs-dev/hotspot repo using visual studio on windows. The fix can be applied cleanly with any modifications. JBS: https://bugs.openjdk.java.net/browse/JDK-8035650 jdk9 review thread: http://comments.gmane.org/gmane.comp.java.openjdk.hotspot.runtime.devel/11044 jdk9 changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/61ab121722b8 8u40 webrev: http://cr.openjdk.java.net/~ccheung/8035650_8u40/webrev/ thanks, Calvin From max.ockner at oracle.com Wed Oct 15 18:04:10 2014 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 15 Oct 2014 14:04:10 -0400 Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx Message-ID: <543EB71A.8000403@oracle.com> Hi all, I am a new member of the Hotspot runtime team in Burlington, MA. Please review my first fix related to safepoint checking. Summary: MutexLockerEx can either acquire a lock with or without a safepoint check. In some cases, a particular lock must either safepoint check always or never to avoid deadlocking. Some other locks have semantics which allow them to avoid deadlocks despite having a safepoint check only some of the time. All locks that are OK having inconsistent safepoint checks have been marked. All locks that should never safepoint check and all locks that should always safepoint check have also been marked. When a MutexLockerEx acquires a lock with or without a safepoint check, the lock's safepointAllowed marker is checked to ensure consistent safepoint checking. Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/ Bug: https://bugs.openjdk.java.net/browse/JDK-8047290 Tested with: jprt "-testset hotspot" jtreg hotspot vm.quick.testlist Whitebox tests: test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: Test expects Assert ("This lock should always have a safepoint check") test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: Test expects Assert ("This lock should never have a safepoint check") test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: code should not assert. (Lock is properly acquired with no safepoint check) test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: code should not assert. (Lock is properly acquired with safepoint check) Thanks, Max From george.triantafillou at oracle.com Wed Oct 15 22:05:18 2014 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 15 Oct 2014 18:05:18 -0400 Subject: [8u40] request for approval: 8035650: Exclude AIX from VS.NET make/windows/projectcreator.make In-Reply-To: <543EE4E7.40806@oracle.com> References: <543EE4E7.40806@oracle.com> Message-ID: <543EEF9E.2040408@oracle.com> Hi Calvin, Looks good. -George On 10/15/2014 5:19 PM, Calvin Cheung wrote: > Please approve this 8u40 backport request. Without this fix, one > cannot build the jdk8u/hs-dev/hotspot repo using visual studio on > windows. The fix can be applied cleanly with any modifications. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8035650 > jdk9 review thread: > http://comments.gmane.org/gmane.comp.java.openjdk.hotspot.runtime.devel/11044 > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/61ab121722b8 > 8u40 webrev: http://cr.openjdk.java.net/~ccheung/8035650_8u40/webrev/ > > thanks, > Calvin > From calvin.cheung at oracle.com Wed Oct 15 22:13:18 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 15 Oct 2014 15:13:18 -0700 Subject: [8u40] request for approval: 8035650: Exclude AIX from VS.NET make/windows/projectcreator.make In-Reply-To: <543EEF9E.2040408@oracle.com> References: <543EE4E7.40806@oracle.com> <543EEF9E.2040408@oracle.com> Message-ID: <543EF17E.3080602@oracle.com> Thanks, George. I'm going to push the fix. Calvin On 10/15/2014 3:05 PM, George Triantafillou wrote: > Hi Calvin, > > Looks good. > > -George > > On 10/15/2014 5:19 PM, Calvin Cheung wrote: >> Please approve this 8u40 backport request. Without this fix, one >> cannot build the jdk8u/hs-dev/hotspot repo using visual studio on >> windows. The fix can be applied cleanly with any modifications. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8035650 >> jdk9 review thread: >> http://comments.gmane.org/gmane.comp.java.openjdk.hotspot.runtime.devel/11044 >> jdk9 changeset: >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/61ab121722b8 >> 8u40 webrev: http://cr.openjdk.java.net/~ccheung/8035650_8u40/webrev/ >> >> thanks, >> Calvin >> > From david.holmes at oracle.com Thu Oct 16 00:54:39 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Oct 2014 10:54:39 +1000 Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx In-Reply-To: <543EB71A.8000403@oracle.com> References: <543EB71A.8000403@oracle.com> Message-ID: <543F174F.7040204@oracle.com> Hi Max, This is looking good. A few high-level initial comments: I think SafepointAllowed should be SafepointCheckNeeded Why are the checks in MutexLocker when the state is maintained in the mutex itself and the mutex/monitor has lock_without_safepoint, and wait() ? I would have expected to see the check in the mutex/monitor methods. Checking consistent usage of the _no_safepoint_check_flag is good. But another part of this is that a monitor/mutex that never checks for safepoints should never be held when a thread blocks at a safepoint - is there some way to easily check that? I was surprised how many locks are actually not checking for safepoints. Did you find any cases where the mutex/monitor was being used inconsistently and incorrectly? Did you analyse the "sometimes" cases to see if they were safe? (Aside: just for fun check out what happens if you lock the Threads_lock with a safepoint check and a safepoint has been requested :) ). Cheers, David On 16/10/2014 4:04 AM, Max Ockner wrote: > Hi all, > > I am a new member of the Hotspot runtime team in Burlington, MA. > Please review my first fix related to safepoint checking. > > Summary: MutexLockerEx can either acquire a lock with or without a > safepoint check. > In some cases, a particular lock must either safepoint check always or > never to avoid deadlocking. > Some other locks have semantics which allow them to avoid deadlocks > despite having a safepoint check only some of the time. > All locks that are OK having inconsistent safepoint checks have been > marked. All locks that should never safepoint check and all locks that > should always safepoint check have also been marked. > When a MutexLockerEx acquires a lock with or without a safepoint check, > the lock's safepointAllowed marker is checked to ensure consistent > safepoint checking. > > Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8047290 > > Tested with: > jprt "-testset hotspot" > jtreg hotspot > vm.quick.testlist > > Whitebox tests: > test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: Test > expects Assert ("This lock should always have a safepoint check") > test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: Test > expects Assert ("This lock should never have a safepoint check") > test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: code > should not assert. (Lock is properly acquired with no safepoint check) > test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: code > should not assert. (Lock is properly acquired with safepoint check) > > Thanks, > Max > From karen.kinnear at oracle.com Thu Oct 16 06:01:17 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 16 Oct 2014 02:01:17 -0400 Subject: RFR: 8043275 Interface initialization for default methods Message-ID: <9EF3DCF2-0B86-441A-AAD9-C693B5233786@oracle.com> Please review for 9 (8u40 back port will follow): webrev: http://cr.openjdk.java.net/~acorn/8043275/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8043275 Summary: Fix superinterface initialization to be based on declaring a non-static instance method rather than on declaring or inheriting one Tested (linux-x64): defmeth - enhanced jtreg TestInterfaceInit and TestInterfaceOrder jtreg hotspot, jdk.lambda, java.util, java.lang jck vm, lang nsk: vm.defmeth (added 2 tests), vm.mlvm, vm.fast.quick Thanks to Dan Smith, Alex Buckley, John Rose for specification clarification. thanks, Karen From andreas.eriksson at oracle.com Thu Oct 16 11:19:09 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Thu, 16 Oct 2014 13:19:09 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543E7B08.8040305@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> <543E77CA.3090806@oracle.com> <543E7B08.8040305@oracle.com> Message-ID: <543FA9AD.2070404@oracle.com> On 2014-10-15 15:47, Daniel D. Daugherty wrote: > On 10/15/14 7:34 AM, Coleen Phillimore wrote: >> >> There are lots of other rewrite_cp_refs_in* function calls. Please >> indent your function like them, not differently. > > The above implies that my answer below was made without sufficient > context... my apologies for that. > > The general rule is to follow the existing style in the file so > if there are rewrite_cp_refs_in* function calls in the file, then > please follow that style. Unless, of course, you want to fix all > of them to follow the HotSpot style guideline: > > https://wiki.openjdk.java.net/display/HotSpot/StyleGuide > > > Use good taste to break lines and align corresponding tokens > > on adjacent lines. > > but that may cause Coleen some heartburn :-) I fixed the calls to follow the already existing indent style. I have also made changes to the test, which I hope Joel can take a look at. New webrev: http://cr.openjdk.java.net/~aeriksso/8057043/webrev.01/ Thanks, Andreas > > Dan > > >> >> Coleen >> >> On 10/15/14, 9:05 AM, Daniel D. Daugherty wrote: >>> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>>> Thanks Serguei. >>>> >>>> I have a question about the if-blocks that had the wrong indent: >>>> >>>> 2335 if >>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>> >>>> 2336 byte_i, "method_info", THREAD)) { >>>> >>>> How should I indent them? >>> >>> Trying again without the line numbers... >>> >>> if >>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>> >>> byte_i, >>> "method_info", >>> THREAD)) { >>> >>> Just in case, TB messes with the spacing again, the "byte_i" line and >>> "THREAD" lines are aligned under "method_type_annotations". >>> >>> Dan >>> >>> >>>> >>>> /Andreas >>>> >>>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>>> Hi Andreas, >>>>> >>>>> Sorry I did not reply on this early. >>>>> I assumed, it is a thumbs up from me. >>>>> Just wanted make it clean now. :) >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>>> Hi Serguei, thanks for looking at this! >>>>>> >>>>>> I'll make sure to fix the style problems. >>>>>> For the symbolic names / #defines, please see my answer to Coleen. >>>>>> >>>>>> Regards, >>>>>> Andreas >>>>>> >>>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Andreas, >>>>>>> >>>>>>> >>>>>>> Thank you for fixing this issue! >>>>>>> The fix looks nice, I do not see any logical issues. >>>>>>> >>>>>>> >>>>>>> Only minor comments... >>>>>>> >>>>>>> >>>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>>> >>>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>>> 2785 } // end skip_type_annotation_target >>>>>>> 2844 } // end skip_type_annotation_type_path >>>>>>> >>>>>>> The ')' is missed at 2281, 2315. >>>>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>>>> function-end comments in the file. >>>>>>> >>>>>>> >>>>>>> 2335 if >>>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>> >>>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>>> . . . >>>>>>> 2378 if >>>>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>>> >>>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>>> . . . >>>>>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>>> 2429 return false; >>>>>>> 2430 } >>>>>>> 2431 >>>>>>> 2432 if >>>>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>>> 2433 byte_i_ref, THREAD)) { >>>>>>> 2434 return false; >>>>>>> 2435 } >>>>>>> 2436 >>>>>>> 2437 if >>>>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>>> 2438 byte_i_ref, THREAD)) { >>>>>>> 2439 return false; >>>>>>> Wrong indent at 2336, 2379, etc. >>>>>>> >>>>>>> >>>>>>> I also concur with Coleen that it would be good to define and use >>>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>>> >>>>>>> >>>>>>> >>>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>>> >>>>>>> Java indent must be 4, not 2. >>>>>>> >>>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>>>>> TypeAnnotatedTestClass arg) >>>>>>> >>>>>>> The line is too long. >>>>>>> >>>>>>> >>>>>>> 143 } >>>>>>> 144 public static void main(String argv[]) { >>>>>>> . . . >>>>>>> 209 } >>>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>>> 212 } >>>>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>>>> annoTypes) { >>>>>>> 214 for (AnnotatedType p : annoTypes) >>>>>>> checkAnnotations(p.getAnnotations()); >>>>>>> 215 } >>>>>>> 216 private static void >>>>>>> checkAnnotations(Class c) { >>>>>>> . . . >>>>>>> 257 } >>>>>>> 258 public void run() {} >>>>>>> >>>>>>> Adding empty lines between method definitions would improve >>>>>>> readability. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review this patch to RedefineClasses to allow type >>>>>>>> annotations to be preserved. >>>>>>>> >>>>>>>> Summary: >>>>>>>> During redefine / retransform class the constant pool indexes >>>>>>>> can change. >>>>>>>> Since annotations have indexes into the constant pool these >>>>>>>> indexes need to be rewritten. >>>>>>>> This is already done for regular annotations, but not for type >>>>>>>> annotations. >>>>>>>> This patch adds code to add this rewriting for the type >>>>>>>> annotations as well. >>>>>>>> The patch also contains minor changes to >>>>>>>> ClassFileReconstituter, to make sure that type annotations are >>>>>>>> preserved during a redefine / retransform class operation. >>>>>>>> It also has a test that uses asm to change constant pool >>>>>>>> indexes through a retransform, and then verifies that type >>>>>>>> annotations are preserved. >>>>>>>> >>>>>>>> Detail: >>>>>>>> A type annotation struct consists of some target information >>>>>>>> and a type path, followed by a regular annotation struct. >>>>>>>> Constant pool indexes are only present in the regular >>>>>>>> annotation struct. >>>>>>>> The added code skips over the type annotation specific parts, >>>>>>>> then calls previously existing code to rewrite constant pool >>>>>>>> indexes in the regular annotation struct. >>>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more >>>>>>>> info about the type annotation struct. >>>>>>>> >>>>>>>> JPRT with the new test passes without failures on all platforms. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>>> >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>>> >>>>>>>> Regards >>>>>>>> Andreas >>>>>>> >>>>>> >>>>> >>>> >>> >> > From vladimir.x.ivanov at oracle.com Thu Oct 16 11:25:16 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 16 Oct 2014 15:25:16 +0400 Subject: [8u40] Bulk backport request: 8058825, 8059556, 8058828 In-Reply-To: <543ECE82.4000309@oracle.com> References: <543E580F.3020207@oracle.com> <543ECE82.4000309@oracle.com> Message-ID: <543FAB1C.1080704@oracle.com> Thanks, Vladimir. Best regards, Vladimir Ivanov On 10/15/14, 11:44 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/15/14 4:18 AM, Vladimir Ivanov wrote: >> This is a bulk request to backport the following changes into 8u40. They >> were integrated into 9 and cleanly apply to 8u-dev. >> >> (1) 8058825: EA: ConnectionGraph::split_unique_types does incorrect >> scalar replacement >> https://bugs.openjdk.java.net/browse/JDK-8058825 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/19c71767e456 >> >> (2) 8059556: C2: crash while inlining MethodHandle invocation w/ null >> receiver >> https://bugs.openjdk.java.net/browse/JDK-8059556 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9c4780bccc23 >> >> (3) 8058828: Wrong ciConstant type for arrays from >> ConstantPool::_resolved_reference >> https://bugs.openjdk.java.net/browse/JDK-8058828 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/677d7ff6a1cf >> >> Best regards, >> Vladimir Ivanov From kmcguigan at twitter.com Thu Oct 16 13:13:07 2014 From: kmcguigan at twitter.com (Keith McGuigan) Date: Thu, 16 Oct 2014 09:13:07 -0400 Subject: RFR: 8043275 Interface initialization for default methods In-Reply-To: <9EF3DCF2-0B86-441A-AAD9-C693B5233786@oracle.com> References: <9EF3DCF2-0B86-441A-AAD9-C693B5233786@oracle.com> Message-ID: Hi Karen, Why in classFileParser.cpp does the check for 'has_default_methods' check for a method not being private, but the 'declares_default_methods' check omits that check? On Thu, Oct 16, 2014 at 2:01 AM, Karen Kinnear wrote: > > Please review for 9 (8u40 back port will follow): > > webrev: http://cr.openjdk.java.net/~acorn/8043275/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8043275 > > Summary: > Fix superinterface initialization to be based on declaring a non-static > instance method rather than on declaring or inheriting one > > Tested (linux-x64): > defmeth - enhanced > jtreg TestInterfaceInit and TestInterfaceOrder > jtreg hotspot, jdk.lambda, java.util, java.lang > jck vm, lang > nsk: vm.defmeth (added 2 tests), vm.mlvm, vm.fast.quick > > Thanks to Dan Smith, Alex Buckley, John Rose for specification > clarification. > > thanks, > Karen > > -- [image: twitter-icon-large.png] Keith McGuigan @kamggg kmcguigan at twitter.com From max.ockner at oracle.com Thu Oct 16 15:12:35 2014 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 16 Oct 2014 11:12:35 -0400 Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx In-Reply-To: <543F174F.7040204@oracle.com> References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com> Message-ID: <543FE063.2050503@oracle.com> David, Thanks for the comments. I have replied individually to each comment below: On 10/15/2014 8:54 PM, David Holmes wrote: > Hi Max, > > This is looking good. > > A few high-level initial comments: > > I think SafepointAllowed should be SafepointCheckNeeded Sure, I can change this. > Why are the checks in MutexLocker when the state is maintained in the > mutex itself and the mutex/monitor has lock_without_safepoint, and > wait() ? I would have expected to see the > check in the mutex/monitor methods. Good point. This didn't occur to me when I first made the change, but I will move the check into the mutex/monitor locking methods. > Checking consistent usage of the _no_safepoint_check_flag is good. But > another part of this is that a monitor/mutex that never checks for > safepoints should never be held when a thread blocks at a safepoint - > is there some way to easily check that? I was surprised how many locks > are actually not checking for safepoints. Not sure how at the moment, but I can file another bug for this. > Did you find any cases where the mutex/monitor was being used > inconsistently and incorrectly? > Did you analyse the "sometimes" cases to see if they were safe? > (Aside: just for fun check out what happens if you lock the > Threads_lock with a safepoint check and a safepoint has been requested > :) ). I could not verify that any were being used correctly/incorrectly, and I'm afraid that I would break the code if I forced these locks to safepoint check consistently. > Cheers, > David > > On 16/10/2014 4:04 AM, Max Ockner wrote: >> Hi all, >> >> I am a new member of the Hotspot runtime team in Burlington, MA. >> Please review my first fix related to safepoint checking. >> >> Summary: MutexLockerEx can either acquire a lock with or without a >> safepoint check. >> In some cases, a particular lock must either safepoint check always or >> never to avoid deadlocking. >> Some other locks have semantics which allow them to avoid deadlocks >> despite having a safepoint check only some of the time. >> All locks that are OK having inconsistent safepoint checks have been >> marked. All locks that should never safepoint check and all locks that >> should always safepoint check have also been marked. >> When a MutexLockerEx acquires a lock with or without a safepoint check, >> the lock's safepointAllowed marker is checked to ensure consistent >> safepoint checking. >> >> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290 >> >> Tested with: >> jprt "-testset hotspot" >> jtreg hotspot >> vm.quick.testlist >> >> Whitebox tests: >> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: Test >> expects Assert ("This lock should always have a safepoint check") >> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: Test >> expects Assert ("This lock should never have a safepoint check") >> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: code >> should not assert. (Lock is properly acquired with no safepoint check) >> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: code >> should not assert. (Lock is properly acquired with safepoint check) >> >> Thanks, >> Max >> From mandars at cse.iitb.ac.in Thu Oct 16 15:38:01 2014 From: mandars at cse.iitb.ac.in (Mandar Shinde) Date: Thu, 16 Oct 2014 21:08:01 +0530 Subject: Adding compiler optimization to open jdk Message-ID: <543FE659.2010706@cse.iitb.ac.in> Hi, I want to add an optimization to openjdk 6 (like some modifications to existing constant folding or CSE optimization), for which i have downloaded the source bundle. However I am not able to figure out where to add the optimization and see my changes reflected in the code. Also in some file like for Eg.: hotspot/src/share/vm/c1/c1_Canonicalizer.cpp there are statements like /tty->print_cr(). My question is where can we see these statements printed once we send our java source file to the compiler? Thanks, ~Mandar From rednaxelafx at gmail.com Thu Oct 16 23:10:20 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 16 Oct 2014 16:10:20 -0700 Subject: Adding compiler optimization to open jdk In-Reply-To: <543FE659.2010706@cse.iitb.ac.in> References: <543FE659.2010706@cse.iitb.ac.in> Message-ID: Hi Mandar, I would suggest starting with the IR visualizers for HotSpot's two compilers: c1visualizer [1] for C1 and IdealGraphVisualizer [2] for C2. Download them, read their user manual and related papers, and then try them in your experiments. They come in really handy. (By the way, if you're developing features in the VM you're most certainly going to use one of the debug build variants, e.g. fastdebug. Use that when you're doing experiments, it gives you a lot more information then a product build.) If you actually prefer text-based stuff, then you can get the IRs from C1 and C2 via various "Print" VM flags, e.g. -XX:+PrintHIR for C1's HIR, and -XX:+PrintIdeal for C2's IR. - Kris [1]: https://java.net/projects/c1visualizer/ [2]: http://ssw.jku.at/General/Staff/TW/igv.html On Thu, Oct 16, 2014 at 8:38 AM, Mandar Shinde wrote: > Hi, > > I want to add an optimization to openjdk 6 (like some modifications to > existing constant folding or CSE optimization), for which i have downloaded > the source bundle. > > However I am not able to figure out where to add the optimization and see > my changes reflected in the code. > > Also in some file like for > > Eg.: hotspot/src/share/vm/c1/c1_Canonicalizer.cpp there are statements > like /tty->print_cr(). > > My question is where can we see these statements printed once we send our > java source file to the compiler? > > Thanks, > ~Mandar > > From staffan.larsen at oracle.com Fri Oct 17 05:30:45 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 16 Oct 2014 22:30:45 -0700 Subject: RFR (XS) 8060245: update bsd version of jhelper.d to be in sync with the fix of 8009204 on solaris In-Reply-To: <543E0AAE.2060705@oracle.com> References: <543C4421.2070604@oracle.com> <543D6E47.1080002@oracle.com> <543E0AAE.2060705@oracle.com> Message-ID: jhelper.d is not used on OS X. It is possible that it is used on other bsd platforms (although I doubt it), but we don?t support those - that would be done in downstreams projects. We should probably clean this up... Your changes look good, although I don?t know if they are ever used. /Staffan On 14 okt 2014, at 22:48, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Thank you for looking at it! > > Do you mean to move the jhelper.d + deps from bsd to posix? > > I don't know how to answer your question. > What I understand is the jhelper.d has never been tested on bsd platform. > It can be a reason why there is almost no difference with solaris yet. > > In order to use the jhelper.d the dtrace framework on bsd (or posix) must support helpers > in a similar way as it is done on solaris and implement jstack action. > I'd do as minimal as possible here until any commitment is seen in this area. > It is not clear why the jhelper.d was ported on bsd in the first place. > > Please, let me know what is your opinion. > > Thanks, > Serguei > > In general, I have a question > > On 10/14/14 11:41 AM, Coleen Phillimore wrote: >> >> Serguei, >> >> Could the jhelper.d files be put in src/os/posix/dtrace since they only differ by the mangled name for Method::vtable? >> >> Thanks, >> Coleen >> >> >> On 10/13/14, 5:29 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8060245 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8060245-dtrace.1/ >>> >>> >>> Summary: >>> >>> The fix of 8009204 for jhelper.d was applied to the Solaris >>> version only but the bsd version must match it too. >>> >>> >>> Testing: >>> N/A: The jhelper.d is not used on bsd yet >>> >>> >>> Thanks, >>> Serguei >> > From serguei.spitsyn at oracle.com Fri Oct 17 05:38:42 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Oct 2014 22:38:42 -0700 Subject: RFR (XS) 8060245: update bsd version of jhelper.d to be in sync with the fix of 8009204 on solaris In-Reply-To: References: <543C4421.2070604@oracle.com> <543D6E47.1080002@oracle.com> <543E0AAE.2060705@oracle.com> Message-ID: <5440AB62.4060905@oracle.com> Ok, thanks! Serguei On 10/16/14 10:30 PM, Staffan Larsen wrote: > jhelper.d is not used on OS X. It is possible that it is used on other bsd platforms (although I doubt it), but we don?t support those - that would be done in downstreams projects. We should probably clean this up... > > Your changes look good, although I don?t know if they are ever used. > > /Staffan > > On 14 okt 2014, at 22:48, serguei.spitsyn at oracle.com wrote: > >> Hi Coleen, >> >> Thank you for looking at it! >> >> Do you mean to move the jhelper.d + deps from bsd to posix? >> >> I don't know how to answer your question. >> What I understand is the jhelper.d has never been tested on bsd platform. >> It can be a reason why there is almost no difference with solaris yet. >> >> In order to use the jhelper.d the dtrace framework on bsd (or posix) must support helpers >> in a similar way as it is done on solaris and implement jstack action. >> I'd do as minimal as possible here until any commitment is seen in this area. >> It is not clear why the jhelper.d was ported on bsd in the first place. >> >> Please, let me know what is your opinion. >> >> Thanks, >> Serguei >> >> In general, I have a question >> >> On 10/14/14 11:41 AM, Coleen Phillimore wrote: >>> Serguei, >>> >>> Could the jhelper.d files be put in src/os/posix/dtrace since they only differ by the mangled name for Method::vtable? >>> >>> Thanks, >>> Coleen >>> >>> >>> On 10/13/14, 5:29 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8060245 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8060245-dtrace.1/ >>>> >>>> >>>> Summary: >>>> >>>> The fix of 8009204 for jhelper.d was applied to the Solaris >>>> version only but the bsd version must match it too. >>>> >>>> >>>> Testing: >>>> N/A: The jhelper.d is not used on bsd yet >>>> >>>> >>>> Thanks, >>>> Serguei From albert.noll at oracle.com Fri Oct 17 13:18:01 2014 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 17 Oct 2014 15:18:01 +0200 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop Message-ID: <54411709.6000400@oracle.com> Hi, could I get reviews for this patch: Bug: https://bugs.openjdk.java.net/browse/JDK-8037842 Problem: If the interpreter (or the compilers) fail to allocate from metaspace (e.g., to allocate a MDO), the exception is cleared and - as a result - not reported to the Java application. Not propagating the OOME to the Java application can lead to a serious performance regression, since every attempt to allocate from metaspace (if we have run out of metaspace and a full GC cannot free memory) triggers another full GC. Consequently, the application continues to run and schedules full GCs until (1) a critical allocation (one that throws an OOME) fails, or (2) the application finishes normally (successfully). Note that the VM can continue to execute without allocating MethodCounters or MDOs. Solution 1: Report OOME to the Java application. This solution avoids handling the problem (running a large number of full GCs) in the VM by passing the problem over to the the Java application. I.e., the performance regression is solved by throwing an OOME. The only way to make the application run is to re-run the application with a larger (yet unknown) metaspace size. However, the application could have continued to run (with an undefined performance drop). Note that the metaspace size in the failing test case is artificially small (20m). Should we change the default behavior of Hotspot to fix such a corner case? Also, I am not sure if throwing an OOME in such a case makes Hotspot conform with the Java Language Specification. The Specification says: "Asynchronous exceptions occur only as a result of: An internal error or resource limitation in the Java Virtual Machine that prevents it from implementing the semantics of the Java programming language. In this case, the asynchronous exception that is thrown is an instance of a subclass of VirtualMachineError" An OOME is an asynchronous exception. As I understand the paragraph above, we are only allowed to throw an asynchronous exception, if we are not able to "implement the semantics of the Java programming language". Not being able to run the JIT compiler does not seem to constrain the semantics of the Java language. Solution 2: If allocation from metaspace fails, we (1) report a warning to the user and (2) do not try to allocate MethodCounters and MDO (as well as all other non-critical metaspace allocations) and thereby avoid the overhead from running full GCs. As a result, the application can continue to run. I have not yet worked on such a solution. I just bring this up for discussion. Testing: JPRT Webrev: Here is the webrev for Solution 1. Please note that I am not familiar with this part of the code. http://cr.openjdk.java.net/~anoll/8037842/webrev.00/ May thanks in advance, Albert From vitalyd at gmail.com Fri Oct 17 13:26:56 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 17 Oct 2014 09:26:56 -0400 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <54411709.6000400@oracle.com> References: <54411709.6000400@oracle.com> Message-ID: I think option 2 is better and similar to the situation/warning that's issued when code cache is full and compiler turned off. Just my 2 cents. Sent from my phone On Oct 17, 2014 9:18 AM, "Albert Noll" wrote: > Hi, > > could I get reviews for this patch: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8037842 > > Problem: > If the interpreter (or the compilers) fail to allocate from metaspace > (e.g., to allocate a MDO), the exception > is cleared and - as a result - not reported to the Java application. Not > propagating the OOME to the Java application > can lead to a serious performance regression, since every attempt to > allocate from metaspace (if we have run out > of metaspace and a full GC cannot free memory) triggers another full GC. > Consequently, the application continues > to run and schedules full GCs until (1) a critical allocation (one that > throws an OOME) fails, or (2) the application finishes > normally (successfully). Note that the VM can continue to execute without > allocating MethodCounters or MDOs. > > Solution 1: > Report OOME to the Java application. This solution avoids handling the > problem (running a large number of full GCs) > in the VM by passing the problem over to the the Java application. I.e., > the performance regression is solved by > throwing an OOME. The only way to make the application run is to re-run > the application with a larger (yet unknown) > metaspace size. However, the application could have continued to run (with > an undefined performance drop). > > Note that the metaspace size in the failing test case is artificially > small (20m). Should we change the default behavior of Hotspot > to fix such a corner case? > > Also, I am not sure if throwing an OOME in such a case makes Hotspot > conform with the Java Language Specification. > The Specification says: > > "Asynchronous exceptions occur only as a result of: > > An internal error or resource limitation in the Java Virtual Machine that > prevents > it from implementing the semantics of the Java programming language. In > this > case, the asynchronous exception that is thrown is an instance of a > subclass of > VirtualMachineError" > > An OOME is an asynchronous exception. As I understand the paragraph above, > we are only allowed to throw an asynchronous > exception, if we are not able to "implement the semantics of the Java > programming language". Not being able to run the JIT > compiler does not seem to constrain the semantics of the Java language. > > Solution 2: > If allocation from metaspace fails, we (1) report a warning to the user > and (2) do not try to allocate MethodCounters and MDO > (as well as all other non-critical metaspace allocations) and thereby > avoid the overhead from running full GCs. As a result, the > application can continue to run. I have not yet worked on such a solution. > I just bring this up for discussion. > > Testing: > JPRT > > Webrev: > Here is the webrev for Solution 1. Please note that I am not familiar with > this part of the code. > > http://cr.openjdk.java.net/~anoll/8037842/webrev.00/ > > May thanks in advance, > Albert > > From david.holmes at oracle.com Sat Oct 18 05:29:04 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 18 Oct 2014 15:29:04 +1000 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <54411709.6000400@oracle.com> References: <54411709.6000400@oracle.com> Message-ID: <5441FAA0.5070701@oracle.com> Hi Albert, As using the JIT is just an optimization, an OOME condition in the JIT should not be reported to the Java level code. It should be handled internally with suitable warnings and fallback - as happens elsewhere (but preferably not with vm_exit_out_of_memory! :) ) David On 17/10/2014 11:18 PM, Albert Noll wrote: > Hi, > > could I get reviews for this patch: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8037842 > > Problem: > If the interpreter (or the compilers) fail to allocate from metaspace > (e.g., to allocate a MDO), the exception > is cleared and - as a result - not reported to the Java application. Not > propagating the OOME to the Java application > can lead to a serious performance regression, since every attempt to > allocate from metaspace (if we have run out > of metaspace and a full GC cannot free memory) triggers another full GC. > Consequently, the application continues > to run and schedules full GCs until (1) a critical allocation (one that > throws an OOME) fails, or (2) the application finishes > normally (successfully). Note that the VM can continue to execute > without allocating MethodCounters or MDOs. > > Solution 1: > Report OOME to the Java application. This solution avoids handling the > problem (running a large number of full GCs) > in the VM by passing the problem over to the the Java application. I.e., > the performance regression is solved by > throwing an OOME. The only way to make the application run is to re-run > the application with a larger (yet unknown) > metaspace size. However, the application could have continued to run > (with an undefined performance drop). > > Note that the metaspace size in the failing test case is artificially > small (20m). Should we change the default behavior of Hotspot > to fix such a corner case? > > Also, I am not sure if throwing an OOME in such a case makes Hotspot > conform with the Java Language Specification. > The Specification says: > > "Asynchronous exceptions occur only as a result of: > > An internal error or resource limitation in the Java Virtual Machine > that prevents > it from implementing the semantics of the Java programming language. In > this > case, the asynchronous exception that is thrown is an instance of a > subclass of > VirtualMachineError" > > An OOME is an asynchronous exception. As I understand the paragraph > above, we are only allowed to throw an asynchronous > exception, if we are not able to "implement the semantics of the Java > programming language". Not being able to run the JIT > compiler does not seem to constrain the semantics of the Java language. > > Solution 2: > If allocation from metaspace fails, we (1) report a warning to the user > and (2) do not try to allocate MethodCounters and MDO > (as well as all other non-critical metaspace allocations) and thereby > avoid the overhead from running full GCs. As a result, the > application can continue to run. I have not yet worked on such a > solution. I just bring this up for discussion. > > Testing: > JPRT > > Webrev: > Here is the webrev for Solution 1. Please note that I am not familiar > with this part of the code. > > http://cr.openjdk.java.net/~anoll/8037842/webrev.00/ > > May thanks in advance, > Albert > From erik.helin at oracle.com Mon Oct 20 11:04:17 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 20 Oct 2014 13:04:17 +0200 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <5441FAA0.5070701@oracle.com> References: <54411709.6000400@oracle.com> <5441FAA0.5070701@oracle.com> Message-ID: <5444EC31.1030405@oracle.com> On 2014-10-18 07:29, David Holmes wrote: > Hi Albert, > > As using the JIT is just an optimization, an OOME condition in the JIT > should not be reported to the Java level code. It should be handled > internally with suitable warnings and fallback - as happens elsewhere > (but preferably not with vm_exit_out_of_memory! :) ) The VM can run out of metaspace for two reasons: 1. The user set the flag -XX:MaxMetaspaceSize to value, e.g. 128m. 2. The VM has used up all of the native memory available for the java process (we can't commit more memory). If the VM is operating in scenario two, then the process will most likely have to throw an OOME at some point, either due to a metaspace allocation request or because some other subsystem of the VM tries to allocate native memory and fails. If the user has set the MaxMetaspaceSize, then they have apparently chosen the wrong value, since their Java application needs more metaspace than they think it does. Unless the application, or the VM, can free metaspace memory, the VM will continue in a rather bad state: - no JIT compilation, only iterpretation - no metaspace allocation, i.e. no class loading Please note that just having the interpreter/compiler stop allocating metaspace will not give us back more metaspace. If I had written a Java application that encountered either of these two scenarios, then I would prefer that the application gets an OOME, because something is seriously wrong with my Java process, and I would prefer to find that out as soon as possible (a log message might be missed). However, I'm not familiar with the specification, so I can't comment on if throwing an OOME in either one of this situations is allowed? There might also be some middle-ground here that I'm not aware of, something that is more critical than a warning on stderr but not as dramatic as throwing an OOME. Thanks, Erik > David > > On 17/10/2014 11:18 PM, Albert Noll wrote: >> Hi, >> >> could I get reviews for this patch: >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8037842 >> >> Problem: >> If the interpreter (or the compilers) fail to allocate from metaspace >> (e.g., to allocate a MDO), the exception >> is cleared and - as a result - not reported to the Java application. Not >> propagating the OOME to the Java application >> can lead to a serious performance regression, since every attempt to >> allocate from metaspace (if we have run out >> of metaspace and a full GC cannot free memory) triggers another full GC. >> Consequently, the application continues >> to run and schedules full GCs until (1) a critical allocation (one that >> throws an OOME) fails, or (2) the application finishes >> normally (successfully). Note that the VM can continue to execute >> without allocating MethodCounters or MDOs. >> >> Solution 1: >> Report OOME to the Java application. This solution avoids handling the >> problem (running a large number of full GCs) >> in the VM by passing the problem over to the the Java application. I.e., >> the performance regression is solved by >> throwing an OOME. The only way to make the application run is to re-run >> the application with a larger (yet unknown) >> metaspace size. However, the application could have continued to run >> (with an undefined performance drop). >> >> Note that the metaspace size in the failing test case is artificially >> small (20m). Should we change the default behavior of Hotspot >> to fix such a corner case? >> >> Also, I am not sure if throwing an OOME in such a case makes Hotspot >> conform with the Java Language Specification. >> The Specification says: >> >> "Asynchronous exceptions occur only as a result of: >> >> An internal error or resource limitation in the Java Virtual Machine >> that prevents >> it from implementing the semantics of the Java programming language. In >> this >> case, the asynchronous exception that is thrown is an instance of a >> subclass of >> VirtualMachineError" >> >> An OOME is an asynchronous exception. As I understand the paragraph >> above, we are only allowed to throw an asynchronous >> exception, if we are not able to "implement the semantics of the Java >> programming language". Not being able to run the JIT >> compiler does not seem to constrain the semantics of the Java language. >> >> Solution 2: >> If allocation from metaspace fails, we (1) report a warning to the user >> and (2) do not try to allocate MethodCounters and MDO >> (as well as all other non-critical metaspace allocations) and thereby >> avoid the overhead from running full GCs. As a result, the >> application can continue to run. I have not yet worked on such a >> solution. I just bring this up for discussion. >> >> Testing: >> JPRT >> >> Webrev: >> Here is the webrev for Solution 1. Please note that I am not familiar >> with this part of the code. >> >> http://cr.openjdk.java.net/~anoll/8037842/webrev.00/ >> >> May thanks in advance, >> Albert >> From coleen.phillimore at oracle.com Mon Oct 20 14:04:24 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 20 Oct 2014 10:04:24 -0400 Subject: RFR: 8043275 Interface initialization for default methods In-Reply-To: <9EF3DCF2-0B86-441A-AAD9-C693B5233786@oracle.com> References: <9EF3DCF2-0B86-441A-AAD9-C693B5233786@oracle.com> Message-ID: <54451668.2070305@oracle.com> Karen, This looks great. I only have two small requests for comments. At instanceKlass.cpp right before line 749, can you add a short one line comment about only calling initialize() for interfaces that *declare* concrete methods. In case people miss that subtlety (which I missed at first reading). http://cr.openjdk.java.net/~acorn/8043275/webrev/test/runtime/lambda-features/TestInterfaceInit.java.html The test case could use a comment between 68-72. There's a trick there which is hard to see. The classes that have concrete methods are initialized for 'L' (which is probably an ldc) but then the ones without concrete methods are initialized when you do a getfield of 'v'. I think? I don't need to see another version with comments since they are small requests. thanks, Coleen On 10/16/14, 2:01 AM, Karen Kinnear wrote: > Please review for 9 (8u40 back port will follow): > > webrev: http://cr.openjdk.java.net/~acorn/8043275/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8043275 > > Summary: > Fix superinterface initialization to be based on declaring a non-static instance method rather than on declaring or inheriting one > > Tested (linux-x64): > defmeth - enhanced > jtreg TestInterfaceInit and TestInterfaceOrder > jtreg hotspot, jdk.lambda, java.util, java.lang > jck vm, lang > nsk: vm.defmeth (added 2 tests), vm.mlvm, vm.fast.quick > > Thanks to Dan Smith, Alex Buckley, John Rose for specification clarification. > > thanks, > Karen > From paul.hohensee at gmail.com Mon Oct 20 14:10:43 2014 From: paul.hohensee at gmail.com (Paul Hohensee) Date: Mon, 20 Oct 2014 10:10:43 -0400 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> References: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> Message-ID: Sorry for the delay in responding. Idea seems ok. I'd like to see a webrev. You might start with your original solution (the one I reviewed) just to get a fix in place. Paul On Wed, Oct 15, 2014 at 9:47 AM, Erik ?sterlund wrote: > Hi Paul, > > Thank you for the reply. I like the idea of using inheritance too. > I tried a new solution which is similar to the one proposed and I would > like to hear your comment if this is okay so we are all happy. > > The core idea is to have a general AtomicBase class which implements the > old unspecialized cmpxchg (and possibly other stuff to come), then allow > platforms to /optionally/ define their own AtomicPlatform base classes in > the hierarchy that derive from AtomicBase. Then the last step in the > hierarchy is Atomic which inherits from AtomicPlatform if it is defined and > otherwise AtomicBase. It picks the superclass using SFINAE. The reason for > this is that other ports will not be broken by this performance fix and the > definition of such AtomicPlatform class is completely optional. :) > > Benefits: > * Uses inheritance and looks nice like the inheritance based solution > proposed > * Does not break ports outside of the main repo > * Does not require refactoring of everything (moving all methods from > Atomic to AbstractAtomic for all platforms) > * Changes are local to only the platforms that want to add this > functionality > * Flexible for supporting the future demands > > In a bit more detail, it looks like this: > > atomic.hpp: > > class AtomicBase : AllStatic { > protected: > static jbyte cmpxchg_unspecialized(jbyte exchange_value, volatile jbyte* > dest, jbyte compare_value); > public: > inline static jbyte cmpxchg (jbyte exchange_value, volatile > jbyte* dest, jbyte compare_value) { > return cmpxchg_unspecialized(exchange_value, dest, compare_value); > } > }; > > // Linux > #ifdef TARGET_OS_ARCH_linux_x86 > # include "atomic_linux_x86.hpp" > #endif > > // BSD > #ifdef TARGET_OS_ARCH_bsd_x86 > # include "atomic_bsd_x86.hpp" > #endif > > // ... and the other platforms that benefit from specialized > AtomicPlatform ... > > class AtomicPlatform; // Forward declaration to avoid compiler error when > it is not defined > > // Based on some SFINAE stuff I made and will contribute if you like it. > AtomicSuper will be AtomicPlatform if defined in a platform specific > atomic_os_arch.hpp file, otherwise AtomicBase will be used > typedef base_class::type AtomicSuper; > > // AtomicSuper is now the base class of Atomic, and contains the cmpxchgb > implementation > class Atomic : public AtomicSuper { > // ... > inline static jbyte cmpxchg (jbyte exchange_value, volatile > jbyte* dest, jbyte compare_value) { > // Just call super class implementation > return AtomicSuper::cmpxchg(exchange_value, dest, compare_value); > } > // ... > }; > > A new atomic_os_arch.hpp file looks like this (for platforms that support > this): > class AtomicPlatform : public AtomicBase { > public: > static jbyte cmpxchg(jbyte exchange_value, volatile jbyte* dest, jbyte > compare_value); > }; > > And atomic_os_arch.inline.hpp contains the implementation like before, but > as members of AtomicPlatform instead of Atomic > > For the curious reader, the SFINAE stuff for base_class looks like this: > > template > struct is_base_of_host > { > operator Base*() const; > operator Derived*(); > }; > > // Statically check if two types are related in a class hierarchy > template > struct is_base_of > { > typedef char yes[1]; > typedef char no[2]; > > template > static yes &check(Derived*, T); > static no &check(Base*, int); > > static const bool value = sizeof(check(is_base_of_host(), > int())) == sizeof(yes); > }; > > // The ::type of this struct will be the Desired type if it was defined > // and a subtype of Fallback, otherwise it will be Fallback. > // This is useful when optionally inheriting from a specialized subtype. > template > struct base_class { > template > struct check_inheritance { > typedef T type; > }; > > template > struct check_inheritance { > typedef U type; > }; > > typedef typename check_inheritance Desired>::value, Fallback, Desired>::type type; > }; > > If everyone is happy with this solution, then I will prepare another > webrev and send the patch. :) > Thanks for taking the time to read through this change. > > /Erik > > On 14 Oct 2014, at 19:25, Paul Hohensee wrote: > > > David Holmes asked me to take a look at this > > > >>>>> There is now a new webrev with my jbyte cmpxchg changes here: > >>>>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01 > > > > and comment, so... > > > > The approach is good if you're going to stay with the current framework, > > except that I'd get rid of VM_HAS_SPECIALIZED_BYTE_CMPXCHG (#ifdef's are > > the devil). Just call cmpxchg_general (which should be named > > cmpxchgb_general or maybe cmpxchgb_unspecialized, btw) from an os_cpu > file > > as needed. I.e., no change to atomic.inline.hpp needed. Another way to > > look at it is, cmpxchgb_general/unspecialized is the implementation of > > another specialized version of cmpxchgb, on the same abstraction level as > > the asm versions. > > > > If a rewrite is possible, I'd do it the way David suggests with an > > AbstractAtomic class from which per-platform Atomic classes are derived. > > That's the way VM_Version and ICache are defined. > > > > Paul > > From Jessica.Man at gs.com Mon Oct 20 14:14:43 2014 From: Jessica.Man at gs.com (Man, Jessica) Date: Mon, 20 Oct 2014 15:14:43 +0100 Subject: Backport request: JDK-8031376 to JDK 8 In-Reply-To: <2231FA6B9F83604A8A5304D488A6DF6306ADF4C86A@GSCMEUP13EX.firmwide.corp.gs.com> References: <2231FA6B9F83604A8A5304D488A6DF6306ADF4C86A@GSCMEUP13EX.firmwide.corp.gs.com> Message-ID: This is currently still being held and waiting for approval by the list moderator, could someone please let me know if any progress has been made on this and if there is further information I can provide to help please? Thank you. From: Man, Jessica [Tech] Sent: 13 October 2014 09:44 To: hotspot-dev at openjdk.java.net Subject: Backport request: JDK-8031376 to JDK 8 Hi all, We are affected by the issue reported in JDK-8031376, the fix has gone in JDK 9 hotspot, could we ask for it to be backported into current the JDK 8 dev stream please? The fix is important because we cannot use -verbose:class without the JVM crashing. This is the changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/715bc50198c1 We have verified that the fix does work in our scenario and hence can be applied cleanly into JDK 8. Thank you. Regards, Jessica Man, Technology Goldman Sachs International Christchurch Court | 10-15 Newgate Street | London EC1A 7HD | Tel: +44 (0)20 7774 3695 The Goldman Sachs Group, Inc. All rights reserved. See http://www.gs.com/disclaimer/global_email for important risk disclosures, conflicts of interest and other terms and conditions relating to this e-mail and your reliance on information contained in it. This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. From paul.hohensee at gmail.com Mon Oct 20 14:23:31 2014 From: paul.hohensee at gmail.com (Paul Hohensee) Date: Mon, 20 Oct 2014 10:23:31 -0400 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: References: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> Message-ID: I'd also worry about a couple of other things. First, way back in the mists of time, C++ compilers differed with respect to their template implementations. Hopefully the C++ compiles on all openjdk platforms do what you expect. Second, if you do this, we'll have two alternatives for implementing Atomic, which generally isn't a good thing (vis we have two GC frameworks). I'd want to see every platform switch to the new way of doing things asap and get rid of the old way. Paul On Mon, Oct 20, 2014 at 10:10 AM, Paul Hohensee wrote: > Sorry for the delay in responding. > > Idea seems ok. I'd like to see a webrev. > > You might start with your original solution (the one I reviewed) just to > get a fix in place. > > Paul > > > On Wed, Oct 15, 2014 at 9:47 AM, Erik ?sterlund > wrote: > >> Hi Paul, >> >> Thank you for the reply. I like the idea of using inheritance too. >> I tried a new solution which is similar to the one proposed and I would >> like to hear your comment if this is okay so we are all happy. >> >> The core idea is to have a general AtomicBase class which implements the >> old unspecialized cmpxchg (and possibly other stuff to come), then allow >> platforms to /optionally/ define their own AtomicPlatform base classes in >> the hierarchy that derive from AtomicBase. Then the last step in the >> hierarchy is Atomic which inherits from AtomicPlatform if it is defined and >> otherwise AtomicBase. It picks the superclass using SFINAE. The reason for >> this is that other ports will not be broken by this performance fix and the >> definition of such AtomicPlatform class is completely optional. :) >> >> Benefits: >> * Uses inheritance and looks nice like the inheritance based solution >> proposed >> * Does not break ports outside of the main repo >> * Does not require refactoring of everything (moving all methods from >> Atomic to AbstractAtomic for all platforms) >> * Changes are local to only the platforms that want to add this >> functionality >> * Flexible for supporting the future demands >> >> In a bit more detail, it looks like this: >> >> atomic.hpp: >> >> class AtomicBase : AllStatic { >> protected: >> static jbyte cmpxchg_unspecialized(jbyte exchange_value, volatile >> jbyte* dest, jbyte compare_value); >> public: >> inline static jbyte cmpxchg (jbyte exchange_value, >> volatile jbyte* dest, jbyte compare_value) { >> return cmpxchg_unspecialized(exchange_value, dest, compare_value); >> } >> }; >> >> // Linux >> #ifdef TARGET_OS_ARCH_linux_x86 >> # include "atomic_linux_x86.hpp" >> #endif >> >> // BSD >> #ifdef TARGET_OS_ARCH_bsd_x86 >> # include "atomic_bsd_x86.hpp" >> #endif >> >> // ... and the other platforms that benefit from specialized >> AtomicPlatform ... >> >> class AtomicPlatform; // Forward declaration to avoid compiler error when >> it is not defined >> >> // Based on some SFINAE stuff I made and will contribute if you like it. >> AtomicSuper will be AtomicPlatform if defined in a platform specific >> atomic_os_arch.hpp file, otherwise AtomicBase will be used >> typedef base_class::type AtomicSuper; >> >> // AtomicSuper is now the base class of Atomic, and contains the cmpxchgb >> implementation >> class Atomic : public AtomicSuper { >> // ... >> inline static jbyte cmpxchg (jbyte exchange_value, >> volatile jbyte* dest, jbyte compare_value) { >> // Just call super class implementation >> return AtomicSuper::cmpxchg(exchange_value, dest, compare_value); >> } >> // ... >> }; >> >> A new atomic_os_arch.hpp file looks like this (for platforms that support >> this): >> class AtomicPlatform : public AtomicBase { >> public: >> static jbyte cmpxchg(jbyte exchange_value, volatile jbyte* dest, jbyte >> compare_value); >> }; >> >> And atomic_os_arch.inline.hpp contains the implementation like before, >> but as members of AtomicPlatform instead of Atomic >> >> For the curious reader, the SFINAE stuff for base_class looks like this: >> >> template >> struct is_base_of_host >> { >> operator Base*() const; >> operator Derived*(); >> }; >> >> // Statically check if two types are related in a class hierarchy >> template >> struct is_base_of >> { >> typedef char yes[1]; >> typedef char no[2]; >> >> template >> static yes &check(Derived*, T); >> static no &check(Base*, int); >> >> static const bool value = sizeof(check(is_base_of_host> Derived>(), int())) == sizeof(yes); >> }; >> >> // The ::type of this struct will be the Desired type if it was defined >> // and a subtype of Fallback, otherwise it will be Fallback. >> // This is useful when optionally inheriting from a specialized subtype. >> template >> struct base_class { >> template >> struct check_inheritance { >> typedef T type; >> }; >> >> template >> struct check_inheritance { >> typedef U type; >> }; >> >> typedef typename check_inheritance> Desired>::value, Fallback, Desired>::type type; >> }; >> >> If everyone is happy with this solution, then I will prepare another >> webrev and send the patch. :) >> Thanks for taking the time to read through this change. >> >> /Erik >> >> On 14 Oct 2014, at 19:25, Paul Hohensee wrote: >> >> > David Holmes asked me to take a look at this >> > >> >>>>> There is now a new webrev with my jbyte cmpxchg changes here: >> >>>>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01 >> > >> > and comment, so... >> > >> > The approach is good if you're going to stay with the current framework, >> > except that I'd get rid of VM_HAS_SPECIALIZED_BYTE_CMPXCHG (#ifdef's are >> > the devil). Just call cmpxchg_general (which should be named >> > cmpxchgb_general or maybe cmpxchgb_unspecialized, btw) from an os_cpu >> file >> > as needed. I.e., no change to atomic.inline.hpp needed. Another way to >> > look at it is, cmpxchgb_general/unspecialized is the implementation of >> > another specialized version of cmpxchgb, on the same abstraction level >> as >> > the asm versions. >> > >> > If a rewrite is possible, I'd do it the way David suggests with an >> > AbstractAtomic class from which per-platform Atomic classes are derived. >> > That's the way VM_Version and ICache are defined. >> > >> > Paul >> >> > From joel.franck at oracle.com Mon Oct 20 18:48:09 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 20 Oct 2014 20:48:09 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543FA9AD.2070404@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> <543E77CA.3090806@oracle.com> <543E7B08.8040305@oracle.com> <543FA9AD.2070404@oracle.com> Message-ID: <0833BDCF-841B-4070-B22F-F42AA5CA8F98@oracle.com> Sorry for the delay, looks good Andreas! Thanks for fixing this. cheers /Joel On 16 okt 2014, at 13:19, Andreas Eriksson wrote: > > On 2014-10-15 15:47, Daniel D. Daugherty wrote: >> On 10/15/14 7:34 AM, Coleen Phillimore wrote: >>> >>> There are lots of other rewrite_cp_refs_in* function calls. Please indent your function like them, not differently. >> >> The above implies that my answer below was made without sufficient >> context... my apologies for that. >> >> The general rule is to follow the existing style in the file so >> if there are rewrite_cp_refs_in* function calls in the file, then >> please follow that style. Unless, of course, you want to fix all >> of them to follow the HotSpot style guideline: >> >> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide >> >> > Use good taste to break lines and align corresponding tokens >> > on adjacent lines. >> >> but that may cause Coleen some heartburn :-) > > I fixed the calls to follow the already existing indent style. > I have also made changes to the test, which I hope Joel can take a look at. > > New webrev: > http://cr.openjdk.java.net/~aeriksso/8057043/webrev.01/ > > Thanks, > Andreas > >> >> Dan >> >> >>> >>> Coleen >>> >>> On 10/15/14, 9:05 AM, Daniel D. Daugherty wrote: >>>> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>>>> Thanks Serguei. >>>>> >>>>> I have a question about the if-blocks that had the wrong indent: >>>>> >>>>> 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>> 2336 byte_i, "method_info", THREAD)) { >>>>> >>>>> How should I indent them? >>>> >>>> Trying again without the line numbers... >>>> >>>> if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>> byte_i, "method_info", >>>> THREAD)) { >>>> >>>> Just in case, TB messes with the spacing again, the "byte_i" line and >>>> "THREAD" lines are aligned under "method_type_annotations". >>>> >>>> Dan >>>> >>>> >>>>> >>>>> /Andreas >>>>> >>>>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Andreas, >>>>>> >>>>>> Sorry I did not reply on this early. >>>>>> I assumed, it is a thumbs up from me. >>>>>> Just wanted make it clean now. :) >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>>>> Hi Serguei, thanks for looking at this! >>>>>>> >>>>>>> I'll make sure to fix the style problems. >>>>>>> For the symbolic names / #defines, please see my answer to Coleen. >>>>>>> >>>>>>> Regards, >>>>>>> Andreas >>>>>>> >>>>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Andreas, >>>>>>>> >>>>>>>> >>>>>>>> Thank you for fixing this issue! >>>>>>>> The fix looks nice, I do not see any logical issues. >>>>>>>> >>>>>>>> >>>>>>>> Only minor comments... >>>>>>>> >>>>>>>> >>>>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>>>> >>>>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>>>> 2785 } // end skip_type_annotation_target >>>>>>>> 2844 } // end skip_type_annotation_type_path >>>>>>>> >>>>>>>> The ')' is missed at 2281, 2315. >>>>>>>> The 2397-2844 are inconsistent with the 2345 and other function-end comments in the file. >>>>>>>> >>>>>>>> >>>>>>>> 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>>>> . . . >>>>>>>> 2378 if (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>>>> . . . >>>>>>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>>>> 2429 return false; >>>>>>>> 2430 } >>>>>>>> 2431 >>>>>>>> 2432 if (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>>>> 2433 byte_i_ref, THREAD)) { >>>>>>>> 2434 return false; >>>>>>>> 2435 } >>>>>>>> 2436 >>>>>>>> 2437 if (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>>>> 2438 byte_i_ref, THREAD)) { >>>>>>>> 2439 return false; >>>>>>>> Wrong indent at 2336, 2379, etc. >>>>>>>> >>>>>>>> >>>>>>>> I also concur with Coleen that it would be good to define and use >>>>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>>>> >>>>>>>> Java indent must be 4, not 2. >>>>>>>> >>>>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") TypeAnnotatedTestClass arg) >>>>>>>> >>>>>>>> The line is too long. >>>>>>>> >>>>>>>> >>>>>>>> 143 } >>>>>>>> 144 public static void main(String argv[]) { >>>>>>>> . . . >>>>>>>> 209 } >>>>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>>>> 212 } >>>>>>>> 213 private static void checkAnnotations(AnnotatedType[] annoTypes) { >>>>>>>> 214 for (AnnotatedType p : annoTypes) checkAnnotations(p.getAnnotations()); >>>>>>>> 215 } >>>>>>>> 216 private static void checkAnnotations(Class c) { >>>>>>>> . . . >>>>>>>> 257 } >>>>>>>> 258 public void run() {} >>>>>>>> >>>>>>>> Adding empty lines between method definitions would improve readability. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review this patch to RedefineClasses to allow type annotations to be preserved. >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> During redefine / retransform class the constant pool indexes can change. >>>>>>>>> Since annotations have indexes into the constant pool these indexes need to be rewritten. >>>>>>>>> This is already done for regular annotations, but not for type annotations. >>>>>>>>> This patch adds code to add this rewriting for the type annotations as well. >>>>>>>>> The patch also contains minor changes to ClassFileReconstituter, to make sure that type annotations are preserved during a redefine / retransform class operation. >>>>>>>>> It also has a test that uses asm to change constant pool indexes through a retransform, and then verifies that type annotations are preserved. >>>>>>>>> >>>>>>>>> Detail: >>>>>>>>> A type annotation struct consists of some target information and a type path, followed by a regular annotation struct. >>>>>>>>> Constant pool indexes are only present in the regular annotation struct. >>>>>>>>> The added code skips over the type annotation specific parts, then calls previously existing code to rewrite constant pool indexes in the regular annotation struct. >>>>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info about the type annotation struct. >>>>>>>>> >>>>>>>>> JPRT with the new test passes without failures on all platforms. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>>>> >>>>>>>>> Bug: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Andreas From vladimir.kozlov at oracle.com Mon Oct 20 19:11:05 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Oct 2014 12:11:05 -0700 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <54411709.6000400@oracle.com> References: <54411709.6000400@oracle.com> Message-ID: <54455E49.7010603@oracle.com> Inability to allocate in metaspace is different from allocation in codecache. The last one is JIT specific and needs only warning since whole java process is (almost) not impacted. The first one should produce OOM the same ways as it was when we had PermGen. I think the solution 1 is correct. Thanks, Vladimir On 10/17/14 6:18 AM, Albert Noll wrote: > Hi, > > could I get reviews for this patch: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8037842 > > Problem: > If the interpreter (or the compilers) fail to allocate from metaspace > (e.g., to allocate a MDO), the exception > is cleared and - as a result - not reported to the Java application. Not > propagating the OOME to the Java application > can lead to a serious performance regression, since every attempt to > allocate from metaspace (if we have run out > of metaspace and a full GC cannot free memory) triggers another full GC. > Consequently, the application continues > to run and schedules full GCs until (1) a critical allocation (one that > throws an OOME) fails, or (2) the application finishes > normally (successfully). Note that the VM can continue to execute > without allocating MethodCounters or MDOs. > > Solution 1: > Report OOME to the Java application. This solution avoids handling the > problem (running a large number of full GCs) > in the VM by passing the problem over to the the Java application. I.e., > the performance regression is solved by > throwing an OOME. The only way to make the application run is to re-run > the application with a larger (yet unknown) > metaspace size. However, the application could have continued to run > (with an undefined performance drop). > > Note that the metaspace size in the failing test case is artificially > small (20m). Should we change the default behavior of Hotspot > to fix such a corner case? > > Also, I am not sure if throwing an OOME in such a case makes Hotspot > conform with the Java Language Specification. > The Specification says: > > "Asynchronous exceptions occur only as a result of: > > An internal error or resource limitation in the Java Virtual Machine > that prevents > it from implementing the semantics of the Java programming language. In > this > case, the asynchronous exception that is thrown is an instance of a > subclass of > VirtualMachineError" > > An OOME is an asynchronous exception. As I understand the paragraph > above, we are only allowed to throw an asynchronous > exception, if we are not able to "implement the semantics of the Java > programming language". Not being able to run the JIT > compiler does not seem to constrain the semantics of the Java language. > > Solution 2: > If allocation from metaspace fails, we (1) report a warning to the user > and (2) do not try to allocate MethodCounters and MDO > (as well as all other non-critical metaspace allocations) and thereby > avoid the overhead from running full GCs. As a result, the > application can continue to run. I have not yet worked on such a > solution. I just bring this up for discussion. > > Testing: > JPRT > > Webrev: > Here is the webrev for Solution 1. Please note that I am not familiar > with this part of the code. > > http://cr.openjdk.java.net/~anoll/8037842/webrev.00/ > > May thanks in advance, > Albert > From serguei.spitsyn at oracle.com Mon Oct 20 19:54:23 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 Oct 2014 12:54:23 -0700 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <543FA9AD.2070404@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> <543E77CA.3090806@oracle.com> <543E7B08.8040305@oracle.com> <543FA9AD.2070404@oracle.com> Message-ID: <5445686F.4090103@oracle.com> Hi Andreas, Sorry for the delay. On 10/16/14 4:19 AM, Andreas Eriksson wrote: > > On 2014-10-15 15:47, Daniel D. Daugherty wrote: >> On 10/15/14 7:34 AM, Coleen Phillimore wrote: >>> >>> There are lots of other rewrite_cp_refs_in* function calls. Please >>> indent your function like them, not differently. >> >> The above implies that my answer below was made without sufficient >> context... my apologies for that. >> >> The general rule is to follow the existing style in the file so >> if there are rewrite_cp_refs_in* function calls in the file, then >> please follow that style. Unless, of course, you want to fix all >> of them to follow the HotSpot style guideline: >> >> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide >> >> > Use good taste to break lines and align corresponding tokens >> > on adjacent lines. >> >> but that may cause Coleen some heartburn :-) > > I fixed the calls to follow the already existing indent style. > I have also made changes to the test, which I hope Joel can take a > look at. > > New webrev: > http://cr.openjdk.java.net/~aeriksso/8057043/webrev.01/ The fix looks good. A couple of comments about the test. The method testTransformAndVerify() is too big. At least, it looks like there are some ways to refactor it to make calls to smaller methods. There are two directions of doing it: - make a smaller method out of each block: 217-236, 238-260, 262-276, 311-329, 331-351, 353-367 - some of the lines sequences looks very typical: 221 at = c.getDeclaredField("typeAnnotatedArray").getAnnotatedType(); 222 arrayTA1 = at.getAnnotations()[0]; 223 verifyTestAnnSite(arrayTA1, "array1"); 224 225 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); 226 arrayTA2 = at.getAnnotations()[0]; 227 verifyTestAnnSite(arrayTA2, "array2"); 228 229 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); 230 arrayTA3 = at.getAnnotations()[0]; 231 verifyTestAnnSite(arrayTA3, "array3"); 232 233 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); 234 arrayTA4 = at.getAnnotations()[0]; 235 verifyTestAnnSite(arrayTA4, "array4"); But I leave it up to you. Another step to improve the readability is to add a short comment for each block of code saying what is done there. Thanks, Serguei > > Thanks, > Andreas > >> >> Dan >> >> >>> >>> Coleen >>> >>> On 10/15/14, 9:05 AM, Daniel D. Daugherty wrote: >>>> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>>>> Thanks Serguei. >>>>> >>>>> I have a question about the if-blocks that had the wrong indent: >>>>> >>>>> 2335 if >>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>> >>>>> 2336 byte_i, "method_info", THREAD)) { >>>>> >>>>> How should I indent them? >>>> >>>> Trying again without the line numbers... >>>> >>>> if >>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>> >>>> byte_i, >>>> "method_info", >>>> THREAD)) { >>>> >>>> Just in case, TB messes with the spacing again, the "byte_i" line and >>>> "THREAD" lines are aligned under "method_type_annotations". >>>> >>>> Dan >>>> >>>> >>>>> >>>>> /Andreas >>>>> >>>>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Andreas, >>>>>> >>>>>> Sorry I did not reply on this early. >>>>>> I assumed, it is a thumbs up from me. >>>>>> Just wanted make it clean now. :) >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>>>> Hi Serguei, thanks for looking at this! >>>>>>> >>>>>>> I'll make sure to fix the style problems. >>>>>>> For the symbolic names / #defines, please see my answer to Coleen. >>>>>>> >>>>>>> Regards, >>>>>>> Andreas >>>>>>> >>>>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Andreas, >>>>>>>> >>>>>>>> >>>>>>>> Thank you for fixing this issue! >>>>>>>> The fix looks nice, I do not see any logical issues. >>>>>>>> >>>>>>>> >>>>>>>> Only minor comments... >>>>>>>> >>>>>>>> >>>>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>>>> >>>>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>>>> 2785 } // end skip_type_annotation_target >>>>>>>> 2844 } // end skip_type_annotation_type_path >>>>>>>> >>>>>>>> The ')' is missed at 2281, 2315. >>>>>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>>>>> function-end comments in the file. >>>>>>>> >>>>>>>> >>>>>>>> 2335 if >>>>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>>> >>>>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>>>> . . . >>>>>>>> 2378 if >>>>>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>>>> >>>>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>>>> . . . >>>>>>>> 2427 if >>>>>>>> (!skip_type_annotation_target(type_annotations_typeArray, >>>>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>>>> 2429 return false; >>>>>>>> 2430 } >>>>>>>> 2431 >>>>>>>> 2432 if >>>>>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>>>> 2433 byte_i_ref, THREAD)) { >>>>>>>> 2434 return false; >>>>>>>> 2435 } >>>>>>>> 2436 >>>>>>>> 2437 if >>>>>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>>>> 2438 byte_i_ref, THREAD)) { >>>>>>>> 2439 return false; >>>>>>>> Wrong indent at 2336, 2379, etc. >>>>>>>> >>>>>>>> >>>>>>>> I also concur with Coleen that it would be good to define and use >>>>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>>>> >>>>>>>> Java indent must be 4, not 2. >>>>>>>> >>>>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>>>>>> TypeAnnotatedTestClass arg) >>>>>>>> >>>>>>>> The line is too long. >>>>>>>> >>>>>>>> >>>>>>>> 143 } >>>>>>>> 144 public static void main(String argv[]) { >>>>>>>> . . . >>>>>>>> 209 } >>>>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>>>> 212 } >>>>>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>>>>> annoTypes) { >>>>>>>> 214 for (AnnotatedType p : annoTypes) >>>>>>>> checkAnnotations(p.getAnnotations()); >>>>>>>> 215 } >>>>>>>> 216 private static void >>>>>>>> checkAnnotations(Class c) { >>>>>>>> . . . >>>>>>>> 257 } >>>>>>>> 258 public void run() {} >>>>>>>> >>>>>>>> Adding empty lines between method definitions would improve >>>>>>>> readability. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review this patch to RedefineClasses to allow type >>>>>>>>> annotations to be preserved. >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> During redefine / retransform class the constant pool indexes >>>>>>>>> can change. >>>>>>>>> Since annotations have indexes into the constant pool these >>>>>>>>> indexes need to be rewritten. >>>>>>>>> This is already done for regular annotations, but not for type >>>>>>>>> annotations. >>>>>>>>> This patch adds code to add this rewriting for the type >>>>>>>>> annotations as well. >>>>>>>>> The patch also contains minor changes to >>>>>>>>> ClassFileReconstituter, to make sure that type annotations are >>>>>>>>> preserved during a redefine / retransform class operation. >>>>>>>>> It also has a test that uses asm to change constant pool >>>>>>>>> indexes through a retransform, and then verifies that type >>>>>>>>> annotations are preserved. >>>>>>>>> >>>>>>>>> Detail: >>>>>>>>> A type annotation struct consists of some target information >>>>>>>>> and a type path, followed by a regular annotation struct. >>>>>>>>> Constant pool indexes are only present in the regular >>>>>>>>> annotation struct. >>>>>>>>> The added code skips over the type annotation specific parts, >>>>>>>>> then calls previously existing code to rewrite constant pool >>>>>>>>> indexes in the regular annotation struct. >>>>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more >>>>>>>>> info about the type annotation struct. >>>>>>>>> >>>>>>>>> JPRT with the new test passes without failures on all platforms. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>>>> >>>>>>>>> Bug: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Andreas >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Mon Oct 20 21:16:13 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Oct 2014 14:16:13 -0700 Subject: [8u40] RFR (XS) 8059139: It should be possible to explicitly disable usage of TZCNT instr w/ -XX:-UseBMI1Instructions Message-ID: <54457B9D.103@oracle.com> Backport request. Changes was pushed into jdk9 last week. Nighties are fine. Changes are applied cleanly. https://bugs.openjdk.java.net/browse/JDK-8059139 http://cr.openjdk.java.net/~kvn/8059139/webrev/ http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3c4254d2df12 Thanks, Vladimir From christian.thalinger at oracle.com Mon Oct 20 22:57:20 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 20 Oct 2014 15:57:20 -0700 Subject: [8u40] RFR (XS) 8059139: It should be possible to explicitly disable usage of TZCNT instr w/ -XX:-UseBMI1Instructions In-Reply-To: <54457B9D.103@oracle.com> References: <54457B9D.103@oracle.com> Message-ID: <931561E0-3B21-4645-8BBC-204257167AB7@oracle.com> Looks good. > On Oct 20, 2014, at 2:16 PM, Vladimir Kozlov wrote: > > Backport request. Changes was pushed into jdk9 last week. Nighties are fine. Changes are applied cleanly. > > https://bugs.openjdk.java.net/browse/JDK-8059139 > http://cr.openjdk.java.net/~kvn/8059139/webrev/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3c4254d2df12 > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Mon Oct 20 23:02:06 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Oct 2014 16:02:06 -0700 Subject: [8u40] RFR (XS) 8059139: It should be possible to explicitly disable usage of TZCNT instr w/ -XX:-UseBMI1Instructions In-Reply-To: <931561E0-3B21-4645-8BBC-204257167AB7@oracle.com> References: <54457B9D.103@oracle.com> <931561E0-3B21-4645-8BBC-204257167AB7@oracle.com> Message-ID: <5445946E.6040609@oracle.com> Thank you, Chris Vladimir On 10/20/14 3:57 PM, Christian Thalinger wrote: > Looks good. > >> On Oct 20, 2014, at 2:16 PM, Vladimir Kozlov wrote: >> >> Backport request. Changes was pushed into jdk9 last week. Nighties are fine. Changes are applied cleanly. >> >> https://bugs.openjdk.java.net/browse/JDK-8059139 >> http://cr.openjdk.java.net/~kvn/8059139/webrev/ >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3c4254d2df12 >> >> Thanks, >> Vladimir > From erik.osterlund at lnu.se Mon Oct 20 23:04:56 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Mon, 20 Oct 2014 23:04:56 +0000 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: References: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> Message-ID: Hi Paul, Thank you for your reply. Webrev for new inheritance based solution: http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.02/ In my opinion it does not create a conflict that there are two different systems. There are 3 levels in the hierarchy, all with well defined responsibilities: AtomicBase - atomics that can be generalized for all platforms, AtomicPlatform (optional) for atomics overriding AtomicBase with specialized implementations, and Atomic for atomics that always look different on all platforms (and hence has little benefit of inheritance). With this view (and responsibilities), it is already consistent AFAIK unless we have more things that could be generalized that should be shifted up in the hierarchy which would be nice. Do you propose we use my old solution (http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01/) for now which is less reliant on compiler support and strictly only fixes the jbyte cmpxchg in a less architecturally intrusive way, or the new cleaner inheritance variant? Thanks, /Erik On 20 Oct 2014, at 16:23, Paul Hohensee > wrote: I'd also worry about a couple of other things. First, way back in the mists of time, C++ compilers differed with respect to their template implementations. Hopefully the C++ compiles on all openjdk platforms do what you expect. Second, if you do this, we'll have two alternatives for implementing Atomic, which generally isn't a good thing (vis we have two GC frameworks). I'd want to see every platform switch to the new way of doing things asap and get rid of the old way. Paul On Mon, Oct 20, 2014 at 10:10 AM, Paul Hohensee > wrote: Sorry for the delay in responding. Idea seems ok. I'd like to see a webrev. You might start with your original solution (the one I reviewed) just to get a fix in place. Paul On Wed, Oct 15, 2014 at 9:47 AM, Erik ?sterlund > wrote: Hi Paul, Thank you for the reply. I like the idea of using inheritance too. I tried a new solution which is similar to the one proposed and I would like to hear your comment if this is okay so we are all happy. The core idea is to have a general AtomicBase class which implements the old unspecialized cmpxchg (and possibly other stuff to come), then allow platforms to /optionally/ define their own AtomicPlatform base classes in the hierarchy that derive from AtomicBase. Then the last step in the hierarchy is Atomic which inherits from AtomicPlatform if it is defined and otherwise AtomicBase. It picks the superclass using SFINAE. The reason for this is that other ports will not be broken by this performance fix and the definition of such AtomicPlatform class is completely optional. :) Benefits: * Uses inheritance and looks nice like the inheritance based solution proposed * Does not break ports outside of the main repo * Does not require refactoring of everything (moving all methods from Atomic to AbstractAtomic for all platforms) * Changes are local to only the platforms that want to add this functionality * Flexible for supporting the future demands In a bit more detail, it looks like this: atomic.hpp: class AtomicBase : AllStatic { protected: static jbyte cmpxchg_unspecialized(jbyte exchange_value, volatile jbyte* dest, jbyte compare_value); public: inline static jbyte cmpxchg (jbyte exchange_value, volatile jbyte* dest, jbyte compare_value) { return cmpxchg_unspecialized(exchange_value, dest, compare_value); } }; // Linux #ifdef TARGET_OS_ARCH_linux_x86 # include "atomic_linux_x86.hpp" #endif // BSD #ifdef TARGET_OS_ARCH_bsd_x86 # include "atomic_bsd_x86.hpp" #endif // ... and the other platforms that benefit from specialized AtomicPlatform ... class AtomicPlatform; // Forward declaration to avoid compiler error when it is not defined // Based on some SFINAE stuff I made and will contribute if you like it. AtomicSuper will be AtomicPlatform if defined in a platform specific atomic_os_arch.hpp file, otherwise AtomicBase will be used typedef base_class::type AtomicSuper; // AtomicSuper is now the base class of Atomic, and contains the cmpxchgb implementation class Atomic : public AtomicSuper { // ... inline static jbyte cmpxchg (jbyte exchange_value, volatile jbyte* dest, jbyte compare_value) { // Just call super class implementation return AtomicSuper::cmpxchg(exchange_value, dest, compare_value); } // ... }; A new atomic_os_arch.hpp file looks like this (for platforms that support this): class AtomicPlatform : public AtomicBase { public: static jbyte cmpxchg(jbyte exchange_value, volatile jbyte* dest, jbyte compare_value); }; And atomic_os_arch.inline.hpp contains the implementation like before, but as members of AtomicPlatform instead of Atomic For the curious reader, the SFINAE stuff for base_class looks like this: template struct is_base_of_host { operator Base*() const; operator Derived*(); }; // Statically check if two types are related in a class hierarchy template struct is_base_of { typedef char yes[1]; typedef char no[2]; template static yes &check(Derived*, T); static no &check(Base*, int); static const bool value = sizeof(check(is_base_of_host(), int())) == sizeof(yes); }; // The ::type of this struct will be the Desired type if it was defined // and a subtype of Fallback, otherwise it will be Fallback. // This is useful when optionally inheriting from a specialized subtype. template struct base_class { template struct check_inheritance { typedef T type; }; template struct check_inheritance { typedef U type; }; typedef typename check_inheritance::value, Fallback, Desired>::type type; }; If everyone is happy with this solution, then I will prepare another webrev and send the patch. :) Thanks for taking the time to read through this change. /Erik On 14 Oct 2014, at 19:25, Paul Hohensee > wrote: > David Holmes asked me to take a look at this > >>>>> There is now a new webrev with my jbyte cmpxchg changes here: >>>>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01 > > and comment, so... > > The approach is good if you're going to stay with the current framework, > except that I'd get rid of VM_HAS_SPECIALIZED_BYTE_CMPXCHG (#ifdef's are > the devil). Just call cmpxchg_general (which should be named > cmpxchgb_general or maybe cmpxchgb_unspecialized, btw) from an os_cpu file > as needed. I.e., no change to atomic.inline.hpp needed. Another way to > look at it is, cmpxchgb_general/unspecialized is the implementation of > another specialized version of cmpxchgb, on the same abstraction level as > the asm versions. > > If a rewrite is possible, I'd do it the way David suggests with an > AbstractAtomic class from which per-platform Atomic classes are derived. > That's the way VM_Version and ICache are defined. > > Paul From david.holmes at oracle.com Tue Oct 21 01:03:52 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Oct 2014 11:03:52 +1000 Subject: Backport request: JDK-8031376 to JDK 8 In-Reply-To: References: <2231FA6B9F83604A8A5304D488A6DF6306ADF4C86A@GSCMEUP13EX.firmwide.corp.gs.com> Message-ID: <5445B0F8.7000303@oracle.com> On 21/10/2014 12:14 AM, Man, Jessica wrote: > This is currently still being held and waiting for approval by the list moderator, could someone please let me know if any progress has been made on this and if there is further information I can provide to help please? If still held then no one will have seen it. Something seems amiss with the mailing list as the archive only goes up to Oct 14. I don't see any issue with getting this backported to 8u. If noone else volunteers I will pick it up. David > Thank you. > > From: Man, Jessica [Tech] > Sent: 13 October 2014 09:44 > To: hotspot-dev at openjdk.java.net > Subject: Backport request: JDK-8031376 to JDK 8 > > Hi all, > > We are affected by the issue reported in JDK-8031376, the fix has gone in JDK 9 hotspot, could we ask for it to be backported into current the JDK 8 dev stream please? The fix is important because we cannot use -verbose:class without the JVM crashing. > > This is the changeset: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/715bc50198c1 > > We have verified that the fix does work in our scenario and hence can be applied cleanly into JDK 8. > > Thank you. > > Regards, > Jessica Man, Technology > Goldman Sachs International > Christchurch Court | 10-15 Newgate Street | London EC1A 7HD | Tel: +44 (0)20 7774 3695 > > The Goldman Sachs Group, Inc. All rights reserved. > See http://www.gs.com/disclaimer/global_email for important risk disclosures, conflicts of interest and other terms and conditions relating to this e-mail and your reliance on information contained in it. This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. > From david.holmes at oracle.com Tue Oct 21 01:17:52 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Oct 2014 11:17:52 +1000 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <54455E49.7010603@oracle.com> References: <54411709.6000400@oracle.com> <54455E49.7010603@oracle.com> Message-ID: <5445B440.1040806@oracle.com> On 21/10/2014 5:11 AM, Vladimir Kozlov wrote: > Inability to allocate in metaspace is different from allocation in > codecache. > > The last one is JIT specific and needs only warning since whole java > process is (almost) not impacted. > > The first one should produce OOM the same ways as it was when we had > PermGen. > > I think the solution 1 is correct. Throwing an asynchronous exception is very bad and should always be a last resort. Such exceptions can lead to corrupt state very easily. IMHO problems encountered by the JIT should not manifest as Java-level exceptions. I would also consider them (regardless of whether they have always been there) a violation of the spec as quoted by Albert. David > Thanks, > Vladimir > > On 10/17/14 6:18 AM, Albert Noll wrote: >> Hi, >> >> could I get reviews for this patch: >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8037842 >> >> Problem: >> If the interpreter (or the compilers) fail to allocate from metaspace >> (e.g., to allocate a MDO), the exception >> is cleared and - as a result - not reported to the Java application. Not >> propagating the OOME to the Java application >> can lead to a serious performance regression, since every attempt to >> allocate from metaspace (if we have run out >> of metaspace and a full GC cannot free memory) triggers another full GC. >> Consequently, the application continues >> to run and schedules full GCs until (1) a critical allocation (one that >> throws an OOME) fails, or (2) the application finishes >> normally (successfully). Note that the VM can continue to execute >> without allocating MethodCounters or MDOs. >> >> Solution 1: >> Report OOME to the Java application. This solution avoids handling the >> problem (running a large number of full GCs) >> in the VM by passing the problem over to the the Java application. I.e., >> the performance regression is solved by >> throwing an OOME. The only way to make the application run is to re-run >> the application with a larger (yet unknown) >> metaspace size. However, the application could have continued to run >> (with an undefined performance drop). >> >> Note that the metaspace size in the failing test case is artificially >> small (20m). Should we change the default behavior of Hotspot >> to fix such a corner case? >> >> Also, I am not sure if throwing an OOME in such a case makes Hotspot >> conform with the Java Language Specification. >> The Specification says: >> >> "Asynchronous exceptions occur only as a result of: >> >> An internal error or resource limitation in the Java Virtual Machine >> that prevents >> it from implementing the semantics of the Java programming language. In >> this >> case, the asynchronous exception that is thrown is an instance of a >> subclass of >> VirtualMachineError" >> >> An OOME is an asynchronous exception. As I understand the paragraph >> above, we are only allowed to throw an asynchronous >> exception, if we are not able to "implement the semantics of the Java >> programming language". Not being able to run the JIT >> compiler does not seem to constrain the semantics of the Java language. >> >> Solution 2: >> If allocation from metaspace fails, we (1) report a warning to the user >> and (2) do not try to allocate MethodCounters and MDO >> (as well as all other non-critical metaspace allocations) and thereby >> avoid the overhead from running full GCs. As a result, the >> application can continue to run. I have not yet worked on such a >> solution. I just bring this up for discussion. >> >> Testing: >> JPRT >> >> Webrev: >> Here is the webrev for Solution 1. Please note that I am not familiar >> with this part of the code. >> >> http://cr.openjdk.java.net/~anoll/8037842/webrev.00/ >> >> May thanks in advance, >> Albert >> From albert.noll at oracle.com Tue Oct 21 09:10:06 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 21 Oct 2014 11:10:06 +0200 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <5445B440.1040806@oracle.com> References: <54411709.6000400@oracle.com> <54455E49.7010603@oracle.com> <5445B440.1040806@oracle.com> Message-ID: <544622EE.5080106@oracle.com> Hi, I agree with David. Executing a Java program with 'java myProgram' does not imply that we *must* be able to execute the program using a JIT compiler. Throwing an OOME because we are unable to compile a method (due to insufficient metaspace) can cause much more problems than it solves. For example, I tried to execute the JVMSPEC2008 compiler.compiler benchmark as follows: java -XX:+ExitOnMetaSpaceAllocFail -XX:MaxMetaspaceSize=16m -jar SPECjvm2008.jar -ikv -wt 10 -i 5 -it 60 compiler.compiler If the "ExitOnMetaSpaceAllocFail" is enabled, the JVM exits if we are unable to allocate MethodCounters and MDO. On my laptop, compiler.compiler finishes *without a performance regression* if ExitOnMetaSpaceAllocFail is false. If ExitOnMetaSpaceAllocFail is true, the run does not finish because we are out of metaspace. Such a behavior is clearly a regression. Given the large number of customers we have, it seems likely that throwing an OOME will cause trouble. In addition, I think that throwing an OOME exposes implementation details of hotspot to the user that are not easy to understand. To understand the cause of the OOME (and I think it is very important for the user to understand the behavior of the JVM) the user must know that Hotspot uses JIT compilers that store method profiles in metaspace. If we decide to throw an OOME, it will be hard to debug the program, since compilers are not deterministic in when a method is compiled. I.e., the customer can get OOMEs at random (asynchronous) places. From a serviceability point of view, throwing an OOME is a poor choice. I think we could add an option that lets the user decide on the behavior (ExitOnMetaSpaceAllocFail). However, the default behavior should be according to the Spec, i.e., ExitOnMetaSpaceAllocFail should be 'false' by default. I think it is reasonable to assume that someone who knows about -XX:MaxMetaspaceSize will know about -XX:ExitOnMetaSpaceAllocFail. The argument that performance problems are 'hidden' by not throwing an OOME is valid, but can be mitigated by such a flag. Thanks, Albert On 10/21/2014 03:17 AM, David Holmes wrote: > On 21/10/2014 5:11 AM, Vladimir Kozlov wrote: >> Inability to allocate in metaspace is different from allocation in >> codecache. >> >> The last one is JIT specific and needs only warning since whole java >> process is (almost) not impacted. >> >> The first one should produce OOM the same ways as it was when we had >> PermGen. >> >> I think the solution 1 is correct. > > Throwing an asynchronous exception is very bad and should always be a > last resort. Such exceptions can lead to corrupt state very easily. > > IMHO problems encountered by the JIT should not manifest as Java-level > exceptions. I would also consider them (regardless of whether they > have always been there) a violation of the spec as quoted by Albert. > > David > >> Thanks, >> Vladimir >> >> On 10/17/14 6:18 AM, Albert Noll wrote: >>> Hi, >>> >>> could I get reviews for this patch: >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8037842 >>> >>> Problem: >>> If the interpreter (or the compilers) fail to allocate from metaspace >>> (e.g., to allocate a MDO), the exception >>> is cleared and - as a result - not reported to the Java application. >>> Not >>> propagating the OOME to the Java application >>> can lead to a serious performance regression, since every attempt to >>> allocate from metaspace (if we have run out >>> of metaspace and a full GC cannot free memory) triggers another full >>> GC. >>> Consequently, the application continues >>> to run and schedules full GCs until (1) a critical allocation (one that >>> throws an OOME) fails, or (2) the application finishes >>> normally (successfully). Note that the VM can continue to execute >>> without allocating MethodCounters or MDOs. >>> >>> Solution 1: >>> Report OOME to the Java application. This solution avoids handling the >>> problem (running a large number of full GCs) >>> in the VM by passing the problem over to the the Java application. >>> I.e., >>> the performance regression is solved by >>> throwing an OOME. The only way to make the application run is to re-run >>> the application with a larger (yet unknown) >>> metaspace size. However, the application could have continued to run >>> (with an undefined performance drop). >>> >>> Note that the metaspace size in the failing test case is artificially >>> small (20m). Should we change the default behavior of Hotspot >>> to fix such a corner case? >>> >>> Also, I am not sure if throwing an OOME in such a case makes Hotspot >>> conform with the Java Language Specification. >>> The Specification says: >>> >>> "Asynchronous exceptions occur only as a result of: >>> >>> An internal error or resource limitation in the Java Virtual Machine >>> that prevents >>> it from implementing the semantics of the Java programming language. In >>> this >>> case, the asynchronous exception that is thrown is an instance of a >>> subclass of >>> VirtualMachineError" >>> >>> An OOME is an asynchronous exception. As I understand the paragraph >>> above, we are only allowed to throw an asynchronous >>> exception, if we are not able to "implement the semantics of the Java >>> programming language". Not being able to run the JIT >>> compiler does not seem to constrain the semantics of the Java language. >>> >>> Solution 2: >>> If allocation from metaspace fails, we (1) report a warning to the user >>> and (2) do not try to allocate MethodCounters and MDO >>> (as well as all other non-critical metaspace allocations) and thereby >>> avoid the overhead from running full GCs. As a result, the >>> application can continue to run. I have not yet worked on such a >>> solution. I just bring this up for discussion. >>> >>> Testing: >>> JPRT >>> >>> Webrev: >>> Here is the webrev for Solution 1. Please note that I am not familiar >>> with this part of the code. >>> >>> http://cr.openjdk.java.net/~anoll/8037842/webrev.00/ >>> >>> May thanks in advance, >>> Albert >>> From vitalyd at gmail.com Tue Oct 21 12:35:22 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 21 Oct 2014 08:35:22 -0400 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <544622EE.5080106@oracle.com> References: <54411709.6000400@oracle.com> <54455E49.7010603@oracle.com> <5445B440.1040806@oracle.com> <544622EE.5080106@oracle.com> Message-ID: +1, as a user. I think an OOME from the VM should come if something critical cannot proceed due to some space exhaustion. PermGen was a hotspot implementation detail (I.e. it's not a java or even a JVM standard, of course) so I don't think it sets any sort of precedent that needs to be followed. A loud warning to stdout/stderr indicating the issue and stating that performance may degrade is sufficient. Sent from my phone On Oct 21, 2014 5:10 AM, "Albert Noll" wrote: > Hi, > > I agree with David. > > Executing a Java program with 'java myProgram' does not imply that we > *must* be able to execute the program using a JIT compiler. > Throwing an OOME because we are unable to compile a method (due to > insufficient metaspace) can cause much more problems than it solves. For > example, > I tried to execute the JVMSPEC2008 compiler.compiler benchmark as follows: > > java -XX:+ExitOnMetaSpaceAllocFail -XX:MaxMetaspaceSize=16m -jar > SPECjvm2008.jar -ikv -wt 10 -i 5 -it 60 compiler.compiler > > If the "ExitOnMetaSpaceAllocFail" is enabled, the JVM exits if we are > unable to allocate MethodCounters and MDO. On my laptop, compiler.compiler > finishes *without a performance regression* if ExitOnMetaSpaceAllocFail is > false. If ExitOnMetaSpaceAllocFail is true, the run does not finish because > we are out of metaspace. Such a behavior is clearly a regression. Given the > large number of customers we have, it seems likely that throwing an OOME > will cause trouble. > > In addition, I think that throwing an OOME exposes implementation details > of hotspot to the user that are not easy to understand. To understand the > cause of the OOME (and I think it is very important for the user to > understand the behavior of the JVM) the user must know that Hotspot uses > JIT compilers that store method profiles in metaspace. If we decide to > throw an OOME, it will be hard to debug the program, since compilers are > not deterministic in when a method is compiled. I.e., the customer can get > OOMEs at random (asynchronous) places. From a serviceability point of view, > throwing an OOME is a poor choice. > > I think we could add an option that lets the user decide on the behavior > (ExitOnMetaSpaceAllocFail). However, the default behavior should be > according to the Spec, i.e., ExitOnMetaSpaceAllocFail should be 'false' by > default. I think it is reasonable to assume that someone who knows about > -XX:MaxMetaspaceSize will know about -XX:ExitOnMetaSpaceAllocFail. The > argument that performance problems are 'hidden' by not throwing an OOME is > valid, but can be mitigated by such a flag. > > Thanks, > Albert > > > On 10/21/2014 03:17 AM, David Holmes wrote: > >> On 21/10/2014 5:11 AM, Vladimir Kozlov wrote: >> >>> Inability to allocate in metaspace is different from allocation in >>> codecache. >>> >>> The last one is JIT specific and needs only warning since whole java >>> process is (almost) not impacted. >>> >>> The first one should produce OOM the same ways as it was when we had >>> PermGen. >>> >>> I think the solution 1 is correct. >>> >> >> Throwing an asynchronous exception is very bad and should always be a >> last resort. Such exceptions can lead to corrupt state very easily. >> >> IMHO problems encountered by the JIT should not manifest as Java-level >> exceptions. I would also consider them (regardless of whether they have >> always been there) a violation of the spec as quoted by Albert. >> >> David >> >> Thanks, >>> Vladimir >>> >>> On 10/17/14 6:18 AM, Albert Noll wrote: >>> >>>> Hi, >>>> >>>> could I get reviews for this patch: >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8037842 >>>> >>>> Problem: >>>> If the interpreter (or the compilers) fail to allocate from metaspace >>>> (e.g., to allocate a MDO), the exception >>>> is cleared and - as a result - not reported to the Java application. Not >>>> propagating the OOME to the Java application >>>> can lead to a serious performance regression, since every attempt to >>>> allocate from metaspace (if we have run out >>>> of metaspace and a full GC cannot free memory) triggers another full GC. >>>> Consequently, the application continues >>>> to run and schedules full GCs until (1) a critical allocation (one that >>>> throws an OOME) fails, or (2) the application finishes >>>> normally (successfully). Note that the VM can continue to execute >>>> without allocating MethodCounters or MDOs. >>>> >>>> Solution 1: >>>> Report OOME to the Java application. This solution avoids handling the >>>> problem (running a large number of full GCs) >>>> in the VM by passing the problem over to the the Java application. I.e., >>>> the performance regression is solved by >>>> throwing an OOME. The only way to make the application run is to re-run >>>> the application with a larger (yet unknown) >>>> metaspace size. However, the application could have continued to run >>>> (with an undefined performance drop). >>>> >>>> Note that the metaspace size in the failing test case is artificially >>>> small (20m). Should we change the default behavior of Hotspot >>>> to fix such a corner case? >>>> >>>> Also, I am not sure if throwing an OOME in such a case makes Hotspot >>>> conform with the Java Language Specification. >>>> The Specification says: >>>> >>>> "Asynchronous exceptions occur only as a result of: >>>> >>>> An internal error or resource limitation in the Java Virtual Machine >>>> that prevents >>>> it from implementing the semantics of the Java programming language. In >>>> this >>>> case, the asynchronous exception that is thrown is an instance of a >>>> subclass of >>>> VirtualMachineError" >>>> >>>> An OOME is an asynchronous exception. As I understand the paragraph >>>> above, we are only allowed to throw an asynchronous >>>> exception, if we are not able to "implement the semantics of the Java >>>> programming language". Not being able to run the JIT >>>> compiler does not seem to constrain the semantics of the Java language. >>>> >>>> Solution 2: >>>> If allocation from metaspace fails, we (1) report a warning to the user >>>> and (2) do not try to allocate MethodCounters and MDO >>>> (as well as all other non-critical metaspace allocations) and thereby >>>> avoid the overhead from running full GCs. As a result, the >>>> application can continue to run. I have not yet worked on such a >>>> solution. I just bring this up for discussion. >>>> >>>> Testing: >>>> JPRT >>>> >>>> Webrev: >>>> Here is the webrev for Solution 1. Please note that I am not familiar >>>> with this part of the code. >>>> >>>> http://cr.openjdk.java.net/~anoll/8037842/webrev.00/ >>>> >>>> May thanks in advance, >>>> Albert >>>> >>>> > From andreas.eriksson at oracle.com Tue Oct 21 12:55:10 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Tue, 21 Oct 2014 14:55:10 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <0833BDCF-841B-4070-B22F-F42AA5CA8F98@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> <543E77CA.3090806@oracle.com> <543E7B08.8040305@oracle.com> <543FA9AD.2070404@oracle.com> <0833BDCF-841B-4070-B22F-F42AA5CA8F98@oracle.com> Message-ID: <544657AE.3010209@oracle.com> Thanks Joel! /Andreas On 2014-10-20 20:48, Joel Borggr?n-Franck wrote: > Sorry for the delay, looks good Andreas! > > Thanks for fixing this. > > cheers > /Joel > > On 16 okt 2014, at 13:19, Andreas Eriksson wrote: > >> On 2014-10-15 15:47, Daniel D. Daugherty wrote: >>> On 10/15/14 7:34 AM, Coleen Phillimore wrote: >>>> There are lots of other rewrite_cp_refs_in* function calls. Please indent your function like them, not differently. >>> The above implies that my answer below was made without sufficient >>> context... my apologies for that. >>> >>> The general rule is to follow the existing style in the file so >>> if there are rewrite_cp_refs_in* function calls in the file, then >>> please follow that style. Unless, of course, you want to fix all >>> of them to follow the HotSpot style guideline: >>> >>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide >>> >>> > Use good taste to break lines and align corresponding tokens >>> > on adjacent lines. >>> >>> but that may cause Coleen some heartburn :-) >> I fixed the calls to follow the already existing indent style. >> I have also made changes to the test, which I hope Joel can take a look at. >> >> New webrev: >> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.01/ >> >> Thanks, >> Andreas >> >>> Dan >>> >>> >>>> Coleen >>>> >>>> On 10/15/14, 9:05 AM, Daniel D. Daugherty wrote: >>>>> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>>>>> Thanks Serguei. >>>>>> >>>>>> I have a question about the if-blocks that had the wrong indent: >>>>>> >>>>>> 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>> >>>>>> How should I indent them? >>>>> Trying again without the line numbers... >>>>> >>>>> if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>> byte_i, "method_info", >>>>> THREAD)) { >>>>> >>>>> Just in case, TB messes with the spacing again, the "byte_i" line and >>>>> "THREAD" lines are aligned under "method_type_annotations". >>>>> >>>>> Dan >>>>> >>>>> >>>>>> /Andreas >>>>>> >>>>>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Andreas, >>>>>>> >>>>>>> Sorry I did not reply on this early. >>>>>>> I assumed, it is a thumbs up from me. >>>>>>> Just wanted make it clean now. :) >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>>>>> Hi Serguei, thanks for looking at this! >>>>>>>> >>>>>>>> I'll make sure to fix the style problems. >>>>>>>> For the symbolic names / #defines, please see my answer to Coleen. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Andreas >>>>>>>> >>>>>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Andreas, >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you for fixing this issue! >>>>>>>>> The fix looks nice, I do not see any logical issues. >>>>>>>>> >>>>>>>>> >>>>>>>>> Only minor comments... >>>>>>>>> >>>>>>>>> >>>>>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>>>>> >>>>>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>>>>> 2785 } // end skip_type_annotation_target >>>>>>>>> 2844 } // end skip_type_annotation_type_path >>>>>>>>> >>>>>>>>> The ')' is missed at 2281, 2315. >>>>>>>>> The 2397-2844 are inconsistent with the 2345 and other function-end comments in the file. >>>>>>>>> >>>>>>>>> >>>>>>>>> 2335 if (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>>>>> . . . >>>>>>>>> 2378 if (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>>>>> . . . >>>>>>>>> 2427 if (!skip_type_annotation_target(type_annotations_typeArray, >>>>>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>>>>> 2429 return false; >>>>>>>>> 2430 } >>>>>>>>> 2431 >>>>>>>>> 2432 if (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>>>>> 2433 byte_i_ref, THREAD)) { >>>>>>>>> 2434 return false; >>>>>>>>> 2435 } >>>>>>>>> 2436 >>>>>>>>> 2437 if (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>>>>> 2438 byte_i_ref, THREAD)) { >>>>>>>>> 2439 return false; >>>>>>>>> Wrong indent at 2336, 2379, etc. >>>>>>>>> >>>>>>>>> >>>>>>>>> I also concur with Coleen that it would be good to define and use >>>>>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>>>>> >>>>>>>>> Java indent must be 4, not 2. >>>>>>>>> >>>>>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") TypeAnnotatedTestClass arg) >>>>>>>>> >>>>>>>>> The line is too long. >>>>>>>>> >>>>>>>>> >>>>>>>>> 143 } >>>>>>>>> 144 public static void main(String argv[]) { >>>>>>>>> . . . >>>>>>>>> 209 } >>>>>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>>>>> 212 } >>>>>>>>> 213 private static void checkAnnotations(AnnotatedType[] annoTypes) { >>>>>>>>> 214 for (AnnotatedType p : annoTypes) checkAnnotations(p.getAnnotations()); >>>>>>>>> 215 } >>>>>>>>> 216 private static void checkAnnotations(Class c) { >>>>>>>>> . . . >>>>>>>>> 257 } >>>>>>>>> 258 public void run() {} >>>>>>>>> >>>>>>>>> Adding empty lines between method definitions would improve readability. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review this patch to RedefineClasses to allow type annotations to be preserved. >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> During redefine / retransform class the constant pool indexes can change. >>>>>>>>>> Since annotations have indexes into the constant pool these indexes need to be rewritten. >>>>>>>>>> This is already done for regular annotations, but not for type annotations. >>>>>>>>>> This patch adds code to add this rewriting for the type annotations as well. >>>>>>>>>> The patch also contains minor changes to ClassFileReconstituter, to make sure that type annotations are preserved during a redefine / retransform class operation. >>>>>>>>>> It also has a test that uses asm to change constant pool indexes through a retransform, and then verifies that type annotations are preserved. >>>>>>>>>> >>>>>>>>>> Detail: >>>>>>>>>> A type annotation struct consists of some target information and a type path, followed by a regular annotation struct. >>>>>>>>>> Constant pool indexes are only present in the regular annotation struct. >>>>>>>>>> The added code skips over the type annotation specific parts, then calls previously existing code to rewrite constant pool indexes in the regular annotation struct. >>>>>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more info about the type annotation struct. >>>>>>>>>> >>>>>>>>>> JPRT with the new test passes without failures on all platforms. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>>>>> >>>>>>>>>> Bug: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Andreas From andreas.eriksson at oracle.com Tue Oct 21 13:06:26 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Tue, 21 Oct 2014 15:06:26 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <5445686F.4090103@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> <543E77CA.3090806@oracle.com> <543E7B08.8040305@oracle.com> <543FA9AD.2070404@oracle.com> <5445686F.4090103@oracle.com> Message-ID: <54465A52.5030005@oracle.com> On 2014-10-20 21:54, serguei.spitsyn at oracle.com wrote: > Hi Andreas, > > Sorry for the delay. > > On 10/16/14 4:19 AM, Andreas Eriksson wrote: >> >> On 2014-10-15 15:47, Daniel D. Daugherty wrote: >>> On 10/15/14 7:34 AM, Coleen Phillimore wrote: >>>> >>>> There are lots of other rewrite_cp_refs_in* function calls. Please >>>> indent your function like them, not differently. >>> >>> The above implies that my answer below was made without sufficient >>> context... my apologies for that. >>> >>> The general rule is to follow the existing style in the file so >>> if there are rewrite_cp_refs_in* function calls in the file, then >>> please follow that style. Unless, of course, you want to fix all >>> of them to follow the HotSpot style guideline: >>> >>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide >>> >>> > Use good taste to break lines and align corresponding tokens >>> > on adjacent lines. >>> >>> but that may cause Coleen some heartburn :-) >> >> I fixed the calls to follow the already existing indent style. >> I have also made changes to the test, which I hope Joel can take a >> look at. >> >> New webrev: >> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.01/ > > The fix looks good. > > A couple of comments about the test. > > The method testTransformAndVerify() is too big. > At least, it looks like there are some ways to refactor it to make > calls to smaller methods. > > There are two directions of doing it: > - make a smaller method out of each block: > 217-236, 238-260, 262-276, 311-329, 331-351, 353-367 > - some of the lines sequences looks very typical: > 221 at = c.getDeclaredField("typeAnnotatedArray").getAnnotatedType(); > 222 arrayTA1 = at.getAnnotations()[0]; > 223 verifyTestAnnSite(arrayTA1, "array1"); > 224 > 225 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); > 226 arrayTA2 = at.getAnnotations()[0]; > 227 verifyTestAnnSite(arrayTA2, "array2"); > 228 > 229 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); > 230 arrayTA3 = at.getAnnotations()[0]; > 231 verifyTestAnnSite(arrayTA3, "array3"); > 232 > 233 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); > 234 arrayTA4 = at.getAnnotations()[0]; > 235 verifyTestAnnSite(arrayTA4, "array4"); > But I leave it up to you. > I'll see what I can do. Thanks, Andreas > Another step to improve the readability is to add a short comment for > each block of code saying what is done there. > > Thanks, > Serguei > > >> >> Thanks, >> Andreas >> >>> >>> Dan >>> >>> >>>> >>>> Coleen >>>> >>>> On 10/15/14, 9:05 AM, Daniel D. Daugherty wrote: >>>>> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>>>>> Thanks Serguei. >>>>>> >>>>>> I have a question about the if-blocks that had the wrong indent: >>>>>> >>>>>> 2335 if >>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>> >>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>> >>>>>> How should I indent them? >>>>> >>>>> Trying again without the line numbers... >>>>> >>>>> if >>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>> >>>>> byte_i, "method_info", >>>>> THREAD)) { >>>>> >>>>> Just in case, TB messes with the spacing again, the "byte_i" line and >>>>> "THREAD" lines are aligned under "method_type_annotations". >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> /Andreas >>>>>> >>>>>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Andreas, >>>>>>> >>>>>>> Sorry I did not reply on this early. >>>>>>> I assumed, it is a thumbs up from me. >>>>>>> Just wanted make it clean now. :) >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>>>>> Hi Serguei, thanks for looking at this! >>>>>>>> >>>>>>>> I'll make sure to fix the style problems. >>>>>>>> For the symbolic names / #defines, please see my answer to Coleen. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Andreas >>>>>>>> >>>>>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Andreas, >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you for fixing this issue! >>>>>>>>> The fix looks nice, I do not see any logical issues. >>>>>>>>> >>>>>>>>> >>>>>>>>> Only minor comments... >>>>>>>>> >>>>>>>>> >>>>>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>>>>> >>>>>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>>>>> 2785 } // end skip_type_annotation_target >>>>>>>>> 2844 } // end skip_type_annotation_type_path >>>>>>>>> >>>>>>>>> The ')' is missed at 2281, 2315. >>>>>>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>>>>>> function-end comments in the file. >>>>>>>>> >>>>>>>>> >>>>>>>>> 2335 if >>>>>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>>>> >>>>>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>>>>> . . . >>>>>>>>> 2378 if >>>>>>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>>>>> >>>>>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>>>>> . . . >>>>>>>>> 2427 if >>>>>>>>> (!skip_type_annotation_target(type_annotations_typeArray, >>>>>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>>>>> 2429 return false; >>>>>>>>> 2430 } >>>>>>>>> 2431 >>>>>>>>> 2432 if >>>>>>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>>>>> 2433 byte_i_ref, THREAD)) { >>>>>>>>> 2434 return false; >>>>>>>>> 2435 } >>>>>>>>> 2436 >>>>>>>>> 2437 if >>>>>>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>>>>> >>>>>>>>> 2438 byte_i_ref, THREAD)) { >>>>>>>>> 2439 return false; >>>>>>>>> Wrong indent at 2336, 2379, etc. >>>>>>>>> >>>>>>>>> >>>>>>>>> I also concur with Coleen that it would be good to define and use >>>>>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>>>>> >>>>>>>>> Java indent must be 4, not 2. >>>>>>>>> >>>>>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>>>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>>>>>>> TypeAnnotatedTestClass arg) >>>>>>>>> >>>>>>>>> The line is too long. >>>>>>>>> >>>>>>>>> >>>>>>>>> 143 } >>>>>>>>> 144 public static void main(String argv[]) { >>>>>>>>> . . . >>>>>>>>> 209 } >>>>>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>>>>> 212 } >>>>>>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>>>>>> annoTypes) { >>>>>>>>> 214 for (AnnotatedType p : annoTypes) >>>>>>>>> checkAnnotations(p.getAnnotations()); >>>>>>>>> 215 } >>>>>>>>> 216 private static void >>>>>>>>> checkAnnotations(Class c) { >>>>>>>>> . . . >>>>>>>>> 257 } >>>>>>>>> 258 public void run() {} >>>>>>>>> >>>>>>>>> Adding empty lines between method definitions would improve >>>>>>>>> readability. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review this patch to RedefineClasses to allow type >>>>>>>>>> annotations to be preserved. >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> During redefine / retransform class the constant pool indexes >>>>>>>>>> can change. >>>>>>>>>> Since annotations have indexes into the constant pool these >>>>>>>>>> indexes need to be rewritten. >>>>>>>>>> This is already done for regular annotations, but not for >>>>>>>>>> type annotations. >>>>>>>>>> This patch adds code to add this rewriting for the type >>>>>>>>>> annotations as well. >>>>>>>>>> The patch also contains minor changes to >>>>>>>>>> ClassFileReconstituter, to make sure that type annotations >>>>>>>>>> are preserved during a redefine / retransform class operation. >>>>>>>>>> It also has a test that uses asm to change constant pool >>>>>>>>>> indexes through a retransform, and then verifies that type >>>>>>>>>> annotations are preserved. >>>>>>>>>> >>>>>>>>>> Detail: >>>>>>>>>> A type annotation struct consists of some target information >>>>>>>>>> and a type path, followed by a regular annotation struct. >>>>>>>>>> Constant pool indexes are only present in the regular >>>>>>>>>> annotation struct. >>>>>>>>>> The added code skips over the type annotation specific parts, >>>>>>>>>> then calls previously existing code to rewrite constant pool >>>>>>>>>> indexes in the regular annotation struct. >>>>>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more >>>>>>>>>> info about the type annotation struct. >>>>>>>>>> >>>>>>>>>> JPRT with the new test passes without failures on all platforms. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>>>>> >>>>>>>>>> Bug: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Andreas >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From tobias.hartmann at oracle.com Tue Oct 21 13:08:57 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 21 Oct 2014 15:08:57 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds Message-ID: <54465AE9.70908@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ Problem: The Whitebox API methods get*VMFlag() fail with develop/notproduct flags in product builds. Solution: The code is changed to invoke 'Flag::find_flag' with allow_locked=true and return_flag=true to return both locked and notproduct/develop flags. I also changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. I adapted the existing tests to check for develop flags as well. I noticed that HotspotDiagnosticMXBean.getVMOption() fails with double flags and filed JDK-8061616 [1]. Testing: - New testcases - JPRT Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8061616 From karen.kinnear at oracle.com Tue Oct 21 14:26:17 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 21 Oct 2014 10:26:17 -0400 Subject: RFR: 8043275 Interface initialization for default methods In-Reply-To: References: <9EF3DCF2-0B86-441A-AAD9-C693B5233786@oracle.com> Message-ID: <9F4148A4-FC87-4B5C-833C-B2973F552EE5@oracle.com> Keith, Thank you so much for looking at this. Let me see if I can explain this clearly. In the "before" code has_default_methods only counted public non-abstract instance methods - i.e. the methods that could be inherited from an interface. The has_default_methods flag, as you know, is used in reducing the default method inheritance calculations. In the updated specification, it was determined that we should initialize superinterfaces that contain non-abstract instance methods, regardless of their access. Invocation of static methods triggers initialization, so that case is already covered. The concern with only initializing superinterfaces containing public non-abstract instance methods was that there might be a way to do an invokespecial on a private interface method and if there were a bug, possibly circumvent the access check (I was not able to create a test case for that despite bytecode patching). Should we ever extend interface methods to allow additional access flags, this would naturally extend with the minimum of surprise for folks. So the initialization loop follows the has_default_methods (which I could rename could_inherit_default_methods but that got a little long and complicated) and explicitly initializes any interface that declares_default_methods. hope that makes sense, thanks, Karen p.s. does that mean I can count you as a reviewer :-) ? On Oct 16, 2014, at 9:13 AM, Keith McGuigan wrote: > Hi Karen, > > Why in classFileParser.cpp does the check for 'has_default_methods' check for a method not being private, but the 'declares_default_methods' check omits that check? > > On Thu, Oct 16, 2014 at 2:01 AM, Karen Kinnear wrote: > > Please review for 9 (8u40 back port will follow): > > webrev: http://cr.openjdk.java.net/~acorn/8043275/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8043275 > > Summary: > Fix superinterface initialization to be based on declaring a non-static instance method rather than on declaring or inheriting one > > Tested (linux-x64): > defmeth - enhanced > jtreg TestInterfaceInit and TestInterfaceOrder > jtreg hotspot, jdk.lambda, java.util, java.lang > jck vm, lang > nsk: vm.defmeth (added 2 tests), vm.mlvm, vm.fast.quick > > Thanks to Dan Smith, Alex Buckley, John Rose for specification clarification. > > thanks, > Karen > > > > > -- > > Keith McGuigan > @kamggg > kmcguigan at twitter.com From kmcguigan at twitter.com Tue Oct 21 14:33:35 2014 From: kmcguigan at twitter.com (Keith McGuigan) Date: Tue, 21 Oct 2014 10:33:35 -0400 Subject: RFR: 8043275 Interface initialization for default methods In-Reply-To: <9F4148A4-FC87-4B5C-833C-B2973F552EE5@oracle.com> References: <9EF3DCF2-0B86-441A-AAD9-C693B5233786@oracle.com> <9F4148A4-FC87-4B5C-833C-B2973F552EE5@oracle.com> Message-ID: Thanks for the explanation -- that makes sense. Sure, you can put me down as a reviewer for this. On Tue, Oct 21, 2014 at 10:26 AM, Karen Kinnear wrote: > Keith, > > Thank you so much for looking at this. > > Let me see if I can explain this clearly. > > In the "before" code has_default_methods only counted public non-abstract > instance methods - i.e. the methods > that could be inherited from an interface. The has_default_methods flag, > as you know, is used in reducing the default method > inheritance calculations. > > In the updated specification, it was determined that we should initialize > superinterfaces that contain non-abstract instance methods, > regardless of their access. Invocation of static methods triggers > initialization, so that case is already covered. The concern with > only initializing superinterfaces containing public non-abstract instance > methods was that there might be a way to do an invokespecial > on a private interface method and if there were a bug, possibly circumvent > the access check (I was not able to create a test case for > that despite bytecode patching). Should we ever extend interface methods > to allow additional access flags, this would naturally extend > with the minimum of surprise for folks. > > So the initialization loop follows the has_default_methods (which I could > rename could_inherit_default_methods but that got a little long and > complicated) and explicitly initializes any interface that > declares_default_methods. > > hope that makes sense, > thanks, > Karen > > p.s. does that mean I can count you as a reviewer :-) ? > > > On Oct 16, 2014, at 9:13 AM, Keith McGuigan wrote: > > Hi Karen, > > Why in classFileParser.cpp does the check for 'has_default_methods' check > for a method not being private, but the 'declares_default_methods' check > omits that check? > > On Thu, Oct 16, 2014 at 2:01 AM, Karen Kinnear > wrote: > >> >> Please review for 9 (8u40 back port will follow): >> >> webrev: http://cr.openjdk.java.net/~acorn/8043275/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8043275 >> >> Summary: >> Fix superinterface initialization to be based on declaring a non-static >> instance method rather than on declaring or inheriting one >> >> Tested (linux-x64): >> defmeth - enhanced >> jtreg TestInterfaceInit and TestInterfaceOrder >> jtreg hotspot, jdk.lambda, java.util, java.lang >> jck vm, lang >> nsk: vm.defmeth (added 2 tests), vm.mlvm, vm.fast.quick >> >> Thanks to Dan Smith, Alex Buckley, John Rose for specification >> clarification. >> >> thanks, >> Karen >> >> > > > -- > [image: twitter-icon-large.png] > Keith McGuigan > @kamggg > kmcguigan at twitter.com > > > -- [image: twitter-icon-large.png] Keith McGuigan @kamggg kmcguigan at twitter.com From erik.osterlund at lnu.se Tue Oct 21 15:55:27 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Tue, 21 Oct 2014 15:55:27 +0000 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: References: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> Message-ID: Hi Paul, I understand your defensive thinking. :) There is indeed no conflict between the two schemes, which was an important design goal to me. In this case I will need some reviews for my old solution first so I can push the changes. So this time, let's pretend that #define VM_HAS_SPECIALIZED_BYTE_CMPXCHG isn't there as it will be fixed in a cleaner way in the successive change. Bug: https://bugs.openjdk.java.net/browse/JDK-8058255 Webrev for the simple fix (which I intend to push initially): http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.macro/ Webrev for the inheritance/template solution (which will be pushed after and is the intended "end" result): http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.templates/ Webrev for the delta from the macro solution to the inheritance/template solution: http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.incremental/ The solutions are unchanged from before except for one thing: the Assembler::cmpxchgb used in code stub used by awkward AMD64 windows config. I added a flag needed to put a REX prefix (0x40) in front of the (new) cmpxchgb machine code encoding when byte-sized registers are used, required by the hardware specification. Testing of webrev.03.macro which I want to push now: 1. jprt (big thanks to Jesper for helping me with this!) 2. I have tested that the assembly produced in CodeStub works locally by carefully introspecting the machine code produced compared to the machine code produced by inline asm. 3. Running through some DaCapo benchmarks (with the CodeStub cmpxchgb and G1 which uses jbyte cmpxchg quite a bit for card manipulation). I would like to thank Jesper again for helping me make webrevs and supporting me. Thanks, /Erik On 21 Oct 2014, at 04:33, Paul Hohensee wrote: I was perhaps unclear. :) The new scheme and the old will co-exist, i.e., there's no conflict between the two, right? That makes transition to the new easier, but if we leave the old way there, then two ways of doing the same thing will result in more cognitive overhead and thus higher maintenance costs, just as is the case with the two parallel scavengers. So, I'd prefer the new way to supplant the old as soon as practicable. I proposed to implement your old solution as a step on the way to the new, so there'd be a record of how that worked. It's also the minimal change, so if it's in the repo and there are issues with the new way, it's easy to revert while a fix is done. Call it paranoia. :) Paul On Mon, Oct 20, 2014 at 7:04 PM, Erik ?sterlund > wrote: Hi Paul, Thank you for your reply. Webrev for new inheritance based solution: http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.02/ In my opinion it does not create a conflict that there are two different systems. There are 3 levels in the hierarchy, all with well defined responsibilities: AtomicBase - atomics that can be generalized for all platforms, AtomicPlatform (optional) for atomics overriding AtomicBase with specialized implementations, and Atomic for atomics that always look different on all platforms (and hence has little benefit of inheritance). With this view (and responsibilities), it is already consistent AFAIK unless we have more things that could be generalized that should be shifted up in the hierarchy which would be nice. Do you propose we use my old solution (http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01/) for now which is less reliant on compiler support and strictly only fixes the jbyte cmpxchg in a less architecturally intrusive way, or the new cleaner inheritance variant? Thanks, /Erik On 20 Oct 2014, at 16:23, Paul Hohensee > wrote: I'd also worry about a couple of other things. First, way back in the mists of time, C++ compilers differed with respect to their template implementations. Hopefully the C++ compiles on all openjdk platforms do what you expect. Second, if you do this, we'll have two alternatives for implementing Atomic, which generally isn't a good thing (vis we have two GC frameworks). I'd want to see every platform switch to the new way of doing things asap and get rid of the old way. Paul On Mon, Oct 20, 2014 at 10:10 AM, Paul Hohensee > wrote: Sorry for the delay in responding. Idea seems ok. I'd like to see a webrev. You might start with your original solution (the one I reviewed) just to get a fix in place. Paul On Wed, Oct 15, 2014 at 9:47 AM, Erik ?sterlund > wrote: Hi Paul, Thank you for the reply. I like the idea of using inheritance too. I tried a new solution which is similar to the one proposed and I would like to hear your comment if this is okay so we are all happy. The core idea is to have a general AtomicBase class which implements the old unspecialized cmpxchg (and possibly other stuff to come), then allow platforms to /optionally/ define their own AtomicPlatform base classes in the hierarchy that derive from AtomicBase. Then the last step in the hierarchy is Atomic which inherits from AtomicPlatform if it is defined and otherwise AtomicBase. It picks the superclass using SFINAE. The reason for this is that other ports will not be broken by this performance fix and the definition of such AtomicPlatform class is completely optional. :) Benefits: * Uses inheritance and looks nice like the inheritance based solution proposed * Does not break ports outside of the main repo * Does not require refactoring of everything (moving all methods from Atomic to AbstractAtomic for all platforms) * Changes are local to only the platforms that want to add this functionality * Flexible for supporting the future demands In a bit more detail, it looks like this: atomic.hpp: class AtomicBase : AllStatic { protected: static jbyte cmpxchg_unspecialized(jbyte exchange_value, volatile jbyte* dest, jbyte compare_value); public: inline static jbyte cmpxchg (jbyte exchange_value, volatile jbyte* dest, jbyte compare_value) { return cmpxchg_unspecialized(exchange_value, dest, compare_value); } }; // Linux #ifdef TARGET_OS_ARCH_linux_x86 # include "atomic_linux_x86.hpp" #endif // BSD #ifdef TARGET_OS_ARCH_bsd_x86 # include "atomic_bsd_x86.hpp" #endif // ... and the other platforms that benefit from specialized AtomicPlatform ... class AtomicPlatform; // Forward declaration to avoid compiler error when it is not defined // Based on some SFINAE stuff I made and will contribute if you like it. AtomicSuper will be AtomicPlatform if defined in a platform specific atomic_os_arch.hpp file, otherwise AtomicBase will be used typedef base_class::type AtomicSuper; // AtomicSuper is now the base class of Atomic, and contains the cmpxchgb implementation class Atomic : public AtomicSuper { // ... inline static jbyte cmpxchg (jbyte exchange_value, volatile jbyte* dest, jbyte compare_value) { // Just call super class implementation return AtomicSuper::cmpxchg(exchange_value, dest, compare_value); } // ... }; A new atomic_os_arch.hpp file looks like this (for platforms that support this): class AtomicPlatform : public AtomicBase { public: static jbyte cmpxchg(jbyte exchange_value, volatile jbyte* dest, jbyte compare_value); }; And atomic_os_arch.inline.hpp contains the implementation like before, but as members of AtomicPlatform instead of Atomic For the curious reader, the SFINAE stuff for base_class looks like this: template struct is_base_of_host { operator Base*() const; operator Derived*(); }; // Statically check if two types are related in a class hierarchy template struct is_base_of { typedef char yes[1]; typedef char no[2]; template static yes &check(Derived*, T); static no &check(Base*, int); static const bool value = sizeof(check(is_base_of_host(), int())) == sizeof(yes); }; // The ::type of this struct will be the Desired type if it was defined // and a subtype of Fallback, otherwise it will be Fallback. // This is useful when optionally inheriting from a specialized subtype. template struct base_class { template struct check_inheritance { typedef T type; }; template struct check_inheritance { typedef U type; }; typedef typename check_inheritance::value, Fallback, Desired>::type type; }; If everyone is happy with this solution, then I will prepare another webrev and send the patch. :) Thanks for taking the time to read through this change. /Erik On 14 Oct 2014, at 19:25, Paul Hohensee > wrote: > David Holmes asked me to take a look at this > >>>>> There is now a new webrev with my jbyte cmpxchg changes here: >>>>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01 > > and comment, so... > > The approach is good if you're going to stay with the current framework, > except that I'd get rid of VM_HAS_SPECIALIZED_BYTE_CMPXCHG (#ifdef's are > the devil). Just call cmpxchg_general (which should be named > cmpxchgb_general or maybe cmpxchgb_unspecialized, btw) from an os_cpu file > as needed. I.e., no change to atomic.inline.hpp needed. Another way to > look at it is, cmpxchgb_general/unspecialized is the implementation of > another specialized version of cmpxchgb, on the same abstraction level as > the asm versions. > > If a rewrite is possible, I'd do it the way David suggests with an > AbstractAtomic class from which per-platform Atomic classes are derived. > That's the way VM_Version and ICache are defined. > > Paul From karen.kinnear at oracle.com Tue Oct 21 16:27:44 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 21 Oct 2014 12:27:44 -0400 Subject: RFR: 8043275 Interface initialization for default methods In-Reply-To: <54451668.2070305@oracle.com> References: <9EF3DCF2-0B86-441A-AAD9-C693B5233786@oracle.com> <54451668.2070305@oracle.com> Message-ID: Coleen, Many thanks for the review (8u40 backport coming soon). details below, thanks, Karen On Oct 20, 2014, at 10:04 AM, Coleen Phillimore wrote: > > Karen, > This looks great. I only have two small requests for comments. > > At instanceKlass.cpp right before line 749, can you add a short one line comment about only calling initialize() for interfaces that *declare* concrete methods. In case people miss that subtlety (which I missed at first reading). Great suggestion - here is what I added. // Only initialize() interfaces that "declare" concrete methods. // has_default_methods drives searching superinterfaces since it // means has_default_methods in its superinterface hierarchy > > http://cr.openjdk.java.net/~acorn/8043275/webrev/test/runtime/lambda-features/TestInterfaceInit.java.html > > The test case could use a comment between 68-72. There's a trick there which is hard to see. The classes that have concrete methods are initialized for 'L' (which is probably an ldc) but then the ones without concrete methods are initialized when you do a getfield of 'v'. I think? I will add a comment (and actually improve using Paul's array suggestion). Due to the L.v, only the ones with concrete methods are initialized at all - so the order is 1,2,3,4 and the two interfaces without default methods (JN and KN) actually do not get initialized at all. I will definitely improve the comments so that is clearer. thank you for the review! > > I don't need to see another version with comments since they are small requests. > > thanks, > Coleen > > On 10/16/14, 2:01 AM, Karen Kinnear wrote: >> Please review for 9 (8u40 back port will follow): >> >> webrev: http://cr.openjdk.java.net/~acorn/8043275/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8043275 >> >> Summary: >> Fix superinterface initialization to be based on declaring a non-static instance method rather than on declaring or inheriting one >> >> Tested (linux-x64): >> defmeth - enhanced >> jtreg TestInterfaceInit and TestInterfaceOrder >> jtreg hotspot, jdk.lambda, java.util, java.lang >> jck vm, lang >> nsk: vm.defmeth (added 2 tests), vm.mlvm, vm.fast.quick >> >> Thanks to Dan Smith, Alex Buckley, John Rose for specification clarification. >> >> thanks, >> Karen >> > From vladimir.kozlov at oracle.com Tue Oct 21 17:59:59 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Oct 2014 10:59:59 -0700 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <54465AE9.70908@oracle.com> References: <54465AE9.70908@oracle.com> Message-ID: <54469F1F.5080806@oracle.com> Looks reasonable to me. Thanks, Vladimir On 10/21/14 6:08 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 > Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ > > Problem: > The Whitebox API methods get*VMFlag() fail with develop/notproduct flags in > product builds. > > Solution: > The code is changed to invoke 'Flag::find_flag' with allow_locked=true and > return_flag=true to return both locked and notproduct/develop flags. I also > changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. > > I adapted the existing tests to check for develop flags as well. I noticed that > HotspotDiagnosticMXBean.getVMOption() fails with double flags and filed > JDK-8061616 [1]. > > Testing: > - New testcases > - JPRT > > Thanks, > Tobias > > > [1] https://bugs.openjdk.java.net/browse/JDK-8061616 > From tobias.hartmann at oracle.com Tue Oct 21 18:36:49 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 21 Oct 2014 20:36:49 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <54469F1F.5080806@oracle.com> References: <54465AE9.70908@oracle.com> <54469F1F.5080806@oracle.com> Message-ID: <5446A7C1.1080400@oracle.com> Thanks, Vladimir. Best, Tobias On 21.10.2014 19:59, Vladimir Kozlov wrote: > Looks reasonable to me. > > Thanks, > Vladimir > > On 10/21/14 6:08 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >> >> Problem: >> The Whitebox API methods get*VMFlag() fail with develop/notproduct flags in >> product builds. >> >> Solution: >> The code is changed to invoke 'Flag::find_flag' with allow_locked=true and >> return_flag=true to return both locked and notproduct/develop flags. I also >> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >> >> I adapted the existing tests to check for develop flags as well. I noticed that >> HotspotDiagnosticMXBean.getVMOption() fails with double flags and filed >> JDK-8061616 [1]. >> >> Testing: >> - New testcases >> - JPRT >> >> Thanks, >> Tobias >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >> From paul.hohensee at gmail.com Tue Oct 21 19:29:20 2014 From: paul.hohensee at gmail.com (Paul Hohensee) Date: Tue, 21 Oct 2014 15:29:20 -0400 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: References: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> Message-ID: Re the simple fix, if you've successfully run DaCapo using G1 on all platforms for which you've added custom implementations, and considering it'll be replaced (so I withdraw my previous comments and accept it as is), consider it reviewed. For the template fix: A nit: in templateIdioms.hpp, put the on-one-line-by-themselves-{'s at the end of the previous lines. If it passes the same tests as the simple fix, it's good to go too. Paul On Tue, Oct 21, 2014 at 11:55 AM, Erik ?sterlund wrote: > Hi Paul, > > I understand your defensive thinking. :) There is indeed no conflict > between the two schemes, which was an important design goal to me. > In this case I will need some reviews for my old solution first so I can > push the changes. > > So this time, let's pretend that #define VM_HAS_SPECIALIZED_BYTE_CMPXCHG > isn't there as it will be fixed in a cleaner way in the successive change. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8058255 > > Webrev for the simple fix (which I intend to push initially): > http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.macro/ > > Webrev for the inheritance/template solution (which will be pushed after > and is the intended "end" result): > http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.templates/ > > Webrev for the delta from the macro solution to the inheritance/template > solution: > http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.incremental/ > > The solutions are unchanged from before except for one thing: the > Assembler::cmpxchgb used in code stub used by awkward AMD64 windows config. > I added a flag needed to put a REX prefix (0x40) in front of the (new) > cmpxchgb machine code encoding when byte-sized registers are used, required > by the hardware specification. > > Testing of webrev.03.macro which I want to push now: > 1. jprt (big thanks to Jesper for helping me with this!) > 2. I have tested that the assembly produced in CodeStub works locally by > carefully introspecting the machine code produced compared to the machine > code produced by inline asm. > 3. Running through some DaCapo benchmarks (with the CodeStub cmpxchgb and > G1 which uses jbyte cmpxchg quite a bit for card manipulation). > > I would like to thank Jesper again for helping me make webrevs and > supporting me. > > Thanks, > /Erik > > On 21 Oct 2014, at 04:33, Paul Hohensee wrote: > > I was perhaps unclear. :) The new scheme and the old will co-exist, > i.e., there's no conflict between the two, right? That makes transition to > the new easier, but if we leave the old way there, then two ways of doing > the same thing will result in more cognitive overhead and thus higher > maintenance costs, just as is the case with the two parallel scavengers. > So, I'd prefer the new way to supplant the old as soon as practicable. > > I proposed to implement your old solution as a step on the way to the > new, so there'd be a record of how that worked. It's also the minimal > change, so if it's in the repo and there are issues with the new way, it's > easy to revert while a fix is done. Call it paranoia. :) > > Paul > > > On Mon, Oct 20, 2014 at 7:04 PM, Erik ?sterlund > wrote: > >> Hi Paul, >> >> Thank you for your reply. >> >> Webrev for new inheritance based solution: >> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.02/ >> >> In my opinion it does not create a conflict that there are two >> different systems. There are 3 levels in the hierarchy, all with well >> defined responsibilities: AtomicBase - atomics that can be generalized for >> all platforms, AtomicPlatform (optional) for atomics overriding AtomicBase >> with specialized implementations, and Atomic for atomics that always look >> different on all platforms (and hence has little benefit of inheritance). >> >> With this view (and responsibilities), it is already consistent AFAIK >> unless we have more things that could be generalized that should be shifted >> up in the hierarchy which would be nice. >> >> Do you propose we use my old solution ( >> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01/) for now which >> is less reliant on compiler support and strictly only fixes the jbyte >> cmpxchg in a less architecturally intrusive way, or the new cleaner >> inheritance variant? >> >> Thanks, >> >> /Erik >> >> On 20 Oct 2014, at 16:23, Paul Hohensee wrote: >> >> I'd also worry about a couple of other things. First, way back in the >> mists of time, C++ compilers differed with respect to their template >> implementations. Hopefully the C++ compiles on all openjdk platforms do >> what you expect. Second, if you do this, we'll have two alternatives for >> implementing Atomic, which generally isn't a good thing (vis we have two GC >> frameworks). I'd want to see every platform switch to the new way of doing >> things asap and get rid of the old way. >> >> Paul >> >> >> On Mon, Oct 20, 2014 at 10:10 AM, Paul Hohensee >> wrote: >> >>> Sorry for the delay in responding. >>> >>> Idea seems ok. I'd like to see a webrev. >>> >>> You might start with your original solution (the one I reviewed) just >>> to get a fix in place. >>> >>> Paul >>> >>> >>> On Wed, Oct 15, 2014 at 9:47 AM, Erik ?sterlund >>> wrote: >>> >>>> Hi Paul, >>>> >>>> Thank you for the reply. I like the idea of using inheritance too. >>>> I tried a new solution which is similar to the one proposed and I would >>>> like to hear your comment if this is okay so we are all happy. >>>> >>>> The core idea is to have a general AtomicBase class which implements >>>> the old unspecialized cmpxchg (and possibly other stuff to come), then >>>> allow platforms to /optionally/ define their own AtomicPlatform base >>>> classes in the hierarchy that derive from AtomicBase. Then the last step in >>>> the hierarchy is Atomic which inherits from AtomicPlatform if it is defined >>>> and otherwise AtomicBase. It picks the superclass using SFINAE. The reason >>>> for this is that other ports will not be broken by this performance fix and >>>> the definition of such AtomicPlatform class is completely optional. :) >>>> >>>> Benefits: >>>> * Uses inheritance and looks nice like the inheritance based solution >>>> proposed >>>> * Does not break ports outside of the main repo >>>> * Does not require refactoring of everything (moving all methods from >>>> Atomic to AbstractAtomic for all platforms) >>>> * Changes are local to only the platforms that want to add this >>>> functionality >>>> * Flexible for supporting the future demands >>>> >>>> In a bit more detail, it looks like this: >>>> >>>> atomic.hpp: >>>> >>>> class AtomicBase : AllStatic { >>>> protected: >>>> static jbyte cmpxchg_unspecialized(jbyte exchange_value, volatile >>>> jbyte* dest, jbyte compare_value); >>>> public: >>>> inline static jbyte cmpxchg (jbyte exchange_value, >>>> volatile jbyte* dest, jbyte compare_value) { >>>> return cmpxchg_unspecialized(exchange_value, dest, compare_value); >>>> } >>>> }; >>>> >>>> // Linux >>>> #ifdef TARGET_OS_ARCH_linux_x86 >>>> # include "atomic_linux_x86.hpp" >>>> #endif >>>> >>>> // BSD >>>> #ifdef TARGET_OS_ARCH_bsd_x86 >>>> # include "atomic_bsd_x86.hpp" >>>> #endif >>>> >>>> // ... and the other platforms that benefit from specialized >>>> AtomicPlatform ... >>>> >>>> class AtomicPlatform; // Forward declaration to avoid compiler error >>>> when it is not defined >>>> >>>> // Based on some SFINAE stuff I made and will contribute if you like >>>> it. AtomicSuper will be AtomicPlatform if defined in a platform specific >>>> atomic_os_arch.hpp file, otherwise AtomicBase will be used >>>> typedef base_class::type AtomicSuper; >>>> >>>> // AtomicSuper is now the base class of Atomic, and contains the >>>> cmpxchgb implementation >>>> class Atomic : public AtomicSuper { >>>> // ... >>>> inline static jbyte cmpxchg (jbyte exchange_value, >>>> volatile jbyte* dest, jbyte compare_value) { >>>> // Just call super class implementation >>>> return AtomicSuper::cmpxchg(exchange_value, dest, compare_value); >>>> } >>>> // ... >>>> }; >>>> >>>> A new atomic_os_arch.hpp file looks like this (for platforms that >>>> support this): >>>> class AtomicPlatform : public AtomicBase { >>>> public: >>>> static jbyte cmpxchg(jbyte exchange_value, volatile jbyte* dest, >>>> jbyte compare_value); >>>> }; >>>> >>>> And atomic_os_arch.inline.hpp contains the implementation like before, >>>> but as members of AtomicPlatform instead of Atomic >>>> >>>> For the curious reader, the SFINAE stuff for base_class looks like this: >>>> >>>> template >>>> struct is_base_of_host >>>> { >>>> operator Base*() const; >>>> operator Derived*(); >>>> }; >>>> >>>> // Statically check if two types are related in a class hierarchy >>>> template >>>> struct is_base_of >>>> { >>>> typedef char yes[1]; >>>> typedef char no[2]; >>>> >>>> template >>>> static yes &check(Derived*, T); >>>> static no &check(Base*, int); >>>> >>>> static const bool value = sizeof(check(is_base_of_host>>> Derived>(), int())) == sizeof(yes); >>>> }; >>>> >>>> // The ::type of this struct will be the Desired type if it was defined >>>> // and a subtype of Fallback, otherwise it will be Fallback. >>>> // This is useful when optionally inheriting from a specialized subtype. >>>> template >>>> struct base_class { >>>> template >>>> struct check_inheritance { >>>> typedef T type; >>>> }; >>>> >>>> template >>>> struct check_inheritance { >>>> typedef U type; >>>> }; >>>> >>>> typedef typename check_inheritance>>> Desired>::value, Fallback, Desired>::type type; >>>> }; >>>> >>>> If everyone is happy with this solution, then I will prepare another >>>> webrev and send the patch. :) >>>> Thanks for taking the time to read through this change. >>>> >>>> /Erik >>>> >>>> On 14 Oct 2014, at 19:25, Paul Hohensee >>>> wrote: >>>> >>>> > David Holmes asked me to take a look at this >>>> > >>>> >>>>> There is now a new webrev with my jbyte cmpxchg changes here: >>>> >>>>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01 >>>> > >>>> > and comment, so... >>>> > >>>> > The approach is good if you're going to stay with the current >>>> framework, >>>> > except that I'd get rid of VM_HAS_SPECIALIZED_BYTE_CMPXCHG (#ifdef's >>>> are >>>> > the devil). Just call cmpxchg_general (which should be named >>>> > cmpxchgb_general or maybe cmpxchgb_unspecialized, btw) from an os_cpu >>>> file >>>> > as needed. I.e., no change to atomic.inline.hpp needed. Another way >>>> to >>>> > look at it is, cmpxchgb_general/unspecialized is the implementation of >>>> > another specialized version of cmpxchgb, on the same abstraction >>>> level as >>>> > the asm versions. >>>> > >>>> > If a rewrite is possible, I'd do it the way David suggests with an >>>> > AbstractAtomic class from which per-platform Atomic classes are >>>> derived. >>>> > That's the way VM_Version and ICache are defined. >>>> > >>>> > Paul >>>> >>>> >>> >> >> > > From vladimir.kozlov at oracle.com Tue Oct 21 19:46:28 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Oct 2014 12:46:28 -0700 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: References: <54411709.6000400@oracle.com> <54455E49.7010603@oracle.com> <5445B440.1040806@oracle.com> <544622EE.5080106@oracle.com> Message-ID: <5446B814.6040105@oracle.com> Okay, I see your and others points. Albert, I will agree without your solution 2. Thanks, Vladimir On 10/21/14 5:35 AM, Vitaly Davidovich wrote: > +1, as a user. I think an OOME from the VM should come if something > critical cannot proceed due to some space exhaustion. PermGen was a > hotspot implementation detail (I.e. it's not a java or even a JVM > standard, of course) so I don't think it sets any sort of precedent that > needs to be followed. A loud warning to stdout/stderr indicating the issue > and stating that performance may degrade is sufficient. > > Sent from my phone > On Oct 21, 2014 5:10 AM, "Albert Noll" wrote: > >> Hi, >> >> I agree with David. >> >> Executing a Java program with 'java myProgram' does not imply that we >> *must* be able to execute the program using a JIT compiler. >> Throwing an OOME because we are unable to compile a method (due to >> insufficient metaspace) can cause much more problems than it solves. For >> example, >> I tried to execute the JVMSPEC2008 compiler.compiler benchmark as follows: >> >> java -XX:+ExitOnMetaSpaceAllocFail -XX:MaxMetaspaceSize=16m -jar >> SPECjvm2008.jar -ikv -wt 10 -i 5 -it 60 compiler.compiler >> >> If the "ExitOnMetaSpaceAllocFail" is enabled, the JVM exits if we are >> unable to allocate MethodCounters and MDO. On my laptop, compiler.compiler >> finishes *without a performance regression* if ExitOnMetaSpaceAllocFail is >> false. If ExitOnMetaSpaceAllocFail is true, the run does not finish because >> we are out of metaspace. Such a behavior is clearly a regression. Given the >> large number of customers we have, it seems likely that throwing an OOME >> will cause trouble. >> >> In addition, I think that throwing an OOME exposes implementation details >> of hotspot to the user that are not easy to understand. To understand the >> cause of the OOME (and I think it is very important for the user to >> understand the behavior of the JVM) the user must know that Hotspot uses >> JIT compilers that store method profiles in metaspace. If we decide to >> throw an OOME, it will be hard to debug the program, since compilers are >> not deterministic in when a method is compiled. I.e., the customer can get >> OOMEs at random (asynchronous) places. From a serviceability point of view, >> throwing an OOME is a poor choice. >> >> I think we could add an option that lets the user decide on the behavior >> (ExitOnMetaSpaceAllocFail). However, the default behavior should be >> according to the Spec, i.e., ExitOnMetaSpaceAllocFail should be 'false' by >> default. I think it is reasonable to assume that someone who knows about >> -XX:MaxMetaspaceSize will know about -XX:ExitOnMetaSpaceAllocFail. The >> argument that performance problems are 'hidden' by not throwing an OOME is >> valid, but can be mitigated by such a flag. >> >> Thanks, >> Albert >> >> >> On 10/21/2014 03:17 AM, David Holmes wrote: >> >>> On 21/10/2014 5:11 AM, Vladimir Kozlov wrote: >>> >>>> Inability to allocate in metaspace is different from allocation in >>>> codecache. >>>> >>>> The last one is JIT specific and needs only warning since whole java >>>> process is (almost) not impacted. >>>> >>>> The first one should produce OOM the same ways as it was when we had >>>> PermGen. >>>> >>>> I think the solution 1 is correct. >>>> >>> >>> Throwing an asynchronous exception is very bad and should always be a >>> last resort. Such exceptions can lead to corrupt state very easily. >>> >>> IMHO problems encountered by the JIT should not manifest as Java-level >>> exceptions. I would also consider them (regardless of whether they have >>> always been there) a violation of the spec as quoted by Albert. >>> >>> David >>> >>> Thanks, >>>> Vladimir >>>> >>>> On 10/17/14 6:18 AM, Albert Noll wrote: >>>> >>>>> Hi, >>>>> >>>>> could I get reviews for this patch: >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8037842 >>>>> >>>>> Problem: >>>>> If the interpreter (or the compilers) fail to allocate from metaspace >>>>> (e.g., to allocate a MDO), the exception >>>>> is cleared and - as a result - not reported to the Java application. Not >>>>> propagating the OOME to the Java application >>>>> can lead to a serious performance regression, since every attempt to >>>>> allocate from metaspace (if we have run out >>>>> of metaspace and a full GC cannot free memory) triggers another full GC. >>>>> Consequently, the application continues >>>>> to run and schedules full GCs until (1) a critical allocation (one that >>>>> throws an OOME) fails, or (2) the application finishes >>>>> normally (successfully). Note that the VM can continue to execute >>>>> without allocating MethodCounters or MDOs. >>>>> >>>>> Solution 1: >>>>> Report OOME to the Java application. This solution avoids handling the >>>>> problem (running a large number of full GCs) >>>>> in the VM by passing the problem over to the the Java application. I.e., >>>>> the performance regression is solved by >>>>> throwing an OOME. The only way to make the application run is to re-run >>>>> the application with a larger (yet unknown) >>>>> metaspace size. However, the application could have continued to run >>>>> (with an undefined performance drop). >>>>> >>>>> Note that the metaspace size in the failing test case is artificially >>>>> small (20m). Should we change the default behavior of Hotspot >>>>> to fix such a corner case? >>>>> >>>>> Also, I am not sure if throwing an OOME in such a case makes Hotspot >>>>> conform with the Java Language Specification. >>>>> The Specification says: >>>>> >>>>> "Asynchronous exceptions occur only as a result of: >>>>> >>>>> An internal error or resource limitation in the Java Virtual Machine >>>>> that prevents >>>>> it from implementing the semantics of the Java programming language. In >>>>> this >>>>> case, the asynchronous exception that is thrown is an instance of a >>>>> subclass of >>>>> VirtualMachineError" >>>>> >>>>> An OOME is an asynchronous exception. As I understand the paragraph >>>>> above, we are only allowed to throw an asynchronous >>>>> exception, if we are not able to "implement the semantics of the Java >>>>> programming language". Not being able to run the JIT >>>>> compiler does not seem to constrain the semantics of the Java language. >>>>> >>>>> Solution 2: >>>>> If allocation from metaspace fails, we (1) report a warning to the user >>>>> and (2) do not try to allocate MethodCounters and MDO >>>>> (as well as all other non-critical metaspace allocations) and thereby >>>>> avoid the overhead from running full GCs. As a result, the >>>>> application can continue to run. I have not yet worked on such a >>>>> solution. I just bring this up for discussion. >>>>> >>>>> Testing: >>>>> JPRT >>>>> >>>>> Webrev: >>>>> Here is the webrev for Solution 1. Please note that I am not familiar >>>>> with this part of the code. >>>>> >>>>> http://cr.openjdk.java.net/~anoll/8037842/webrev.00/ >>>>> >>>>> May thanks in advance, >>>>> Albert >>>>> >>>>> >> From coleen.phillimore at oracle.com Tue Oct 21 19:52:24 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 21 Oct 2014 15:52:24 -0400 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <5446B814.6040105@oracle.com> References: <54411709.6000400@oracle.com> <54455E49.7010603@oracle.com> <5445B440.1040806@oracle.com> <544622EE.5080106@oracle.com> <5446B814.6040105@oracle.com> Message-ID: <5446B978.5070801@oracle.com> Hi, I suggested option 1 because if we OOM trying to allocate metaspace for MethodCounters and MethodData, then the system is pretty close to running into the metaspace limit and is not going to be able to make very much progress anyway. If we run out of Metaspace while allocating metadata for a class, we throw OOM. In the class loading case, a user can maybe catch OOM and stop loading so many classes (???). During method compilation this is more surprising, so I'm going to change my vote for #2 now. Coleen On 10/21/14, 3:46 PM, Vladimir Kozlov wrote: > Okay, I see your and others points. > > Albert, I will agree without your solution 2. > > Thanks, > Vladimir > > On 10/21/14 5:35 AM, Vitaly Davidovich wrote: >> +1, as a user. I think an OOME from the VM should come if something >> critical cannot proceed due to some space exhaustion. PermGen was a >> hotspot implementation detail (I.e. it's not a java or even a JVM >> standard, of course) so I don't think it sets any sort of precedent >> that >> needs to be followed. A loud warning to stdout/stderr indicating the >> issue >> and stating that performance may degrade is sufficient. >> >> Sent from my phone >> On Oct 21, 2014 5:10 AM, "Albert Noll" wrote: >> >>> Hi, >>> >>> I agree with David. >>> >>> Executing a Java program with 'java myProgram' does not imply that we >>> *must* be able to execute the program using a JIT compiler. >>> Throwing an OOME because we are unable to compile a method (due to >>> insufficient metaspace) can cause much more problems than it solves. >>> For >>> example, >>> I tried to execute the JVMSPEC2008 compiler.compiler benchmark as >>> follows: >>> >>> java -XX:+ExitOnMetaSpaceAllocFail -XX:MaxMetaspaceSize=16m -jar >>> SPECjvm2008.jar -ikv -wt 10 -i 5 -it 60 compiler.compiler >>> >>> If the "ExitOnMetaSpaceAllocFail" is enabled, the JVM exits if we are >>> unable to allocate MethodCounters and MDO. On my laptop, >>> compiler.compiler >>> finishes *without a performance regression* if >>> ExitOnMetaSpaceAllocFail is >>> false. If ExitOnMetaSpaceAllocFail is true, the run does not finish >>> because >>> we are out of metaspace. Such a behavior is clearly a regression. >>> Given the >>> large number of customers we have, it seems likely that throwing an >>> OOME >>> will cause trouble. >>> >>> In addition, I think that throwing an OOME exposes implementation >>> details >>> of hotspot to the user that are not easy to understand. To >>> understand the >>> cause of the OOME (and I think it is very important for the user to >>> understand the behavior of the JVM) the user must know that Hotspot >>> uses >>> JIT compilers that store method profiles in metaspace. If we decide to >>> throw an OOME, it will be hard to debug the program, since compilers >>> are >>> not deterministic in when a method is compiled. I.e., the customer >>> can get >>> OOMEs at random (asynchronous) places. From a serviceability point >>> of view, >>> throwing an OOME is a poor choice. >>> >>> I think we could add an option that lets the user decide on the >>> behavior >>> (ExitOnMetaSpaceAllocFail). However, the default behavior should be >>> according to the Spec, i.e., ExitOnMetaSpaceAllocFail should be >>> 'false' by >>> default. I think it is reasonable to assume that someone who knows >>> about >>> -XX:MaxMetaspaceSize will know about -XX:ExitOnMetaSpaceAllocFail. The >>> argument that performance problems are 'hidden' by not throwing an >>> OOME is >>> valid, but can be mitigated by such a flag. >>> >>> Thanks, >>> Albert >>> >>> >>> On 10/21/2014 03:17 AM, David Holmes wrote: >>> >>>> On 21/10/2014 5:11 AM, Vladimir Kozlov wrote: >>>> >>>>> Inability to allocate in metaspace is different from allocation in >>>>> codecache. >>>>> >>>>> The last one is JIT specific and needs only warning since whole java >>>>> process is (almost) not impacted. >>>>> >>>>> The first one should produce OOM the same ways as it was when we had >>>>> PermGen. >>>>> >>>>> I think the solution 1 is correct. >>>>> >>>> >>>> Throwing an asynchronous exception is very bad and should always be a >>>> last resort. Such exceptions can lead to corrupt state very easily. >>>> >>>> IMHO problems encountered by the JIT should not manifest as Java-level >>>> exceptions. I would also consider them (regardless of whether they >>>> have >>>> always been there) a violation of the spec as quoted by Albert. >>>> >>>> David >>>> >>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/17/14 6:18 AM, Albert Noll wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> could I get reviews for this patch: >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8037842 >>>>>> >>>>>> Problem: >>>>>> If the interpreter (or the compilers) fail to allocate from >>>>>> metaspace >>>>>> (e.g., to allocate a MDO), the exception >>>>>> is cleared and - as a result - not reported to the Java >>>>>> application. Not >>>>>> propagating the OOME to the Java application >>>>>> can lead to a serious performance regression, since every attempt to >>>>>> allocate from metaspace (if we have run out >>>>>> of metaspace and a full GC cannot free memory) triggers another >>>>>> full GC. >>>>>> Consequently, the application continues >>>>>> to run and schedules full GCs until (1) a critical allocation >>>>>> (one that >>>>>> throws an OOME) fails, or (2) the application finishes >>>>>> normally (successfully). Note that the VM can continue to execute >>>>>> without allocating MethodCounters or MDOs. >>>>>> >>>>>> Solution 1: >>>>>> Report OOME to the Java application. This solution avoids >>>>>> handling the >>>>>> problem (running a large number of full GCs) >>>>>> in the VM by passing the problem over to the the Java >>>>>> application. I.e., >>>>>> the performance regression is solved by >>>>>> throwing an OOME. The only way to make the application run is to >>>>>> re-run >>>>>> the application with a larger (yet unknown) >>>>>> metaspace size. However, the application could have continued to run >>>>>> (with an undefined performance drop). >>>>>> >>>>>> Note that the metaspace size in the failing test case is >>>>>> artificially >>>>>> small (20m). Should we change the default behavior of Hotspot >>>>>> to fix such a corner case? >>>>>> >>>>>> Also, I am not sure if throwing an OOME in such a case makes Hotspot >>>>>> conform with the Java Language Specification. >>>>>> The Specification says: >>>>>> >>>>>> "Asynchronous exceptions occur only as a result of: >>>>>> >>>>>> An internal error or resource limitation in the Java Virtual Machine >>>>>> that prevents >>>>>> it from implementing the semantics of the Java programming >>>>>> language. In >>>>>> this >>>>>> case, the asynchronous exception that is thrown is an instance of a >>>>>> subclass of >>>>>> VirtualMachineError" >>>>>> >>>>>> An OOME is an asynchronous exception. As I understand the paragraph >>>>>> above, we are only allowed to throw an asynchronous >>>>>> exception, if we are not able to "implement the semantics of the >>>>>> Java >>>>>> programming language". Not being able to run the JIT >>>>>> compiler does not seem to constrain the semantics of the Java >>>>>> language. >>>>>> >>>>>> Solution 2: >>>>>> If allocation from metaspace fails, we (1) report a warning to >>>>>> the user >>>>>> and (2) do not try to allocate MethodCounters and MDO >>>>>> (as well as all other non-critical metaspace allocations) and >>>>>> thereby >>>>>> avoid the overhead from running full GCs. As a result, the >>>>>> application can continue to run. I have not yet worked on such a >>>>>> solution. I just bring this up for discussion. >>>>>> >>>>>> Testing: >>>>>> JPRT >>>>>> >>>>>> Webrev: >>>>>> Here is the webrev for Solution 1. Please note that I am not >>>>>> familiar >>>>>> with this part of the code. >>>>>> >>>>>> http://cr.openjdk.java.net/~anoll/8037842/webrev.00/ >>>>>> >>>>>> May thanks in advance, >>>>>> Albert >>>>>> >>>>>> >>> From andreas.eriksson at oracle.com Tue Oct 21 19:54:34 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Tue, 21 Oct 2014 21:54:34 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <5445686F.4090103@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> <543E77CA.3090806@oracle.com> <543E7B08.8040305@oracle.com> <543FA9AD.2070404@oracle.com> <5445686F.4090103@oracle.com> Message-ID: <5446B9FA.4080201@oracle.com> Hi Serguei, I split up the method into several, and made the verification before and after retransform share logic. Webrev: http://cr.openjdk.java.net/~aeriksso/8057043/webrev.02/ Regards, Andreas On 2014-10-20 21:54, serguei.spitsyn at oracle.com wrote: > Hi Andreas, > > Sorry for the delay. > > On 10/16/14 4:19 AM, Andreas Eriksson wrote: >> >> On 2014-10-15 15:47, Daniel D. Daugherty wrote: >>> On 10/15/14 7:34 AM, Coleen Phillimore wrote: >>>> >>>> There are lots of other rewrite_cp_refs_in* function calls. Please >>>> indent your function like them, not differently. >>> >>> The above implies that my answer below was made without sufficient >>> context... my apologies for that. >>> >>> The general rule is to follow the existing style in the file so >>> if there are rewrite_cp_refs_in* function calls in the file, then >>> please follow that style. Unless, of course, you want to fix all >>> of them to follow the HotSpot style guideline: >>> >>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide >>> >>> > Use good taste to break lines and align corresponding tokens >>> > on adjacent lines. >>> >>> but that may cause Coleen some heartburn :-) >> >> I fixed the calls to follow the already existing indent style. >> I have also made changes to the test, which I hope Joel can take a >> look at. >> >> New webrev: >> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.01/ > > The fix looks good. > > A couple of comments about the test. > > The method testTransformAndVerify() is too big. > At least, it looks like there are some ways to refactor it to make > calls to smaller methods. > > There are two directions of doing it: > - make a smaller method out of each block: > 217-236, 238-260, 262-276, 311-329, 331-351, 353-367 > - some of the lines sequences looks very typical: > 221 at = c.getDeclaredField("typeAnnotatedArray").getAnnotatedType(); > 222 arrayTA1 = at.getAnnotations()[0]; > 223 verifyTestAnnSite(arrayTA1, "array1"); > 224 > 225 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); > 226 arrayTA2 = at.getAnnotations()[0]; > 227 verifyTestAnnSite(arrayTA2, "array2"); > 228 > 229 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); > 230 arrayTA3 = at.getAnnotations()[0]; > 231 verifyTestAnnSite(arrayTA3, "array3"); > 232 > 233 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); > 234 arrayTA4 = at.getAnnotations()[0]; > 235 verifyTestAnnSite(arrayTA4, "array4"); > But I leave it up to you. > > Another step to improve the readability is to add a short comment for > each block of code saying what is done there. > > Thanks, > Serguei > > >> >> Thanks, >> Andreas >> >>> >>> Dan >>> >>> >>>> >>>> Coleen >>>> >>>> On 10/15/14, 9:05 AM, Daniel D. Daugherty wrote: >>>>> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>>>>> Thanks Serguei. >>>>>> >>>>>> I have a question about the if-blocks that had the wrong indent: >>>>>> >>>>>> 2335 if >>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>> >>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>> >>>>>> How should I indent them? >>>>> >>>>> Trying again without the line numbers... >>>>> >>>>> if >>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>> >>>>> byte_i, "method_info", >>>>> THREAD)) { >>>>> >>>>> Just in case, TB messes with the spacing again, the "byte_i" line and >>>>> "THREAD" lines are aligned under "method_type_annotations". >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> /Andreas >>>>>> >>>>>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Andreas, >>>>>>> >>>>>>> Sorry I did not reply on this early. >>>>>>> I assumed, it is a thumbs up from me. >>>>>>> Just wanted make it clean now. :) >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>>>>> Hi Serguei, thanks for looking at this! >>>>>>>> >>>>>>>> I'll make sure to fix the style problems. >>>>>>>> For the symbolic names / #defines, please see my answer to Coleen. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Andreas >>>>>>>> >>>>>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Andreas, >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you for fixing this issue! >>>>>>>>> The fix looks nice, I do not see any logical issues. >>>>>>>>> >>>>>>>>> >>>>>>>>> Only minor comments... >>>>>>>>> >>>>>>>>> >>>>>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>>>>> >>>>>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>>>>> 2785 } // end skip_type_annotation_target >>>>>>>>> 2844 } // end skip_type_annotation_type_path >>>>>>>>> >>>>>>>>> The ')' is missed at 2281, 2315. >>>>>>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>>>>>> function-end comments in the file. >>>>>>>>> >>>>>>>>> >>>>>>>>> 2335 if >>>>>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>>>> >>>>>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>>>>> . . . >>>>>>>>> 2378 if >>>>>>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>>>>> >>>>>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>>>>> . . . >>>>>>>>> 2427 if >>>>>>>>> (!skip_type_annotation_target(type_annotations_typeArray, >>>>>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>>>>> 2429 return false; >>>>>>>>> 2430 } >>>>>>>>> 2431 >>>>>>>>> 2432 if >>>>>>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>>>>> 2433 byte_i_ref, THREAD)) { >>>>>>>>> 2434 return false; >>>>>>>>> 2435 } >>>>>>>>> 2436 >>>>>>>>> 2437 if >>>>>>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>>>>> >>>>>>>>> 2438 byte_i_ref, THREAD)) { >>>>>>>>> 2439 return false; >>>>>>>>> Wrong indent at 2336, 2379, etc. >>>>>>>>> >>>>>>>>> >>>>>>>>> I also concur with Coleen that it would be good to define and use >>>>>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>>>>> >>>>>>>>> Java indent must be 4, not 2. >>>>>>>>> >>>>>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>>>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>>>>>>> TypeAnnotatedTestClass arg) >>>>>>>>> >>>>>>>>> The line is too long. >>>>>>>>> >>>>>>>>> >>>>>>>>> 143 } >>>>>>>>> 144 public static void main(String argv[]) { >>>>>>>>> . . . >>>>>>>>> 209 } >>>>>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>>>>> 212 } >>>>>>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>>>>>> annoTypes) { >>>>>>>>> 214 for (AnnotatedType p : annoTypes) >>>>>>>>> checkAnnotations(p.getAnnotations()); >>>>>>>>> 215 } >>>>>>>>> 216 private static void >>>>>>>>> checkAnnotations(Class c) { >>>>>>>>> . . . >>>>>>>>> 257 } >>>>>>>>> 258 public void run() {} >>>>>>>>> >>>>>>>>> Adding empty lines between method definitions would improve >>>>>>>>> readability. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review this patch to RedefineClasses to allow type >>>>>>>>>> annotations to be preserved. >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> During redefine / retransform class the constant pool indexes >>>>>>>>>> can change. >>>>>>>>>> Since annotations have indexes into the constant pool these >>>>>>>>>> indexes need to be rewritten. >>>>>>>>>> This is already done for regular annotations, but not for >>>>>>>>>> type annotations. >>>>>>>>>> This patch adds code to add this rewriting for the type >>>>>>>>>> annotations as well. >>>>>>>>>> The patch also contains minor changes to >>>>>>>>>> ClassFileReconstituter, to make sure that type annotations >>>>>>>>>> are preserved during a redefine / retransform class operation. >>>>>>>>>> It also has a test that uses asm to change constant pool >>>>>>>>>> indexes through a retransform, and then verifies that type >>>>>>>>>> annotations are preserved. >>>>>>>>>> >>>>>>>>>> Detail: >>>>>>>>>> A type annotation struct consists of some target information >>>>>>>>>> and a type path, followed by a regular annotation struct. >>>>>>>>>> Constant pool indexes are only present in the regular >>>>>>>>>> annotation struct. >>>>>>>>>> The added code skips over the type annotation specific parts, >>>>>>>>>> then calls previously existing code to rewrite constant pool >>>>>>>>>> indexes in the regular annotation struct. >>>>>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for more >>>>>>>>>> info about the type annotation struct. >>>>>>>>>> >>>>>>>>>> JPRT with the new test passes without failures on all platforms. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>>>>> >>>>>>>>>> Bug: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Andreas >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From john.r.rose at oracle.com Tue Oct 21 20:25:43 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 21 Oct 2014 13:25:43 -0700 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <5446B978.5070801@oracle.com> References: <54411709.6000400@oracle.com> <54455E49.7010603@oracle.com> <5445B440.1040806@oracle.com> <544622EE.5080106@oracle.com> <5446B814.6040105@oracle.com> <5446B978.5070801@oracle.com> Message-ID: <200C103C-F356-4A1A-BD06-F1D7FCDDFC4A@oracle.com> On Oct 21, 2014, at 12:52 PM, Coleen Phillimore wrote: > I suggested option 1 because if we OOM trying to allocate metaspace for MethodCounters and MethodData, then the system is pretty close to running into the metaspace limit and is not going to be able to make very much progress anyway. Piling on here: OOME (or some other VM error) is a *great* way to handle resource exhaustion corner cases, but *only if* the occasion was directly (synchronously, to use David H.'s term) caused by a user event. So in this case the JVM has to find a way to continue. In this case the JVM's internal optimization logic is stumbling, which isn't something the user can control (or usually observe). > If we run out of Metaspace while allocating metadata for a class, we throw OOM. In the class loading case, a user can maybe catch OOM and stop loading so many classes (???). During method compilation this is more surprising, so I'm going to change my vote for #2 now. I support throwing VM errors when the VM is out of resources for normal execution, but only under these conditions: 1. the error must be linked to a user request that somehow contributed to the resource exhaustion 2. the user has a reasonable chance to catch and recover from the error (Dirty secret: That's a pretty broad permission, since the JVMS allows us to throw SOE almost anywhere; think "apush". That's why point #2 is there.) If the conditions are not met, then the JVM has to do without the resources, with as much graceful degradation as is feasible. If the degradation is likely to felt as a bug, or if the user has turned on some sort of logging, the JVM should communicate the event appropriately, along the lines of CompileBroker::handle_full_code_cache. ? John P.S. Here's an optimization which stretches condition #1: Sometimes the JVM can optimistically *delay* the creation of user-allocated objects, using (for example) escape analysis. When it wins, the creation is delayed forever and the heap is never used. In some corner cases, the delayed object must be created (at de-opt time). At this point memory might run out. The resulting OOME might appear to be thrown long after the user thought the object was allocated, so the causal link might be tenuous. What this tells me is we need workable rules for deferring resource exhaustion events. From serguei.spitsyn at oracle.com Tue Oct 21 20:30:12 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Oct 2014 13:30:12 -0700 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <5446B9FA.4080201@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> <543E77CA.3090806@oracle.com> <543E7B08.8040305@oracle.com> <543FA9AD.2070404@oracle.com> <5445686F.4090103@oracle.com> <5446B9FA.4080201@oracle.com> Message-ID: <5446C254.7040801@oracle.com> Hi Andreas, Very nice, thank you for the refactoring! Thumbs up. Thanks, Serguei On 10/21/14 12:54 PM, Andreas Eriksson wrote: > Hi Serguei, > > I split up the method into several, and made the verification before > and after retransform share logic. > Webrev: http://cr.openjdk.java.net/~aeriksso/8057043/webrev.02/ > > Regards, > Andreas > > On 2014-10-20 21:54, serguei.spitsyn at oracle.com wrote: >> Hi Andreas, >> >> Sorry for the delay. >> >> On 10/16/14 4:19 AM, Andreas Eriksson wrote: >>> >>> On 2014-10-15 15:47, Daniel D. Daugherty wrote: >>>> On 10/15/14 7:34 AM, Coleen Phillimore wrote: >>>>> >>>>> There are lots of other rewrite_cp_refs_in* function calls. Please >>>>> indent your function like them, not differently. >>>> >>>> The above implies that my answer below was made without sufficient >>>> context... my apologies for that. >>>> >>>> The general rule is to follow the existing style in the file so >>>> if there are rewrite_cp_refs_in* function calls in the file, then >>>> please follow that style. Unless, of course, you want to fix all >>>> of them to follow the HotSpot style guideline: >>>> >>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide >>>> >>>> > Use good taste to break lines and align corresponding tokens >>>> > on adjacent lines. >>>> >>>> but that may cause Coleen some heartburn :-) >>> >>> I fixed the calls to follow the already existing indent style. >>> I have also made changes to the test, which I hope Joel can take a >>> look at. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.01/ >> >> The fix looks good. >> >> A couple of comments about the test. >> >> The method testTransformAndVerify() is too big. >> At least, it looks like there are some ways to refactor it to make >> calls to smaller methods. >> >> There are two directions of doing it: >> - make a smaller method out of each block: >> 217-236, 238-260, 262-276, 311-329, 331-351, 353-367 >> - some of the lines sequences looks very typical: >> 221 at = c.getDeclaredField("typeAnnotatedArray").getAnnotatedType(); >> 222 arrayTA1 = at.getAnnotations()[0]; >> 223 verifyTestAnnSite(arrayTA1, "array1"); >> 224 >> 225 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); >> 226 arrayTA2 = at.getAnnotations()[0]; >> 227 verifyTestAnnSite(arrayTA2, "array2"); >> 228 >> 229 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); >> 230 arrayTA3 = at.getAnnotations()[0]; >> 231 verifyTestAnnSite(arrayTA3, "array3"); >> 232 >> 233 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); >> 234 arrayTA4 = at.getAnnotations()[0]; >> 235 verifyTestAnnSite(arrayTA4, "array4"); >> But I leave it up to you. >> >> Another step to improve the readability is to add a short comment for >> each block of code saying what is done there. >> >> Thanks, >> Serguei >> >> >>> >>> Thanks, >>> Andreas >>> >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Coleen >>>>> >>>>> On 10/15/14, 9:05 AM, Daniel D. Daugherty wrote: >>>>>> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>>>>>> Thanks Serguei. >>>>>>> >>>>>>> I have a question about the if-blocks that had the wrong indent: >>>>>>> >>>>>>> 2335 if >>>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>> >>>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>>> >>>>>>> How should I indent them? >>>>>> >>>>>> Trying again without the line numbers... >>>>>> >>>>>> if >>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>> >>>>>> byte_i, "method_info", >>>>>> THREAD)) { >>>>>> >>>>>> Just in case, TB messes with the spacing again, the "byte_i" line >>>>>> and >>>>>> "THREAD" lines are aligned under "method_type_annotations". >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> /Andreas >>>>>>> >>>>>>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Andreas, >>>>>>>> >>>>>>>> Sorry I did not reply on this early. >>>>>>>> I assumed, it is a thumbs up from me. >>>>>>>> Just wanted make it clean now. :) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>>>>>> Hi Serguei, thanks for looking at this! >>>>>>>>> >>>>>>>>> I'll make sure to fix the style problems. >>>>>>>>> For the symbolic names / #defines, please see my answer to >>>>>>>>> Coleen. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Andreas >>>>>>>>> >>>>>>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Andreas, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thank you for fixing this issue! >>>>>>>>>> The fix looks nice, I do not see any logical issues. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Only minor comments... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>>>>>> >>>>>>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>>>>>> 2785 } // end skip_type_annotation_target >>>>>>>>>> 2844 } // end skip_type_annotation_type_path >>>>>>>>>> >>>>>>>>>> The ')' is missed at 2281, 2315. >>>>>>>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>>>>>>> function-end comments in the file. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2335 if >>>>>>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>>>>> >>>>>>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>>>>>> . . . >>>>>>>>>> 2378 if >>>>>>>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>>>>>> >>>>>>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>>>>>> . . . >>>>>>>>>> 2427 if >>>>>>>>>> (!skip_type_annotation_target(type_annotations_typeArray, >>>>>>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>>>>>> 2429 return false; >>>>>>>>>> 2430 } >>>>>>>>>> 2431 >>>>>>>>>> 2432 if >>>>>>>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>>>>>> 2433 byte_i_ref, THREAD)) { >>>>>>>>>> 2434 return false; >>>>>>>>>> 2435 } >>>>>>>>>> 2436 >>>>>>>>>> 2437 if >>>>>>>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>>>>>> >>>>>>>>>> 2438 byte_i_ref, THREAD)) { >>>>>>>>>> 2439 return false; >>>>>>>>>> Wrong indent at 2336, 2379, etc. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I also concur with Coleen that it would be good to define and >>>>>>>>>> use >>>>>>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>>>>>> >>>>>>>>>> Java indent must be 4, not 2. >>>>>>>>>> >>>>>>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>>>>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>>>>>>>> TypeAnnotatedTestClass arg) >>>>>>>>>> >>>>>>>>>> The line is too long. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 143 } >>>>>>>>>> 144 public static void main(String argv[]) { >>>>>>>>>> . . . >>>>>>>>>> 209 } >>>>>>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>>>>>> 212 } >>>>>>>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>>>>>>> annoTypes) { >>>>>>>>>> 214 for (AnnotatedType p : annoTypes) >>>>>>>>>> checkAnnotations(p.getAnnotations()); >>>>>>>>>> 215 } >>>>>>>>>> 216 private static void >>>>>>>>>> checkAnnotations(Class c) { >>>>>>>>>> . . . >>>>>>>>>> 257 } >>>>>>>>>> 258 public void run() {} >>>>>>>>>> >>>>>>>>>> Adding empty lines between method definitions would >>>>>>>>>> improve readability. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review this patch to RedefineClasses to allow type >>>>>>>>>>> annotations to be preserved. >>>>>>>>>>> >>>>>>>>>>> Summary: >>>>>>>>>>> During redefine / retransform class the constant pool >>>>>>>>>>> indexes can change. >>>>>>>>>>> Since annotations have indexes into the constant pool these >>>>>>>>>>> indexes need to be rewritten. >>>>>>>>>>> This is already done for regular annotations, but not for >>>>>>>>>>> type annotations. >>>>>>>>>>> This patch adds code to add this rewriting for the type >>>>>>>>>>> annotations as well. >>>>>>>>>>> The patch also contains minor changes to >>>>>>>>>>> ClassFileReconstituter, to make sure that type annotations >>>>>>>>>>> are preserved during a redefine / retransform class operation. >>>>>>>>>>> It also has a test that uses asm to change constant pool >>>>>>>>>>> indexes through a retransform, and then verifies that type >>>>>>>>>>> annotations are preserved. >>>>>>>>>>> >>>>>>>>>>> Detail: >>>>>>>>>>> A type annotation struct consists of some target information >>>>>>>>>>> and a type path, followed by a regular annotation struct. >>>>>>>>>>> Constant pool indexes are only present in the regular >>>>>>>>>>> annotation struct. >>>>>>>>>>> The added code skips over the type annotation specific >>>>>>>>>>> parts, then calls previously existing code to rewrite >>>>>>>>>>> constant pool indexes in the regular annotation struct. >>>>>>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for >>>>>>>>>>> more info about the type annotation struct. >>>>>>>>>>> >>>>>>>>>>> JPRT with the new test passes without failures on all >>>>>>>>>>> platforms. >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Bug: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Andreas >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From john.r.rose at oracle.com Tue Oct 21 20:37:36 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 21 Oct 2014 13:37:36 -0700 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <54411709.6000400@oracle.com> References: <54411709.6000400@oracle.com> Message-ID: On Oct 17, 2014, at 6:18 AM, Albert Noll wrote: > Here is the webrev for Solution 1. Please note that I am not familiar with this part of the code. > > http://cr.openjdk.java.net/~anoll/8037842/webrev.00/ Per previous messages, we should work on solution #2. Also, the code changes for solution #1 look wrong to me, in that they appear to "tunnel" exceptions through C function calls which do *not* have "TRAPS" in their signature. This is historically a rich source of bugs, since it is a non-local effect. If a second exception gets thrown while the first is in transit, you may get a crash. Another observed bug is dangling managed pointers, since "TRAPS" functions may block and cause GCs. If you have a TRAPS function E calling a non-TRAPS function F calling a TRAPS function G, then raw oops in E are at risk of being broken during the call to G, because the author of E had no easy way to know the GC might have happened during the call to E. Regarding the CLEAR_PENDING_EXCEPTION macro, if you use it you have to really return normally or generate a new exception. Conversely, if you don't use it, you must use the CHECK macro (or similar) after any TRAPS function to propagate any current exception. ? John From erik.osterlund at lnu.se Wed Oct 22 00:38:53 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Wed, 22 Oct 2014 00:38:53 +0000 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: References: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> Message-ID: <21D89760-6941-4CB4-B5D1-DD90A70A4E28@lnu.se> Hi Paul, On 21 Oct 2014, at 21:29, Paul Hohensee > wrote: Re the simple fix, if you've successfully run DaCapo using G1 on all platforms for which you've added custom implementations, and considering it'll be replaced (so I withdraw my previous comments and accept it as is), consider it reviewed. Just to clarify, I don't have access to all platforms unfortunately, so the solaris (32 and 64 bit) and windows 32-bit approaches have still only been tested with jprt and careful manual reviewing, so an extra eye should probably glance over it. The windows AMD64 variant with runtime-produced cmpxchgb, linux and bsd variants have been tested with DaCapo + G1. Sorry if I was not clear enough with this. For the template fix: A nit: in templateIdioms.hpp, put the on-one-line-by-themselves-{'s at the end of the previous lines. The styling of templateIdioms.hpp has been fixed now. (Do you need a new webrev for this?) If it passes the same tests as the simple fix, it's good to go too. The inheritance/template solution went through the same tests as the first and it's fine. Big thanks again to Jesper for running it through jprt. Big thanks for reviewing my changes! :) /Erik Paul On Tue, Oct 21, 2014 at 11:55 AM, Erik ?sterlund > wrote: Hi Paul, I understand your defensive thinking. :) There is indeed no conflict between the two schemes, which was an important design goal to me. In this case I will need some reviews for my old solution first so I can push the changes. So this time, let's pretend that #define VM_HAS_SPECIALIZED_BYTE_CMPXCHG isn't there as it will be fixed in a cleaner way in the successive change. Bug: https://bugs.openjdk.java.net/browse/JDK-8058255 Webrev for the simple fix (which I intend to push initially): http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.macro/ Webrev for the inheritance/template solution (which will be pushed after and is the intended "end" result): http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.templates/ Webrev for the delta from the macro solution to the inheritance/template solution: http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.incremental/ The solutions are unchanged from before except for one thing: the Assembler::cmpxchgb used in code stub used by awkward AMD64 windows config. I added a flag needed to put a REX prefix (0x40) in front of the (new) cmpxchgb machine code encoding when byte-sized registers are used, required by the hardware specification. Testing of webrev.03.macro which I want to push now: 1. jprt (big thanks to Jesper for helping me with this!) 2. I have tested that the assembly produced in CodeStub works locally by carefully introspecting the machine code produced compared to the machine code produced by inline asm. 3. Running through some DaCapo benchmarks (with the CodeStub cmpxchgb and G1 which uses jbyte cmpxchg quite a bit for card manipulation). I would like to thank Jesper again for helping me make webrevs and supporting me. Thanks, /Erik On 21 Oct 2014, at 04:33, Paul Hohensee > wrote: I was perhaps unclear. :) The new scheme and the old will co-exist, i.e., there's no conflict between the two, right? That makes transition to the new easier, but if we leave the old way there, then two ways of doing the same thing will result in more cognitive overhead and thus higher maintenance costs, just as is the case with the two parallel scavengers. So, I'd prefer the new way to supplant the old as soon as practicable. I proposed to implement your old solution as a step on the way to the new, so there'd be a record of how that worked. It's also the minimal change, so if it's in the repo and there are issues with the new way, it's easy to revert while a fix is done. Call it paranoia. :) Paul On Mon, Oct 20, 2014 at 7:04 PM, Erik ?sterlund > wrote: Hi Paul, Thank you for your reply. Webrev for new inheritance based solution: http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.02/ In my opinion it does not create a conflict that there are two different systems. There are 3 levels in the hierarchy, all with well defined responsibilities: AtomicBase - atomics that can be generalized for all platforms, AtomicPlatform (optional) for atomics overriding AtomicBase with specialized implementations, and Atomic for atomics that always look different on all platforms (and hence has little benefit of inheritance). With this view (and responsibilities), it is already consistent AFAIK unless we have more things that could be generalized that should be shifted up in the hierarchy which would be nice. Do you propose we use my old solution (http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01/) for now which is less reliant on compiler support and strictly only fixes the jbyte cmpxchg in a less architecturally intrusive way, or the new cleaner inheritance variant? Thanks, /Erik On 20 Oct 2014, at 16:23, Paul Hohensee > wrote: I'd also worry about a couple of other things. First, way back in the mists of time, C++ compilers differed with respect to their template implementations. Hopefully the C++ compiles on all openjdk platforms do what you expect. Second, if you do this, we'll have two alternatives for implementing Atomic, which generally isn't a good thing (vis we have two GC frameworks). I'd want to see every platform switch to the new way of doing things asap and get rid of the old way. Paul On Mon, Oct 20, 2014 at 10:10 AM, Paul Hohensee > wrote: Sorry for the delay in responding. Idea seems ok. I'd like to see a webrev. You might start with your original solution (the one I reviewed) just to get a fix in place. Paul On Wed, Oct 15, 2014 at 9:47 AM, Erik ?sterlund > wrote: Hi Paul, Thank you for the reply. I like the idea of using inheritance too. I tried a new solution which is similar to the one proposed and I would like to hear your comment if this is okay so we are all happy. The core idea is to have a general AtomicBase class which implements the old unspecialized cmpxchg (and possibly other stuff to come), then allow platforms to /optionally/ define their own AtomicPlatform base classes in the hierarchy that derive from AtomicBase. Then the last step in the hierarchy is Atomic which inherits from AtomicPlatform if it is defined and otherwise AtomicBase. It picks the superclass using SFINAE. The reason for this is that other ports will not be broken by this performance fix and the definition of such AtomicPlatform class is completely optional. :) Benefits: * Uses inheritance and looks nice like the inheritance based solution proposed * Does not break ports outside of the main repo * Does not require refactoring of everything (moving all methods from Atomic to AbstractAtomic for all platforms) * Changes are local to only the platforms that want to add this functionality * Flexible for supporting the future demands In a bit more detail, it looks like this: atomic.hpp: class AtomicBase : AllStatic { protected: static jbyte cmpxchg_unspecialized(jbyte exchange_value, volatile jbyte* dest, jbyte compare_value); public: inline static jbyte cmpxchg (jbyte exchange_value, volatile jbyte* dest, jbyte compare_value) { return cmpxchg_unspecialized(exchange_value, dest, compare_value); } }; // Linux #ifdef TARGET_OS_ARCH_linux_x86 # include "atomic_linux_x86.hpp" #endif // BSD #ifdef TARGET_OS_ARCH_bsd_x86 # include "atomic_bsd_x86.hpp" #endif // ... and the other platforms that benefit from specialized AtomicPlatform ... class AtomicPlatform; // Forward declaration to avoid compiler error when it is not defined // Based on some SFINAE stuff I made and will contribute if you like it. AtomicSuper will be AtomicPlatform if defined in a platform specific atomic_os_arch.hpp file, otherwise AtomicBase will be used typedef base_class::type AtomicSuper; // AtomicSuper is now the base class of Atomic, and contains the cmpxchgb implementation class Atomic : public AtomicSuper { // ... inline static jbyte cmpxchg (jbyte exchange_value, volatile jbyte* dest, jbyte compare_value) { // Just call super class implementation return AtomicSuper::cmpxchg(exchange_value, dest, compare_value); } // ... }; A new atomic_os_arch.hpp file looks like this (for platforms that support this): class AtomicPlatform : public AtomicBase { public: static jbyte cmpxchg(jbyte exchange_value, volatile jbyte* dest, jbyte compare_value); }; And atomic_os_arch.inline.hpp contains the implementation like before, but as members of AtomicPlatform instead of Atomic For the curious reader, the SFINAE stuff for base_class looks like this: template struct is_base_of_host { operator Base*() const; operator Derived*(); }; // Statically check if two types are related in a class hierarchy template struct is_base_of { typedef char yes[1]; typedef char no[2]; template static yes &check(Derived*, T); static no &check(Base*, int); static const bool value = sizeof(check(is_base_of_host(), int())) == sizeof(yes); }; // The ::type of this struct will be the Desired type if it was defined // and a subtype of Fallback, otherwise it will be Fallback. // This is useful when optionally inheriting from a specialized subtype. template struct base_class { template struct check_inheritance { typedef T type; }; template struct check_inheritance { typedef U type; }; typedef typename check_inheritance::value, Fallback, Desired>::type type; }; If everyone is happy with this solution, then I will prepare another webrev and send the patch. :) Thanks for taking the time to read through this change. /Erik On 14 Oct 2014, at 19:25, Paul Hohensee > wrote: > David Holmes asked me to take a look at this > >>>>> There is now a new webrev with my jbyte cmpxchg changes here: >>>>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01 > > and comment, so... > > The approach is good if you're going to stay with the current framework, > except that I'd get rid of VM_HAS_SPECIALIZED_BYTE_CMPXCHG (#ifdef's are > the devil). Just call cmpxchg_general (which should be named > cmpxchgb_general or maybe cmpxchgb_unspecialized, btw) from an os_cpu file > as needed. I.e., no change to atomic.inline.hpp needed. Another way to > look at it is, cmpxchgb_general/unspecialized is the implementation of > another specialized version of cmpxchgb, on the same abstraction level as > the asm versions. > > If a rewrite is possible, I'd do it the way David suggests with an > AbstractAtomic class from which per-platform Atomic classes are derived. > That's the way VM_Version and ICache are defined. > > Paul From david.holmes at oracle.com Wed Oct 22 00:46:02 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Oct 2014 10:46:02 +1000 Subject: [8u40] RFR Backport 8056183: os::is_MP() always reports true when NMT is enabled Message-ID: <5446FE4A.9050802@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8056183/webrev/ This is a direct backport from 9. http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2ade0284497b Thanks, David From david.holmes at oracle.com Wed Oct 22 00:46:07 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Oct 2014 10:46:07 +1000 Subject: [8u40] RFR backport 8049411: Minimal VM build broken after gcId.cpp was added Message-ID: <5446FE4F.7060200@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8049411/webrev/ This is a direct backport from 9: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3976a725c192 Thanks, David From david.holmes at oracle.com Wed Oct 22 00:46:13 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Oct 2014 10:46:13 +1000 Subject: [8u40] RFR backport 8058919 and 8049071 Message-ID: <5446FE55.8040809@oracle.com> webrevs: http://cr.openjdk.java.net/~dholmes/8058919-8049071/webrev.hotspot/ http://cr.openjdk.java.net/~dholmes/8058919-8049071/webrev.top/ 8058919: Add sanity test for minimal VM in test/Makefile This is a direct backport from 9: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c602ed4cfca9 --- 8049071: Add jtreg jobs to JPRT for hotspot These are direct backports from 9 on the hotspot side: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a527e4909a92 The top-level jprt.properties file had to be adjusted for the 8u platforms vs 9 platforms: http://hg.openjdk.java.net/jdk9/hs-rt/rev/e291a5c557d1 From vladimir.kozlov at oracle.com Wed Oct 22 00:58:32 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Oct 2014 17:58:32 -0700 Subject: [8u40] RFR Backport 8056183: os::is_MP() always reports true when NMT is enabled In-Reply-To: <5446FE4A.9050802@oracle.com> References: <5446FE4A.9050802@oracle.com> Message-ID: <54470138.9040806@oracle.com> Good. Vladimir On 10/21/14 5:46 PM, David Holmes wrote: > webrev: > > http://cr.openjdk.java.net/~dholmes/8056183/webrev/ > > This is a direct backport from 9. > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2ade0284497b > > Thanks, > David From vladimir.kozlov at oracle.com Wed Oct 22 00:59:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Oct 2014 17:59:01 -0700 Subject: [8u40] RFR backport 8049411: Minimal VM build broken after gcId.cpp was added In-Reply-To: <5446FE4F.7060200@oracle.com> References: <5446FE4F.7060200@oracle.com> Message-ID: <54470155.9080101@oracle.com> Good. Vladimir On 10/21/14 5:46 PM, David Holmes wrote: > webrev: > > http://cr.openjdk.java.net/~dholmes/8049411/webrev/ > > This is a direct backport from 9: > > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3976a725c192 > > Thanks, > David > From vladimir.kozlov at oracle.com Wed Oct 22 01:03:45 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Oct 2014 18:03:45 -0700 Subject: [8u40] RFR backport 8058919 and 8049071 In-Reply-To: <5446FE55.8040809@oracle.com> References: <5446FE55.8040809@oracle.com> Message-ID: <54470271.9080207@oracle.com> Why you did not separate 8058919 from 8049071? I am fine with it but don't forget to list both bugs in hotspot changeset. Thanks, Vladimir On 10/21/14 5:46 PM, David Holmes wrote: > webrevs: > > http://cr.openjdk.java.net/~dholmes/8058919-8049071/webrev.hotspot/ > http://cr.openjdk.java.net/~dholmes/8058919-8049071/webrev.top/ > > 8058919: Add sanity test for minimal VM in test/Makefile > > This is a direct backport from 9: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c602ed4cfca9 > > --- > > 8049071: Add jtreg jobs to JPRT for hotspot > > These are direct backports from 9 on the hotspot side: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a527e4909a92 > > The top-level jprt.properties file had to be adjusted for the 8u > platforms vs 9 platforms: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/e291a5c557d1 > > > From david.holmes at oracle.com Wed Oct 22 01:30:01 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Oct 2014 11:30:01 +1000 Subject: [8u40] RFR backport 8058919 and 8049071 In-Reply-To: <54470271.9080207@oracle.com> References: <5446FE55.8040809@oracle.com> <54470271.9080207@oracle.com> Message-ID: <54470899.6050108@oracle.com> Hi Vladimir, On 22/10/2014 11:03 AM, Vladimir Kozlov wrote: > Why you did not separate 8058919 from 8049071? > I am fine with it but don't forget to list both bugs in hotspot changeset. I had already imported both changesets before knowing I might need to process them one at a time. It was too painful to try and revert and then do them one at a time. As per the webrev two distinct changesets are present - one for each bug. Thanks for all the reviews/approvals! I can now push them all together. David > Thanks, > Vladimir > > On 10/21/14 5:46 PM, David Holmes wrote: >> webrevs: >> >> http://cr.openjdk.java.net/~dholmes/8058919-8049071/webrev.hotspot/ >> http://cr.openjdk.java.net/~dholmes/8058919-8049071/webrev.top/ >> >> 8058919: Add sanity test for minimal VM in test/Makefile >> >> This is a direct backport from 9: >> >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c602ed4cfca9 >> >> --- >> >> 8049071: Add jtreg jobs to JPRT for hotspot >> >> These are direct backports from 9 on the hotspot side: >> >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a527e4909a92 >> >> The top-level jprt.properties file had to be adjusted for the 8u >> platforms vs 9 platforms: >> >> http://hg.openjdk.java.net/jdk9/hs-rt/rev/e291a5c557d1 >> >> >> From david.holmes at oracle.com Wed Oct 22 02:16:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Oct 2014 12:16:46 +1000 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <54465AE9.70908@oracle.com> References: <54465AE9.70908@oracle.com> Message-ID: <5447138E.9060702@oracle.com> Hi Tobias, On 21/10/2014 11:08 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 > Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ > > Problem: > The Whitebox API methods get*VMFlag() fail with develop/notproduct flags in > product builds. > > Solution: > The code is changed to invoke 'Flag::find_flag' with allow_locked=true and > return_flag=true to return both locked and notproduct/develop flags. I also > changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. Why did you change the jmm code? You seemed to have changed its semantics - which may require a CCC request. Thanks, David > I adapted the existing tests to check for develop flags as well. I noticed that > HotspotDiagnosticMXBean.getVMOption() fails with double flags and filed > JDK-8061616 [1]. > > Testing: > - New testcases > - JPRT > > Thanks, > Tobias > > > [1] https://bugs.openjdk.java.net/browse/JDK-8061616 > From paul.hohensee at gmail.com Wed Oct 22 03:08:59 2014 From: paul.hohensee at gmail.com (Paul Hohensee) Date: Tue, 21 Oct 2014 23:08:59 -0400 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: <21D89760-6941-4CB4-B5D1-DD90A70A4E28@lnu.se> References: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> <21D89760-6941-4CB4-B5D1-DD90A70A4E28@lnu.se> Message-ID: Can't complain as long as you've tested on all available platforms. :) No need for a new webrev for formatting changes. You're good to go afaic. Paul On Tue, Oct 21, 2014 at 8:38 PM, Erik ?sterlund wrote: > Hi Paul, > > On 21 Oct 2014, at 21:29, Paul Hohensee wrote: > > Re the simple fix, if you've successfully run DaCapo using G1 on all > platforms for which you've added custom implementations, and considering > it'll be replaced (so I withdraw my previous comments and accept it as is), > consider it reviewed. > > > Just to clarify, I don't have access to all platforms unfortunately, so > the solaris (32 and 64 bit) and windows 32-bit approaches have still only > been tested with jprt and careful manual reviewing, so an extra eye should > probably glance over it. The windows AMD64 variant with runtime-produced > cmpxchgb, linux and bsd variants have been tested with DaCapo + G1. Sorry > if I was not clear enough with this. > > For the template fix: > > A nit: in templateIdioms.hpp, put the on-one-line-by-themselves-{'s at > the end of the previous lines. > > > The styling of templateIdioms.hpp has been fixed now. (Do you need a new > webrev for this?) > > If it passes the same tests as the simple fix, it's good to go too. > > > The inheritance/template solution went through the same tests as the > first and it's fine. > Big thanks again to Jesper for running it through jprt. > > Big thanks for reviewing my changes! :) > > /Erik > > > Paul > > > On Tue, Oct 21, 2014 at 11:55 AM, Erik ?sterlund > wrote: > >> Hi Paul, >> >> I understand your defensive thinking. :) There is indeed no conflict >> between the two schemes, which was an important design goal to me. >> In this case I will need some reviews for my old solution first so I can >> push the changes. >> >> So this time, let's pretend that #define >> VM_HAS_SPECIALIZED_BYTE_CMPXCHG isn't there as it will be fixed in a >> cleaner way in the successive change. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8058255 >> >> Webrev for the simple fix (which I intend to push initially): >> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.macro/ >> >> Webrev for the inheritance/template solution (which will be pushed >> after and is the intended "end" result): >> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.templates/ >> >> Webrev for the delta from the macro solution to the >> inheritance/template solution: >> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.incremental/ >> >> The solutions are unchanged from before except for one thing: the >> Assembler::cmpxchgb used in code stub used by awkward AMD64 windows config. >> I added a flag needed to put a REX prefix (0x40) in front of the (new) >> cmpxchgb machine code encoding when byte-sized registers are used, required >> by the hardware specification. >> >> Testing of webrev.03.macro which I want to push now: >> 1. jprt (big thanks to Jesper for helping me with this!) >> 2. I have tested that the assembly produced in CodeStub works locally by >> carefully introspecting the machine code produced compared to the machine >> code produced by inline asm. >> 3. Running through some DaCapo benchmarks (with the CodeStub cmpxchgb and >> G1 which uses jbyte cmpxchg quite a bit for card manipulation). >> >> I would like to thank Jesper again for helping me make webrevs and >> supporting me. >> >> Thanks, >> /Erik >> >> On 21 Oct 2014, at 04:33, Paul Hohensee wrote: >> >> I was perhaps unclear. :) The new scheme and the old will co-exist, >> i.e., there's no conflict between the two, right? That makes transition to >> the new easier, but if we leave the old way there, then two ways of doing >> the same thing will result in more cognitive overhead and thus higher >> maintenance costs, just as is the case with the two parallel scavengers. >> So, I'd prefer the new way to supplant the old as soon as practicable. >> >> I proposed to implement your old solution as a step on the way to the >> new, so there'd be a record of how that worked. It's also the minimal >> change, so if it's in the repo and there are issues with the new way, it's >> easy to revert while a fix is done. Call it paranoia. :) >> >> Paul >> >> >> On Mon, Oct 20, 2014 at 7:04 PM, Erik ?sterlund >> wrote: >> >>> Hi Paul, >>> >>> Thank you for your reply. >>> >>> Webrev for new inheritance based solution: >>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.02/ >>> >>> In my opinion it does not create a conflict that there are two >>> different systems. There are 3 levels in the hierarchy, all with well >>> defined responsibilities: AtomicBase - atomics that can be generalized for >>> all platforms, AtomicPlatform (optional) for atomics overriding AtomicBase >>> with specialized implementations, and Atomic for atomics that always look >>> different on all platforms (and hence has little benefit of inheritance). >>> >>> With this view (and responsibilities), it is already consistent AFAIK >>> unless we have more things that could be generalized that should be shifted >>> up in the hierarchy which would be nice. >>> >>> Do you propose we use my old solution ( >>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01/) for now which >>> is less reliant on compiler support and strictly only fixes the jbyte >>> cmpxchg in a less architecturally intrusive way, or the new cleaner >>> inheritance variant? >>> >>> Thanks, >>> >>> /Erik >>> >>> On 20 Oct 2014, at 16:23, Paul Hohensee >>> wrote: >>> >>> I'd also worry about a couple of other things. First, way back in the >>> mists of time, C++ compilers differed with respect to their template >>> implementations. Hopefully the C++ compiles on all openjdk platforms do >>> what you expect. Second, if you do this, we'll have two alternatives for >>> implementing Atomic, which generally isn't a good thing (vis we have two GC >>> frameworks). I'd want to see every platform switch to the new way of doing >>> things asap and get rid of the old way. >>> >>> Paul >>> >>> >>> On Mon, Oct 20, 2014 at 10:10 AM, Paul Hohensee >> > wrote: >>> >>>> Sorry for the delay in responding. >>>> >>>> Idea seems ok. I'd like to see a webrev. >>>> >>>> You might start with your original solution (the one I reviewed) just >>>> to get a fix in place. >>>> >>>> Paul >>>> >>>> >>>> On Wed, Oct 15, 2014 at 9:47 AM, Erik ?sterlund >>>> wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> Thank you for the reply. I like the idea of using inheritance too. >>>>> I tried a new solution which is similar to the one proposed and I >>>>> would like to hear your comment if this is okay so we are all happy. >>>>> >>>>> The core idea is to have a general AtomicBase class which implements >>>>> the old unspecialized cmpxchg (and possibly other stuff to come), then >>>>> allow platforms to /optionally/ define their own AtomicPlatform base >>>>> classes in the hierarchy that derive from AtomicBase. Then the last step in >>>>> the hierarchy is Atomic which inherits from AtomicPlatform if it is defined >>>>> and otherwise AtomicBase. It picks the superclass using SFINAE. The reason >>>>> for this is that other ports will not be broken by this performance fix and >>>>> the definition of such AtomicPlatform class is completely optional. :) >>>>> >>>>> Benefits: >>>>> * Uses inheritance and looks nice like the inheritance based solution >>>>> proposed >>>>> * Does not break ports outside of the main repo >>>>> * Does not require refactoring of everything (moving all methods from >>>>> Atomic to AbstractAtomic for all platforms) >>>>> * Changes are local to only the platforms that want to add this >>>>> functionality >>>>> * Flexible for supporting the future demands >>>>> >>>>> In a bit more detail, it looks like this: >>>>> >>>>> atomic.hpp: >>>>> >>>>> class AtomicBase : AllStatic { >>>>> protected: >>>>> static jbyte cmpxchg_unspecialized(jbyte exchange_value, volatile >>>>> jbyte* dest, jbyte compare_value); >>>>> public: >>>>> inline static jbyte cmpxchg (jbyte exchange_value, >>>>> volatile jbyte* dest, jbyte compare_value) { >>>>> return cmpxchg_unspecialized(exchange_value, dest, compare_value); >>>>> } >>>>> }; >>>>> >>>>> // Linux >>>>> #ifdef TARGET_OS_ARCH_linux_x86 >>>>> # include "atomic_linux_x86.hpp" >>>>> #endif >>>>> >>>>> // BSD >>>>> #ifdef TARGET_OS_ARCH_bsd_x86 >>>>> # include "atomic_bsd_x86.hpp" >>>>> #endif >>>>> >>>>> // ... and the other platforms that benefit from specialized >>>>> AtomicPlatform ... >>>>> >>>>> class AtomicPlatform; // Forward declaration to avoid compiler error >>>>> when it is not defined >>>>> >>>>> // Based on some SFINAE stuff I made and will contribute if you like >>>>> it. AtomicSuper will be AtomicPlatform if defined in a platform specific >>>>> atomic_os_arch.hpp file, otherwise AtomicBase will be used >>>>> typedef base_class::type AtomicSuper; >>>>> >>>>> // AtomicSuper is now the base class of Atomic, and contains the >>>>> cmpxchgb implementation >>>>> class Atomic : public AtomicSuper { >>>>> // ... >>>>> inline static jbyte cmpxchg (jbyte exchange_value, >>>>> volatile jbyte* dest, jbyte compare_value) { >>>>> // Just call super class implementation >>>>> return AtomicSuper::cmpxchg(exchange_value, dest, compare_value); >>>>> } >>>>> // ... >>>>> }; >>>>> >>>>> A new atomic_os_arch.hpp file looks like this (for platforms that >>>>> support this): >>>>> class AtomicPlatform : public AtomicBase { >>>>> public: >>>>> static jbyte cmpxchg(jbyte exchange_value, volatile jbyte* dest, >>>>> jbyte compare_value); >>>>> }; >>>>> >>>>> And atomic_os_arch.inline.hpp contains the implementation like before, >>>>> but as members of AtomicPlatform instead of Atomic >>>>> >>>>> For the curious reader, the SFINAE stuff for base_class looks like >>>>> this: >>>>> >>>>> template >>>>> struct is_base_of_host >>>>> { >>>>> operator Base*() const; >>>>> operator Derived*(); >>>>> }; >>>>> >>>>> // Statically check if two types are related in a class hierarchy >>>>> template >>>>> struct is_base_of >>>>> { >>>>> typedef char yes[1]; >>>>> typedef char no[2]; >>>>> >>>>> template >>>>> static yes &check(Derived*, T); >>>>> static no &check(Base*, int); >>>>> >>>>> static const bool value = sizeof(check(is_base_of_host>>>> Derived>(), int())) == sizeof(yes); >>>>> }; >>>>> >>>>> // The ::type of this struct will be the Desired type if it was defined >>>>> // and a subtype of Fallback, otherwise it will be Fallback. >>>>> // This is useful when optionally inheriting from a specialized >>>>> subtype. >>>>> template >>>>> struct base_class { >>>>> template >>>>> struct check_inheritance { >>>>> typedef T type; >>>>> }; >>>>> >>>>> template >>>>> struct check_inheritance { >>>>> typedef U type; >>>>> }; >>>>> >>>>> typedef typename check_inheritance>>>> Desired>::value, Fallback, Desired>::type type; >>>>> }; >>>>> >>>>> If everyone is happy with this solution, then I will prepare another >>>>> webrev and send the patch. :) >>>>> Thanks for taking the time to read through this change. >>>>> >>>>> /Erik >>>>> >>>>> On 14 Oct 2014, at 19:25, Paul Hohensee >>>>> wrote: >>>>> >>>>> > David Holmes asked me to take a look at this >>>>> > >>>>> >>>>> There is now a new webrev with my jbyte cmpxchg changes here: >>>>> >>>>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01 >>>>> > >>>>> > and comment, so... >>>>> > >>>>> > The approach is good if you're going to stay with the current >>>>> framework, >>>>> > except that I'd get rid of VM_HAS_SPECIALIZED_BYTE_CMPXCHG (#ifdef's >>>>> are >>>>> > the devil). Just call cmpxchg_general (which should be named >>>>> > cmpxchgb_general or maybe cmpxchgb_unspecialized, btw) from an >>>>> os_cpu file >>>>> > as needed. I.e., no change to atomic.inline.hpp needed. Another >>>>> way to >>>>> > look at it is, cmpxchgb_general/unspecialized is the implementation >>>>> of >>>>> > another specialized version of cmpxchgb, on the same abstraction >>>>> level as >>>>> > the asm versions. >>>>> > >>>>> > If a rewrite is possible, I'd do it the way David suggests with an >>>>> > AbstractAtomic class from which per-platform Atomic classes are >>>>> derived. >>>>> > That's the way VM_Version and ICache are defined. >>>>> > >>>>> > Paul >>>>> >>>>> >>>> >>> >>> >> >> > > From david.holmes at oracle.com Wed Oct 22 06:56:47 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Oct 2014 16:56:47 +1000 Subject: [8u40] RFR backport 8031376: TraceClassLoading expects there to be a (Java) caller when you load a class with the bootstrap class loader Message-ID: <5447552F.9060609@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8031376/webrev.8u/ This is a sponsored backport request: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015618.html The changeset imported directly from 9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/715bc50198c1 Thanks, David From albert.noll at oracle.com Wed Oct 22 07:21:42 2014 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 22 Oct 2014 09:21:42 +0200 Subject: RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <200C103C-F356-4A1A-BD06-F1D7FCDDFC4A@oracle.com> References: <54411709.6000400@oracle.com> <54455E49.7010603@oracle.com> <5445B440.1040806@oracle.com> <544622EE.5080106@oracle.com> <5446B814.6040105@oracle.com> <5446B978.5070801@oracle.com> <200C103C-F356-4A1A-BD06-F1D7FCDDFC4A@oracle.com> Message-ID: <54475B06.9010700@oracle.com> Vitaly, Vladimir, Coleen, John, thanks for your comments. Based on the feedback, I withdraw this RFR. Best, Albert On 10/21/2014 10:25 PM, John Rose wrote: > On Oct 21, 2014, at 12:52 PM, Coleen Phillimore wrote: > >> I suggested option 1 because if we OOM trying to allocate metaspace for MethodCounters and MethodData, then the system is pretty close to running into the metaspace limit and is not going to be able to make very much progress anyway. > Piling on here: OOME (or some other VM error) is a *great* way to handle resource exhaustion corner cases, but *only if* the occasion was directly (synchronously, to use David H.'s term) caused by a user event. So in this case the JVM has to find a way to continue. > > In this case the JVM's internal optimization logic is stumbling, which isn't something the user can control (or usually observe). > >> If we run out of Metaspace while allocating metadata for a class, we throw OOM. In the class loading case, a user can maybe catch OOM and stop loading so many classes (???). During method compilation this is more surprising, so I'm going to change my vote for #2 now. > I support throwing VM errors when the VM is out of resources for normal execution, but only under these conditions: > 1. the error must be linked to a user request that somehow contributed to the resource exhaustion > 2. the user has a reasonable chance to catch and recover from the error > > (Dirty secret: That's a pretty broad permission, since the JVMS allows us to throw SOE almost anywhere; think "apush". That's why point #2 is there.) > > If the conditions are not met, then the JVM has to do without the resources, with as much graceful degradation as is feasible. > > If the degradation is likely to felt as a bug, or if the user has turned on some sort of logging, the JVM should communicate the event appropriately, along the lines of CompileBroker::handle_full_code_cache. > > ? John > > P.S. Here's an optimization which stretches condition #1: Sometimes the JVM can optimistically *delay* the creation of user-allocated objects, using (for example) escape analysis. When it wins, the creation is delayed forever and the heap is never used. In some corner cases, the delayed object must be created (at de-opt time). At this point memory might run out. The resulting OOME might appear to be thrown long after the user thought the object was allocated, so the causal link might be tenuous. What this tells me is we need workable rules for deferring resource exhaustion events. From tobias.hartmann at oracle.com Wed Oct 22 08:48:43 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 22 Oct 2014 10:48:43 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <5447138E.9060702@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> Message-ID: <54476F6B.3050901@oracle.com> Hi David, On 22.10.2014 04:16, David Holmes wrote: > Hi Tobias, > > On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >> >> Problem: >> The Whitebox API methods get*VMFlag() fail with develop/notproduct flags in >> product builds. >> >> Solution: >> The code is changed to invoke 'Flag::find_flag' with allow_locked=true and >> return_flag=true to return both locked and notproduct/develop flags. I also >> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. > > Why did you change the jmm code? You seemed to have changed its semantics - > which may require a CCC request. I changed the jmm code because the whitebox tests use a JMM call to verify the return value (see 'VmFlagTest.getVMOptionAsString()'). Do you think a CCC request is necessary here? Thanks, Tobias > > Thanks, > David > >> I adapted the existing tests to check for develop flags as well. I noticed that >> HotspotDiagnosticMXBean.getVMOption() fails with double flags and filed >> JDK-8061616 [1]. >> >> Testing: >> - New testcases >> - JPRT >> >> Thanks, >> Tobias >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >> From andreas.eriksson at oracle.com Wed Oct 22 11:54:18 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 22 Oct 2014 13:54:18 +0200 Subject: RFR(M): 8057043: Type annotations not retained during class redefine / retransform In-Reply-To: <5446C254.7040801@oracle.com> References: <54368BC1.3000905@oracle.com> <54390854.1090109@oracle.com> <543BA4DB.3000104@oracle.com> <543DFF76.80605@oracle.com> <543E590A.4020304@oracle.com> <543E712D.90900@oracle.com> <543E77CA.3090806@oracle.com> <543E7B08.8040305@oracle.com> <543FA9AD.2070404@oracle.com> <5445686F.4090103@oracle.com> <5446B9FA.4080201@oracle.com> <5446C254.7040801@oracle.com> Message-ID: <54479AEA.8040308@oracle.com> Thanks Serguei! Regards, Andreas On 2014-10-21 22:30, serguei.spitsyn at oracle.com wrote: > Hi Andreas, > > Very nice, thank you for the refactoring! > Thumbs up. > > Thanks, > Serguei > > > On 10/21/14 12:54 PM, Andreas Eriksson wrote: >> Hi Serguei, >> >> I split up the method into several, and made the verification before >> and after retransform share logic. >> Webrev: http://cr.openjdk.java.net/~aeriksso/8057043/webrev.02/ >> >> Regards, >> Andreas >> >> On 2014-10-20 21:54, serguei.spitsyn at oracle.com wrote: >>> Hi Andreas, >>> >>> Sorry for the delay. >>> >>> On 10/16/14 4:19 AM, Andreas Eriksson wrote: >>>> >>>> On 2014-10-15 15:47, Daniel D. Daugherty wrote: >>>>> On 10/15/14 7:34 AM, Coleen Phillimore wrote: >>>>>> >>>>>> There are lots of other rewrite_cp_refs_in* function calls. >>>>>> Please indent your function like them, not differently. >>>>> >>>>> The above implies that my answer below was made without sufficient >>>>> context... my apologies for that. >>>>> >>>>> The general rule is to follow the existing style in the file so >>>>> if there are rewrite_cp_refs_in* function calls in the file, then >>>>> please follow that style. Unless, of course, you want to fix all >>>>> of them to follow the HotSpot style guideline: >>>>> >>>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide >>>>> >>>>> > Use good taste to break lines and align corresponding tokens >>>>> > on adjacent lines. >>>>> >>>>> but that may cause Coleen some heartburn :-) >>>> >>>> I fixed the calls to follow the already existing indent style. >>>> I have also made changes to the test, which I hope Joel can take a >>>> look at. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.01/ >>> >>> The fix looks good. >>> >>> A couple of comments about the test. >>> >>> The method testTransformAndVerify() is too big. >>> At least, it looks like there are some ways to refactor it to make >>> calls to smaller methods. >>> >>> There are two directions of doing it: >>> - make a smaller method out of each block: >>> 217-236, 238-260, 262-276, 311-329, 331-351, 353-367 >>> - some of the lines sequences looks very typical: >>> 221 at = c.getDeclaredField("typeAnnotatedArray").getAnnotatedType(); >>> 222 arrayTA1 = at.getAnnotations()[0]; >>> 223 verifyTestAnnSite(arrayTA1, "array1"); >>> 224 >>> 225 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); >>> 226 arrayTA2 = at.getAnnotations()[0]; >>> 227 verifyTestAnnSite(arrayTA2, "array2"); >>> 228 >>> 229 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); >>> 230 arrayTA3 = at.getAnnotations()[0]; >>> 231 verifyTestAnnSite(arrayTA3, "array3"); >>> 232 >>> 233 at = ((AnnotatedArrayType) at).getAnnotatedGenericComponentType(); >>> 234 arrayTA4 = at.getAnnotations()[0]; >>> 235 verifyTestAnnSite(arrayTA4, "array4"); >>> But I leave it up to you. >>> >>> Another step to improve the readability is to add a short comment >>> for each block of code saying what is done there. >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> Thanks, >>>> Andreas >>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>> On 10/15/14, 9:05 AM, Daniel D. Daugherty wrote: >>>>>>> On 10/15/14 5:22 AM, Andreas Eriksson wrote: >>>>>>>> Thanks Serguei. >>>>>>>> >>>>>>>> I have a question about the if-blocks that had the wrong indent: >>>>>>>> >>>>>>>> 2335 if >>>>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>>> >>>>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>>>> >>>>>>>> How should I indent them? >>>>>>> >>>>>>> Trying again without the line numbers... >>>>>>> >>>>>>> if >>>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>> >>>>>>> byte_i, "method_info", >>>>>>> THREAD)) { >>>>>>> >>>>>>> Just in case, TB messes with the spacing again, the "byte_i" >>>>>>> line and >>>>>>> "THREAD" lines are aligned under "method_type_annotations". >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> /Andreas >>>>>>>> >>>>>>>> On 2014-10-15 07:00, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Andreas, >>>>>>>>> >>>>>>>>> Sorry I did not reply on this early. >>>>>>>>> I assumed, it is a thumbs up from me. >>>>>>>>> Just wanted make it clean now. :) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> On 10/13/14 3:09 AM, Andreas Eriksson wrote: >>>>>>>>>> Hi Serguei, thanks for looking at this! >>>>>>>>>> >>>>>>>>>> I'll make sure to fix the style problems. >>>>>>>>>> For the symbolic names / #defines, please see my answer to >>>>>>>>>> Coleen. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Andreas >>>>>>>>>> >>>>>>>>>> On 2014-10-11 12:37, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi Andreas, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thank you for fixing this issue! >>>>>>>>>>> The fix looks nice, I do not see any logical issues. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Only minor comments... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>>>>>>>> >>>>>>>>>>> 2281 } // end rewrite_cp_refs_in_class_type_annotations( >>>>>>>>>>> 2315 } // end rewrite_cp_refs_in_fields_type_annotations( >>>>>>>>>>> 2345 } // end rewrite_cp_refs_in_methods_type_annotations() >>>>>>>>>>> 2397 } // end rewrite_cp_refs_in_type_annotations_typeArray >>>>>>>>>>> 2443 } // end rewrite_cp_refs_in_type_annotation_struct >>>>>>>>>>> 2785 } // end skip_type_annotation_target >>>>>>>>>>> 2844 } // end skip_type_annotation_type_path >>>>>>>>>>> >>>>>>>>>>> The ')' is missed at 2281, 2315. >>>>>>>>>>> The 2397-2844 are inconsistent with the 2345 and other >>>>>>>>>>> function-end comments in the file. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2335 if >>>>>>>>>>> (!rewrite_cp_refs_in_type_annotations_typeArray(method_type_annotations, >>>>>>>>>>> >>>>>>>>>>> 2336 byte_i, "method_info", THREAD)) { >>>>>>>>>>> . . . >>>>>>>>>>> 2378 if >>>>>>>>>>> (!rewrite_cp_refs_in_type_annotation_struct(type_annotations_typeArray, >>>>>>>>>>> >>>>>>>>>>> 2379 byte_i_ref, location_mesg, THREAD)) { >>>>>>>>>>> . . . >>>>>>>>>>> 2427 if >>>>>>>>>>> (!skip_type_annotation_target(type_annotations_typeArray, >>>>>>>>>>> 2428 byte_i_ref, location_mesg, THREAD)) { >>>>>>>>>>> 2429 return false; >>>>>>>>>>> 2430 } >>>>>>>>>>> 2431 >>>>>>>>>>> 2432 if >>>>>>>>>>> (!skip_type_annotation_type_path(type_annotations_typeArray, >>>>>>>>>>> 2433 byte_i_ref, THREAD)) { >>>>>>>>>>> 2434 return false; >>>>>>>>>>> 2435 } >>>>>>>>>>> 2436 >>>>>>>>>>> 2437 if >>>>>>>>>>> (!rewrite_cp_refs_in_annotation_struct(type_annotations_typeArray, >>>>>>>>>>> >>>>>>>>>>> 2438 byte_i_ref, THREAD)) { >>>>>>>>>>> 2439 return false; >>>>>>>>>>> Wrong indent at 2336, 2379, etc. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I also concur with Coleen that it would be good to define >>>>>>>>>>> and use >>>>>>>>>>> symbolic names for the hexa-decimal constants used in the fix. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> test/runtime/RedefineTests/RedefineAnnotations.java >>>>>>>>>>> >>>>>>>>>>> Java indent must be 4, not 2. >>>>>>>>>>> >>>>>>>>>>> 253 @TestAnn(site="returnTypeAnnotation") Class >>>>>>>>>>> typeAnnotatedMethod(@TestAnn(site="formalParameterTypeAnnotation") >>>>>>>>>>> TypeAnnotatedTestClass arg) >>>>>>>>>>> >>>>>>>>>>> The line is too long. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 143 } >>>>>>>>>>> 144 public static void main(String argv[]) { >>>>>>>>>>> . . . >>>>>>>>>>> 209 } >>>>>>>>>>> 210 private static void checkAnnotations(AnnotatedType p) { >>>>>>>>>>> 211 checkAnnotations(p.getAnnotations()); >>>>>>>>>>> 212 } >>>>>>>>>>> 213 private static void checkAnnotations(AnnotatedType[] >>>>>>>>>>> annoTypes) { >>>>>>>>>>> 214 for (AnnotatedType p : annoTypes) >>>>>>>>>>> checkAnnotations(p.getAnnotations()); >>>>>>>>>>> 215 } >>>>>>>>>>> 216 private static void >>>>>>>>>>> checkAnnotations(Class c) { >>>>>>>>>>> . . . >>>>>>>>>>> 257 } >>>>>>>>>>> 258 public void run() {} >>>>>>>>>>> >>>>>>>>>>> Adding empty lines between method definitions would >>>>>>>>>>> improve readability. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/9/14 6:21 AM, Andreas Eriksson wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Please review this patch to RedefineClasses to allow type >>>>>>>>>>>> annotations to be preserved. >>>>>>>>>>>> >>>>>>>>>>>> Summary: >>>>>>>>>>>> During redefine / retransform class the constant pool >>>>>>>>>>>> indexes can change. >>>>>>>>>>>> Since annotations have indexes into the constant pool these >>>>>>>>>>>> indexes need to be rewritten. >>>>>>>>>>>> This is already done for regular annotations, but not for >>>>>>>>>>>> type annotations. >>>>>>>>>>>> This patch adds code to add this rewriting for the type >>>>>>>>>>>> annotations as well. >>>>>>>>>>>> The patch also contains minor changes to >>>>>>>>>>>> ClassFileReconstituter, to make sure that type annotations >>>>>>>>>>>> are preserved during a redefine / retransform class operation. >>>>>>>>>>>> It also has a test that uses asm to change constant pool >>>>>>>>>>>> indexes through a retransform, and then verifies that type >>>>>>>>>>>> annotations are preserved. >>>>>>>>>>>> >>>>>>>>>>>> Detail: >>>>>>>>>>>> A type annotation struct consists of some target >>>>>>>>>>>> information and a type path, followed by a regular >>>>>>>>>>>> annotation struct. >>>>>>>>>>>> Constant pool indexes are only present in the regular >>>>>>>>>>>> annotation struct. >>>>>>>>>>>> The added code skips over the type annotation specific >>>>>>>>>>>> parts, then calls previously existing code to rewrite >>>>>>>>>>>> constant pool indexes in the regular annotation struct. >>>>>>>>>>>> Please see the Java SE 8 Ed. VM Spec. section 4.7.20 for >>>>>>>>>>>> more info about the type annotation struct. >>>>>>>>>>>> >>>>>>>>>>>> JPRT with the new test passes without failures on all >>>>>>>>>>>> platforms. >>>>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~aeriksso/8057043/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Bug: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057043 >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Andreas >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From erik.osterlund at lnu.se Wed Oct 22 12:00:06 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Wed, 22 Oct 2014 12:00:06 +0000 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: References: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> <21D89760-6941-4CB4-B5D1-DD90A70A4E28@lnu.se> Message-ID: Thanks Paul! /Erik On 22 Oct 2014, at 05:08, Paul Hohensee > wrote: Can't complain as long as you've tested on all available platforms. :) No need for a new webrev for formatting changes. You're good to go afaic. Paul On Tue, Oct 21, 2014 at 8:38 PM, Erik ?sterlund > wrote: Hi Paul, On 21 Oct 2014, at 21:29, Paul Hohensee > wrote: Re the simple fix, if you've successfully run DaCapo using G1 on all platforms for which you've added custom implementations, and considering it'll be replaced (so I withdraw my previous comments and accept it as is), consider it reviewed. Just to clarify, I don't have access to all platforms unfortunately, so the solaris (32 and 64 bit) and windows 32-bit approaches have still only been tested with jprt and careful manual reviewing, so an extra eye should probably glance over it. The windows AMD64 variant with runtime-produced cmpxchgb, linux and bsd variants have been tested with DaCapo + G1. Sorry if I was not clear enough with this. For the template fix: A nit: in templateIdioms.hpp, put the on-one-line-by-themselves-{'s at the end of the previous lines. The styling of templateIdioms.hpp has been fixed now. (Do you need a new webrev for this?) If it passes the same tests as the simple fix, it's good to go too. The inheritance/template solution went through the same tests as the first and it's fine. Big thanks again to Jesper for running it through jprt. Big thanks for reviewing my changes! :) /Erik Paul On Tue, Oct 21, 2014 at 11:55 AM, Erik ?sterlund > wrote: Hi Paul, I understand your defensive thinking. :) There is indeed no conflict between the two schemes, which was an important design goal to me. In this case I will need some reviews for my old solution first so I can push the changes. So this time, let's pretend that #define VM_HAS_SPECIALIZED_BYTE_CMPXCHG isn't there as it will be fixed in a cleaner way in the successive change. Bug: https://bugs.openjdk.java.net/browse/JDK-8058255 Webrev for the simple fix (which I intend to push initially): http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.macro/ Webrev for the inheritance/template solution (which will be pushed after and is the intended "end" result): http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.templates/ Webrev for the delta from the macro solution to the inheritance/template solution: http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.incremental/ The solutions are unchanged from before except for one thing: the Assembler::cmpxchgb used in code stub used by awkward AMD64 windows config. I added a flag needed to put a REX prefix (0x40) in front of the (new) cmpxchgb machine code encoding when byte-sized registers are used, required by the hardware specification. Testing of webrev.03.macro which I want to push now: 1. jprt (big thanks to Jesper for helping me with this!) 2. I have tested that the assembly produced in CodeStub works locally by carefully introspecting the machine code produced compared to the machine code produced by inline asm. 3. Running through some DaCapo benchmarks (with the CodeStub cmpxchgb and G1 which uses jbyte cmpxchg quite a bit for card manipulation). I would like to thank Jesper again for helping me make webrevs and supporting me. Thanks, /Erik On 21 Oct 2014, at 04:33, Paul Hohensee > wrote: I was perhaps unclear. :) The new scheme and the old will co-exist, i.e., there's no conflict between the two, right? That makes transition to the new easier, but if we leave the old way there, then two ways of doing the same thing will result in more cognitive overhead and thus higher maintenance costs, just as is the case with the two parallel scavengers. So, I'd prefer the new way to supplant the old as soon as practicable. I proposed to implement your old solution as a step on the way to the new, so there'd be a record of how that worked. It's also the minimal change, so if it's in the repo and there are issues with the new way, it's easy to revert while a fix is done. Call it paranoia. :) Paul On Mon, Oct 20, 2014 at 7:04 PM, Erik ?sterlund > wrote: Hi Paul, Thank you for your reply. Webrev for new inheritance based solution: http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.02/ In my opinion it does not create a conflict that there are two different systems. There are 3 levels in the hierarchy, all with well defined responsibilities: AtomicBase - atomics that can be generalized for all platforms, AtomicPlatform (optional) for atomics overriding AtomicBase with specialized implementations, and Atomic for atomics that always look different on all platforms (and hence has little benefit of inheritance). With this view (and responsibilities), it is already consistent AFAIK unless we have more things that could be generalized that should be shifted up in the hierarchy which would be nice. Do you propose we use my old solution (http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01/) for now which is less reliant on compiler support and strictly only fixes the jbyte cmpxchg in a less architecturally intrusive way, or the new cleaner inheritance variant? Thanks, /Erik On 20 Oct 2014, at 16:23, Paul Hohensee > wrote: I'd also worry about a couple of other things. First, way back in the mists of time, C++ compilers differed with respect to their template implementations. Hopefully the C++ compiles on all openjdk platforms do what you expect. Second, if you do this, we'll have two alternatives for implementing Atomic, which generally isn't a good thing (vis we have two GC frameworks). I'd want to see every platform switch to the new way of doing things asap and get rid of the old way. Paul On Mon, Oct 20, 2014 at 10:10 AM, Paul Hohensee > wrote: Sorry for the delay in responding. Idea seems ok. I'd like to see a webrev. You might start with your original solution (the one I reviewed) just to get a fix in place. Paul On Wed, Oct 15, 2014 at 9:47 AM, Erik ?sterlund > wrote: Hi Paul, Thank you for the reply. I like the idea of using inheritance too. I tried a new solution which is similar to the one proposed and I would like to hear your comment if this is okay so we are all happy. The core idea is to have a general AtomicBase class which implements the old unspecialized cmpxchg (and possibly other stuff to come), then allow platforms to /optionally/ define their own AtomicPlatform base classes in the hierarchy that derive from AtomicBase. Then the last step in the hierarchy is Atomic which inherits from AtomicPlatform if it is defined and otherwise AtomicBase. It picks the superclass using SFINAE. The reason for this is that other ports will not be broken by this performance fix and the definition of such AtomicPlatform class is completely optional. :) Benefits: * Uses inheritance and looks nice like the inheritance based solution proposed * Does not break ports outside of the main repo * Does not require refactoring of everything (moving all methods from Atomic to AbstractAtomic for all platforms) * Changes are local to only the platforms that want to add this functionality * Flexible for supporting the future demands In a bit more detail, it looks like this: atomic.hpp: class AtomicBase : AllStatic { protected: static jbyte cmpxchg_unspecialized(jbyte exchange_value, volatile jbyte* dest, jbyte compare_value); public: inline static jbyte cmpxchg (jbyte exchange_value, volatile jbyte* dest, jbyte compare_value) { return cmpxchg_unspecialized(exchange_value, dest, compare_value); } }; // Linux #ifdef TARGET_OS_ARCH_linux_x86 # include "atomic_linux_x86.hpp" #endif // BSD #ifdef TARGET_OS_ARCH_bsd_x86 # include "atomic_bsd_x86.hpp" #endif // ... and the other platforms that benefit from specialized AtomicPlatform ... class AtomicPlatform; // Forward declaration to avoid compiler error when it is not defined // Based on some SFINAE stuff I made and will contribute if you like it. AtomicSuper will be AtomicPlatform if defined in a platform specific atomic_os_arch.hpp file, otherwise AtomicBase will be used typedef base_class::type AtomicSuper; // AtomicSuper is now the base class of Atomic, and contains the cmpxchgb implementation class Atomic : public AtomicSuper { // ... inline static jbyte cmpxchg (jbyte exchange_value, volatile jbyte* dest, jbyte compare_value) { // Just call super class implementation return AtomicSuper::cmpxchg(exchange_value, dest, compare_value); } // ... }; A new atomic_os_arch.hpp file looks like this (for platforms that support this): class AtomicPlatform : public AtomicBase { public: static jbyte cmpxchg(jbyte exchange_value, volatile jbyte* dest, jbyte compare_value); }; And atomic_os_arch.inline.hpp contains the implementation like before, but as members of AtomicPlatform instead of Atomic For the curious reader, the SFINAE stuff for base_class looks like this: template struct is_base_of_host { operator Base*() const; operator Derived*(); }; // Statically check if two types are related in a class hierarchy template struct is_base_of { typedef char yes[1]; typedef char no[2]; template static yes &check(Derived*, T); static no &check(Base*, int); static const bool value = sizeof(check(is_base_of_host(), int())) == sizeof(yes); }; // The ::type of this struct will be the Desired type if it was defined // and a subtype of Fallback, otherwise it will be Fallback. // This is useful when optionally inheriting from a specialized subtype. template struct base_class { template struct check_inheritance { typedef T type; }; template struct check_inheritance { typedef U type; }; typedef typename check_inheritance::value, Fallback, Desired>::type type; }; If everyone is happy with this solution, then I will prepare another webrev and send the patch. :) Thanks for taking the time to read through this change. /Erik On 14 Oct 2014, at 19:25, Paul Hohensee > wrote: > David Holmes asked me to take a look at this > >>>>> There is now a new webrev with my jbyte cmpxchg changes here: >>>>> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.01 > > and comment, so... > > The approach is good if you're going to stay with the current framework, > except that I'd get rid of VM_HAS_SPECIALIZED_BYTE_CMPXCHG (#ifdef's are > the devil). Just call cmpxchg_general (which should be named > cmpxchgb_general or maybe cmpxchgb_unspecialized, btw) from an os_cpu file > as needed. I.e., no change to atomic.inline.hpp needed. Another way to > look at it is, cmpxchgb_general/unspecialized is the implementation of > another specialized version of cmpxchgb, on the same abstraction level as > the asm versions. > > If a rewrite is possible, I'd do it the way David suggests with an > AbstractAtomic class from which per-platform Atomic classes are derived. > That's the way VM_Version and ICache are defined. > > Paul From david.holmes at oracle.com Wed Oct 22 12:33:45 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Oct 2014 22:33:45 +1000 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <54476F6B.3050901@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> Message-ID: <5447A429.4070306@oracle.com> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: > Hi David, > > On 22.10.2014 04:16, David Holmes wrote: >> Hi Tobias, >> >> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>> >>> Problem: >>> The Whitebox API methods get*VMFlag() fail with develop/notproduct flags in >>> product builds. >>> >>> Solution: >>> The code is changed to invoke 'Flag::find_flag' with allow_locked=true and >>> return_flag=true to return both locked and notproduct/develop flags. I also >>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >> >> Why did you change the jmm code? You seemed to have changed its semantics - >> which may require a CCC request. > > I changed the jmm code because the whitebox tests use a JMM call to verify the > return value (see 'VmFlagTest.getVMOptionAsString()'). > > Do you think a CCC request is necessary here? Depends what the jmm code is supposed to return - I don't know the spec. But changing the behaviour for the sake of a test without consideration of real users is not something that should be done lightly. David > Thanks, > Tobias > >> >> Thanks, >> David >> >>> I adapted the existing tests to check for develop flags as well. I noticed that >>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and filed >>> JDK-8061616 [1]. >>> >>> Testing: >>> - New testcases >>> - JPRT >>> >>> Thanks, >>> Tobias >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>> From tobias.hartmann at oracle.com Wed Oct 22 13:46:08 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 22 Oct 2014 15:46:08 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <5447A429.4070306@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> Message-ID: <5447B520.50302@oracle.com> Hi David, On 22.10.2014 14:33, David Holmes wrote: > On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >> Hi David, >> >> On 22.10.2014 04:16, David Holmes wrote: >>> Hi Tobias, >>> >>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>> >>>> Problem: >>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct flags in >>>> product builds. >>>> >>>> Solution: >>>> The code is changed to invoke 'Flag::find_flag' with allow_locked=true and >>>> return_flag=true to return both locked and notproduct/develop flags. I also >>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>> >>> Why did you change the jmm code? You seemed to have changed its semantics - >>> which may require a CCC request. >> >> I changed the jmm code because the whitebox tests use a JMM call to verify the >> return value (see 'VmFlagTest.getVMOptionAsString()'). >> >> Do you think a CCC request is necessary here? > > Depends what the jmm code is supposed to return - I don't know the spec. But > changing the behaviour for the sake of a test without consideration of real > users is not something that should be done lightly. I agree. I filed a CCC request and attached the link to the bug. Thanks, Tobias > > David > >> Thanks, >> Tobias >> >>> >>> Thanks, >>> David >>> >>>> I adapted the existing tests to check for develop flags as well. I noticed that >>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and filed >>>> JDK-8061616 [1]. >>>> >>>> Testing: >>>> - New testcases >>>> - JPRT >>>> >>>> Thanks, >>>> Tobias >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>> From coleen.phillimore at oracle.com Wed Oct 22 16:13:10 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Oct 2014 12:13:10 -0400 Subject: [8u40] RFR backport 8031376: TraceClassLoading expects there to be a (Java) caller when you load a class with the bootstrap class loader In-Reply-To: <5447552F.9060609@oracle.com> References: <5447552F.9060609@oracle.com> Message-ID: <5447D796.4050705@oracle.com> This looks good. Thank you for sponsoring it. coleen On 10/22/14, 2:56 AM, David Holmes wrote: > webrev: > > http://cr.openjdk.java.net/~dholmes/8031376/webrev.8u/ > > This is a sponsored backport request: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015618.html > > > The changeset imported directly from 9: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/715bc50198c1 > > > Thanks, > David From kim.barrett at oracle.com Wed Oct 22 21:00:35 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 22 Oct 2014 17:00:35 -0400 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: References: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> Message-ID: <72CCEC68-8564-45D7-A696-F9DDA5DA06C3@oracle.com> On Oct 21, 2014, at 11:55 AM, Erik ?sterlund wrote: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8058255 > > Webrev for the simple fix (which I intend to push initially): > http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.macro/ > > Webrev for the inheritance/template solution (which will be pushed after and is the intended "end" result): > http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.templates/ > > Webrev for the delta from the macro solution to the inheritance/template solution: > http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.incremental/ I haven't had time to do a real review, but I noted a couple of things here. (1) I really dislike the file name "templateIdioms.hpp". It says little or nothing about what is presently in that file, and with a name like that it seems all to likely to become a dumping ground. My own preference is for relatively fine grained header files, so that I can include only what I actually need in a given place. So I'd prefer something like is_base_of.hpp for that class, and not sure whether the base_class struct also goes there or in its own file. (Fine-grained would argue the former.) (2) It's been a while since I looked at it, but my recollection is that the Boost implementation of is_base_of is substantially more complex than what is presently in this file. I don't know how much of that (possible? assuming my recollection is correct) additional complexity might be to correctly support edge cases that might not be properly handled by this simple implementation (I wonder about CV qualifiers and inaccessible or ambiguous base classes), and how much was to deal with deficient compilers. Related to that, I'd like to seem some tests. (3) The documentation and protocol for these structs is weak. For example, I would make only the "value" member of is_base_of public, with the rest private, and comment it as something like: is_base_of::value is true iff T1 is a base class of T2 (4) C++11 is_base_of is true for class types, and similarly for Boost is_base_of (which attempts to match C++11). The is_base_of proposed here is false in that case. Matching the "standard" behavior would be preferable. (I think the under review is_base_of differs from C++11 for some combinations of CV qualifiers too, as C++11 says the operation is performed without regard to CV qualifiers.) From vladimir.kozlov at oracle.com Wed Oct 22 21:22:47 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Oct 2014 14:22:47 -0700 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <5447B520.50302@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> Message-ID: <54482027.1000101@oracle.com> getVMOption() specification does not say anything about product, locked or develop flags. "If a VM option of the given name does not exist" can interpreted different ways. http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html VMOption getVMOption(String name) Returns a VMOption object for a VM option of the given name. Returns: a VMOption object for a VM option of the given name. Throws: NullPointerException - if name is null. IllegalArgumentException - if a VM option of the given name does not exist. Thanks, Vladimir On 10/22/14 6:46 AM, Tobias Hartmann wrote: > Hi David, > > On 22.10.2014 14:33, David Holmes wrote: >> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>> Hi David, >>> >>> On 22.10.2014 04:16, David Holmes wrote: >>>> Hi Tobias, >>>> >>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>> >>>>> Problem: >>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct flags in >>>>> product builds. >>>>> >>>>> Solution: >>>>> The code is changed to invoke 'Flag::find_flag' with allow_locked=true and >>>>> return_flag=true to return both locked and notproduct/develop flags. I also >>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>> >>>> Why did you change the jmm code? You seemed to have changed its semantics - >>>> which may require a CCC request. >>> >>> I changed the jmm code because the whitebox tests use a JMM call to verify the >>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>> >>> Do you think a CCC request is necessary here? >> >> Depends what the jmm code is supposed to return - I don't know the spec. But >> changing the behaviour for the sake of a test without consideration of real >> users is not something that should be done lightly. > > I agree. I filed a CCC request and attached the link to the bug. > > Thanks, > Tobias > >> >> David >> >>> Thanks, >>> Tobias >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> I adapted the existing tests to check for develop flags as well. I noticed that >>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and filed >>>>> JDK-8061616 [1]. >>>>> >>>>> Testing: >>>>> - New testcases >>>>> - JPRT >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>>> From david.holmes at oracle.com Thu Oct 23 02:35:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Oct 2014 12:35:42 +1000 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <54482027.1000101@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> Message-ID: <5448697E.9050604@oracle.com> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: > getVMOption() specification does not say anything about product, locked > or develop flags. "If a VM option of the given name does not exist" can > interpreted different ways. Perhaps, but conceptually develop flags are not part of a product build and by definition non-product flags are not part of a product build, so I think the existing jmm code is quite right to exclude them and the new code should do the same. It doesn't make sense to me to present someone with a list of flags that can't actually be used. Thanks, David > http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html > > > VMOption getVMOption(String name) > > Returns a VMOption object for a VM option of the given name. > > Returns: > a VMOption object for a VM option of the given name. > Throws: > NullPointerException - if name is null. > IllegalArgumentException - if a VM option of the given name > does not exist. > > Thanks, > Vladimir > > On 10/22/14 6:46 AM, Tobias Hartmann wrote: >> Hi David, >> >> On 22.10.2014 14:33, David Holmes wrote: >>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>> Hi David, >>>> >>>> On 22.10.2014 04:16, David Holmes wrote: >>>>> Hi Tobias, >>>>> >>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> please review the following patch. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>> >>>>>> Problem: >>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>> flags in >>>>>> product builds. >>>>>> >>>>>> Solution: >>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>> allow_locked=true and >>>>>> return_flag=true to return both locked and notproduct/develop >>>>>> flags. I also >>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>> >>>>> Why did you change the jmm code? You seemed to have changed its >>>>> semantics - >>>>> which may require a CCC request. >>>> >>>> I changed the jmm code because the whitebox tests use a JMM call to >>>> verify the >>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>> >>>> Do you think a CCC request is necessary here? >>> >>> Depends what the jmm code is supposed to return - I don't know the >>> spec. But >>> changing the behaviour for the sake of a test without consideration >>> of real >>> users is not something that should be done lightly. >> >> I agree. I filed a CCC request and attached the link to the bug. >> >> Thanks, >> Tobias >> >>> >>> David >>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>> noticed that >>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>> filed >>>>>> JDK-8061616 [1]. >>>>>> >>>>>> Testing: >>>>>> - New testcases >>>>>> - JPRT >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>>>> From erik.osterlund at lnu.se Thu Oct 23 03:50:30 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Thu, 23 Oct 2014 03:50:30 +0000 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: <72CCEC68-8564-45D7-A696-F9DDA5DA06C3@oracle.com> References: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> <72CCEC68-8564-45D7-A696-F9DDA5DA06C3@oracle.com> Message-ID: <5BB55DBF-C929-42EE-BCC5-5A1B08FEC270@lnu.se> Hi Kim, Thanks for reviewing this! On 22 Oct 2014, at 23:00, Kim Barrett wrote: > On Oct 21, 2014, at 11:55 AM, Erik ?sterlund wrote: >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8058255 >> >> Webrev for the simple fix (which I intend to push initially): >> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.macro/ >> >> Webrev for the inheritance/template solution (which will be pushed after and is the intended "end" result): >> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.templates/ >> >> Webrev for the delta from the macro solution to the inheritance/template solution: >> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.incremental/ > > I haven't had time to do a real review, but I noted a couple of things > here. > > (1) I really dislike the file name "templateIdioms.hpp". It says > little or nothing about what is presently in that file, and with a > name like that it seems all to likely to become a dumping ground. My > own preference is for relatively fine grained header files, so that I > can include only what I actually need in a given place. So I'd prefer > something like is_base_of.hpp for that class, and not sure whether the > base_class struct also goes there or in its own file. (Fine-grained > would argue the former.) My own preference is also fine grained headers but I have not seen them much in this project so I actually thought coarse grained was the wanted style and thus the intention was indeed to dump things in there. We could do like boost and call it type_traits.hpp as an umbrella include and the fine grained type_traits/is_base_of.hpp if you like that better. :) > (2) It's been a while since I looked at it, but my recollection is > that the Boost implementation of is_base_of is substantially more > complex than what is presently in this file. I don't know how much of > that (possible? assuming my recollection is correct) additional > complexity might be to correctly support edge cases that might not be > properly handled by this simple implementation (I wonder about CV > qualifiers and inaccessible or ambiguous base classes), and how much > was to deal with deficient compilers. Related to that, I'd like to > seem some tests. This is actually very close to the implementation used by boost's is_base_and_derived if you expand their macros. About using weird classes like ambiguous classes or forward declared but not defined classes, it returns false. Ambiguous types always lead to substitution failure. CV qualifiers are not disregarded currently. I have now written a lot of tests using STATIC_ASSERT that defines the guarantees reflected in new comments describing the contract. > (3) The documentation and protocol for these structs is weak. For > example, I would make only the "value" member of is_base_of public, > with the rest private, and comment it as something like: > is_base_of::value is true iff T1 is a base class of T2 Fixed. > (4) C++11 is_base_of is true for class types, and similarly for > Boost is_base_of (which attempts to match C++11). The is_base_of > proposed here is false in that case. Matching the "standard" behavior > would be preferable. (I think the under review is_base_of differs > from C++11 for some combinations of CV qualifiers too, as C++11 says > the operation is performed without regard to CV qualifiers.) I did not intend my traits to be exact replacements of the C++11 standard is_base_of and hence have not followed their semantics and considered all of their corner cases. As a matter of fact, it was a non-goal to me. If you want me to do that though I can give it a good go and fix is_base_of to almost completely follow the standard. With my new implementation below is_base_of::type is true iff the types are class or union and D is either derived from B or the same type as B, disregarding CV qualifiers. The difference to the C++11 standard is that it should return false for unions but the implementation of that is /extremely/ platform dependent and I don't have access to jprt which would make implementing it extremely awkward. Here is my new proposed implementation of is_base_of following the C++11 standard "decently" with more comments and encapsulation as requested: /** * is_class::value is true iff the type T is a class type. */ template class is_class_or_union { typedef char yes[1]; typedef char no[2]; template static yes &check (int U::*); template static no &check (...); public: static const bool value = (sizeof(check(0)) == sizeof(yes)); }; /** * remove_cv::type returns a type T without any CV qualifiers */ template class remove_cv { template struct remove_const { typedef U type; }; template struct remove_const { typedef U type; }; template struct remove_volatile { typedef U type; }; template struct remove_volatile { typedef U type; }; public: typedef typename remove_volatile::type>::type type; }; /** * is_base_of_and_derived::value is true if Derived is a derived class of Base, disgarding their CV qualifiers. * Returns false for non-class types except unions. */ template class is_base_of_and_derived { typedef char yes[1]; typedef char no[2]; template static yes &check(Derived*, T); static no &check(Base*, int); template struct is_base_of_host { operator B*() const; operator D*(); }; template struct is_base_of_and_derived_internal { static const bool value = sizeof(check(is_base_of_host(), int())) == sizeof(yes); }; public: static const bool value = is_class_or_union::value && is_base_of_and_derived_internal::type, typename remove_cv::type>::value; }; /** * is_same::value is true iff T and U are the same type. */ template class is_same { template struct is_same_internal { static const bool value = false; }; template struct is_same_internal { static const bool value = true; }; public: static const bool value = is_same_internal::value; }; /** * is_base_of::value is true if either Derived is a derived class of Base * disregarding CV qualifiers or Derived and Base are the same type disregarding CV qualifiers. * Returns false for all non-class types or unions. */ template class is_base_of { public: static const bool value = (is_base_of_and_derived::value || is_same::type, typename remove_cv::type>::value) && is_class_or_union::value; }; If this seems ok with you I will send a new webrev with the new is_base_of implementation, its new comments describing the contract and new tests, testing the contract in detail. I need to know though if you want me to put all of the traits in different files or not and in that case if you want them in a new subdirectory or not. Thanks, /Erik From staffan.larsen at oracle.com Thu Oct 23 07:06:06 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Oct 2014 09:06:06 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <5448697E.9050604@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> Message-ID: <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> On 23 okt 2014, at 04:35, David Holmes wrote: > On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >> getVMOption() specification does not say anything about product, locked >> or develop flags. "If a VM option of the given name does not exist" can >> interpreted different ways. > > Perhaps, but conceptually develop flags are not part of a product build and by definition non-product flags are not part of a product build, so I think the existing jmm code is quite right to exclude them and the new code should do the same. It doesn't make sense to me to present someone with a list of flags that can't actually be used. I agree with David here. Instead of changing the JMM API, you can add functionality to the WhiteBox API to get the value of non-product flags. /Staffan > > Thanks, > David > >> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >> >> >> VMOption getVMOption(String name) >> >> Returns a VMOption object for a VM option of the given name. >> >> Returns: >> a VMOption object for a VM option of the given name. >> Throws: >> NullPointerException - if name is null. >> IllegalArgumentException - if a VM option of the given name >> does not exist. >> >> Thanks, >> Vladimir >> >> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>> Hi David, >>> >>> On 22.10.2014 14:33, David Holmes wrote: >>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>> Hi David, >>>>> >>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>> Hi Tobias, >>>>>> >>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review the following patch. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>> >>>>>>> Problem: >>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>> flags in >>>>>>> product builds. >>>>>>> >>>>>>> Solution: >>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>> allow_locked=true and >>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>> flags. I also >>>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>>> >>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>> semantics - >>>>>> which may require a CCC request. >>>>> >>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>> verify the >>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>> >>>>> Do you think a CCC request is necessary here? >>>> >>>> Depends what the jmm code is supposed to return - I don't know the >>>> spec. But >>>> changing the behaviour for the sake of a test without consideration >>>> of real >>>> users is not something that should be done lightly. >>> >>> I agree. I filed a CCC request and attached the link to the bug. >>> >>> Thanks, >>> Tobias >>> >>>> >>>> David >>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>> noticed that >>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>> filed >>>>>>> JDK-8061616 [1]. >>>>>>> >>>>>>> Testing: >>>>>>> - New testcases >>>>>>> - JPRT >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>>>>> From tobias.hartmann at oracle.com Thu Oct 23 08:57:58 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Oct 2014 10:57:58 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> Message-ID: <5448C316.2040006@oracle.com> Vladimir, David, Staffan, thanks for the reviews. On 23.10.2014 09:06, Staffan Larsen wrote: > > On 23 okt 2014, at 04:35, David Holmes wrote: > >> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>> getVMOption() specification does not say anything about product, locked >>> or develop flags. "If a VM option of the given name does not exist" can >>> interpreted different ways. >> >> Perhaps, but conceptually develop flags are not part of a product build and by definition non-product flags are not part of a product build, so I think the existing jmm code is quite right to exclude them and the new code should do the same. It doesn't make sense to me to present someone with a list of flags that can't actually be used. > > I agree with David here. Instead of changing the JMM API, you can add functionality to the WhiteBox API to get the value of non-product flags. I agree. I reverted the JMM changes and added a Whitebox API method 'isDebugVMFlag' to check whether a flag is debug/notproduct. I changed the tests such that we only use JMM to verify the values returned by the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct flag in a product build). New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ Thanks, Tobias > /Staffan > >> >> Thanks, >> David >> >>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>> >>> >>> VMOption getVMOption(String name) >>> >>> Returns a VMOption object for a VM option of the given name. >>> >>> Returns: >>> a VMOption object for a VM option of the given name. >>> Throws: >>> NullPointerException - if name is null. >>> IllegalArgumentException - if a VM option of the given name >>> does not exist. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>> Hi David, >>>> >>>> On 22.10.2014 14:33, David Holmes wrote: >>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>> Hi David, >>>>>> >>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>> Hi Tobias, >>>>>>> >>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review the following patch. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>> >>>>>>>> Problem: >>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>> flags in >>>>>>>> product builds. >>>>>>>> >>>>>>>> Solution: >>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>> allow_locked=true and >>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>> flags. I also >>>>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>>>> >>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>> semantics - >>>>>>> which may require a CCC request. >>>>>> >>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>> verify the >>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>> >>>>>> Do you think a CCC request is necessary here? >>>>> >>>>> Depends what the jmm code is supposed to return - I don't know the >>>>> spec. But >>>>> changing the behaviour for the sake of a test without consideration >>>>> of real >>>>> users is not something that should be done lightly. >>>> >>>> I agree. I filed a CCC request and attached the link to the bug. >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> David >>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>> noticed that >>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>> filed >>>>>>>> JDK-8061616 [1]. >>>>>>>> >>>>>>>> Testing: >>>>>>>> - New testcases >>>>>>>> - JPRT >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>>>>>> > From staffan.larsen at oracle.com Thu Oct 23 09:29:38 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Oct 2014 11:29:38 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <5448C316.2040006@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> <5448C316.2040006@oracle.com> Message-ID: <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> This is better! But won?t the new WB_IsDebugVMFlag() return true for flags that don?t exist at all? /Staffan On 23 okt 2014, at 10:57, Tobias Hartmann wrote: > Vladimir, David, Staffan, > > thanks for the reviews. > > On 23.10.2014 09:06, Staffan Larsen wrote: >> >> On 23 okt 2014, at 04:35, David Holmes wrote: >> >>> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>>> getVMOption() specification does not say anything about product, locked >>>> or develop flags. "If a VM option of the given name does not exist" can >>>> interpreted different ways. >>> >>> Perhaps, but conceptually develop flags are not part of a product build and by definition non-product flags are not part of a product build, so I think the existing jmm code is quite right to exclude them and the new code should do the same. It doesn't make sense to me to present someone with a list of flags that can't actually be used. >> >> I agree with David here. Instead of changing the JMM API, you can add functionality to the WhiteBox API to get the value of non-product flags. > > I agree. I reverted the JMM changes and added a Whitebox API method > 'isDebugVMFlag' to check whether a flag is debug/notproduct. > > I changed the tests such that we only use JMM to verify the values returned by > the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct flag > in a product build). > > New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ > > Thanks, > Tobias > >> /Staffan >> >>> >>> Thanks, >>> David >>> >>>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>>> >>>> >>>> VMOption getVMOption(String name) >>>> >>>> Returns a VMOption object for a VM option of the given name. >>>> >>>> Returns: >>>> a VMOption object for a VM option of the given name. >>>> Throws: >>>> NullPointerException - if name is null. >>>> IllegalArgumentException - if a VM option of the given name >>>> does not exist. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>>> Hi David, >>>>> >>>>> On 22.10.2014 14:33, David Holmes wrote: >>>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>>> Hi Tobias, >>>>>>>> >>>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please review the following patch. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>>> >>>>>>>>> Problem: >>>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>>> flags in >>>>>>>>> product builds. >>>>>>>>> >>>>>>>>> Solution: >>>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>>> allow_locked=true and >>>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>>> flags. I also >>>>>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>>>>> >>>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>>> semantics - >>>>>>>> which may require a CCC request. >>>>>>> >>>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>>> verify the >>>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>>> >>>>>>> Do you think a CCC request is necessary here? >>>>>> >>>>>> Depends what the jmm code is supposed to return - I don't know the >>>>>> spec. But >>>>>> changing the behaviour for the sake of a test without consideration >>>>>> of real >>>>>> users is not something that should be done lightly. >>>>> >>>>> I agree. I filed a CCC request and attached the link to the bug. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>>> noticed that >>>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>>> filed >>>>>>>>> JDK-8061616 [1]. >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> - New testcases >>>>>>>>> - JPRT >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tobias >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 From tobias.hartmann at oracle.com Thu Oct 23 10:02:33 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Oct 2014 12:02:33 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> <5448C316.2040006@oracle.com> <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> Message-ID: <5448D239.3070604@oracle.com> Hi Staffan, On 23.10.2014 11:29, Staffan Larsen wrote: > This is better! > > But won?t the new WB_IsDebugVMFlag() return true for flags that don?t exist at all? Of course, you are right. I fixed it and added a call to 'isDebugVMFlag' to 'VmFlagTest.testWriteNegative' to check that it always returns false for non-existing flags. New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.02/ Thanks, Tobias > > /Staffan > > > On 23 okt 2014, at 10:57, Tobias Hartmann > wrote: > >> Vladimir, David, Staffan, >> >> thanks for the reviews. >> >> On 23.10.2014 09:06, Staffan Larsen wrote: >>> >>> On 23 okt 2014, at 04:35, David Holmes >> > wrote: >>> >>>> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>>>> getVMOption() specification does not say anything about product, locked >>>>> or develop flags. "If a VM option of the given name does not exist" can >>>>> interpreted different ways. >>>> >>>> Perhaps, but conceptually develop flags are not part of a product build and >>>> by definition non-product flags are not part of a product build, so I think >>>> the existing jmm code is quite right to exclude them and the new code should >>>> do the same. It doesn't make sense to me to present someone with a list of >>>> flags that can't actually be used. >>> >>> I agree with David here. Instead of changing the JMM API, you can add >>> functionality to the WhiteBox API to get the value of non-product flags. >> >> I agree. I reverted the JMM changes and added a Whitebox API method >> 'isDebugVMFlag' to check whether a flag is debug/notproduct. >> >> I changed the tests such that we only use JMM to verify the values returned by >> the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct flag >> in a product build). >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ >> >> Thanks, >> Tobias >> >>> /Staffan >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>>>> >>>>> >>>>> VMOption getVMOption(String name) >>>>> >>>>> Returns a VMOption object for a VM option of the given name. >>>>> >>>>> Returns: >>>>> a VMOption object for a VM option of the given name. >>>>> Throws: >>>>> NullPointerException - if name is null. >>>>> IllegalArgumentException - if a VM option of the given name >>>>> does not exist. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>>>> Hi David, >>>>>> >>>>>> On 22.10.2014 14:33, David Holmes wrote: >>>>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>>>> Hi Tobias, >>>>>>>>> >>>>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please review the following patch. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>>>> >>>>>>>>>> Problem: >>>>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>>>> flags in >>>>>>>>>> product builds. >>>>>>>>>> >>>>>>>>>> Solution: >>>>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>>>> allow_locked=true and >>>>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>>>> flags. I also >>>>>>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>>>>>> >>>>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>>>> semantics - >>>>>>>>> which may require a CCC request. >>>>>>>> >>>>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>>>> verify the >>>>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>>>> >>>>>>>> Do you think a CCC request is necessary here? >>>>>>> >>>>>>> Depends what the jmm code is supposed to return - I don't know the >>>>>>> spec. But >>>>>>> changing the behaviour for the sake of a test without consideration >>>>>>> of real >>>>>>> users is not something that should be done lightly. >>>>>> >>>>>> I agree. I filed a CCC request and attached the link to the bug. >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>>>> noticed that >>>>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>>>> filed >>>>>>>>>> JDK-8061616 [1]. >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> - New testcases >>>>>>>>>> - JPRT >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 > From staffan.larsen at oracle.com Thu Oct 23 10:13:04 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Oct 2014 12:13:04 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <5448D239.3070604@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> <5448C316.2040006@oracle.com> <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> <5448D239.3070604@oracle.com> Message-ID: I don?t agree that locked flags are the same as debug flags. Perhaps two queries? One for constant flags and one for locked flags? /Staffan On 23 okt 2014, at 12:02, Tobias Hartmann wrote: > Hi Staffan, > > On 23.10.2014 11:29, Staffan Larsen wrote: >> This is better! >> >> But won?t the new WB_IsDebugVMFlag() return true for flags that don?t exist at all? > > Of course, you are right. I fixed it and added a call to 'isDebugVMFlag' to > 'VmFlagTest.testWriteNegative' to check that it always returns false for > non-existing flags. > > New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.02/ > > Thanks, > Tobias > >> >> /Staffan >> >> >> On 23 okt 2014, at 10:57, Tobias Hartmann > > wrote: >> >>> Vladimir, David, Staffan, >>> >>> thanks for the reviews. >>> >>> On 23.10.2014 09:06, Staffan Larsen wrote: >>>> >>>> On 23 okt 2014, at 04:35, David Holmes >>> > wrote: >>>> >>>>> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>>>>> getVMOption() specification does not say anything about product, locked >>>>>> or develop flags. "If a VM option of the given name does not exist" can >>>>>> interpreted different ways. >>>>> >>>>> Perhaps, but conceptually develop flags are not part of a product build and >>>>> by definition non-product flags are not part of a product build, so I think >>>>> the existing jmm code is quite right to exclude them and the new code should >>>>> do the same. It doesn't make sense to me to present someone with a list of >>>>> flags that can't actually be used. >>>> >>>> I agree with David here. Instead of changing the JMM API, you can add >>>> functionality to the WhiteBox API to get the value of non-product flags. >>> >>> I agree. I reverted the JMM changes and added a Whitebox API method >>> 'isDebugVMFlag' to check whether a flag is debug/notproduct. >>> >>> I changed the tests such that we only use JMM to verify the values returned by >>> the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct flag >>> in a product build). >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ >>> >>> Thanks, >>> Tobias >>> >>>> /Staffan >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>>>>> >>>>>> >>>>>> VMOption getVMOption(String name) >>>>>> >>>>>> Returns a VMOption object for a VM option of the given name. >>>>>> >>>>>> Returns: >>>>>> a VMOption object for a VM option of the given name. >>>>>> Throws: >>>>>> NullPointerException - if name is null. >>>>>> IllegalArgumentException - if a VM option of the given name >>>>>> does not exist. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 22.10.2014 14:33, David Holmes wrote: >>>>>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>>>>> Hi Tobias, >>>>>>>>>> >>>>>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review the following patch. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Problem: >>>>>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>>>>> flags in >>>>>>>>>>> product builds. >>>>>>>>>>> >>>>>>>>>>> Solution: >>>>>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>>>>> allow_locked=true and >>>>>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>>>>> flags. I also >>>>>>>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>>>>>>> >>>>>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>>>>> semantics - >>>>>>>>>> which may require a CCC request. >>>>>>>>> >>>>>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>>>>> verify the >>>>>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>>>>> >>>>>>>>> Do you think a CCC request is necessary here? >>>>>>>> >>>>>>>> Depends what the jmm code is supposed to return - I don't know the >>>>>>>> spec. But >>>>>>>> changing the behaviour for the sake of a test without consideration >>>>>>>> of real >>>>>>>> users is not something that should be done lightly. >>>>>>> >>>>>>> I agree. I filed a CCC request and attached the link to the bug. >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tobias >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>>>>> noticed that >>>>>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>>>>> filed >>>>>>>>>>> JDK-8061616 [1]. >>>>>>>>>>> >>>>>>>>>>> Testing: >>>>>>>>>>> - New testcases >>>>>>>>>>> - JPRT >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >> From tobias.hartmann at oracle.com Thu Oct 23 11:15:55 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Oct 2014 13:15:55 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> <5448C316.2040006@oracle.com> <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> <5448D239.3070604@oracle.com> Message-ID: <5448E36B.1040204@oracle.com> On 23.10.2014 12:13, Staffan Larsen wrote: > I don?t agree that locked flags are the same as debug flags. Perhaps two queries? One for constant flags and one for locked flags? Okay, I added the methods 'isLockedVMFlag' and 'isConstantVMFlag' and adapted the tests. New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.03/ Thanks, Tobias > /Staffan > > > On 23 okt 2014, at 12:02, Tobias Hartmann wrote: > >> Hi Staffan, >> >> On 23.10.2014 11:29, Staffan Larsen wrote: >>> This is better! >>> >>> But won?t the new WB_IsDebugVMFlag() return true for flags that don?t exist at all? >> >> Of course, you are right. I fixed it and added a call to 'isDebugVMFlag' to >> 'VmFlagTest.testWriteNegative' to check that it always returns false for >> non-existing flags. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.02/ >> >> Thanks, >> Tobias >> >>> >>> /Staffan >>> >>> >>> On 23 okt 2014, at 10:57, Tobias Hartmann >> > wrote: >>> >>>> Vladimir, David, Staffan, >>>> >>>> thanks for the reviews. >>>> >>>> On 23.10.2014 09:06, Staffan Larsen wrote: >>>>> >>>>> On 23 okt 2014, at 04:35, David Holmes >>>> > wrote: >>>>> >>>>>> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>>>>>> getVMOption() specification does not say anything about product, locked >>>>>>> or develop flags. "If a VM option of the given name does not exist" can >>>>>>> interpreted different ways. >>>>>> >>>>>> Perhaps, but conceptually develop flags are not part of a product build and >>>>>> by definition non-product flags are not part of a product build, so I think >>>>>> the existing jmm code is quite right to exclude them and the new code should >>>>>> do the same. It doesn't make sense to me to present someone with a list of >>>>>> flags that can't actually be used. >>>>> >>>>> I agree with David here. Instead of changing the JMM API, you can add >>>>> functionality to the WhiteBox API to get the value of non-product flags. >>>> >>>> I agree. I reverted the JMM changes and added a Whitebox API method >>>> 'isDebugVMFlag' to check whether a flag is debug/notproduct. >>>> >>>> I changed the tests such that we only use JMM to verify the values returned by >>>> the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct flag >>>> in a product build). >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> /Staffan >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>>>>>> >>>>>>> >>>>>>> VMOption getVMOption(String name) >>>>>>> >>>>>>> Returns a VMOption object for a VM option of the given name. >>>>>>> >>>>>>> Returns: >>>>>>> a VMOption object for a VM option of the given name. >>>>>>> Throws: >>>>>>> NullPointerException - if name is null. >>>>>>> IllegalArgumentException - if a VM option of the given name >>>>>>> does not exist. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 22.10.2014 14:33, David Holmes wrote: >>>>>>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>>>>>> Hi Tobias, >>>>>>>>>>> >>>>>>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please review the following patch. >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Problem: >>>>>>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>>>>>> flags in >>>>>>>>>>>> product builds. >>>>>>>>>>>> >>>>>>>>>>>> Solution: >>>>>>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>>>>>> allow_locked=true and >>>>>>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>>>>>> flags. I also >>>>>>>>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>>>>>>>> >>>>>>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>>>>>> semantics - >>>>>>>>>>> which may require a CCC request. >>>>>>>>>> >>>>>>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>>>>>> verify the >>>>>>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>>>>>> >>>>>>>>>> Do you think a CCC request is necessary here? >>>>>>>>> >>>>>>>>> Depends what the jmm code is supposed to return - I don't know the >>>>>>>>> spec. But >>>>>>>>> changing the behaviour for the sake of a test without consideration >>>>>>>>> of real >>>>>>>>> users is not something that should be done lightly. >>>>>>>> >>>>>>>> I agree. I filed a CCC request and attached the link to the bug. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>>>>>> noticed that >>>>>>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>>>>>> filed >>>>>>>>>>>> JDK-8061616 [1]. >>>>>>>>>>>> >>>>>>>>>>>> Testing: >>>>>>>>>>>> - New testcases >>>>>>>>>>>> - JPRT >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tobias >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>> > From staffan.larsen at oracle.com Thu Oct 23 12:05:12 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Oct 2014 14:05:12 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <5448E36B.1040204@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> <5448C316.2040006@oracle.com> <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> <5448D239.3070604@oracle.com> <5448E36B.1040204@oracle.com> Message-ID: <353D3088-D088-4A50-925D-DF380307F1BE@oracle.com> Looks good! Thanks, /Staffan On 23 okt 2014, at 13:15, Tobias Hartmann wrote: > > On 23.10.2014 12:13, Staffan Larsen wrote: >> I don?t agree that locked flags are the same as debug flags. Perhaps two queries? One for constant flags and one for locked flags? > > Okay, I added the methods 'isLockedVMFlag' and 'isConstantVMFlag' and adapted > the tests. > > New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.03/ > > Thanks, > Tobias > >> /Staffan >> >> >> On 23 okt 2014, at 12:02, Tobias Hartmann wrote: >> >>> Hi Staffan, >>> >>> On 23.10.2014 11:29, Staffan Larsen wrote: >>>> This is better! >>>> >>>> But won?t the new WB_IsDebugVMFlag() return true for flags that don?t exist at all? >>> >>> Of course, you are right. I fixed it and added a call to 'isDebugVMFlag' to >>> 'VmFlagTest.testWriteNegative' to check that it always returns false for >>> non-existing flags. >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.02/ >>> >>> Thanks, >>> Tobias >>> >>>> >>>> /Staffan >>>> >>>> >>>> On 23 okt 2014, at 10:57, Tobias Hartmann >>> > wrote: >>>> >>>>> Vladimir, David, Staffan, >>>>> >>>>> thanks for the reviews. >>>>> >>>>> On 23.10.2014 09:06, Staffan Larsen wrote: >>>>>> >>>>>> On 23 okt 2014, at 04:35, David Holmes >>>>> > wrote: >>>>>> >>>>>>> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>>>>>>> getVMOption() specification does not say anything about product, locked >>>>>>>> or develop flags. "If a VM option of the given name does not exist" can >>>>>>>> interpreted different ways. >>>>>>> >>>>>>> Perhaps, but conceptually develop flags are not part of a product build and >>>>>>> by definition non-product flags are not part of a product build, so I think >>>>>>> the existing jmm code is quite right to exclude them and the new code should >>>>>>> do the same. It doesn't make sense to me to present someone with a list of >>>>>>> flags that can't actually be used. >>>>>> >>>>>> I agree with David here. Instead of changing the JMM API, you can add >>>>>> functionality to the WhiteBox API to get the value of non-product flags. >>>>> >>>>> I agree. I reverted the JMM changes and added a Whitebox API method >>>>> 'isDebugVMFlag' to check whether a flag is debug/notproduct. >>>>> >>>>> I changed the tests such that we only use JMM to verify the values returned by >>>>> the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct flag >>>>> in a product build). >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> /Staffan >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>>>>>>> >>>>>>>> >>>>>>>> VMOption getVMOption(String name) >>>>>>>> >>>>>>>> Returns a VMOption object for a VM option of the given name. >>>>>>>> >>>>>>>> Returns: >>>>>>>> a VMOption object for a VM option of the given name. >>>>>>>> Throws: >>>>>>>> NullPointerException - if name is null. >>>>>>>> IllegalArgumentException - if a VM option of the given name >>>>>>>> does not exist. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> On 22.10.2014 14:33, David Holmes wrote: >>>>>>>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>>>>>>> Hi Tobias, >>>>>>>>>>>> >>>>>>>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> please review the following patch. >>>>>>>>>>>>> >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Problem: >>>>>>>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>>>>>>> flags in >>>>>>>>>>>>> product builds. >>>>>>>>>>>>> >>>>>>>>>>>>> Solution: >>>>>>>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>>>>>>> allow_locked=true and >>>>>>>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>>>>>>> flags. I also >>>>>>>>>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>>>>>>>>> >>>>>>>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>>>>>>> semantics - >>>>>>>>>>>> which may require a CCC request. >>>>>>>>>>> >>>>>>>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>>>>>>> verify the >>>>>>>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>>>>>>> >>>>>>>>>>> Do you think a CCC request is necessary here? >>>>>>>>>> >>>>>>>>>> Depends what the jmm code is supposed to return - I don't know the >>>>>>>>>> spec. But >>>>>>>>>> changing the behaviour for the sake of a test without consideration >>>>>>>>>> of real >>>>>>>>>> users is not something that should be done lightly. >>>>>>>>> >>>>>>>>> I agree. I filed a CCC request and attached the link to the bug. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tobias >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>>>>>>> noticed that >>>>>>>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>>>>>>> filed >>>>>>>>>>>>> JDK-8061616 [1]. >>>>>>>>>>>>> >>>>>>>>>>>>> Testing: >>>>>>>>>>>>> - New testcases >>>>>>>>>>>>> - JPRT >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Tobias >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>> >> From tobias.hartmann at oracle.com Thu Oct 23 12:12:46 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Oct 2014 14:12:46 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <353D3088-D088-4A50-925D-DF380307F1BE@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> <5448C316.2040006@oracle.com> <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> <5448D239.3070604@oracle.com> <5448E36B.1040204@oracle.com> <353D3088-D088-4A50-925D-DF380307F1BE@oracle.com> Message-ID: <5448F0BE.7090509@oracle.com> Thanks, Stefan. Best, Tobias On 23.10.2014 14:05, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 23 okt 2014, at 13:15, Tobias Hartmann wrote: > >> >> On 23.10.2014 12:13, Staffan Larsen wrote: >>> I don?t agree that locked flags are the same as debug flags. Perhaps two queries? One for constant flags and one for locked flags? >> >> Okay, I added the methods 'isLockedVMFlag' and 'isConstantVMFlag' and adapted >> the tests. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.03/ >> >> Thanks, >> Tobias >> >>> /Staffan >>> >>> >>> On 23 okt 2014, at 12:02, Tobias Hartmann wrote: >>> >>>> Hi Staffan, >>>> >>>> On 23.10.2014 11:29, Staffan Larsen wrote: >>>>> This is better! >>>>> >>>>> But won?t the new WB_IsDebugVMFlag() return true for flags that don?t exist at all? >>>> >>>> Of course, you are right. I fixed it and added a call to 'isDebugVMFlag' to >>>> 'VmFlagTest.testWriteNegative' to check that it always returns false for >>>> non-existing flags. >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.02/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> /Staffan >>>>> >>>>> >>>>> On 23 okt 2014, at 10:57, Tobias Hartmann >>>> > wrote: >>>>> >>>>>> Vladimir, David, Staffan, >>>>>> >>>>>> thanks for the reviews. >>>>>> >>>>>> On 23.10.2014 09:06, Staffan Larsen wrote: >>>>>>> >>>>>>> On 23 okt 2014, at 04:35, David Holmes >>>>>> > wrote: >>>>>>> >>>>>>>> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>>>>>>>> getVMOption() specification does not say anything about product, locked >>>>>>>>> or develop flags. "If a VM option of the given name does not exist" can >>>>>>>>> interpreted different ways. >>>>>>>> >>>>>>>> Perhaps, but conceptually develop flags are not part of a product build and >>>>>>>> by definition non-product flags are not part of a product build, so I think >>>>>>>> the existing jmm code is quite right to exclude them and the new code should >>>>>>>> do the same. It doesn't make sense to me to present someone with a list of >>>>>>>> flags that can't actually be used. >>>>>>> >>>>>>> I agree with David here. Instead of changing the JMM API, you can add >>>>>>> functionality to the WhiteBox API to get the value of non-product flags. >>>>>> >>>>>> I agree. I reverted the JMM changes and added a Whitebox API method >>>>>> 'isDebugVMFlag' to check whether a flag is debug/notproduct. >>>>>> >>>>>> I changed the tests such that we only use JMM to verify the values returned by >>>>>> the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct flag >>>>>> in a product build). >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>>>>>>>> >>>>>>>>> >>>>>>>>> VMOption getVMOption(String name) >>>>>>>>> >>>>>>>>> Returns a VMOption object for a VM option of the given name. >>>>>>>>> >>>>>>>>> Returns: >>>>>>>>> a VMOption object for a VM option of the given name. >>>>>>>>> Throws: >>>>>>>>> NullPointerException - if name is null. >>>>>>>>> IllegalArgumentException - if a VM option of the given name >>>>>>>>> does not exist. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> On 22.10.2014 14:33, David Holmes wrote: >>>>>>>>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>>>>>>>> Hi Tobias, >>>>>>>>>>>>> >>>>>>>>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> please review the following patch. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Problem: >>>>>>>>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>>>>>>>> flags in >>>>>>>>>>>>>> product builds. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Solution: >>>>>>>>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>>>>>>>> allow_locked=true and >>>>>>>>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>>>>>>>> flags. I also >>>>>>>>>>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>>>>>>>>>> >>>>>>>>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>>>>>>>> semantics - >>>>>>>>>>>>> which may require a CCC request. >>>>>>>>>>>> >>>>>>>>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>>>>>>>> verify the >>>>>>>>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>>>>>>>> >>>>>>>>>>>> Do you think a CCC request is necessary here? >>>>>>>>>>> >>>>>>>>>>> Depends what the jmm code is supposed to return - I don't know the >>>>>>>>>>> spec. But >>>>>>>>>>> changing the behaviour for the sake of a test without consideration >>>>>>>>>>> of real >>>>>>>>>>> users is not something that should be done lightly. >>>>>>>>>> >>>>>>>>>> I agree. I filed a CCC request and attached the link to the bug. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tobias >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>>>>>>>> noticed that >>>>>>>>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>>>>>>>> filed >>>>>>>>>>>>>> JDK-8061616 [1]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Testing: >>>>>>>>>>>>>> - New testcases >>>>>>>>>>>>>> - JPRT >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Tobias >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>>> >>> > From vladimir.kozlov at oracle.com Thu Oct 23 17:28:25 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Oct 2014 10:28:25 -0700 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <5448E36B.1040204@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> <5448C316.2040006@oracle.com> <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> <5448D239.3070604@oracle.com> <5448E36B.1040204@oracle.com> Message-ID: <54493AB9.5030103@oracle.com> whitebox.cpp I don't why you need to split next lines: + {CC"isConstantVMFlag", CC"(Ljava/lang/String;)Z", + (void*)&WB_IsConstantVMFlag}, + {CC"isLockedVMFlag", CC"(Ljava/lang/String;)Z", + (void*)&WB_IsLockedVMFlag}, VmFlagTest.java add line to the next comment: // JMM cannot access debug flags in product builds or locked flags, // use whitebox methods to get such flags value. Otherwise seems correct. Thanks, Vladimir On 10/23/14 4:15 AM, Tobias Hartmann wrote: > > On 23.10.2014 12:13, Staffan Larsen wrote: >> I don?t agree that locked flags are the same as debug flags. Perhaps two queries? One for constant flags and one for locked flags? > > Okay, I added the methods 'isLockedVMFlag' and 'isConstantVMFlag' and adapted > the tests. > > New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.03/ > > Thanks, > Tobias > >> /Staffan >> >> >> On 23 okt 2014, at 12:02, Tobias Hartmann wrote: >> >>> Hi Staffan, >>> >>> On 23.10.2014 11:29, Staffan Larsen wrote: >>>> This is better! >>>> >>>> But won?t the new WB_IsDebugVMFlag() return true for flags that don?t exist at all? >>> >>> Of course, you are right. I fixed it and added a call to 'isDebugVMFlag' to >>> 'VmFlagTest.testWriteNegative' to check that it always returns false for >>> non-existing flags. >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.02/ >>> >>> Thanks, >>> Tobias >>> >>>> >>>> /Staffan >>>> >>>> >>>> On 23 okt 2014, at 10:57, Tobias Hartmann >>> > wrote: >>>> >>>>> Vladimir, David, Staffan, >>>>> >>>>> thanks for the reviews. >>>>> >>>>> On 23.10.2014 09:06, Staffan Larsen wrote: >>>>>> >>>>>> On 23 okt 2014, at 04:35, David Holmes >>>>> > wrote: >>>>>> >>>>>>> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>>>>>>> getVMOption() specification does not say anything about product, locked >>>>>>>> or develop flags. "If a VM option of the given name does not exist" can >>>>>>>> interpreted different ways. >>>>>>> >>>>>>> Perhaps, but conceptually develop flags are not part of a product build and >>>>>>> by definition non-product flags are not part of a product build, so I think >>>>>>> the existing jmm code is quite right to exclude them and the new code should >>>>>>> do the same. It doesn't make sense to me to present someone with a list of >>>>>>> flags that can't actually be used. >>>>>> >>>>>> I agree with David here. Instead of changing the JMM API, you can add >>>>>> functionality to the WhiteBox API to get the value of non-product flags. >>>>> >>>>> I agree. I reverted the JMM changes and added a Whitebox API method >>>>> 'isDebugVMFlag' to check whether a flag is debug/notproduct. >>>>> >>>>> I changed the tests such that we only use JMM to verify the values returned by >>>>> the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct flag >>>>> in a product build). >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> /Staffan >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>>>>>>> >>>>>>>> >>>>>>>> VMOption getVMOption(String name) >>>>>>>> >>>>>>>> Returns a VMOption object for a VM option of the given name. >>>>>>>> >>>>>>>> Returns: >>>>>>>> a VMOption object for a VM option of the given name. >>>>>>>> Throws: >>>>>>>> NullPointerException - if name is null. >>>>>>>> IllegalArgumentException - if a VM option of the given name >>>>>>>> does not exist. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> On 22.10.2014 14:33, David Holmes wrote: >>>>>>>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>>>>>>> Hi Tobias, >>>>>>>>>>>> >>>>>>>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> please review the following patch. >>>>>>>>>>>>> >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Problem: >>>>>>>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>>>>>>> flags in >>>>>>>>>>>>> product builds. >>>>>>>>>>>>> >>>>>>>>>>>>> Solution: >>>>>>>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>>>>>>> allow_locked=true and >>>>>>>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>>>>>>> flags. I also >>>>>>>>>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>>>>>>>>> >>>>>>>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>>>>>>> semantics - >>>>>>>>>>>> which may require a CCC request. >>>>>>>>>>> >>>>>>>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>>>>>>> verify the >>>>>>>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>>>>>>> >>>>>>>>>>> Do you think a CCC request is necessary here? >>>>>>>>>> >>>>>>>>>> Depends what the jmm code is supposed to return - I don't know the >>>>>>>>>> spec. But >>>>>>>>>> changing the behaviour for the sake of a test without consideration >>>>>>>>>> of real >>>>>>>>>> users is not something that should be done lightly. >>>>>>>>> >>>>>>>>> I agree. I filed a CCC request and attached the link to the bug. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tobias >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>>>>>>> noticed that >>>>>>>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>>>>>>> filed >>>>>>>>>>>>> JDK-8061616 [1]. >>>>>>>>>>>>> >>>>>>>>>>>>> Testing: >>>>>>>>>>>>> - New testcases >>>>>>>>>>>>> - JPRT >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Tobias >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>> >> From tobias.hartmann at oracle.com Thu Oct 23 17:45:20 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Oct 2014 19:45:20 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <54493AB9.5030103@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> <5448C316.2040006@oracle.com> <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> <5448D239.3070604@oracle.com> <5448E36B.1040204@oracle.com> <54493AB9.5030103@oracle.com> Message-ID: <54493EB0.5050109@oracle.com> Hi Vladimir, thanks for the review. On 23.10.2014 19:28, Vladimir Kozlov wrote: > whitebox.cpp I don't why you need to split next lines: > > + {CC"isConstantVMFlag", CC"(Ljava/lang/String;)Z", > + > (void*)&WB_IsConstantVMFlag}, > + {CC"isLockedVMFlag", CC"(Ljava/lang/String;)Z", > + (void*)&WB_IsLockedVMFlag}, > > VmFlagTest.java add line to the next comment: > > // JMM cannot access debug flags in product builds or locked flags, > // use whitebox methods to get such flags value. Done. New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.04/ Thanks, Tobias > > Otherwise seems correct. > > Thanks, > Vladimir > > On 10/23/14 4:15 AM, Tobias Hartmann wrote: >> >> On 23.10.2014 12:13, Staffan Larsen wrote: >>> I don?t agree that locked flags are the same as debug flags. Perhaps two >>> queries? One for constant flags and one for locked flags? >> >> Okay, I added the methods 'isLockedVMFlag' and 'isConstantVMFlag' and adapted >> the tests. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.03/ >> >> Thanks, >> Tobias >> >>> /Staffan >>> >>> >>> On 23 okt 2014, at 12:02, Tobias Hartmann wrote: >>> >>>> Hi Staffan, >>>> >>>> On 23.10.2014 11:29, Staffan Larsen wrote: >>>>> This is better! >>>>> >>>>> But won?t the new WB_IsDebugVMFlag() return true for flags that don?t exist >>>>> at all? >>>> >>>> Of course, you are right. I fixed it and added a call to 'isDebugVMFlag' to >>>> 'VmFlagTest.testWriteNegative' to check that it always returns false for >>>> non-existing flags. >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.02/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> /Staffan >>>>> >>>>> >>>>> On 23 okt 2014, at 10:57, Tobias Hartmann >>>> > wrote: >>>>> >>>>>> Vladimir, David, Staffan, >>>>>> >>>>>> thanks for the reviews. >>>>>> >>>>>> On 23.10.2014 09:06, Staffan Larsen wrote: >>>>>>> >>>>>>> On 23 okt 2014, at 04:35, David Holmes >>>>>> > wrote: >>>>>>> >>>>>>>> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>>>>>>>> getVMOption() specification does not say anything about product, locked >>>>>>>>> or develop flags. "If a VM option of the given name does not exist" can >>>>>>>>> interpreted different ways. >>>>>>>> >>>>>>>> Perhaps, but conceptually develop flags are not part of a product build and >>>>>>>> by definition non-product flags are not part of a product build, so I think >>>>>>>> the existing jmm code is quite right to exclude them and the new code >>>>>>>> should >>>>>>>> do the same. It doesn't make sense to me to present someone with a list of >>>>>>>> flags that can't actually be used. >>>>>>> >>>>>>> I agree with David here. Instead of changing the JMM API, you can add >>>>>>> functionality to the WhiteBox API to get the value of non-product flags. >>>>>> >>>>>> I agree. I reverted the JMM changes and added a Whitebox API method >>>>>> 'isDebugVMFlag' to check whether a flag is debug/notproduct. >>>>>> >>>>>> I changed the tests such that we only use JMM to verify the values >>>>>> returned by >>>>>> the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct >>>>>> flag >>>>>> in a product build). >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> VMOption getVMOption(String name) >>>>>>>>> >>>>>>>>> Returns a VMOption object for a VM option of the given name. >>>>>>>>> >>>>>>>>> Returns: >>>>>>>>> a VMOption object for a VM option of the given name. >>>>>>>>> Throws: >>>>>>>>> NullPointerException - if name is null. >>>>>>>>> IllegalArgumentException - if a VM option of the given name >>>>>>>>> does not exist. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> On 22.10.2014 14:33, David Holmes wrote: >>>>>>>>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>>>>>>>> Hi Tobias, >>>>>>>>>>>>> >>>>>>>>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> please review the following patch. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Problem: >>>>>>>>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>>>>>>>> flags in >>>>>>>>>>>>>> product builds. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Solution: >>>>>>>>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>>>>>>>> allow_locked=true and >>>>>>>>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>>>>>>>> flags. I also >>>>>>>>>>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>>>>>>>>>> >>>>>>>>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>>>>>>>> semantics - >>>>>>>>>>>>> which may require a CCC request. >>>>>>>>>>>> >>>>>>>>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>>>>>>>> verify the >>>>>>>>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>>>>>>>> >>>>>>>>>>>> Do you think a CCC request is necessary here? >>>>>>>>>>> >>>>>>>>>>> Depends what the jmm code is supposed to return - I don't know the >>>>>>>>>>> spec. But >>>>>>>>>>> changing the behaviour for the sake of a test without consideration >>>>>>>>>>> of real >>>>>>>>>>> users is not something that should be done lightly. >>>>>>>>>> >>>>>>>>>> I agree. I filed a CCC request and attached the link to the bug. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tobias >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>>>>>>>> noticed that >>>>>>>>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>>>>>>>> filed >>>>>>>>>>>>>> JDK-8061616 [1]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Testing: >>>>>>>>>>>>>> - New testcases >>>>>>>>>>>>>> - JPRT >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Tobias >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>>> >>> From vladimir.kozlov at oracle.com Thu Oct 23 17:49:59 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Oct 2014 10:49:59 -0700 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <54493EB0.5050109@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> <5448C316.2040006@oracle.com> <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> <5448D239.3070604@oracle.com> <5448E36B.1040204@oracle.com> <54493AB9.5030103@oracle.com> <54493EB0.5050109@oracle.com> Message-ID: <54493FC7.7060509@oracle.com> Good. Thanks, Vladimir On 10/23/14 10:45 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > > On 23.10.2014 19:28, Vladimir Kozlov wrote: >> whitebox.cpp I don't why you need to split next lines: >> >> + {CC"isConstantVMFlag", CC"(Ljava/lang/String;)Z", >> + >> (void*)&WB_IsConstantVMFlag}, >> + {CC"isLockedVMFlag", CC"(Ljava/lang/String;)Z", >> + (void*)&WB_IsLockedVMFlag}, >> >> VmFlagTest.java add line to the next comment: >> >> // JMM cannot access debug flags in product builds or locked flags, >> // use whitebox methods to get such flags value. > > Done. New webrev: > http://cr.openjdk.java.net/~thartmann/8061443/webrev.04/ > > Thanks, > Tobias > >> >> Otherwise seems correct. >> >> Thanks, >> Vladimir >> >> On 10/23/14 4:15 AM, Tobias Hartmann wrote: >>> >>> On 23.10.2014 12:13, Staffan Larsen wrote: >>>> I don?t agree that locked flags are the same as debug flags. Perhaps two >>>> queries? One for constant flags and one for locked flags? >>> >>> Okay, I added the methods 'isLockedVMFlag' and 'isConstantVMFlag' and adapted >>> the tests. >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.03/ >>> >>> Thanks, >>> Tobias >>> >>>> /Staffan >>>> >>>> >>>> On 23 okt 2014, at 12:02, Tobias Hartmann wrote: >>>> >>>>> Hi Staffan, >>>>> >>>>> On 23.10.2014 11:29, Staffan Larsen wrote: >>>>>> This is better! >>>>>> >>>>>> But won?t the new WB_IsDebugVMFlag() return true for flags that don?t exist >>>>>> at all? >>>>> >>>>> Of course, you are right. I fixed it and added a call to 'isDebugVMFlag' to >>>>> 'VmFlagTest.testWriteNegative' to check that it always returns false for >>>>> non-existing flags. >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.02/ >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>> On 23 okt 2014, at 10:57, Tobias Hartmann >>>>> > wrote: >>>>>> >>>>>>> Vladimir, David, Staffan, >>>>>>> >>>>>>> thanks for the reviews. >>>>>>> >>>>>>> On 23.10.2014 09:06, Staffan Larsen wrote: >>>>>>>> >>>>>>>> On 23 okt 2014, at 04:35, David Holmes >>>>>>> > wrote: >>>>>>>> >>>>>>>>> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>>>>>>>>> getVMOption() specification does not say anything about product, locked >>>>>>>>>> or develop flags. "If a VM option of the given name does not exist" can >>>>>>>>>> interpreted different ways. >>>>>>>>> >>>>>>>>> Perhaps, but conceptually develop flags are not part of a product build and >>>>>>>>> by definition non-product flags are not part of a product build, so I think >>>>>>>>> the existing jmm code is quite right to exclude them and the new code >>>>>>>>> should >>>>>>>>> do the same. It doesn't make sense to me to present someone with a list of >>>>>>>>> flags that can't actually be used. >>>>>>>> >>>>>>>> I agree with David here. Instead of changing the JMM API, you can add >>>>>>>> functionality to the WhiteBox API to get the value of non-product flags. >>>>>>> >>>>>>> I agree. I reverted the JMM changes and added a Whitebox API method >>>>>>> 'isDebugVMFlag' to check whether a flag is debug/notproduct. >>>>>>> >>>>>>> I changed the tests such that we only use JMM to verify the values >>>>>>> returned by >>>>>>> the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct >>>>>>> flag >>>>>>> in a product build). >>>>>>> >>>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> VMOption getVMOption(String name) >>>>>>>>>> >>>>>>>>>> Returns a VMOption object for a VM option of the given name. >>>>>>>>>> >>>>>>>>>> Returns: >>>>>>>>>> a VMOption object for a VM option of the given name. >>>>>>>>>> Throws: >>>>>>>>>> NullPointerException - if name is null. >>>>>>>>>> IllegalArgumentException - if a VM option of the given name >>>>>>>>>> does not exist. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> On 22.10.2014 14:33, David Holmes wrote: >>>>>>>>>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>>>>>>>>> Hi Tobias, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> please review the following patch. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Problem: >>>>>>>>>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>>>>>>>>> flags in >>>>>>>>>>>>>>> product builds. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Solution: >>>>>>>>>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>>>>>>>>> allow_locked=true and >>>>>>>>>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>>>>>>>>> flags. I also >>>>>>>>>>>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>>>>>>>>> semantics - >>>>>>>>>>>>>> which may require a CCC request. >>>>>>>>>>>>> >>>>>>>>>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>>>>>>>>> verify the >>>>>>>>>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>>>>>>>>> >>>>>>>>>>>>> Do you think a CCC request is necessary here? >>>>>>>>>>>> >>>>>>>>>>>> Depends what the jmm code is supposed to return - I don't know the >>>>>>>>>>>> spec. But >>>>>>>>>>>> changing the behaviour for the sake of a test without consideration >>>>>>>>>>>> of real >>>>>>>>>>>> users is not something that should be done lightly. >>>>>>>>>>> >>>>>>>>>>> I agree. I filed a CCC request and attached the link to the bug. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Tobias >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>>>>>>>>> noticed that >>>>>>>>>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>>>>>>>>> filed >>>>>>>>>>>>>>> JDK-8061616 [1]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Testing: >>>>>>>>>>>>>>> - New testcases >>>>>>>>>>>>>>> - JPRT >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Tobias >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>>>> >>>> From tobias.hartmann at oracle.com Thu Oct 23 17:51:54 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Oct 2014 19:51:54 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <54493FC7.7060509@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> <5448C316.2040006@oracle.com> <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> <5448D239.3070604@oracle.com> <5448E36B.1040204@oracle.com> <54493AB9.5030103@oracle.com> <54493EB0.5050109@oracle.com> <54493FC7.7060509@oracle.com> Message-ID: <5449403A.6060804@oracle.com> Thanks, Vladimir. Best, Tobias On 23.10.2014 19:49, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/23/14 10:45 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. >> >> On 23.10.2014 19:28, Vladimir Kozlov wrote: >>> whitebox.cpp I don't why you need to split next lines: >>> >>> + {CC"isConstantVMFlag", CC"(Ljava/lang/String;)Z", >>> + >>> (void*)&WB_IsConstantVMFlag}, >>> + {CC"isLockedVMFlag", CC"(Ljava/lang/String;)Z", >>> + >>> (void*)&WB_IsLockedVMFlag}, >>> >>> VmFlagTest.java add line to the next comment: >>> >>> // JMM cannot access debug flags in product builds or locked flags, >>> // use whitebox methods to get such flags value. >> >> Done. New webrev: >> http://cr.openjdk.java.net/~thartmann/8061443/webrev.04/ >> >> Thanks, >> Tobias >> >>> >>> Otherwise seems correct. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/23/14 4:15 AM, Tobias Hartmann wrote: >>>> >>>> On 23.10.2014 12:13, Staffan Larsen wrote: >>>>> I don?t agree that locked flags are the same as debug flags. Perhaps two >>>>> queries? One for constant flags and one for locked flags? >>>> >>>> Okay, I added the methods 'isLockedVMFlag' and 'isConstantVMFlag' and adapted >>>> the tests. >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.03/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> /Staffan >>>>> >>>>> >>>>> On 23 okt 2014, at 12:02, Tobias Hartmann wrote: >>>>> >>>>>> Hi Staffan, >>>>>> >>>>>> On 23.10.2014 11:29, Staffan Larsen wrote: >>>>>>> This is better! >>>>>>> >>>>>>> But won?t the new WB_IsDebugVMFlag() return true for flags that don?t exist >>>>>>> at all? >>>>>> >>>>>> Of course, you are right. I fixed it and added a call to 'isDebugVMFlag' to >>>>>> 'VmFlagTest.testWriteNegative' to check that it always returns false for >>>>>> non-existing flags. >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> On 23 okt 2014, at 10:57, Tobias Hartmann >>>>>> > wrote: >>>>>>> >>>>>>>> Vladimir, David, Staffan, >>>>>>>> >>>>>>>> thanks for the reviews. >>>>>>>> >>>>>>>> On 23.10.2014 09:06, Staffan Larsen wrote: >>>>>>>>> >>>>>>>>> On 23 okt 2014, at 04:35, David Holmes >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>>>>>>>>>> getVMOption() specification does not say anything about product, locked >>>>>>>>>>> or develop flags. "If a VM option of the given name does not exist" can >>>>>>>>>>> interpreted different ways. >>>>>>>>>> >>>>>>>>>> Perhaps, but conceptually develop flags are not part of a product >>>>>>>>>> build and >>>>>>>>>> by definition non-product flags are not part of a product build, so I >>>>>>>>>> think >>>>>>>>>> the existing jmm code is quite right to exclude them and the new code >>>>>>>>>> should >>>>>>>>>> do the same. It doesn't make sense to me to present someone with a >>>>>>>>>> list of >>>>>>>>>> flags that can't actually be used. >>>>>>>>> >>>>>>>>> I agree with David here. Instead of changing the JMM API, you can add >>>>>>>>> functionality to the WhiteBox API to get the value of non-product flags. >>>>>>>> >>>>>>>> I agree. I reverted the JMM changes and added a Whitebox API method >>>>>>>> 'isDebugVMFlag' to check whether a flag is debug/notproduct. >>>>>>>> >>>>>>>> I changed the tests such that we only use JMM to verify the values >>>>>>>> returned by >>>>>>>> the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct >>>>>>>> flag >>>>>>>> in a product build). >>>>>>>> >>>>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> VMOption getVMOption(String name) >>>>>>>>>>> >>>>>>>>>>> Returns a VMOption object for a VM option of the given name. >>>>>>>>>>> >>>>>>>>>>> Returns: >>>>>>>>>>> a VMOption object for a VM option of the given name. >>>>>>>>>>> Throws: >>>>>>>>>>> NullPointerException - if name is null. >>>>>>>>>>> IllegalArgumentException - if a VM option of the given name >>>>>>>>>>> does not exist. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> On 22.10.2014 14:33, David Holmes wrote: >>>>>>>>>>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>>>>>>>>>> Hi Tobias, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> please review the following patch. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Problem: >>>>>>>>>>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>>>>>>>>>> flags in >>>>>>>>>>>>>>>> product builds. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Solution: >>>>>>>>>>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>>>>>>>>>> allow_locked=true and >>>>>>>>>>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>>>>>>>>>> flags. I also >>>>>>>>>>>>>>>> changed the JVM monitoring and management code >>>>>>>>>>>>>>>> 'jmm_GetVMGlobals()'. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>>>>>>>>>> semantics - >>>>>>>>>>>>>>> which may require a CCC request. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>>>>>>>>>> verify the >>>>>>>>>>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do you think a CCC request is necessary here? >>>>>>>>>>>>> >>>>>>>>>>>>> Depends what the jmm code is supposed to return - I don't know the >>>>>>>>>>>>> spec. But >>>>>>>>>>>>> changing the behaviour for the sake of a test without consideration >>>>>>>>>>>>> of real >>>>>>>>>>>>> users is not something that should be done lightly. >>>>>>>>>>>> >>>>>>>>>>>> I agree. I filed a CCC request and attached the link to the bug. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tobias >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Tobias >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>>>>>>>>>> noticed that >>>>>>>>>>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>>>>>>>>>> filed >>>>>>>>>>>>>>>> JDK-8061616 [1]. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Testing: >>>>>>>>>>>>>>>> - New testcases >>>>>>>>>>>>>>>> - JPRT >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Tobias >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>>>>> >>>>> From paul.hohensee at gmail.com Thu Oct 23 20:26:55 2014 From: paul.hohensee at gmail.com (Paul Hohensee) Date: Thu, 23 Oct 2014 16:26:55 -0400 Subject: RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms In-Reply-To: <5BB55DBF-C929-42EE-BCC5-5A1B08FEC270@lnu.se> References: <37B3D027-5B2E-417C-A679-D58AA250FCEF@lnu.se> <72CCEC68-8564-45D7-A696-F9DDA5DA06C3@oracle.com> <5BB55DBF-C929-42EE-BCC5-5A1B08FEC270@lnu.se> Message-ID: Hi Kim, If we go with a fine-grained name (either way is no problem for me: after all, we have such things as globalDefinitions.hpp), then the customary name of the class would be IsBaseOf and of the file containing it isBaseOf.hpp. On filling out the corner cases, I'd recommend going with Erik's minimal implementation because (1) a lot more testing will be needed on the filled-out implementation and (2) the VM won't be using all of the filled-out implementation, which means we ought to create and religiously run unit tests for features the VM doesn't use, which is a PITA (don't even know if the testing framework will allow that). I'd put a note to the effect that it's by no means a complete implementation, and maybe add the filled-out implementation as a comment in case someone needs its functionality at some future time. But I'm not doctrinaire about it. If, after considering the above, you still think the filled-out implementation is needed, it's fine with me. Paul On Wed, Oct 22, 2014 at 11:50 PM, Erik ?sterlund wrote: > Hi Kim, > > Thanks for reviewing this! > > On 22 Oct 2014, at 23:00, Kim Barrett wrote: > > > On Oct 21, 2014, at 11:55 AM, Erik ?sterlund > wrote: > >> > >> Bug: > >> https://bugs.openjdk.java.net/browse/JDK-8058255 > >> > >> Webrev for the simple fix (which I intend to push initially): > >> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.macro/ > >> > >> Webrev for the inheritance/template solution (which will be pushed > after and is the intended "end" result): > >> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.templates/ > >> > >> Webrev for the delta from the macro solution to the > inheritance/template solution: > >> http://cr.openjdk.java.net/~jwilhelm/8058255/webrev.03.incremental/ > > > > I haven't had time to do a real review, but I noted a couple of things > > here. > > > > (1) I really dislike the file name "templateIdioms.hpp". It says > > little or nothing about what is presently in that file, and with a > > name like that it seems all to likely to become a dumping ground. My > > own preference is for relatively fine grained header files, so that I > > can include only what I actually need in a given place. So I'd prefer > > something like is_base_of.hpp for that class, and not sure whether the > > base_class struct also goes there or in its own file. (Fine-grained > > would argue the former.) > > My own preference is also fine grained headers but I have not seen them > much in this project so I actually thought coarse grained was the wanted > style and thus the intention was indeed to dump things in there. We could > do like boost and call it type_traits.hpp as an umbrella include and the > fine grained type_traits/is_base_of.hpp if you like that better. :) > > > (2) It's been a while since I looked at it, but my recollection is > > that the Boost implementation of is_base_of is substantially more > > complex than what is presently in this file. I don't know how much of > > that (possible? assuming my recollection is correct) additional > > complexity might be to correctly support edge cases that might not be > > properly handled by this simple implementation (I wonder about CV > > qualifiers and inaccessible or ambiguous base classes), and how much > > was to deal with deficient compilers. Related to that, I'd like to > > seem some tests. > > This is actually very close to the implementation used by boost's > is_base_and_derived if you expand their macros. > > About using weird classes like ambiguous classes or forward declared but > not defined classes, it returns false. Ambiguous types always lead to > substitution failure. CV qualifiers are not disregarded currently. > > I have now written a lot of tests using STATIC_ASSERT that defines the > guarantees reflected in new comments describing the contract. > > > (3) The documentation and protocol for these structs is weak. For > > example, I would make only the "value" member of is_base_of public, > > with the rest private, and comment it as something like: > > is_base_of::value is true iff T1 is a base class of T2 > > Fixed. > > > (4) C++11 is_base_of is true for class types, and similarly for > > Boost is_base_of (which attempts to match C++11). The is_base_of > > proposed here is false in that case. Matching the "standard" behavior > > would be preferable. (I think the under review is_base_of differs > > from C++11 for some combinations of CV qualifiers too, as C++11 says > > the operation is performed without regard to CV qualifiers.) > > > I did not intend my traits to be exact replacements of the C++11 standard > is_base_of and hence have not followed their semantics and considered all > of their corner cases. As a matter of fact, it was a non-goal to me. > > If you want me to do that though I can give it a good go and fix > is_base_of to almost completely follow the standard. With my new > implementation below is_base_of::type is true iff the types are class > or union and D is either derived from B or the same type as B, disregarding > CV qualifiers. The difference to the C++11 standard is that it should > return false for unions but the implementation of that is /extremely/ > platform dependent and I don't have access to jprt which would make > implementing it extremely awkward. > > Here is my new proposed implementation of is_base_of following the C++11 > standard "decently" with more comments and encapsulation as requested: > > /** > * is_class::value is true iff the type T is a class type. > */ > template > class is_class_or_union { > typedef char yes[1]; > typedef char no[2]; > > template > static yes &check (int U::*); > > template > static no &check (...); > > public: > static const bool value = (sizeof(check(0)) == sizeof(yes)); > }; > > /** > * remove_cv::type returns a type T without any CV qualifiers > */ > template > class remove_cv { > template struct remove_const { typedef U type; }; > template struct remove_const { typedef U type; }; > > template struct remove_volatile { typedef U type; }; > template struct remove_volatile { typedef U > type; }; > > public: > typedef typename remove_volatile::type>::type > type; > }; > > /** > * is_base_of_and_derived::value is true if Derived is a > derived class of Base, disgarding their CV qualifiers. > * Returns false for non-class types except unions. > */ > template > class is_base_of_and_derived { > typedef char yes[1]; > typedef char no[2]; > > template > static yes &check(Derived*, T); > static no &check(Base*, int); > > template > struct is_base_of_host { > operator B*() const; > operator D*(); > }; > > template > struct is_base_of_and_derived_internal { > static const bool value = sizeof(check(is_base_of_host(), > int())) == sizeof(yes); > }; > > public: > static const bool value = is_class_or_union::value && > is_base_of_and_derived_internal::type, > typename remove_cv::type>::value; > }; > > /** > * is_same::value is true iff T and U are the same type. > */ > template > class is_same { > template > struct is_same_internal { > static const bool value = false; > }; > > template > struct is_same_internal { > static const bool value = true; > }; > public: > static const bool value = is_same_internal::value; > }; > > /** > * is_base_of::value is true if either Derived is a derived > class of Base > * disregarding CV qualifiers or Derived and Base are the same type > disregarding CV qualifiers. > * Returns false for all non-class types or unions. > */ > template > class is_base_of { > public: > static const bool value = (is_base_of_and_derived::value > || > is_same::type, typename > remove_cv::type>::value) && > is_class_or_union::value; > }; > > If this seems ok with you I will send a new webrev with the new is_base_of > implementation, its new comments describing the contract and new tests, > testing the contract in detail. I need to know though if you want me to put > all of the traits in different files or not and in that case if you want > them in a new subdirectory or not. > > Thanks, > /Erik From jiangli.zhou at oracle.com Fri Oct 24 00:43:21 2014 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 23 Oct 2014 17:43:21 -0700 Subject: [8u40] Request for approval: JDK-8047935: Adding new API for unlocking diagnostic argument for SharedArchiveFile In-Reply-To: <54499ED2.4010804@oracle.com> References: <54497C13.5000004@oracle.com> <54499ED2.4010804@oracle.com> Message-ID: <5449A0A9.4090105@oracle.com> Sending to hotspot-dev list based on David's suggestion (thanks, David). The repo used for backporting was jdk8u/hs-dev correctly. Thanks, Jiangli On 10/23/2014 05:35 PM, David Holmes wrote: > Hi Jiangli, > > Hotspot changes don't get individual approvals on jd8u-dev but come in > via a bulk update from jdk8u/hs-dev. The RFR should go to the > hotspot-dev list and then push to hs-dev ready for bulk integration. > > David > > On 24/10/2014 8:07 AM, Jiangli Zhou wrote: >> Please approve backport of JDK-8047935 >> to 8u40. This is a >> clean import of the changesets (for JDK-8047934 >> ) from JDK9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8047935 >> Webrev: http://cr.openjdk.java.net/~jiangli/8047935/webrev.00/ >> Changeset: >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/7845c825b8c7 >> >> Thanks, >> Jiangli From david.holmes at oracle.com Fri Oct 24 00:59:06 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Oct 2014 10:59:06 +1000 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <54493EB0.5050109@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> <5448C316.2040006@oracle.com> <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> <5448D239.3070604@oracle.com> <5448E36B.1040204@oracle.com> <54493AB9.5030103@oracle.com> <54493EB0.5050109@oracle.com> Message-ID: <5449A45A.8080108@oracle.com> Thanks Tobias this seems much better to me. David On 24/10/2014 3:45 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > > On 23.10.2014 19:28, Vladimir Kozlov wrote: >> whitebox.cpp I don't why you need to split next lines: >> >> + {CC"isConstantVMFlag", CC"(Ljava/lang/String;)Z", >> + >> (void*)&WB_IsConstantVMFlag}, >> + {CC"isLockedVMFlag", CC"(Ljava/lang/String;)Z", >> + (void*)&WB_IsLockedVMFlag}, >> >> VmFlagTest.java add line to the next comment: >> >> // JMM cannot access debug flags in product builds or locked flags, >> // use whitebox methods to get such flags value. > > Done. New webrev: > http://cr.openjdk.java.net/~thartmann/8061443/webrev.04/ > > Thanks, > Tobias > >> >> Otherwise seems correct. >> >> Thanks, >> Vladimir >> >> On 10/23/14 4:15 AM, Tobias Hartmann wrote: >>> >>> On 23.10.2014 12:13, Staffan Larsen wrote: >>>> I don?t agree that locked flags are the same as debug flags. Perhaps two >>>> queries? One for constant flags and one for locked flags? >>> >>> Okay, I added the methods 'isLockedVMFlag' and 'isConstantVMFlag' and adapted >>> the tests. >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.03/ >>> >>> Thanks, >>> Tobias >>> >>>> /Staffan >>>> >>>> >>>> On 23 okt 2014, at 12:02, Tobias Hartmann wrote: >>>> >>>>> Hi Staffan, >>>>> >>>>> On 23.10.2014 11:29, Staffan Larsen wrote: >>>>>> This is better! >>>>>> >>>>>> But won?t the new WB_IsDebugVMFlag() return true for flags that don?t exist >>>>>> at all? >>>>> >>>>> Of course, you are right. I fixed it and added a call to 'isDebugVMFlag' to >>>>> 'VmFlagTest.testWriteNegative' to check that it always returns false for >>>>> non-existing flags. >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.02/ >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>> On 23 okt 2014, at 10:57, Tobias Hartmann >>>>> > wrote: >>>>>> >>>>>>> Vladimir, David, Staffan, >>>>>>> >>>>>>> thanks for the reviews. >>>>>>> >>>>>>> On 23.10.2014 09:06, Staffan Larsen wrote: >>>>>>>> >>>>>>>> On 23 okt 2014, at 04:35, David Holmes >>>>>>> > wrote: >>>>>>>> >>>>>>>>> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>>>>>>>>> getVMOption() specification does not say anything about product, locked >>>>>>>>>> or develop flags. "If a VM option of the given name does not exist" can >>>>>>>>>> interpreted different ways. >>>>>>>>> >>>>>>>>> Perhaps, but conceptually develop flags are not part of a product build and >>>>>>>>> by definition non-product flags are not part of a product build, so I think >>>>>>>>> the existing jmm code is quite right to exclude them and the new code >>>>>>>>> should >>>>>>>>> do the same. It doesn't make sense to me to present someone with a list of >>>>>>>>> flags that can't actually be used. >>>>>>>> >>>>>>>> I agree with David here. Instead of changing the JMM API, you can add >>>>>>>> functionality to the WhiteBox API to get the value of non-product flags. >>>>>>> >>>>>>> I agree. I reverted the JMM changes and added a Whitebox API method >>>>>>> 'isDebugVMFlag' to check whether a flag is debug/notproduct. >>>>>>> >>>>>>> I changed the tests such that we only use JMM to verify the values >>>>>>> returned by >>>>>>> the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct >>>>>>> flag >>>>>>> in a product build). >>>>>>> >>>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> VMOption getVMOption(String name) >>>>>>>>>> >>>>>>>>>> Returns a VMOption object for a VM option of the given name. >>>>>>>>>> >>>>>>>>>> Returns: >>>>>>>>>> a VMOption object for a VM option of the given name. >>>>>>>>>> Throws: >>>>>>>>>> NullPointerException - if name is null. >>>>>>>>>> IllegalArgumentException - if a VM option of the given name >>>>>>>>>> does not exist. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> On 22.10.2014 14:33, David Holmes wrote: >>>>>>>>>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>>>>>>>>> Hi Tobias, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> please review the following patch. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Problem: >>>>>>>>>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>>>>>>>>> flags in >>>>>>>>>>>>>>> product builds. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Solution: >>>>>>>>>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>>>>>>>>> allow_locked=true and >>>>>>>>>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>>>>>>>>> flags. I also >>>>>>>>>>>>>>> changed the JVM monitoring and management code 'jmm_GetVMGlobals()'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>>>>>>>>> semantics - >>>>>>>>>>>>>> which may require a CCC request. >>>>>>>>>>>>> >>>>>>>>>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>>>>>>>>> verify the >>>>>>>>>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>>>>>>>>> >>>>>>>>>>>>> Do you think a CCC request is necessary here? >>>>>>>>>>>> >>>>>>>>>>>> Depends what the jmm code is supposed to return - I don't know the >>>>>>>>>>>> spec. But >>>>>>>>>>>> changing the behaviour for the sake of a test without consideration >>>>>>>>>>>> of real >>>>>>>>>>>> users is not something that should be done lightly. >>>>>>>>>>> >>>>>>>>>>> I agree. I filed a CCC request and attached the link to the bug. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Tobias >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>>>>>>>>> noticed that >>>>>>>>>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>>>>>>>>> filed >>>>>>>>>>>>>>> JDK-8061616 [1]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Testing: >>>>>>>>>>>>>>> - New testcases >>>>>>>>>>>>>>> - JPRT >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Tobias >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>>>> >>>> From david.holmes at oracle.com Fri Oct 24 01:03:52 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Oct 2014 11:03:52 +1000 Subject: [8u40] Request for approval: JDK-8047935: Adding new API for unlocking diagnostic argument for SharedArchiveFile In-Reply-To: <5449A0A9.4090105@oracle.com> References: <54497C13.5000004@oracle.com> <54499ED2.4010804@oracle.com> <5449A0A9.4090105@oracle.com> Message-ID: <5449A578.2000704@oracle.com> Looks like a clean backport to me. Thanks, David On 24/10/2014 10:43 AM, Jiangli Zhou wrote: > Sending to hotspot-dev list based on David's suggestion (thanks, David). > The repo used for backporting was jdk8u/hs-dev correctly. > > Thanks, > Jiangli > > On 10/23/2014 05:35 PM, David Holmes wrote: >> Hi Jiangli, >> >> Hotspot changes don't get individual approvals on jd8u-dev but come in >> via a bulk update from jdk8u/hs-dev. The RFR should go to the >> hotspot-dev list and then push to hs-dev ready for bulk integration. >> >> David >> >> On 24/10/2014 8:07 AM, Jiangli Zhou wrote: >>> Please approve backport of JDK-8047935 >>> to 8u40. This is a >>> clean import of the changesets (for JDK-8047934 >>> ) from JDK9. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047935 >>> Webrev: http://cr.openjdk.java.net/~jiangli/8047935/webrev.00/ >>> Changeset: >>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/7845c825b8c7 >>> >>> Thanks, >>> Jiangli > From jiangli.zhou at oracle.com Fri Oct 24 01:15:19 2014 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 23 Oct 2014 18:15:19 -0700 Subject: [8u40] Request for approval: JDK-8047935: Adding new API for unlocking diagnostic argument for SharedArchiveFile In-Reply-To: <5449A578.2000704@oracle.com> References: <54497C13.5000004@oracle.com> <54499ED2.4010804@oracle.com> <5449A0A9.4090105@oracle.com> <5449A578.2000704@oracle.com> Message-ID: <5449A827.60806@oracle.com> Thanks, David. I take that as an approval. :) Thanks, Jiangli On 10/23/2014 06:03 PM, David Holmes wrote: > Looks like a clean backport to me. > > Thanks, > David > > On 24/10/2014 10:43 AM, Jiangli Zhou wrote: >> Sending to hotspot-dev list based on David's suggestion (thanks, David). >> The repo used for backporting was jdk8u/hs-dev correctly. >> >> Thanks, >> Jiangli >> >> On 10/23/2014 05:35 PM, David Holmes wrote: >>> Hi Jiangli, >>> >>> Hotspot changes don't get individual approvals on jd8u-dev but come in >>> via a bulk update from jdk8u/hs-dev. The RFR should go to the >>> hotspot-dev list and then push to hs-dev ready for bulk integration. >>> >>> David >>> >>> On 24/10/2014 8:07 AM, Jiangli Zhou wrote: >>>> Please approve backport of JDK-8047935 >>>> to 8u40. This is a >>>> clean import of the changesets (for JDK-8047934 >>>> ) from JDK9. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047935 >>>> Webrev: http://cr.openjdk.java.net/~jiangli/8047935/webrev.00/ >>>> Changeset: >>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/7845c825b8c7 >>>> >>>> Thanks, >>>> Jiangli >> From tobias.hartmann at oracle.com Fri Oct 24 06:07:35 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 24 Oct 2014 08:07:35 +0200 Subject: RFR(S): 8061443: Whitebox get*VMFlag() methods fail with develop flags in product builds In-Reply-To: <5449A45A.8080108@oracle.com> References: <54465AE9.70908@oracle.com> <5447138E.9060702@oracle.com> <54476F6B.3050901@oracle.com> <5447A429.4070306@oracle.com> <5447B520.50302@oracle.com> <54482027.1000101@oracle.com> <5448697E.9050604@oracle.com> <7507F107-7944-4165-8D35-62EDA2C80CF1@oracle.com> <5448C316.2040006@oracle.com> <6688103C-973A-4DCD-BFA8-095D1ABF0A32@oracle.com> <5448D239.3070604@oracle.com> <5448E36B.1040204@oracle.com> <54493AB9.5030103@oracle.com> <54493EB0.5050109@oracle.com> <5449A45A.8080108@oracle.com> Message-ID: <5449ECA7.105@oracle.com> Thanks, David. Best, Tobias On 24.10.2014 02:59, David Holmes wrote: > Thanks Tobias this seems much better to me. > > David > > On 24/10/2014 3:45 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. >> >> On 23.10.2014 19:28, Vladimir Kozlov wrote: >>> whitebox.cpp I don't why you need to split next lines: >>> >>> + {CC"isConstantVMFlag", CC"(Ljava/lang/String;)Z", >>> + >>> (void*)&WB_IsConstantVMFlag}, >>> + {CC"isLockedVMFlag", CC"(Ljava/lang/String;)Z", >>> + >>> (void*)&WB_IsLockedVMFlag}, >>> >>> VmFlagTest.java add line to the next comment: >>> >>> // JMM cannot access debug flags in product builds or locked flags, >>> // use whitebox methods to get such flags value. >> >> Done. New webrev: >> http://cr.openjdk.java.net/~thartmann/8061443/webrev.04/ >> >> Thanks, >> Tobias >> >>> >>> Otherwise seems correct. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/23/14 4:15 AM, Tobias Hartmann wrote: >>>> >>>> On 23.10.2014 12:13, Staffan Larsen wrote: >>>>> I don?t agree that locked flags are the same as debug flags. Perhaps two >>>>> queries? One for constant flags and one for locked flags? >>>> >>>> Okay, I added the methods 'isLockedVMFlag' and 'isConstantVMFlag' and adapted >>>> the tests. >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.03/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> /Staffan >>>>> >>>>> >>>>> On 23 okt 2014, at 12:02, Tobias Hartmann wrote: >>>>> >>>>>> Hi Staffan, >>>>>> >>>>>> On 23.10.2014 11:29, Staffan Larsen wrote: >>>>>>> This is better! >>>>>>> >>>>>>> But won?t the new WB_IsDebugVMFlag() return true for flags that don?t exist >>>>>>> at all? >>>>>> >>>>>> Of course, you are right. I fixed it and added a call to 'isDebugVMFlag' to >>>>>> 'VmFlagTest.testWriteNegative' to check that it always returns false for >>>>>> non-existing flags. >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> On 23 okt 2014, at 10:57, Tobias Hartmann >>>>>> > wrote: >>>>>>> >>>>>>>> Vladimir, David, Staffan, >>>>>>>> >>>>>>>> thanks for the reviews. >>>>>>>> >>>>>>>> On 23.10.2014 09:06, Staffan Larsen wrote: >>>>>>>>> >>>>>>>>> On 23 okt 2014, at 04:35, David Holmes >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> On 23/10/2014 7:22 AM, Vladimir Kozlov wrote: >>>>>>>>>>> getVMOption() specification does not say anything about product, locked >>>>>>>>>>> or develop flags. "If a VM option of the given name does not exist" can >>>>>>>>>>> interpreted different ways. >>>>>>>>>> >>>>>>>>>> Perhaps, but conceptually develop flags are not part of a product >>>>>>>>>> build and >>>>>>>>>> by definition non-product flags are not part of a product build, so I >>>>>>>>>> think >>>>>>>>>> the existing jmm code is quite right to exclude them and the new code >>>>>>>>>> should >>>>>>>>>> do the same. It doesn't make sense to me to present someone with a >>>>>>>>>> list of >>>>>>>>>> flags that can't actually be used. >>>>>>>>> >>>>>>>>> I agree with David here. Instead of changing the JMM API, you can add >>>>>>>>> functionality to the WhiteBox API to get the value of non-product flags. >>>>>>>> >>>>>>>> I agree. I reverted the JMM changes and added a Whitebox API method >>>>>>>> 'isDebugVMFlag' to check whether a flag is debug/notproduct. >>>>>>>> >>>>>>>> I changed the tests such that we only use JMM to verify the values >>>>>>>> returned by >>>>>>>> the Whitebox API if the flag is accessible (i.e. is not a debug/notproduct >>>>>>>> flag >>>>>>>> in a product build). >>>>>>>> >>>>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.01/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> http://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> VMOption getVMOption(String name) >>>>>>>>>>> >>>>>>>>>>> Returns a VMOption object for a VM option of the given name. >>>>>>>>>>> >>>>>>>>>>> Returns: >>>>>>>>>>> a VMOption object for a VM option of the given name. >>>>>>>>>>> Throws: >>>>>>>>>>> NullPointerException - if name is null. >>>>>>>>>>> IllegalArgumentException - if a VM option of the given name >>>>>>>>>>> does not exist. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 10/22/14 6:46 AM, Tobias Hartmann wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> On 22.10.2014 14:33, David Holmes wrote: >>>>>>>>>>>>> On 22/10/2014 6:48 PM, Tobias Hartmann wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 22.10.2014 04:16, David Holmes wrote: >>>>>>>>>>>>>>> Hi Tobias, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 21/10/2014 11:08 PM, Tobias Hartmann wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> please review the following patch. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061443 >>>>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061443/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Problem: >>>>>>>>>>>>>>>> The Whitebox API methods get*VMFlag() fail with develop/notproduct >>>>>>>>>>>>>>>> flags in >>>>>>>>>>>>>>>> product builds. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Solution: >>>>>>>>>>>>>>>> The code is changed to invoke 'Flag::find_flag' with >>>>>>>>>>>>>>>> allow_locked=true and >>>>>>>>>>>>>>>> return_flag=true to return both locked and notproduct/develop >>>>>>>>>>>>>>>> flags. I also >>>>>>>>>>>>>>>> changed the JVM monitoring and management code >>>>>>>>>>>>>>>> 'jmm_GetVMGlobals()'. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why did you change the jmm code? You seemed to have changed its >>>>>>>>>>>>>>> semantics - >>>>>>>>>>>>>>> which may require a CCC request. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I changed the jmm code because the whitebox tests use a JMM call to >>>>>>>>>>>>>> verify the >>>>>>>>>>>>>> return value (see 'VmFlagTest.getVMOptionAsString()'). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do you think a CCC request is necessary here? >>>>>>>>>>>>> >>>>>>>>>>>>> Depends what the jmm code is supposed to return - I don't know the >>>>>>>>>>>>> spec. But >>>>>>>>>>>>> changing the behaviour for the sake of a test without consideration >>>>>>>>>>>>> of real >>>>>>>>>>>>> users is not something that should be done lightly. >>>>>>>>>>>> >>>>>>>>>>>> I agree. I filed a CCC request and attached the link to the bug. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tobias >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Tobias >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I adapted the existing tests to check for develop flags as well. I >>>>>>>>>>>>>>>> noticed that >>>>>>>>>>>>>>>> HotspotDiagnosticMXBean.getVMOption() fails with double flags and >>>>>>>>>>>>>>>> filed >>>>>>>>>>>>>>>> JDK-8061616 [1]. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Testing: >>>>>>>>>>>>>>>> - New testcases >>>>>>>>>>>>>>>> - JPRT >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Tobias >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8061616 >>>>>>> >>>>> From karen.kinnear at oracle.com Fri Oct 24 16:06:24 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 24 Oct 2014 12:06:24 -0400 Subject: RFR: 8043275 8u40 backport: Interface initialization for default methods Message-ID: <0D035C74-97C4-454F-A219-866CCC77C318@oracle.com> Please review 8u40 backport: webrev: http://cr.openjdk.java.net/~acorn/8043275.8u40/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8043275 Summary: Fix superinterface initialization to be based on declaring a non-static instance method rather than on declaring or inheriting one Tested (linux-x64) 8u40: jtreg hotspot lambda-features which includes the two new tests: TestInterfaceInit and TestInterfaceOrder InvokespecialInterface was changed to use nested classes so there is no name conflict for C.class in that directory thanks, Karen From daniel.daugherty at oracle.com Fri Oct 24 16:40:41 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 24 Oct 2014 10:40:41 -0600 Subject: RFR: 8043275 8u40 backport: Interface initialization for default methods In-Reply-To: <0D035C74-97C4-454F-A219-866CCC77C318@oracle.com> References: <0D035C74-97C4-454F-A219-866CCC77C318@oracle.com> Message-ID: <544A8109.3030005@oracle.com> On 10/24/14 10:06 AM, Karen Kinnear wrote: > Please review 8u40 backport: > > webrev: http://cr.openjdk.java.net/~acorn/8043275.8u40/webrev/ I compared the JDK9-hs-rt version with the JDK8u40-hs version. src/share/vm/classfile/classFileParser.cpp No comments. src/share/vm/classfile/classFileParser.hpp No comments. src/share/vm/oops/instanceKlass.cpp 799 if (HAS_PENDING_EXCEPTION) { 800 Handle e(THREAD, PENDING_EXCEPTION); 801 CLEAR_PENDING_EXCEPTION; 802 { 803 EXCEPTION_MARK; 804 // Locks object, set state, and notify all waiting threads 805 this_oop->set_initialization_state_and_notify( 806 initialization_error, THREAD); 807 808 // ignore any exception thrown, superclass initialization error is 809 // thrown below 810 CLEAR_PENDING_EXCEPTION; 811 } 812 } The JDK9 version has this between lines 811 and 812: THROW_OOP(e()); Is there reason for the difference? src/share/vm/oops/instanceKlass.hpp No comments. src/share/vm/utilities/dtrace_disabled.hpp The JDK9 patch modified this file, but the file doesn't exist in JDK8u40-hs. test/runtime/lambda-features/InvokespecialInterface.java The @run changes already existed in JDK9 before your patch. test/runtime/lambda-features/TestInterfaceInit.java The second line has a blank at the end of it: + public static void main(String[] args) { + // Trigger initialization test/runtime/lambda-features/TestInterfaceOrder.java No comments. Dan > bug: https://bugs.openjdk.java.net/browse/JDK-8043275 > > Summary: > Fix superinterface initialization to be based on declaring a non-static instance method rather than > on declaring or inheriting one > > Tested (linux-x64) 8u40: > jtreg hotspot lambda-features which includes the two new tests: TestInterfaceInit and TestInterfaceOrder > InvokespecialInterface was changed to use nested classes so there is no name conflict for C.class in that directory > > thanks, > Karen From karen.kinnear at oracle.com Fri Oct 24 17:05:37 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 24 Oct 2014 13:05:37 -0400 Subject: RFR: 8043275 8u40 backport: Interface initialization for default methods In-Reply-To: <544A8109.3030005@oracle.com> References: <0D035C74-97C4-454F-A219-866CCC77C318@oracle.com> <544A8109.3030005@oracle.com> Message-ID: Dan, Many many thanks - good catches! Updated webrev: http://cr.openjdk.java.net/~acorn/8043275.uu40.2/webrev thanks, Karen On Oct 24, 2014, at 12:40 PM, Daniel D. Daugherty wrote: > On 10/24/14 10:06 AM, Karen Kinnear wrote: >> Please review 8u40 backport: >> >> webrev: http://cr.openjdk.java.net/~acorn/8043275.8u40/webrev/ > > I compared the JDK9-hs-rt version with the JDK8u40-hs version. > > src/share/vm/classfile/classFileParser.cpp > No comments. > > src/share/vm/classfile/classFileParser.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > > 799 if (HAS_PENDING_EXCEPTION) { > 800 Handle e(THREAD, PENDING_EXCEPTION); > 801 CLEAR_PENDING_EXCEPTION; > 802 { > 803 EXCEPTION_MARK; > 804 // Locks object, set state, and notify all waiting threads > 805 this_oop->set_initialization_state_and_notify( > 806 initialization_error, THREAD); > 807 > 808 // ignore any exception thrown, superclass initialization error is > 809 // thrown below > 810 CLEAR_PENDING_EXCEPTION; > 811 } > 812 } > > The JDK9 version has this between lines 811 and 812: > > THROW_OOP(e()); > > Is there reason for the difference? Bad manual merge > > src/share/vm/oops/instanceKlass.hpp > No comments. > > src/share/vm/utilities/dtrace_disabled.hpp > The JDK9 patch modified this file, but the file doesn't > exist in JDK8u40-hs. That was a comment spelling fix - I was in there for another reason which I ended up not needing. Change isn't needed in 8u40. > > test/runtime/lambda-features/InvokespecialInterface.java > The @run changes already existed in JDK9 before your patch. I undid those > > test/runtime/lambda-features/TestInterfaceInit.java > > The second line has a blank at the end of it: > > + public static void main(String[] args) { > + // Trigger initialization Fixed > > test/runtime/lambda-features/TestInterfaceOrder.java > No comments. > > Dan > > >> bug: https://bugs.openjdk.java.net/browse/JDK-8043275 >> >> Summary: >> Fix superinterface initialization to be based on declaring a non-static instance method rather than >> on declaring or inheriting one >> >> Tested (linux-x64) 8u40: >> jtreg hotspot lambda-features which includes the two new tests: TestInterfaceInit and TestInterfaceOrder >> InvokespecialInterface was changed to use nested classes so there is no name conflict for C.class in that directory >> >> thanks, >> Karen > From daniel.daugherty at oracle.com Fri Oct 24 17:17:33 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 24 Oct 2014 11:17:33 -0600 Subject: RFR: 8043275 8u40 backport: Interface initialization for default methods In-Reply-To: References: <0D035C74-97C4-454F-A219-866CCC77C318@oracle.com> <544A8109.3030005@oracle.com> Message-ID: <544A89AD.1010407@oracle.com> This URL should work: http://cr.openjdk.java.net/~acorn/8043275.8u40.2/webrev/ Dan On 10/24/14 11:05 AM, Karen Kinnear wrote: > Dan, > > Many many thanks - good catches! > > Updated webrev: http://cr.openjdk.java.net/~acorn/8043275.uu40.2/webrev > > thanks, > Karen > > On Oct 24, 2014, at 12:40 PM, Daniel D. Daugherty wrote: > >> On 10/24/14 10:06 AM, Karen Kinnear wrote: >>> Please review 8u40 backport: >>> >>> webrev: http://cr.openjdk.java.net/~acorn/8043275.8u40/webrev/ >> I compared the JDK9-hs-rt version with the JDK8u40-hs version. >> >> src/share/vm/classfile/classFileParser.cpp >> No comments. >> >> src/share/vm/classfile/classFileParser.hpp >> No comments. >> >> src/share/vm/oops/instanceKlass.cpp >> >> 799 if (HAS_PENDING_EXCEPTION) { >> 800 Handle e(THREAD, PENDING_EXCEPTION); >> 801 CLEAR_PENDING_EXCEPTION; >> 802 { >> 803 EXCEPTION_MARK; >> 804 // Locks object, set state, and notify all waiting threads >> 805 this_oop->set_initialization_state_and_notify( >> 806 initialization_error, THREAD); >> 807 >> 808 // ignore any exception thrown, superclass initialization error is >> 809 // thrown below >> 810 CLEAR_PENDING_EXCEPTION; >> 811 } >> 812 } >> >> The JDK9 version has this between lines 811 and 812: >> >> THROW_OOP(e()); >> >> Is there reason for the difference? > Bad manual merge >> src/share/vm/oops/instanceKlass.hpp >> No comments. >> >> src/share/vm/utilities/dtrace_disabled.hpp >> The JDK9 patch modified this file, but the file doesn't >> exist in JDK8u40-hs. > That was a comment spelling fix - I was in there for another reason which > I ended up not needing. Change isn't needed in 8u40. >> test/runtime/lambda-features/InvokespecialInterface.java >> The @run changes already existed in JDK9 before your patch. > I undid those >> test/runtime/lambda-features/TestInterfaceInit.java >> >> The second line has a blank at the end of it: >> >> + public static void main(String[] args) { >> + // Trigger initialization > Fixed >> test/runtime/lambda-features/TestInterfaceOrder.java >> No comments. >> >> Dan >> >> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8043275 >>> >>> Summary: >>> Fix superinterface initialization to be based on declaring a non-static instance method rather than >>> on declaring or inheriting one >>> >>> Tested (linux-x64) 8u40: >>> jtreg hotspot lambda-features which includes the two new tests: TestInterfaceInit and TestInterfaceOrder >>> InvokespecialInterface was changed to use nested classes so there is no name conflict for C.class in that directory >>> >>> thanks, >>> Karen From daniel.daugherty at oracle.com Fri Oct 24 17:24:35 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 24 Oct 2014 11:24:35 -0600 Subject: RFR: 8043275 8u40 backport: Interface initialization for default methods In-Reply-To: <544A89AD.1010407@oracle.com> References: <0D035C74-97C4-454F-A219-866CCC77C318@oracle.com> <544A8109.3030005@oracle.com> <544A89AD.1010407@oracle.com> Message-ID: <544A8B53.1000409@oracle.com> On 10/24/14 11:17 AM, Daniel D. Daugherty wrote: > This URL should work: > > http://cr.openjdk.java.net/~acorn/8043275.8u40.2/webrev/ src/share/vm/classfile/classFileParser.cpp No comments. src/share/vm/classfile/classFileParser.hpp No comments. src/share/vm/oops/instanceKlass.cpp No comments. src/share/vm/oops/instanceKlass.hpp No comments. test/runtime/lambda-features/InvokespecialInterface.java Sorry, I didn't mean for you to back out this change: - * @run main/othervm -XX:+StressRewriter InvokespecialInterface + * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRewriter InvokespecialInterface That change was not part of your JDK9 patch that bug had been fixed in JDK9 before your changes. I think you do need to make the above change for 8u40. test/runtime/lambda-features/TestInterfaceInit.java No comments. test/runtime/lambda-features/TestInterfaceOrder.java No comments. Dan > > Dan > > > On 10/24/14 11:05 AM, Karen Kinnear wrote: >> Dan, >> >> Many many thanks - good catches! >> >> Updated webrev: http://cr.openjdk.java.net/~acorn/8043275.uu40.2/webrev >> >> thanks, >> Karen >> >> On Oct 24, 2014, at 12:40 PM, Daniel D. Daugherty wrote: >> >>> On 10/24/14 10:06 AM, Karen Kinnear wrote: >>>> Please review 8u40 backport: >>>> >>>> webrev: http://cr.openjdk.java.net/~acorn/8043275.8u40/webrev/ >>> I compared the JDK9-hs-rt version with the JDK8u40-hs version. >>> >>> src/share/vm/classfile/classFileParser.cpp >>> No comments. >>> >>> src/share/vm/classfile/classFileParser.hpp >>> No comments. >>> >>> src/share/vm/oops/instanceKlass.cpp >>> >>> 799 if (HAS_PENDING_EXCEPTION) { >>> 800 Handle e(THREAD, PENDING_EXCEPTION); >>> 801 CLEAR_PENDING_EXCEPTION; >>> 802 { >>> 803 EXCEPTION_MARK; >>> 804 // Locks object, set state, and notify all waiting >>> threads >>> 805 this_oop->set_initialization_state_and_notify( >>> 806 initialization_error, THREAD); >>> 807 >>> 808 // ignore any exception thrown, superclass >>> initialization error is >>> 809 // thrown below >>> 810 CLEAR_PENDING_EXCEPTION; >>> 811 } >>> 812 } >>> >>> The JDK9 version has this between lines 811 and 812: >>> >>> THROW_OOP(e()); >>> >>> Is there reason for the difference? >> Bad manual merge >>> src/share/vm/oops/instanceKlass.hpp >>> No comments. >>> >>> src/share/vm/utilities/dtrace_disabled.hpp >>> The JDK9 patch modified this file, but the file doesn't >>> exist in JDK8u40-hs. >> That was a comment spelling fix - I was in there for another reason >> which >> I ended up not needing. Change isn't needed in 8u40. >>> test/runtime/lambda-features/InvokespecialInterface.java >>> The @run changes already existed in JDK9 before your patch. >> I undid those >>> test/runtime/lambda-features/TestInterfaceInit.java >>> >>> The second line has a blank at the end of it: >>> >>> + public static void main(String[] args) { >>> + // Trigger initialization >> Fixed >>> test/runtime/lambda-features/TestInterfaceOrder.java >>> No comments. >>> >>> Dan >>> >>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8043275 >>>> >>>> Summary: >>>> Fix superinterface initialization to be based on declaring a >>>> non-static instance method rather than >>>> on declaring or inheriting one >>>> >>>> Tested (linux-x64) 8u40: >>>> jtreg hotspot lambda-features which includes the two new tests: >>>> TestInterfaceInit and TestInterfaceOrder >>>> InvokespecialInterface was changed to use nested classes so there >>>> is no name conflict for C.class in that directory >>>> >>>> thanks, >>>> Karen > From karen.kinnear at oracle.com Fri Oct 24 18:24:34 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 24 Oct 2014 14:24:34 -0400 Subject: RFR: 8043275 8u40 backport: Interface initialization for default methods In-Reply-To: <544A8B53.1000409@oracle.com> References: <0D035C74-97C4-454F-A219-866CCC77C318@oracle.com> <544A8109.3030005@oracle.com> <544A89AD.1010407@oracle.com> <544A8B53.1000409@oracle.com> Message-ID: <4ED26753-FA8A-42D1-9AEB-8DB632309664@oracle.com> Dan, Thank you again. Copying Coleen since the 8035132 fix was hers Yes, InvokespecialInterface.java fix was part of 8035132 which has a request on it to backport. I assumed you meant that backport should be done separately from this push so that folks tracking the backport would be clear. If I can do an hg commit with two bugids I can push that change to 8u40 as well, but I don't know if our tools will automatically update the 8035132 bug report or if we are better off leaving that change for a separate commit. I am also not backporting this change to any other version. Do you know what works best here? thanks, Karen On Oct 24, 2014, at 1:24 PM, Daniel D. Daugherty wrote: > > On 10/24/14 11:17 AM, Daniel D. Daugherty wrote: >> This URL should work: >> >> http://cr.openjdk.java.net/~acorn/8043275.8u40.2/webrev/ > > src/share/vm/classfile/classFileParser.cpp > No comments. > > src/share/vm/classfile/classFileParser.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > No comments. > > src/share/vm/oops/instanceKlass.hpp > No comments. > > test/runtime/lambda-features/InvokespecialInterface.java > Sorry, I didn't mean for you to back out this change: > > - * @run main/othervm -XX:+StressRewriter InvokespecialInterface > + * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRewriter InvokespecialInterface > > That change was not part of your JDK9 patch that bug had > been fixed in JDK9 before your changes. I think you do need > to make the above change for 8u40. > > test/runtime/lambda-features/TestInterfaceInit.java > No comments. > > test/runtime/lambda-features/TestInterfaceOrder.java > No comments. > > Dan > > > >> >> Dan >> >> >> On 10/24/14 11:05 AM, Karen Kinnear wrote: >>> Dan, >>> >>> Many many thanks - good catches! >>> >>> Updated webrev: http://cr.openjdk.java.net/~acorn/8043275.uu40.2/webrev >>> >>> thanks, >>> Karen >>> >>> On Oct 24, 2014, at 12:40 PM, Daniel D. Daugherty wrote: >>> >>>> On 10/24/14 10:06 AM, Karen Kinnear wrote: >>>>> Please review 8u40 backport: >>>>> >>>>> webrev: http://cr.openjdk.java.net/~acorn/8043275.8u40/webrev/ >>>> I compared the JDK9-hs-rt version with the JDK8u40-hs version. >>>> >>>> src/share/vm/classfile/classFileParser.cpp >>>> No comments. >>>> >>>> src/share/vm/classfile/classFileParser.hpp >>>> No comments. >>>> >>>> src/share/vm/oops/instanceKlass.cpp >>>> >>>> 799 if (HAS_PENDING_EXCEPTION) { >>>> 800 Handle e(THREAD, PENDING_EXCEPTION); >>>> 801 CLEAR_PENDING_EXCEPTION; >>>> 802 { >>>> 803 EXCEPTION_MARK; >>>> 804 // Locks object, set state, and notify all waiting threads >>>> 805 this_oop->set_initialization_state_and_notify( >>>> 806 initialization_error, THREAD); >>>> 807 >>>> 808 // ignore any exception thrown, superclass initialization error is >>>> 809 // thrown below >>>> 810 CLEAR_PENDING_EXCEPTION; >>>> 811 } >>>> 812 } >>>> >>>> The JDK9 version has this between lines 811 and 812: >>>> >>>> THROW_OOP(e()); >>>> >>>> Is there reason for the difference? >>> Bad manual merge >>>> src/share/vm/oops/instanceKlass.hpp >>>> No comments. >>>> >>>> src/share/vm/utilities/dtrace_disabled.hpp >>>> The JDK9 patch modified this file, but the file doesn't >>>> exist in JDK8u40-hs. >>> That was a comment spelling fix - I was in there for another reason which >>> I ended up not needing. Change isn't needed in 8u40. >>>> test/runtime/lambda-features/InvokespecialInterface.java >>>> The @run changes already existed in JDK9 before your patch. >>> I undid those >>>> test/runtime/lambda-features/TestInterfaceInit.java >>>> >>>> The second line has a blank at the end of it: >>>> >>>> + public static void main(String[] args) { >>>> + // Trigger initialization >>> Fixed >>>> test/runtime/lambda-features/TestInterfaceOrder.java >>>> No comments. >>>> >>>> Dan >>>> >>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8043275 >>>>> >>>>> Summary: >>>>> Fix superinterface initialization to be based on declaring a non-static instance method rather than >>>>> on declaring or inheriting one >>>>> >>>>> Tested (linux-x64) 8u40: >>>>> jtreg hotspot lambda-features which includes the two new tests: TestInterfaceInit and TestInterfaceOrder >>>>> InvokespecialInterface was changed to use nested classes so there is no name conflict for C.class in that directory >>>>> >>>>> thanks, >>>>> Karen >> > From daniel.daugherty at oracle.com Fri Oct 24 18:33:07 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 24 Oct 2014 12:33:07 -0600 Subject: RFR: 8043275 8u40 backport: Interface initialization for default methods In-Reply-To: <4ED26753-FA8A-42D1-9AEB-8DB632309664@oracle.com> References: <0D035C74-97C4-454F-A219-866CCC77C318@oracle.com> <544A8109.3030005@oracle.com> <544A89AD.1010407@oracle.com> <544A8B53.1000409@oracle.com> <4ED26753-FA8A-42D1-9AEB-8DB632309664@oracle.com> Message-ID: <544A9B63.2030401@oracle.com> On 10/24/14 12:24 PM, Karen Kinnear wrote: > Dan, > > Thank you again. Copying Coleen since the 8035132 fix was hers > > Yes, InvokespecialInterface.java fix was part of 8035132 which has a request on it to backport. > I assumed you meant that backport should be done separately from this push so that folks > tracking the backport would be clear. > > If I can do an hg commit with two bugids I can push that change to 8u40 as well, but > I don't know if our tools will automatically update the 8035132 bug report or if we are > better off leaving that change for a separate commit. If you list the two bug ID lines in same commit mesg, then both bugs will get updated when the changeset is pushed. However, if the two fixes were in distinct changesets in JDK9, then you should keep them in distinct changesets in JD8u40. You can commit one changeset, commit the second changeset and then push both changesets as part of the same JPRT job... Dan > > I am also not backporting this change to any other version. > > Do you know what works best here? > > thanks, > Karen > > On Oct 24, 2014, at 1:24 PM, Daniel D. Daugherty wrote: > >> On 10/24/14 11:17 AM, Daniel D. Daugherty wrote: >>> This URL should work: >>> >>> http://cr.openjdk.java.net/~acorn/8043275.8u40.2/webrev/ >> src/share/vm/classfile/classFileParser.cpp >> No comments. >> >> src/share/vm/classfile/classFileParser.hpp >> No comments. >> >> src/share/vm/oops/instanceKlass.cpp >> No comments. >> >> src/share/vm/oops/instanceKlass.hpp >> No comments. >> >> test/runtime/lambda-features/InvokespecialInterface.java >> Sorry, I didn't mean for you to back out this change: >> >> - * @run main/othervm -XX:+StressRewriter InvokespecialInterface >> + * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRewriter InvokespecialInterface >> >> That change was not part of your JDK9 patch that bug had >> been fixed in JDK9 before your changes. I think you do need >> to make the above change for 8u40. >> >> test/runtime/lambda-features/TestInterfaceInit.java >> No comments. >> >> test/runtime/lambda-features/TestInterfaceOrder.java >> No comments. >> >> Dan >> >> >> >>> Dan >>> >>> >>> On 10/24/14 11:05 AM, Karen Kinnear wrote: >>>> Dan, >>>> >>>> Many many thanks - good catches! >>>> >>>> Updated webrev: http://cr.openjdk.java.net/~acorn/8043275.uu40.2/webrev >>>> >>>> thanks, >>>> Karen >>>> >>>> On Oct 24, 2014, at 12:40 PM, Daniel D. Daugherty wrote: >>>> >>>>> On 10/24/14 10:06 AM, Karen Kinnear wrote: >>>>>> Please review 8u40 backport: >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~acorn/8043275.8u40/webrev/ >>>>> I compared the JDK9-hs-rt version with the JDK8u40-hs version. >>>>> >>>>> src/share/vm/classfile/classFileParser.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/classfile/classFileParser.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/oops/instanceKlass.cpp >>>>> >>>>> 799 if (HAS_PENDING_EXCEPTION) { >>>>> 800 Handle e(THREAD, PENDING_EXCEPTION); >>>>> 801 CLEAR_PENDING_EXCEPTION; >>>>> 802 { >>>>> 803 EXCEPTION_MARK; >>>>> 804 // Locks object, set state, and notify all waiting threads >>>>> 805 this_oop->set_initialization_state_and_notify( >>>>> 806 initialization_error, THREAD); >>>>> 807 >>>>> 808 // ignore any exception thrown, superclass initialization error is >>>>> 809 // thrown below >>>>> 810 CLEAR_PENDING_EXCEPTION; >>>>> 811 } >>>>> 812 } >>>>> >>>>> The JDK9 version has this between lines 811 and 812: >>>>> >>>>> THROW_OOP(e()); >>>>> >>>>> Is there reason for the difference? >>>> Bad manual merge >>>>> src/share/vm/oops/instanceKlass.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/utilities/dtrace_disabled.hpp >>>>> The JDK9 patch modified this file, but the file doesn't >>>>> exist in JDK8u40-hs. >>>> That was a comment spelling fix - I was in there for another reason which >>>> I ended up not needing. Change isn't needed in 8u40. >>>>> test/runtime/lambda-features/InvokespecialInterface.java >>>>> The @run changes already existed in JDK9 before your patch. >>>> I undid those >>>>> test/runtime/lambda-features/TestInterfaceInit.java >>>>> >>>>> The second line has a blank at the end of it: >>>>> >>>>> + public static void main(String[] args) { >>>>> + // Trigger initialization >>>> Fixed >>>>> test/runtime/lambda-features/TestInterfaceOrder.java >>>>> No comments. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8043275 >>>>>> >>>>>> Summary: >>>>>> Fix superinterface initialization to be based on declaring a non-static instance method rather than >>>>>> on declaring or inheriting one >>>>>> >>>>>> Tested (linux-x64) 8u40: >>>>>> jtreg hotspot lambda-features which includes the two new tests: TestInterfaceInit and TestInterfaceOrder >>>>>> InvokespecialInterface was changed to use nested classes so there is no name conflict for C.class in that directory >>>>>> >>>>>> thanks, >>>>>> Karen From coleen.phillimore at oracle.com Fri Oct 24 18:40:31 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 24 Oct 2014 14:40:31 -0400 Subject: RFR: 8043275 8u40 backport: Interface initialization for default methods In-Reply-To: <4ED26753-FA8A-42D1-9AEB-8DB632309664@oracle.com> References: <0D035C74-97C4-454F-A219-866CCC77C318@oracle.com> <544A8109.3030005@oracle.com> <544A89AD.1010407@oracle.com> <544A8B53.1000409@oracle.com> <4ED26753-FA8A-42D1-9AEB-8DB632309664@oracle.com> Message-ID: <544A9D1F.6080207@oracle.com> On 10/24/14, 2:24 PM, Karen Kinnear wrote: > Dan, > > Thank you again. Copying Coleen since the 8035132 fix was hers > > Yes, InvokespecialInterface.java fix was part of 8035132 which has a request on it to backport. > I assumed you meant that backport should be done separately from this push so that folks > tracking the backport would be clear. I didn't see that this had a request to backport until just now. > > If I can do an hg commit with two bugids I can push that change to 8u40 as well, but > I don't know if our tools will automatically update the 8035132 bug report or if we are > better off leaving that change for a separate commit. Dan - I think you can do a commit with two bug lines and both will get marked as resolved, please correct me if I'm wrong. > > I am also not backporting this change to any other version. > > Do you know what works best here? I don't know either. I could make the InvokespecialInterface.java changes separately and do an RFR for a backport if that helps? Or check both in with two bugid lines, which would be faster if it works. Thanks, Coleen > > thanks, > Karen > > On Oct 24, 2014, at 1:24 PM, Daniel D. Daugherty wrote: > >> On 10/24/14 11:17 AM, Daniel D. Daugherty wrote: >>> This URL should work: >>> >>> http://cr.openjdk.java.net/~acorn/8043275.8u40.2/webrev/ >> src/share/vm/classfile/classFileParser.cpp >> No comments. >> >> src/share/vm/classfile/classFileParser.hpp >> No comments. >> >> src/share/vm/oops/instanceKlass.cpp >> No comments. >> >> src/share/vm/oops/instanceKlass.hpp >> No comments. >> >> test/runtime/lambda-features/InvokespecialInterface.java >> Sorry, I didn't mean for you to back out this change: >> >> - * @run main/othervm -XX:+StressRewriter InvokespecialInterface >> + * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRewriter InvokespecialInterface >> >> That change was not part of your JDK9 patch that bug had >> been fixed in JDK9 before your changes. I think you do need >> to make the above change for 8u40. >> >> test/runtime/lambda-features/TestInterfaceInit.java >> No comments. >> >> test/runtime/lambda-features/TestInterfaceOrder.java >> No comments. >> >> Dan >> >> >> >>> Dan >>> >>> >>> On 10/24/14 11:05 AM, Karen Kinnear wrote: >>>> Dan, >>>> >>>> Many many thanks - good catches! >>>> >>>> Updated webrev: http://cr.openjdk.java.net/~acorn/8043275.uu40.2/webrev >>>> >>>> thanks, >>>> Karen >>>> >>>> On Oct 24, 2014, at 12:40 PM, Daniel D. Daugherty wrote: >>>> >>>>> On 10/24/14 10:06 AM, Karen Kinnear wrote: >>>>>> Please review 8u40 backport: >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~acorn/8043275.8u40/webrev/ >>>>> I compared the JDK9-hs-rt version with the JDK8u40-hs version. >>>>> >>>>> src/share/vm/classfile/classFileParser.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/classfile/classFileParser.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/oops/instanceKlass.cpp >>>>> >>>>> 799 if (HAS_PENDING_EXCEPTION) { >>>>> 800 Handle e(THREAD, PENDING_EXCEPTION); >>>>> 801 CLEAR_PENDING_EXCEPTION; >>>>> 802 { >>>>> 803 EXCEPTION_MARK; >>>>> 804 // Locks object, set state, and notify all waiting threads >>>>> 805 this_oop->set_initialization_state_and_notify( >>>>> 806 initialization_error, THREAD); >>>>> 807 >>>>> 808 // ignore any exception thrown, superclass initialization error is >>>>> 809 // thrown below >>>>> 810 CLEAR_PENDING_EXCEPTION; >>>>> 811 } >>>>> 812 } >>>>> >>>>> The JDK9 version has this between lines 811 and 812: >>>>> >>>>> THROW_OOP(e()); >>>>> >>>>> Is there reason for the difference? >>>> Bad manual merge >>>>> src/share/vm/oops/instanceKlass.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/utilities/dtrace_disabled.hpp >>>>> The JDK9 patch modified this file, but the file doesn't >>>>> exist in JDK8u40-hs. >>>> That was a comment spelling fix - I was in there for another reason which >>>> I ended up not needing. Change isn't needed in 8u40. >>>>> test/runtime/lambda-features/InvokespecialInterface.java >>>>> The @run changes already existed in JDK9 before your patch. >>>> I undid those >>>>> test/runtime/lambda-features/TestInterfaceInit.java >>>>> >>>>> The second line has a blank at the end of it: >>>>> >>>>> + public static void main(String[] args) { >>>>> + // Trigger initialization >>>> Fixed >>>>> test/runtime/lambda-features/TestInterfaceOrder.java >>>>> No comments. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8043275 >>>>>> >>>>>> Summary: >>>>>> Fix superinterface initialization to be based on declaring a non-static instance method rather than >>>>>> on declaring or inheriting one >>>>>> >>>>>> Tested (linux-x64) 8u40: >>>>>> jtreg hotspot lambda-features which includes the two new tests: TestInterfaceInit and TestInterfaceOrder >>>>>> InvokespecialInterface was changed to use nested classes so there is no name conflict for C.class in that directory >>>>>> >>>>>> thanks, >>>>>> Karen From coleen.phillimore at oracle.com Fri Oct 24 18:42:48 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 24 Oct 2014 14:42:48 -0400 Subject: RFR: 8043275 8u40 backport: Interface initialization for default methods In-Reply-To: <544A9D1F.6080207@oracle.com> References: <0D035C74-97C4-454F-A219-866CCC77C318@oracle.com> <544A8109.3030005@oracle.com> <544A89AD.1010407@oracle.com> <544A8B53.1000409@oracle.com> <4ED26753-FA8A-42D1-9AEB-8DB632309664@oracle.com> <544A9D1F.6080207@oracle.com> Message-ID: <544A9DA8.8080701@oracle.com> Our emails crossed. I recommend whatever Dan says... thank you in advance for pushing the backport (and additional fixes to InvokespecialInterface.java). Coleen On 10/24/14, 2:40 PM, Coleen Phillimore wrote: > > On 10/24/14, 2:24 PM, Karen Kinnear wrote: >> Dan, >> >> Thank you again. Copying Coleen since the 8035132 fix was hers >> >> Yes, InvokespecialInterface.java fix was part of 8035132 which has a >> request on it to backport. >> I assumed you meant that backport should be done separately from this >> push so that folks >> tracking the backport would be clear. > > I didn't see that this had a request to backport until just now. > >> >> If I can do an hg commit with two bugids I can push that change to >> 8u40 as well, but >> I don't know if our tools will automatically update the 8035132 bug >> report or if we are >> better off leaving that change for a separate commit. > > Dan - I think you can do a commit with two bug lines and both will get > marked as resolved, please correct me if I'm wrong. >> >> I am also not backporting this change to any other version. >> >> Do you know what works best here? > > I don't know either. I could make the InvokespecialInterface.java > changes separately and do an RFR for a backport if that helps? Or > check both in with two bugid lines, which would be faster if it works. > > Thanks, > Coleen > > >> >> thanks, >> Karen >> >> On Oct 24, 2014, at 1:24 PM, Daniel D. Daugherty wrote: >> >>> On 10/24/14 11:17 AM, Daniel D. Daugherty wrote: >>>> This URL should work: >>>> >>>> http://cr.openjdk.java.net/~acorn/8043275.8u40.2/webrev/ >>> src/share/vm/classfile/classFileParser.cpp >>> No comments. >>> >>> src/share/vm/classfile/classFileParser.hpp >>> No comments. >>> >>> src/share/vm/oops/instanceKlass.cpp >>> No comments. >>> >>> src/share/vm/oops/instanceKlass.hpp >>> No comments. >>> >>> test/runtime/lambda-features/InvokespecialInterface.java >>> Sorry, I didn't mean for you to back out this change: >>> >>> - * @run main/othervm -XX:+StressRewriter InvokespecialInterface >>> + * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions >>> -XX:+StressRewriter InvokespecialInterface >>> >>> That change was not part of your JDK9 patch that bug had >>> been fixed in JDK9 before your changes. I think you do need >>> to make the above change for 8u40. >>> >>> test/runtime/lambda-features/TestInterfaceInit.java >>> No comments. >>> >>> test/runtime/lambda-features/TestInterfaceOrder.java >>> No comments. >>> >>> Dan >>> >>> >>> >>>> Dan >>>> >>>> >>>> On 10/24/14 11:05 AM, Karen Kinnear wrote: >>>>> Dan, >>>>> >>>>> Many many thanks - good catches! >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~acorn/8043275.uu40.2/webrev >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> On Oct 24, 2014, at 12:40 PM, Daniel D. Daugherty wrote: >>>>> >>>>>> On 10/24/14 10:06 AM, Karen Kinnear wrote: >>>>>>> Please review 8u40 backport: >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~acorn/8043275.8u40/webrev/ >>>>>> I compared the JDK9-hs-rt version with the JDK8u40-hs version. >>>>>> >>>>>> src/share/vm/classfile/classFileParser.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/classfile/classFileParser.hpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/oops/instanceKlass.cpp >>>>>> >>>>>> 799 if (HAS_PENDING_EXCEPTION) { >>>>>> 800 Handle e(THREAD, PENDING_EXCEPTION); >>>>>> 801 CLEAR_PENDING_EXCEPTION; >>>>>> 802 { >>>>>> 803 EXCEPTION_MARK; >>>>>> 804 // Locks object, set state, and notify all >>>>>> waiting threads >>>>>> 805 this_oop->set_initialization_state_and_notify( >>>>>> 806 initialization_error, THREAD); >>>>>> 807 >>>>>> 808 // ignore any exception thrown, superclass >>>>>> initialization error is >>>>>> 809 // thrown below >>>>>> 810 CLEAR_PENDING_EXCEPTION; >>>>>> 811 } >>>>>> 812 } >>>>>> >>>>>> The JDK9 version has this between lines 811 and 812: >>>>>> >>>>>> THROW_OOP(e()); >>>>>> >>>>>> Is there reason for the difference? >>>>> Bad manual merge >>>>>> src/share/vm/oops/instanceKlass.hpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/utilities/dtrace_disabled.hpp >>>>>> The JDK9 patch modified this file, but the file doesn't >>>>>> exist in JDK8u40-hs. >>>>> That was a comment spelling fix - I was in there for another >>>>> reason which >>>>> I ended up not needing. Change isn't needed in 8u40. >>>>>> test/runtime/lambda-features/InvokespecialInterface.java >>>>>> The @run changes already existed in JDK9 before your patch. >>>>> I undid those >>>>>> test/runtime/lambda-features/TestInterfaceInit.java >>>>>> >>>>>> The second line has a blank at the end of it: >>>>>> >>>>>> + public static void main(String[] args) { >>>>>> + // Trigger initialization >>>>> Fixed >>>>>> test/runtime/lambda-features/TestInterfaceOrder.java >>>>>> No comments. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8043275 >>>>>>> >>>>>>> Summary: >>>>>>> Fix superinterface initialization to be based on declaring a >>>>>>> non-static instance method rather than >>>>>>> on declaring or inheriting one >>>>>>> >>>>>>> Tested (linux-x64) 8u40: >>>>>>> jtreg hotspot lambda-features which includes the two new tests: >>>>>>> TestInterfaceInit and TestInterfaceOrder >>>>>>> InvokespecialInterface was changed to use nested classes so >>>>>>> there is no name conflict for C.class in that directory >>>>>>> >>>>>>> thanks, >>>>>>> Karen > From coleen.phillimore at oracle.com Fri Oct 24 19:28:01 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 24 Oct 2014 15:28:01 -0400 Subject: RFR: 8043275 8u40 backport: Interface initialization for default methods In-Reply-To: <4ED26753-FA8A-42D1-9AEB-8DB632309664@oracle.com> References: <0D035C74-97C4-454F-A219-866CCC77C318@oracle.com> <544A8109.3030005@oracle.com> <544A89AD.1010407@oracle.com> <544A8B53.1000409@oracle.com> <4ED26753-FA8A-42D1-9AEB-8DB632309664@oracle.com> Message-ID: <544AA841.9070104@oracle.com> I have reviewed these changes and they look fine. Coleen On 10/24/14, 2:24 PM, Karen Kinnear wrote: > Dan, > > Thank you again. Copying Coleen since the 8035132 fix was hers > > Yes, InvokespecialInterface.java fix was part of 8035132 which has a request on it to backport. > I assumed you meant that backport should be done separately from this push so that folks > tracking the backport would be clear. > > If I can do an hg commit with two bugids I can push that change to 8u40 as well, but > I don't know if our tools will automatically update the 8035132 bug report or if we are > better off leaving that change for a separate commit. > > I am also not backporting this change to any other version. > > Do you know what works best here? > > thanks, > Karen > > On Oct 24, 2014, at 1:24 PM, Daniel D. Daugherty wrote: > >> On 10/24/14 11:17 AM, Daniel D. Daugherty wrote: >>> This URL should work: >>> >>> http://cr.openjdk.java.net/~acorn/8043275.8u40.2/webrev/ >> src/share/vm/classfile/classFileParser.cpp >> No comments. >> >> src/share/vm/classfile/classFileParser.hpp >> No comments. >> >> src/share/vm/oops/instanceKlass.cpp >> No comments. >> >> src/share/vm/oops/instanceKlass.hpp >> No comments. >> >> test/runtime/lambda-features/InvokespecialInterface.java >> Sorry, I didn't mean for you to back out this change: >> >> - * @run main/othervm -XX:+StressRewriter InvokespecialInterface >> + * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRewriter InvokespecialInterface >> >> That change was not part of your JDK9 patch that bug had >> been fixed in JDK9 before your changes. I think you do need >> to make the above change for 8u40. >> >> test/runtime/lambda-features/TestInterfaceInit.java >> No comments. >> >> test/runtime/lambda-features/TestInterfaceOrder.java >> No comments. >> >> Dan >> >> >> >>> Dan >>> >>> >>> On 10/24/14 11:05 AM, Karen Kinnear wrote: >>>> Dan, >>>> >>>> Many many thanks - good catches! >>>> >>>> Updated webrev: http://cr.openjdk.java.net/~acorn/8043275.uu40.2/webrev >>>> >>>> thanks, >>>> Karen >>>> >>>> On Oct 24, 2014, at 12:40 PM, Daniel D. Daugherty wrote: >>>> >>>>> On 10/24/14 10:06 AM, Karen Kinnear wrote: >>>>>> Please review 8u40 backport: >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~acorn/8043275.8u40/webrev/ >>>>> I compared the JDK9-hs-rt version with the JDK8u40-hs version. >>>>> >>>>> src/share/vm/classfile/classFileParser.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/classfile/classFileParser.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/oops/instanceKlass.cpp >>>>> >>>>> 799 if (HAS_PENDING_EXCEPTION) { >>>>> 800 Handle e(THREAD, PENDING_EXCEPTION); >>>>> 801 CLEAR_PENDING_EXCEPTION; >>>>> 802 { >>>>> 803 EXCEPTION_MARK; >>>>> 804 // Locks object, set state, and notify all waiting threads >>>>> 805 this_oop->set_initialization_state_and_notify( >>>>> 806 initialization_error, THREAD); >>>>> 807 >>>>> 808 // ignore any exception thrown, superclass initialization error is >>>>> 809 // thrown below >>>>> 810 CLEAR_PENDING_EXCEPTION; >>>>> 811 } >>>>> 812 } >>>>> >>>>> The JDK9 version has this between lines 811 and 812: >>>>> >>>>> THROW_OOP(e()); >>>>> >>>>> Is there reason for the difference? >>>> Bad manual merge >>>>> src/share/vm/oops/instanceKlass.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/utilities/dtrace_disabled.hpp >>>>> The JDK9 patch modified this file, but the file doesn't >>>>> exist in JDK8u40-hs. >>>> That was a comment spelling fix - I was in there for another reason which >>>> I ended up not needing. Change isn't needed in 8u40. >>>>> test/runtime/lambda-features/InvokespecialInterface.java >>>>> The @run changes already existed in JDK9 before your patch. >>>> I undid those >>>>> test/runtime/lambda-features/TestInterfaceInit.java >>>>> >>>>> The second line has a blank at the end of it: >>>>> >>>>> + public static void main(String[] args) { >>>>> + // Trigger initialization >>>> Fixed >>>>> test/runtime/lambda-features/TestInterfaceOrder.java >>>>> No comments. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8043275 >>>>>> >>>>>> Summary: >>>>>> Fix superinterface initialization to be based on declaring a non-static instance method rather than >>>>>> on declaring or inheriting one >>>>>> >>>>>> Tested (linux-x64) 8u40: >>>>>> jtreg hotspot lambda-features which includes the two new tests: TestInterfaceInit and TestInterfaceOrder >>>>>> InvokespecialInterface was changed to use nested classes so there is no name conflict for C.class in that directory >>>>>> >>>>>> thanks, >>>>>> Karen From vladimir.kozlov at oracle.com Fri Oct 24 19:28:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Oct 2014 12:28:58 -0700 Subject: [9] and [8u40] ports RFR (S): 8049542 and 8054530 Message-ID: <544AA87A.9070101@oracle.com> Request to forward port fixes we did only in 7u. Fixes were done 2 months ago. Changes are applied cleanly. http://cr.openjdk.java.net/~morris/8054530.02/ https://bugs.openjdk.java.net/browse/JDK-8054530 http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/612e0c2ebea4 http://cr.openjdk.java.net/~kvn/8049542/webrev https://bugs.openjdk.java.net/browse/JDK-8049542 http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/16f41a7c5c28 Thanks, Vladimir From igor.veresov at oracle.com Sat Oct 25 11:17:02 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Sat, 25 Oct 2014 01:17:02 -1000 Subject: [9] and [8u40] ports RFR (S): 8049542 and 8054530 In-Reply-To: <544AA87A.9070101@oracle.com> References: <544AA87A.9070101@oracle.com> Message-ID: Looks good. igor On Oct 24, 2014, at 9:28 AM, Vladimir Kozlov wrote: > Request to forward port fixes we did only in 7u. Fixes were done 2 months ago. Changes are applied cleanly. > > http://cr.openjdk.java.net/~morris/8054530.02/ > https://bugs.openjdk.java.net/browse/JDK-8054530 > http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/612e0c2ebea4 > > http://cr.openjdk.java.net/~kvn/8049542/webrev > https://bugs.openjdk.java.net/browse/JDK-8049542 > http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/16f41a7c5c28 > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Sat Oct 25 18:24:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 25 Oct 2014 11:24:26 -0700 Subject: [9] and [8u40] ports RFR (S): 8049542 and 8054530 In-Reply-To: References: <544AA87A.9070101@oracle.com> Message-ID: <544BEADA.803@oracle.com> Thank you, Igor Vladimir On 10/25/14 4:17 AM, Igor Veresov wrote: > Looks good. > > igor > > On Oct 24, 2014, at 9:28 AM, Vladimir Kozlov wrote: > >> Request to forward port fixes we did only in 7u. Fixes were done 2 months ago. Changes are applied cleanly. >> >> http://cr.openjdk.java.net/~morris/8054530.02/ >> https://bugs.openjdk.java.net/browse/JDK-8054530 >> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/612e0c2ebea4 >> >> http://cr.openjdk.java.net/~kvn/8049542/webrev >> https://bugs.openjdk.java.net/browse/JDK-8049542 >> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/16f41a7c5c28 >> >> Thanks, >> Vladimir > From igor.veresov at oracle.com Tue Oct 28 21:11:57 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 28 Oct 2014 11:11:57 -1000 Subject: [8u] backport request for 8047383, 8059200 Message-ID: 8059200: Promoted JDK9 b31 for Solaris-amd64 fails (Error: dl failure on line 744, no picl library) on Solaris 11.1 JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/d0e59d57dda2 Webrev: http://cr.openjdk.java.net/~iveresov/8059200/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8059200 8047383: SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions. JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0385cbc59f3b Webrev: http://cr.openjdk.java.net/~iveresov/8047383/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8047383 Thanks, igor From vladimir.kozlov at oracle.com Tue Oct 28 21:34:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Oct 2014 14:34:01 -0700 Subject: [8u] backport request for 8047383, 8059200 In-Reply-To: References: Message-ID: <54500BC9.4020109@oracle.com> Looks good. Thanks, Vladimir On 10/28/14 2:11 PM, Igor Veresov wrote: > 8059200: Promoted JDK9 b31 for Solaris-amd64 fails (Error: dl failure on line 744, no picl library) on Solaris 11.1 > JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/d0e59d57dda2 > Webrev: http://cr.openjdk.java.net/~iveresov/8059200/webrev.01/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8059200 > > 8047383: SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions. > JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0385cbc59f3b > Webrev: http://cr.openjdk.java.net/~iveresov/8047383/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8047383 > > Thanks, > igor > From igor.veresov at oracle.com Tue Oct 28 23:12:27 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 28 Oct 2014 13:12:27 -1000 Subject: [8u] backport request for 8047383, 8059200 In-Reply-To: <54500BC9.4020109@oracle.com> References: <54500BC9.4020109@oracle.com> Message-ID: Thanks, Vladimir! igor > On Oct 28, 2014, at 11:34 AM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > >> On 10/28/14 2:11 PM, Igor Veresov wrote: >> 8059200: Promoted JDK9 b31 for Solaris-amd64 fails (Error: dl failure on line 744, no picl library) on Solaris 11.1 >> JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/d0e59d57dda2 >> Webrev: http://cr.openjdk.java.net/~iveresov/8059200/webrev.01/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8059200 >> >> 8047383: SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions. >> JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0385cbc59f3b >> Webrev: http://cr.openjdk.java.net/~iveresov/8047383/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8047383 >> >> Thanks, >> igor >> From serguei.spitsyn at oracle.com Wed Oct 29 01:11:30 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Oct 2014 18:11:30 -0700 Subject: RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) Message-ID: <54503EC2.6070601@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-6988950 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ Summary: The failing scenario: The debugger and the debuggee are well aware a VM shutdown has been started in the target process. The debugger at this point is not expected to send any commands to the JDWP agent. However, the JDI layer (debugger side) and the jdwp agent (debuggee side) are not in sync with the consumer layers. One reason is because the test debugger does not invoke the JDI method VirtualMachine.dispose(). Another reason is that the Debugger and the debuggee processes are uneasy to sync in general. As a result the following steps are possible: - The test debugger sends a 'quit' command to the test debuggee - The debuggee is normally exiting - The jdwp backend reports (over the jdwp protocol) an anonymous class unload event - The JDI InternalEventHandler thread handles the ClassUnloadEvent event - The InternalEventHandler wants to uncache the matching reference type. If there is more than one class with the same host class signature, it can't distinguish them, and so, deletes all references and re-retrieves them again (see tracing below): MY_TRACE: JDI: VirtualMachineImpl.retrieveClassesBySignature: sig=Ljava/lang/invoke/LambdaForm$DMH; - The jdwp backend debugLoop_run() gets the command from JDI and calls the functions classesForSignature() and classStatus() recursively. - The classStatus() makes a call to the JVMTI GetClassStatus() and gets the JVMTI_ERROR_WRONG_PHASE - As a result the jdwp backend reports the JVMTI error to the JDI, and so, the test fails For details, see the analysis in bug report closed as a dup of the bug 6988950: https://bugs.openjdk.java.net/browse/JDK-8024865 Some similar cases can be found in the two bug reports (6988950 and 8024865) describing this issue. The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as it is normal at the VM shutdown. The original jdwp backend implementation had a similar approach for the raw monitor functions. Threy use the ignore_vm_death() to workaround the JVMTI_ERROR_WRONG_PHASE errors. For reference, please, see the file: src/share/back/util.c Testing: Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests Thanks, Serguei From staffan.larsen at oracle.com Wed Oct 29 11:52:52 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 29 Oct 2014 12:52:52 +0100 Subject: RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <54503EC2.6070601@oracle.com> References: <54503EC2.6070601@oracle.com> Message-ID: This looks good - and thanks for the detailed description! My only comment is that you chose to ignore the error in only some of the methods - I assume these were the methods where you have encountered a problem in. Should we write a comment about that, or should we ignore the error in all methods? /Staffan On 29 okt 2014, at 02:11, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6988950 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ > > > Summary: > > The failing scenario: > The debugger and the debuggee are well aware a VM shutdown has been started in the target process. > The debugger at this point is not expected to send any commands to the JDWP agent. > However, the JDI layer (debugger side) and the jdwp agent (debuggee side) > are not in sync with the consumer layers. > > One reason is because the test debugger does not invoke the JDI method VirtualMachine.dispose(). > Another reason is that the Debugger and the debuggee processes are uneasy to sync in general. > > As a result the following steps are possible: > - The test debugger sends a 'quit' command to the test debuggee > - The debuggee is normally exiting > - The jdwp backend reports (over the jdwp protocol) an anonymous class unload event > - The JDI InternalEventHandler thread handles the ClassUnloadEvent event > - The InternalEventHandler wants to uncache the matching reference type. > If there is more than one class with the same host class signature, it can't distinguish them, > and so, deletes all references and re-retrieves them again (see tracing below): > MY_TRACE: JDI: VirtualMachineImpl.retrieveClassesBySignature: sig=Ljava/lang/invoke/LambdaForm$DMH; > - The jdwp backend debugLoop_run() gets the command from JDI and calls the functions > classesForSignature() and classStatus() recursively. > - The classStatus() makes a call to the JVMTI GetClassStatus() and gets the JVMTI_ERROR_WRONG_PHASE > - As a result the jdwp backend reports the JVMTI error to the JDI, and so, the test fails > > For details, see the analysis in bug report closed as a dup of the bug 6988950: > https://bugs.openjdk.java.net/browse/JDK-8024865 > > Some similar cases can be found in the two bug reports (6988950 and 8024865) describing this issue. > > The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as it is normal at the VM shutdown. > The original jdwp backend implementation had a similar approach for the raw monitor functions. > Threy use the ignore_vm_death() to workaround the JVMTI_ERROR_WRONG_PHASE errors. > For reference, please, see the file: src/share/back/util.c > > > Testing: > Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests > > > Thanks, > Serguei > From tobias.hartmann at oracle.com Wed Oct 29 12:27:39 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 29 Oct 2014 13:27:39 +0100 Subject: [8u40] Bulk backport request: 8046268, 8060454, 8061486, 8061983 Message-ID: <5450DD3B.3010204@oracle.com> Hi, please review this bulk request to backport the following fixes for the Whitebox API tests into 8u40. For 8046268 I had to remove the "- * @ignore 8046268" changes because the tests were not quarantined in 8u40. New webrev for this fix: http://cr.openjdk.java.net/~thartmann/8046268_8u/webrev.00/ The other changes apply cleanly. Nightly testing showed no problems. (1) 8046268: compiler/whitebox/ tests fail : must be osr_compiled https://bugs.openjdk.java.net/browse/JDK-8046268 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2b1ea93ea45e (2) 8060454: [TESTBUG] Whitebox tests fail with -XX:CompileThreshold=100 https://bugs.openjdk.java.net/browse/JDK-8060454 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/400c6e3c13a4 (3) 061486: [TESTBUG] compiler/whitebox/ tests fail : must be osr_compiled (reappeared in nightlies) https://bugs.openjdk.java.net/browse/JDK-8061486 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a754d0298071 (4) 8061983: [TESTBUG] compiler/whitebox/MakeMethodNotCompilableTest.java fails with "must not be in queue" https://bugs.openjdk.java.net/browse/JDK-8061983 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c2c9379993da Thanks, Tobias From daniel.daugherty at oracle.com Wed Oct 29 13:46:37 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 29 Oct 2014 07:46:37 -0600 Subject: RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <54503EC2.6070601@oracle.com> References: <54503EC2.6070601@oracle.com> Message-ID: <5450EFBD.8060504@oracle.com> Serguei, Do you have a scenario for the non-anonymous class case? This bug (6988950) has been around much longer than anonymous classes... Dan On 10/28/14 7:11 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6988950 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ > > > > Summary: > > The failing scenario: > The debugger and the debuggee are well aware a VM shutdown has > been started in the target process. > The debugger at this point is not expected to send any commands > to the JDWP agent. > However, the JDI layer (debugger side) and the jdwp agent > (debuggee side) > are not in sync with the consumer layers. > > One reason is because the test debugger does not invoke the JDI > method VirtualMachine.dispose(). > Another reason is that the Debugger and the debuggee processes > are uneasy to sync in general. > > As a result the following steps are possible: > - The test debugger sends a 'quit' command to the test debuggee > - The debuggee is normally exiting > - The jdwp backend reports (over the jdwp protocol) an > anonymous class unload event > - The JDI InternalEventHandler thread handles the > ClassUnloadEvent event > - The InternalEventHandler wants to uncache the matching > reference type. > If there is more than one class with the same host class > signature, it can't distinguish them, > and so, deletes all references and re-retrieves them again > (see tracing below): > MY_TRACE: JDI: > VirtualMachineImpl.retrieveClassesBySignature: > sig=Ljava/lang/invoke/LambdaForm$DMH; > - The jdwp backend debugLoop_run() gets the command from JDI > and calls the functions > classesForSignature() and classStatus() recursively. > - The classStatus() makes a call to the JVMTI GetClassStatus() > and gets the JVMTI_ERROR_WRONG_PHASE > - As a result the jdwp backend reports the JVMTI error to the > JDI, and so, the test fails > > For details, see the analysis in bug report closed as a dup of > the bug 6988950: > https://bugs.openjdk.java.net/browse/JDK-8024865 > > Some similar cases can be found in the two bug reports (6988950 > and 8024865) describing this issue. > > The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as > it is normal at the VM shutdown. > The original jdwp backend implementation had a similar approach > for the raw monitor functions. > Threy use the ignore_vm_death() to workaround the > JVMTI_ERROR_WRONG_PHASE errors. > For reference, please, see the file: src/share/back/util.c > > > Testing: > Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests > > > Thanks, > Serguei > From dmitry.samersoff at oracle.com Wed Oct 29 13:59:32 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 29 Oct 2014 16:59:32 +0300 Subject: RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <54503EC2.6070601@oracle.com> References: <54503EC2.6070601@oracle.com> Message-ID: <5450F2C4.9020604@oracle.com> Serguei, What happens in a caller function if we ignore the error? e. g. getMethodClass has the code: ... error = methodClass(method, &clazz); if ( error != JVMTI_ERROR_NONE ) { EXIT_ERROR(error,"Can't get jclass for a methodID, invalid?"); return NULL; } return clazz; after the fix it probably will return NULL. Is it correct? -Dmitry On 2014-10-29 04:11, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6988950 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ > > > > Summary: > > The failing scenario: > The debugger and the debuggee are well aware a VM shutdown has been > started in the target process. > The debugger at this point is not expected to send any commands to > the JDWP agent. > However, the JDI layer (debugger side) and the jdwp agent (debuggee > side) > are not in sync with the consumer layers. > > One reason is because the test debugger does not invoke the JDI > method VirtualMachine.dispose(). > Another reason is that the Debugger and the debuggee processes are > uneasy to sync in general. > > As a result the following steps are possible: > - The test debugger sends a 'quit' command to the test debuggee > - The debuggee is normally exiting > - The jdwp backend reports (over the jdwp protocol) an anonymous > class unload event > - The JDI InternalEventHandler thread handles the > ClassUnloadEvent event > - The InternalEventHandler wants to uncache the matching > reference type. > If there is more than one class with the same host class > signature, it can't distinguish them, > and so, deletes all references and re-retrieves them again (see > tracing below): > MY_TRACE: JDI: VirtualMachineImpl.retrieveClassesBySignature: > sig=Ljava/lang/invoke/LambdaForm$DMH; > - The jdwp backend debugLoop_run() gets the command from JDI and > calls the functions > classesForSignature() and classStatus() recursively. > - The classStatus() makes a call to the JVMTI GetClassStatus() > and gets the JVMTI_ERROR_WRONG_PHASE > - As a result the jdwp backend reports the JVMTI error to the > JDI, and so, the test fails > > For details, see the analysis in bug report closed as a dup of the > bug 6988950: > https://bugs.openjdk.java.net/browse/JDK-8024865 > > Some similar cases can be found in the two bug reports (6988950 and > 8024865) describing this issue. > > The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as > it is normal at the VM shutdown. > The original jdwp backend implementation had a similar approach for > the raw monitor functions. > Threy use the ignore_vm_death() to workaround the > JVMTI_ERROR_WRONG_PHASE errors. > For reference, please, see the file: src/share/back/util.c > > > Testing: > Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests > > > Thanks, > Serguei > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Wed Oct 29 14:09:14 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Oct 2014 07:09:14 -0700 Subject: RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <5450EFBD.8060504@oracle.com> References: <54503EC2.6070601@oracle.com> <5450EFBD.8060504@oracle.com> Message-ID: <5450F50A.7070903@oracle.com> Dan, I do not have a scenario for non-anonymous class case while they should exist. The anonymous scenario was well reproducible in a range of the jdk8 ea builds. However, it is not as such anymore. I was not able to reproduce it in jdk9, nor 8u40. But I believe the shutdown race issue is still there and can hit anytime. Thanks, Serguei On 10/29/14 6:46 AM, Daniel D. Daugherty wrote: > Serguei, > > Do you have a scenario for the non-anonymous class case? This bug > (6988950) has been around much longer than anonymous classes... > > Dan > > > On 10/28/14 7:11 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6988950 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >> >> >> >> Summary: >> >> The failing scenario: >> The debugger and the debuggee are well aware a VM shutdown has >> been started in the target process. >> The debugger at this point is not expected to send any commands >> to the JDWP agent. >> However, the JDI layer (debugger side) and the jdwp agent >> (debuggee side) >> are not in sync with the consumer layers. >> >> One reason is because the test debugger does not invoke the JDI >> method VirtualMachine.dispose(). >> Another reason is that the Debugger and the debuggee processes >> are uneasy to sync in general. >> >> As a result the following steps are possible: >> - The test debugger sends a 'quit' command to the test debuggee >> - The debuggee is normally exiting >> - The jdwp backend reports (over the jdwp protocol) an >> anonymous class unload event >> - The JDI InternalEventHandler thread handles the >> ClassUnloadEvent event >> - The InternalEventHandler wants to uncache the matching >> reference type. >> If there is more than one class with the same host class >> signature, it can't distinguish them, >> and so, deletes all references and re-retrieves them again >> (see tracing below): >> MY_TRACE: JDI: >> VirtualMachineImpl.retrieveClassesBySignature: >> sig=Ljava/lang/invoke/LambdaForm$DMH; >> - The jdwp backend debugLoop_run() gets the command from JDI >> and calls the functions >> classesForSignature() and classStatus() recursively. >> - The classStatus() makes a call to the JVMTI GetClassStatus() >> and gets the JVMTI_ERROR_WRONG_PHASE >> - As a result the jdwp backend reports the JVMTI error to the >> JDI, and so, the test fails >> >> For details, see the analysis in bug report closed as a dup of >> the bug 6988950: >> https://bugs.openjdk.java.net/browse/JDK-8024865 >> >> Some similar cases can be found in the two bug reports (6988950 >> and 8024865) describing this issue. >> >> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error >> as it is normal at the VM shutdown. >> The original jdwp backend implementation had a similar approach >> for the raw monitor functions. >> Threy use the ignore_vm_death() to workaround the >> JVMTI_ERROR_WRONG_PHASE errors. >> For reference, please, see the file: src/share/back/util.c >> >> >> Testing: >> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Wed Oct 29 14:14:16 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Oct 2014 07:14:16 -0700 Subject: RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: References: <54503EC2.6070601@oracle.com> Message-ID: <5450F638.70503@oracle.com> Staffan, Thank you for the review! I agree that maybe it'd make sense to ignore in all functions. But I'm trying to be careful - let's see if this approach works first. It is a good idea to add a comment. Thanks, Serguei On 10/29/14 4:52 AM, Staffan Larsen wrote: > This looks good - and thanks for the detailed description! > > My only comment is that you chose to ignore the error in only some of the methods - I assume these were the methods where you have encountered a problem in. Should we write a comment about that, or should we ignore the error in all methods? > > /Staffan > > On 29 okt 2014, at 02:11, serguei.spitsyn at oracle.com wrote: > >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6988950 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >> >> >> Summary: >> >> The failing scenario: >> The debugger and the debuggee are well aware a VM shutdown has been started in the target process. >> The debugger at this point is not expected to send any commands to the JDWP agent. >> However, the JDI layer (debugger side) and the jdwp agent (debuggee side) >> are not in sync with the consumer layers. >> >> One reason is because the test debugger does not invoke the JDI method VirtualMachine.dispose(). >> Another reason is that the Debugger and the debuggee processes are uneasy to sync in general. >> >> As a result the following steps are possible: >> - The test debugger sends a 'quit' command to the test debuggee >> - The debuggee is normally exiting >> - The jdwp backend reports (over the jdwp protocol) an anonymous class unload event >> - The JDI InternalEventHandler thread handles the ClassUnloadEvent event >> - The InternalEventHandler wants to uncache the matching reference type. >> If there is more than one class with the same host class signature, it can't distinguish them, >> and so, deletes all references and re-retrieves them again (see tracing below): >> MY_TRACE: JDI: VirtualMachineImpl.retrieveClassesBySignature: sig=Ljava/lang/invoke/LambdaForm$DMH; >> - The jdwp backend debugLoop_run() gets the command from JDI and calls the functions >> classesForSignature() and classStatus() recursively. >> - The classStatus() makes a call to the JVMTI GetClassStatus() and gets the JVMTI_ERROR_WRONG_PHASE >> - As a result the jdwp backend reports the JVMTI error to the JDI, and so, the test fails >> >> For details, see the analysis in bug report closed as a dup of the bug 6988950: >> https://bugs.openjdk.java.net/browse/JDK-8024865 >> >> Some similar cases can be found in the two bug reports (6988950 and 8024865) describing this issue. >> >> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as it is normal at the VM shutdown. >> The original jdwp backend implementation had a similar approach for the raw monitor functions. >> Threy use the ignore_vm_death() to workaround the JVMTI_ERROR_WRONG_PHASE errors. >> For reference, please, see the file: src/share/back/util.c >> >> >> Testing: >> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >> >> >> Thanks, >> Serguei >> From serguei.spitsyn at oracle.com Wed Oct 29 14:35:30 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Oct 2014 07:35:30 -0700 Subject: RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <5450F2C4.9020604@oracle.com> References: <54503EC2.6070601@oracle.com> <5450F2C4.9020604@oracle.com> Message-ID: <5450FB32.4020602@oracle.com> Dmitry, Yes, it will return NULL if the case of JVMTI_ERROR_WRONG_PHASE error. It is Ok for the getMethodClass() as the NULL return value listed in the comment. It seems to be Ok for other two uses of the methodClass(). Thanks! Serguei On 10/29/14 6:59 AM, Dmitry Samersoff wrote: > Serguei, > > What happens in a caller function if we ignore the error? > > e. g. getMethodClass has the code: > ... > > error = methodClass(method, &clazz); > if ( error != JVMTI_ERROR_NONE ) { > EXIT_ERROR(error,"Can't get jclass for a methodID, invalid?"); > return NULL; > } > return clazz; > > after the fix it probably will return NULL. Is it correct? > > -Dmitry > > On 2014-10-29 04:11, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6988950 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >> >> >> >> Summary: >> >> The failing scenario: >> The debugger and the debuggee are well aware a VM shutdown has been >> started in the target process. >> The debugger at this point is not expected to send any commands to >> the JDWP agent. >> However, the JDI layer (debugger side) and the jdwp agent (debuggee >> side) >> are not in sync with the consumer layers. >> >> One reason is because the test debugger does not invoke the JDI >> method VirtualMachine.dispose(). >> Another reason is that the Debugger and the debuggee processes are >> uneasy to sync in general. >> >> As a result the following steps are possible: >> - The test debugger sends a 'quit' command to the test debuggee >> - The debuggee is normally exiting >> - The jdwp backend reports (over the jdwp protocol) an anonymous >> class unload event >> - The JDI InternalEventHandler thread handles the >> ClassUnloadEvent event >> - The InternalEventHandler wants to uncache the matching >> reference type. >> If there is more than one class with the same host class >> signature, it can't distinguish them, >> and so, deletes all references and re-retrieves them again (see >> tracing below): >> MY_TRACE: JDI: VirtualMachineImpl.retrieveClassesBySignature: >> sig=Ljava/lang/invoke/LambdaForm$DMH; >> - The jdwp backend debugLoop_run() gets the command from JDI and >> calls the functions >> classesForSignature() and classStatus() recursively. >> - The classStatus() makes a call to the JVMTI GetClassStatus() >> and gets the JVMTI_ERROR_WRONG_PHASE >> - As a result the jdwp backend reports the JVMTI error to the >> JDI, and so, the test fails >> >> For details, see the analysis in bug report closed as a dup of the >> bug 6988950: >> https://bugs.openjdk.java.net/browse/JDK-8024865 >> >> Some similar cases can be found in the two bug reports (6988950 and >> 8024865) describing this issue. >> >> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as >> it is normal at the VM shutdown. >> The original jdwp backend implementation had a similar approach for >> the raw monitor functions. >> Threy use the ignore_vm_death() to workaround the >> JVMTI_ERROR_WRONG_PHASE errors. >> For reference, please, see the file: src/share/back/util.c >> >> >> Testing: >> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Wed Oct 29 14:39:17 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Oct 2014 07:39:17 -0700 Subject: RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <5450FB32.4020602@oracle.com> References: <54503EC2.6070601@oracle.com> <5450F2C4.9020604@oracle.com> <5450FB32.4020602@oracle.com> Message-ID: <5450FC15.4080807@oracle.com> On 10/29/14 7:35 AM, serguei.spitsyn at oracle.com wrote: > Dmitry, > > Yes, it will return NULL if the case of JVMTI_ERROR_WRONG_PHASE error. A typo above: "if the case" => "in the case" Thanks, Serguei > It is Ok for the getMethodClass() as the NULL return value listed in > the comment. > It seems to be Ok for other two uses of the methodClass(). > > Thanks! > Serguei > > On 10/29/14 6:59 AM, Dmitry Samersoff wrote: >> Serguei, >> >> What happens in a caller function if we ignore the error? >> >> e. g. getMethodClass has the code: >> ... >> >> error = methodClass(method, &clazz); >> if ( error != JVMTI_ERROR_NONE ) { >> EXIT_ERROR(error,"Can't get jclass for a methodID, invalid?"); >> return NULL; >> } >> return clazz; >> >> after the fix it probably will return NULL. Is it correct? >> >> -Dmitry >> >> On 2014-10-29 04:11, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>> >>> >>> >>> >>> Summary: >>> >>> The failing scenario: >>> The debugger and the debuggee are well aware a VM shutdown has >>> been >>> started in the target process. >>> The debugger at this point is not expected to send any >>> commands to >>> the JDWP agent. >>> However, the JDI layer (debugger side) and the jdwp agent >>> (debuggee >>> side) >>> are not in sync with the consumer layers. >>> >>> One reason is because the test debugger does not invoke the JDI >>> method VirtualMachine.dispose(). >>> Another reason is that the Debugger and the debuggee processes >>> are >>> uneasy to sync in general. >>> >>> As a result the following steps are possible: >>> - The test debugger sends a 'quit' command to the test debuggee >>> - The debuggee is normally exiting >>> - The jdwp backend reports (over the jdwp protocol) an >>> anonymous >>> class unload event >>> - The JDI InternalEventHandler thread handles the >>> ClassUnloadEvent event >>> - The InternalEventHandler wants to uncache the matching >>> reference type. >>> If there is more than one class with the same host class >>> signature, it can't distinguish them, >>> and so, deletes all references and re-retrieves them again >>> (see >>> tracing below): >>> MY_TRACE: JDI: >>> VirtualMachineImpl.retrieveClassesBySignature: >>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>> - The jdwp backend debugLoop_run() gets the command from JDI >>> and >>> calls the functions >>> classesForSignature() and classStatus() recursively. >>> - The classStatus() makes a call to the JVMTI GetClassStatus() >>> and gets the JVMTI_ERROR_WRONG_PHASE >>> - As a result the jdwp backend reports the JVMTI error to the >>> JDI, and so, the test fails >>> >>> For details, see the analysis in bug report closed as a dup of >>> the >>> bug 6988950: >>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>> >>> Some similar cases can be found in the two bug reports >>> (6988950 and >>> 8024865) describing this issue. >>> >>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as >>> it is normal at the VM shutdown. >>> The original jdwp backend implementation had a similar >>> approach for >>> the raw monitor functions. >>> Threy use the ignore_vm_death() to workaround the >>> JVMTI_ERROR_WRONG_PHASE errors. >>> For reference, please, see the file: src/share/back/util.c >>> >>> >>> Testing: >>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >> > From dmitry.samersoff at oracle.com Wed Oct 29 14:50:53 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 29 Oct 2014 17:50:53 +0300 Subject: RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <5450FB32.4020602@oracle.com> References: <54503EC2.6070601@oracle.com> <5450F2C4.9020604@oracle.com> <5450FB32.4020602@oracle.com> Message-ID: <5450FECD.3010504@oracle.com> Serguei, Thank you! Fix looks good for me. -Dmitry On 2014-10-29 17:35, serguei.spitsyn at oracle.com wrote: > Dmitry, > > Yes, it will return NULL if the case of JVMTI_ERROR_WRONG_PHASE error. > It is Ok for the getMethodClass() as the NULL return value listed in the > comment. > It seems to be Ok for other two uses of the methodClass(). > > Thanks! > Serguei > > On 10/29/14 6:59 AM, Dmitry Samersoff wrote: >> Serguei, >> >> What happens in a caller function if we ignore the error? >> >> e. g. getMethodClass has the code: >> ... >> >> error = methodClass(method, &clazz); >> if ( error != JVMTI_ERROR_NONE ) { >> EXIT_ERROR(error,"Can't get jclass for a methodID, invalid?"); >> return NULL; >> } >> return clazz; >> >> after the fix it probably will return NULL. Is it correct? >> >> -Dmitry >> >> On 2014-10-29 04:11, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>> >>> >>> >>> >>> Summary: >>> >>> The failing scenario: >>> The debugger and the debuggee are well aware a VM shutdown has >>> been >>> started in the target process. >>> The debugger at this point is not expected to send any commands to >>> the JDWP agent. >>> However, the JDI layer (debugger side) and the jdwp agent >>> (debuggee >>> side) >>> are not in sync with the consumer layers. >>> >>> One reason is because the test debugger does not invoke the JDI >>> method VirtualMachine.dispose(). >>> Another reason is that the Debugger and the debuggee processes are >>> uneasy to sync in general. >>> >>> As a result the following steps are possible: >>> - The test debugger sends a 'quit' command to the test debuggee >>> - The debuggee is normally exiting >>> - The jdwp backend reports (over the jdwp protocol) an anonymous >>> class unload event >>> - The JDI InternalEventHandler thread handles the >>> ClassUnloadEvent event >>> - The InternalEventHandler wants to uncache the matching >>> reference type. >>> If there is more than one class with the same host class >>> signature, it can't distinguish them, >>> and so, deletes all references and re-retrieves them again >>> (see >>> tracing below): >>> MY_TRACE: JDI: >>> VirtualMachineImpl.retrieveClassesBySignature: >>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>> - The jdwp backend debugLoop_run() gets the command from JDI and >>> calls the functions >>> classesForSignature() and classStatus() recursively. >>> - The classStatus() makes a call to the JVMTI GetClassStatus() >>> and gets the JVMTI_ERROR_WRONG_PHASE >>> - As a result the jdwp backend reports the JVMTI error to the >>> JDI, and so, the test fails >>> >>> For details, see the analysis in bug report closed as a dup of the >>> bug 6988950: >>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>> >>> Some similar cases can be found in the two bug reports (6988950 >>> and >>> 8024865) describing this issue. >>> >>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as >>> it is normal at the VM shutdown. >>> The original jdwp backend implementation had a similar approach >>> for >>> the raw monitor functions. >>> Threy use the ignore_vm_death() to workaround the >>> JVMTI_ERROR_WRONG_PHASE errors. >>> For reference, please, see the file: src/share/back/util.c >>> >>> >>> Testing: >>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Wed Oct 29 14:54:16 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Oct 2014 07:54:16 -0700 Subject: RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <5450FECD.3010504@oracle.com> References: <54503EC2.6070601@oracle.com> <5450F2C4.9020604@oracle.com> <5450FB32.4020602@oracle.com> <5450FECD.3010504@oracle.com> Message-ID: <5450FF98.7000902@oracle.com> Thanks, Dmitry! I'm still in a process of checking the consequences of the ignore_wrong_phase() calls. Thanks, Serguei On 10/29/14 7:50 AM, Dmitry Samersoff wrote: > Serguei, > > Thank you! > > Fix looks good for me. > > -Dmitry > > On 2014-10-29 17:35, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> Yes, it will return NULL if the case of JVMTI_ERROR_WRONG_PHASE error. >> It is Ok for the getMethodClass() as the NULL return value listed in the >> comment. >> It seems to be Ok for other two uses of the methodClass(). >> >> Thanks! >> Serguei >> >> On 10/29/14 6:59 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> What happens in a caller function if we ignore the error? >>> >>> e. g. getMethodClass has the code: >>> ... >>> >>> error = methodClass(method, &clazz); >>> if ( error != JVMTI_ERROR_NONE ) { >>> EXIT_ERROR(error,"Can't get jclass for a methodID, invalid?"); >>> return NULL; >>> } >>> return clazz; >>> >>> after the fix it probably will return NULL. Is it correct? >>> >>> -Dmitry >>> >>> On 2014-10-29 04:11, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>> >>>> >>>> >>>> >>>> Summary: >>>> >>>> The failing scenario: >>>> The debugger and the debuggee are well aware a VM shutdown has >>>> been >>>> started in the target process. >>>> The debugger at this point is not expected to send any commands to >>>> the JDWP agent. >>>> However, the JDI layer (debugger side) and the jdwp agent >>>> (debuggee >>>> side) >>>> are not in sync with the consumer layers. >>>> >>>> One reason is because the test debugger does not invoke the JDI >>>> method VirtualMachine.dispose(). >>>> Another reason is that the Debugger and the debuggee processes are >>>> uneasy to sync in general. >>>> >>>> As a result the following steps are possible: >>>> - The test debugger sends a 'quit' command to the test debuggee >>>> - The debuggee is normally exiting >>>> - The jdwp backend reports (over the jdwp protocol) an anonymous >>>> class unload event >>>> - The JDI InternalEventHandler thread handles the >>>> ClassUnloadEvent event >>>> - The InternalEventHandler wants to uncache the matching >>>> reference type. >>>> If there is more than one class with the same host class >>>> signature, it can't distinguish them, >>>> and so, deletes all references and re-retrieves them again >>>> (see >>>> tracing below): >>>> MY_TRACE: JDI: >>>> VirtualMachineImpl.retrieveClassesBySignature: >>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>> - The jdwp backend debugLoop_run() gets the command from JDI and >>>> calls the functions >>>> classesForSignature() and classStatus() recursively. >>>> - The classStatus() makes a call to the JVMTI GetClassStatus() >>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>> - As a result the jdwp backend reports the JVMTI error to the >>>> JDI, and so, the test fails >>>> >>>> For details, see the analysis in bug report closed as a dup of the >>>> bug 6988950: >>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>> >>>> Some similar cases can be found in the two bug reports (6988950 >>>> and >>>> 8024865) describing this issue. >>>> >>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as >>>> it is normal at the VM shutdown. >>>> The original jdwp backend implementation had a similar approach >>>> for >>>> the raw monitor functions. >>>> Threy use the ignore_vm_death() to workaround the >>>> JVMTI_ERROR_WRONG_PHASE errors. >>>> For reference, please, see the file: src/share/back/util.c >>>> >>>> >>>> Testing: >>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >>>> >>>> >>>> Thanks, >>>> Serguei >>>> > From vladimir.kozlov at oracle.com Wed Oct 29 14:56:49 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Oct 2014 07:56:49 -0700 Subject: [8u40] Bulk backport request: 8046268, 8060454, 8061486, 8061983 In-Reply-To: <5450DD3B.3010204@oracle.com> References: <5450DD3B.3010204@oracle.com> Message-ID: <54510031.3030800@oracle.com> Looks good. Thanks, Vladimir On 10/29/14 5:27 AM, Tobias Hartmann wrote: > Hi, > > please review this bulk request to backport the following fixes for the Whitebox > API tests into 8u40. > > For 8046268 I had to remove the "- * @ignore 8046268" changes because the tests > were not quarantined in 8u40. New webrev for this fix: > http://cr.openjdk.java.net/~thartmann/8046268_8u/webrev.00/ > > The other changes apply cleanly. Nightly testing showed no problems. > > (1) 8046268: compiler/whitebox/ tests fail : must be osr_compiled > https://bugs.openjdk.java.net/browse/JDK-8046268 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2b1ea93ea45e > > (2) 8060454: [TESTBUG] Whitebox tests fail with -XX:CompileThreshold=100 > https://bugs.openjdk.java.net/browse/JDK-8060454 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/400c6e3c13a4 > > (3) 061486: [TESTBUG] compiler/whitebox/ tests fail : must be osr_compiled > (reappeared in nightlies) > https://bugs.openjdk.java.net/browse/JDK-8061486 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a754d0298071 > > (4) 8061983: [TESTBUG] compiler/whitebox/MakeMethodNotCompilableTest.java fails > with "must not be in queue" > https://bugs.openjdk.java.net/browse/JDK-8061983 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c2c9379993da > > Thanks, > Tobias > From tobias.hartmann at oracle.com Wed Oct 29 14:59:14 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 29 Oct 2014 15:59:14 +0100 Subject: [8u40] Bulk backport request: 8046268, 8060454, 8061486, 8061983 In-Reply-To: <54510031.3030800@oracle.com> References: <5450DD3B.3010204@oracle.com> <54510031.3030800@oracle.com> Message-ID: <545100C2.1000304@oracle.com> Thanks, Vladimir. Best, Tobias On 29.10.2014 15:56, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/29/14 5:27 AM, Tobias Hartmann wrote: >> Hi, >> >> please review this bulk request to backport the following fixes for the Whitebox >> API tests into 8u40. >> >> For 8046268 I had to remove the "- * @ignore 8046268" changes because the tests >> were not quarantined in 8u40. New webrev for this fix: >> http://cr.openjdk.java.net/~thartmann/8046268_8u/webrev.00/ >> >> The other changes apply cleanly. Nightly testing showed no problems. >> >> (1) 8046268: compiler/whitebox/ tests fail : must be osr_compiled >> https://bugs.openjdk.java.net/browse/JDK-8046268 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2b1ea93ea45e >> >> (2) 8060454: [TESTBUG] Whitebox tests fail with -XX:CompileThreshold=100 >> https://bugs.openjdk.java.net/browse/JDK-8060454 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/400c6e3c13a4 >> >> (3) 061486: [TESTBUG] compiler/whitebox/ tests fail : must be osr_compiled >> (reappeared in nightlies) >> https://bugs.openjdk.java.net/browse/JDK-8061486 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a754d0298071 >> >> (4) 8061983: [TESTBUG] compiler/whitebox/MakeMethodNotCompilableTest.java fails >> with "must not be in queue" >> https://bugs.openjdk.java.net/browse/JDK-8061983 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c2c9379993da >> >> Thanks, >> Tobias >> From eric.mccorkle at oracle.com Wed Oct 29 14:59:56 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 29 Oct 2014 10:59:56 -0400 Subject: Review request for 8058322: Zero name_index item of MethodParameters attribute cause MalformedParameterException Message-ID: <545100EC.5000204@oracle.com> Hello, Please review this simple change which addresses a failure condition in the method parameter reflection implementation. In the initial implementation of method parameter reflection, a parameter with a parameter_name index of 0 denoted a parameter with no name, and the VM translated this into the empty string when creating the Parameter object to return to Java code. However, towards the end of the 8 cycle, the spec was updated to state that a zero parameter_name index should denote a parameter with no name, and should result in Parameter.getName() returning an empty string, whereas the empty string /constant/ is expressly forbidden as a parameter name, and should result in MalformedParametersException. The reflection API was updated to reflect this behavior, but it seems the VM still translates a parameter_name index of 0 into the empty string. This patch removes that, resulting in correct behavior of the reflection API for parameters with no name. The webrev is here: http://cr.openjdk.java.net/~emc/8058322/ The bug is here: https://bugs.openjdk.java.net/browse/JDK-8058322 From coleen.phillimore at oracle.com Wed Oct 29 16:20:10 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 29 Oct 2014 12:20:10 -0400 Subject: Review request for 8058322: Zero name_index item of MethodParameters attribute cause MalformedParameterException In-Reply-To: <545100EC.5000204@oracle.com> References: <545100EC.5000204@oracle.com> Message-ID: <545113BA.6010504@oracle.com> Looks good, Eric. thanks, Coleen On 10/29/14, 10:59 AM, Eric McCorkle wrote: > Hello, > > Please review this simple change which addresses a failure condition in > the method parameter reflection implementation. In the initial > implementation of method parameter reflection, a parameter with a > parameter_name index of 0 denoted a parameter with no name, and the VM > translated this into the empty string when creating the Parameter object > to return to Java code. However, towards the end of the 8 cycle, the > spec was updated to state that a zero parameter_name index should denote > a parameter with no name, and should result in Parameter.getName() > returning an empty string, whereas the empty string /constant/ is > expressly forbidden as a parameter name, and should result in > MalformedParametersException. The reflection API was updated to reflect > this behavior, but it seems the VM still translates a parameter_name > index of 0 into the empty string. This patch removes that, resulting in > correct behavior of the reflection API for parameters with no name. > > The webrev is here: > http://cr.openjdk.java.net/~emc/8058322/ > > The bug is here: > https://bugs.openjdk.java.net/browse/JDK-8058322 From eric.mccorkle at oracle.com Wed Oct 29 17:00:24 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 29 Oct 2014 13:00:24 -0400 Subject: Review request for 8058322: Zero name_index item of MethodParameters attribute cause MalformedParameterException In-Reply-To: <545113BA.6010504@oracle.com> References: <545100EC.5000204@oracle.com> <545113BA.6010504@oracle.com> Message-ID: <54511D28.4030601@oracle.com> I need a second for hotspot changes, if I recall? On 10/29/14 12:20, Coleen Phillimore wrote: > > Looks good, Eric. > > thanks, > Coleen > > On 10/29/14, 10:59 AM, Eric McCorkle wrote: >> Hello, >> >> Please review this simple change which addresses a failure condition in >> the method parameter reflection implementation. In the initial >> implementation of method parameter reflection, a parameter with a >> parameter_name index of 0 denoted a parameter with no name, and the VM >> translated this into the empty string when creating the Parameter object >> to return to Java code. However, towards the end of the 8 cycle, the >> spec was updated to state that a zero parameter_name index should denote >> a parameter with no name, and should result in Parameter.getName() >> returning an empty string, whereas the empty string /constant/ is >> expressly forbidden as a parameter name, and should result in >> MalformedParametersException. The reflection API was updated to reflect >> this behavior, but it seems the VM still translates a parameter_name >> index of 0 into the empty string. This patch removes that, resulting in >> correct behavior of the reflection API for parameters with no name. >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8058322/ >> >> The bug is here: >> https://bugs.openjdk.java.net/browse/JDK-8058322 > From vladimir.kozlov at oracle.com Wed Oct 29 19:54:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Oct 2014 12:54:29 -0700 Subject: [8u40] RFR(M) 8041984: CompilerThread seems to occupy all CPU in a very rare situation Message-ID: <545145F5.5010207@oracle.com> Backport request. Changes were pushed into jdk9 last week. Nighties are fine. Changes are applied cleanly to 8u sources. https://bugs.openjdk.java.net/browse/JDK-8041984 http://cr.openjdk.java.net/~kvn/8041984/webrev.01/ Review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-October/015855.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b9576378eaad Thanks, Vladimir From coleen.phillimore at oracle.com Wed Oct 29 20:30:46 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 29 Oct 2014 16:30:46 -0400 Subject: RFR 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop Message-ID: <54514E76.1060707@oracle.com> Summary: Stop allocating compiler profiling metadata when metaspace is full. open webrev at http://cr.openjdk.java.net/~coleenp/8037842/ bug link https://bugs.openjdk.java.net/browse/JDK-8037842 Tested with test case in the report with prints in the JVM and test. I can't add this test though, there seems to be sketchy things going on with metaspace high water marks and it prints out too much before getting the compiler message for jtreg to deal with. And it may time out and has some timing issues. Also ran jtreg, jck, nsk.quick.testlist tests. Thanks, Coleen From eric.mccorkle at oracle.com Wed Oct 29 22:39:22 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 29 Oct 2014 18:39:22 -0400 Subject: Review request for 8058313: Mismatch of method descriptor and MethodParameters.parameters_count should cause MalformedParameterException Message-ID: <54516C9A.7070404@oracle.com> Hello, Please review this fix for parameter reflection which addresses hotspot falsely ignoring zero-length MethodParameter attributes. The JVMS allows a MethodParameters attribute with parameter_count = 0, and the parameter reflection spec states that a MalformedParametersException should be thrown if parameter_count does not match the number of real parameters to a method. Hotspot currently ignores MethodParameters attributes with parameter_count = 0; however, in a case where a (bad) MethodParameters attribute has parameter_count = 0, but the method has a nonzero number of real parameters, hotspot will return null from JVM_GetMethodParameters, the result being that a MalformedParametersException is not thrown (rather, the reflection API acts like there is no MethodParameters attribute). This patch causes hotspot to record the fact that a zero-length MethodParameters attribute does exist, causing the exception to be thrown when it should be. The bug is here: https://bugs.openjdk.java.net/browse/JDK-8058313 The webrev is here: http://cr.openjdk.java.net/~emc/8058313/ From vladimir.kozlov at oracle.com Thu Oct 30 00:00:53 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Oct 2014 17:00:53 -0700 Subject: RFR 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <54514E76.1060707@oracle.com> References: <54514E76.1060707@oracle.com> Message-ID: <54517FB5.2010607@oracle.com> Thank you, Coleen, for fixing this. Changes looks fine to me. Thanks, Vladimir On 10/29/14 1:30 PM, Coleen Phillimore wrote: > Summary: Stop allocating compiler profiling metadata when metaspace is > full. > > open webrev at http://cr.openjdk.java.net/~coleenp/8037842/ > bug link https://bugs.openjdk.java.net/browse/JDK-8037842 > > Tested with test case in the report with prints in the JVM and test. I > can't add this test though, there seems to be sketchy things going on > with metaspace high water marks and it prints out too much before > getting the compiler message for jtreg to deal with. And it may time > out and has some timing issues. > > Also ran jtreg, jck, nsk.quick.testlist tests. > > Thanks, > Coleen From jiangli.zhou at oracle.com Thu Oct 30 00:36:48 2014 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 29 Oct 2014 17:36:48 -0700 Subject: Review request for 8058313: Mismatch of method descriptor and MethodParameters.parameters_count should cause MalformedParameterException In-Reply-To: <54516C9A.7070404@oracle.com> References: <54516C9A.7070404@oracle.com> Message-ID: <54518820.50700@oracle.com> Hi Eric, I wonder if we could specialize this particular case and avoid changing the parsing code. How about setting the _has_method_parameters flag in the ConstMethod when encounter such MethodParameter, and changing JVM_GetMethodParameters() to return non-NULL value for such case when _has_method_parameters is true but method_parameters_length is 0. Would that work? Thanks, Jiangli On 10/29/2014 03:39 PM, Eric McCorkle wrote: > Hello, > > Please review this fix for parameter reflection which addresses hotspot > falsely ignoring zero-length MethodParameter attributes. The JVMS > allows a MethodParameters attribute with parameter_count = 0, and the > parameter reflection spec states that a MalformedParametersException > should be thrown if parameter_count does not match the number of real > parameters to a method. Hotspot currently ignores MethodParameters > attributes with parameter_count = 0; however, in a case where a (bad) > MethodParameters attribute has parameter_count = 0, but the method has a > nonzero number of real parameters, hotspot will return null from > JVM_GetMethodParameters, the result being that a > MalformedParametersException is not thrown (rather, the reflection API > acts like there is no MethodParameters attribute). > > This patch causes hotspot to record the fact that a zero-length > MethodParameters attribute does exist, causing the exception to be > thrown when it should be. > > The bug is here: > https://bugs.openjdk.java.net/browse/JDK-8058313 > > The webrev is here: > http://cr.openjdk.java.net/~emc/8058313/ From serguei.spitsyn at oracle.com Thu Oct 30 01:05:37 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Oct 2014 18:05:37 -0700 Subject: 2-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <54503EC2.6070601@oracle.com> References: <54503EC2.6070601@oracle.com> Message-ID: <54518EE1.9040208@oracle.com> The updated webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ The changes are: - added a comment recommended by Staffan - removed the ignore_wrong_phase() call from function classSignature() The classSignature() function is called in 16 places. Most of them do not tolerate the NULL in place of returned signature and will crash. I'm not comfortable to fix all the occurrences now and suggest to return to this issue after gaining experience with more failure cases that are still expected. The failure with the classSignature() involved was observed only once in the nightly and should be extremely rare reproducible. I'll file a placeholder bug if necessary. Thanks, Serguei On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6988950 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ > > > > Summary: > > The failing scenario: > The debugger and the debuggee are well aware a VM shutdown has > been started in the target process. > The debugger at this point is not expected to send any commands > to the JDWP agent. > However, the JDI layer (debugger side) and the jdwp agent > (debuggee side) > are not in sync with the consumer layers. > > One reason is because the test debugger does not invoke the JDI > method VirtualMachine.dispose(). > Another reason is that the Debugger and the debuggee processes > are uneasy to sync in general. > > As a result the following steps are possible: > - The test debugger sends a 'quit' command to the test debuggee > - The debuggee is normally exiting > - The jdwp backend reports (over the jdwp protocol) an > anonymous class unload event > - The JDI InternalEventHandler thread handles the > ClassUnloadEvent event > - The InternalEventHandler wants to uncache the matching > reference type. > If there is more than one class with the same host class > signature, it can't distinguish them, > and so, deletes all references and re-retrieves them again > (see tracing below): > MY_TRACE: JDI: > VirtualMachineImpl.retrieveClassesBySignature: > sig=Ljava/lang/invoke/LambdaForm$DMH; > - The jdwp backend debugLoop_run() gets the command from JDI > and calls the functions > classesForSignature() and classStatus() recursively. > - The classStatus() makes a call to the JVMTI GetClassStatus() > and gets the JVMTI_ERROR_WRONG_PHASE > - As a result the jdwp backend reports the JVMTI error to the > JDI, and so, the test fails > > For details, see the analysis in bug report closed as a dup of > the bug 6988950: > https://bugs.openjdk.java.net/browse/JDK-8024865 > > Some similar cases can be found in the two bug reports (6988950 > and 8024865) describing this issue. > > The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as > it is normal at the VM shutdown. > The original jdwp backend implementation had a similar approach > for the raw monitor functions. > Threy use the ignore_vm_death() to workaround the > JVMTI_ERROR_WRONG_PHASE errors. > For reference, please, see the file: src/share/back/util.c > > > Testing: > Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests > > > Thanks, > Serguei > From coleen.phillimore at oracle.com Thu Oct 30 01:52:35 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 29 Oct 2014 21:52:35 -0400 Subject: RFR 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <54517FB5.2010607@oracle.com> References: <54514E76.1060707@oracle.com> <54517FB5.2010607@oracle.com> Message-ID: <545199E3.6040806@oracle.com> Thank you, Vladimir. Coleen On 10/29/14, 8:00 PM, Vladimir Kozlov wrote: > Thank you, Coleen, for fixing this. > Changes looks fine to me. > > Thanks, > Vladimir > > On 10/29/14 1:30 PM, Coleen Phillimore wrote: >> Summary: Stop allocating compiler profiling metadata when metaspace is >> full. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8037842/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8037842 >> >> Tested with test case in the report with prints in the JVM and test. I >> can't add this test though, there seems to be sketchy things going on >> with metaspace high water marks and it prints out too much before >> getting the compiler message for jtreg to deal with. And it may time >> out and has some timing issues. >> >> Also ran jtreg, jck, nsk.quick.testlist tests. >> >> Thanks, >> Coleen From goetz.lindenmaier at sap.com Thu Oct 30 08:28:07 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 30 Oct 2014 08:28:07 +0000 Subject: RFR (L): 8062370: Various minor code improvements Message-ID: <4295855A5C1DE049A61835A1887419CC2CF22447@DEWDFEMB12A.global.corp.sap> Hi, this change contains a row of minor code improvements we did to fulfil our internal quality requirements. We would like to share these with openJDK. Please review and test this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8062370/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8062370 We tested this on windows 64, linux x86_64, mac, solaris sparc 32+64 bit and, of course, the ppc platforms. Some details: CONST64(0x8000000000000000) is wrong, as 0x8... is positive, and thus not representable as i64 what is used in the CONST64 macro. This change adapts UCONST64 to use ui64, and the usages of these macros where necessary. We add some more strncpy uses. Also, we fix strncpy on windows. There, strncpy does not write a \0 into the last byte if the copied string is too long. We add some missing memory frees and some closing of files. jio_vsnprintf() works differently on windows and linux. This change adapts this to show the same behaviour on all platforms. See java.cpp. Best regards, Goetz From albert.noll at oracle.com Thu Oct 30 08:39:46 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 30 Oct 2014 09:39:46 +0100 Subject: Review request for 8058322: Zero name_index item of MethodParameters attribute cause MalformedParameterException In-Reply-To: <54511D28.4030601@oracle.com> References: <545100EC.5000204@oracle.com> <545113BA.6010504@oracle.com> <54511D28.4030601@oracle.com> Message-ID: <5451F952.20205@oracle.com> On 10/29/2014 06:00 PM, Eric McCorkle wrote: > I need a second for hotspot changes, if I recall? For simple changes, 1 review is enough. Best, Albert > On 10/29/14 12:20, Coleen Phillimore wrote: >> Looks good, Eric. >> >> thanks, >> Coleen >> >> On 10/29/14, 10:59 AM, Eric McCorkle wrote: >>> Hello, >>> >>> Please review this simple change which addresses a failure condition in >>> the method parameter reflection implementation. In the initial >>> implementation of method parameter reflection, a parameter with a >>> parameter_name index of 0 denoted a parameter with no name, and the VM >>> translated this into the empty string when creating the Parameter object >>> to return to Java code. However, towards the end of the 8 cycle, the >>> spec was updated to state that a zero parameter_name index should denote >>> a parameter with no name, and should result in Parameter.getName() >>> returning an empty string, whereas the empty string /constant/ is >>> expressly forbidden as a parameter name, and should result in >>> MalformedParametersException. The reflection API was updated to reflect >>> this behavior, but it seems the VM still translates a parameter_name >>> index of 0 into the empty string. This patch removes that, resulting in >>> correct behavior of the reflection API for parameters with no name. >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8058322/ >>> >>> The bug is here: >>> https://bugs.openjdk.java.net/browse/JDK-8058322 From david.holmes at oracle.com Thu Oct 30 09:44:27 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Oct 2014 19:44:27 +1000 Subject: Review request for 8058322: Zero name_index item of MethodParameters attribute cause MalformedParameterException In-Reply-To: <5451F952.20205@oracle.com> References: <545100EC.5000204@oracle.com> <545113BA.6010504@oracle.com> <54511D28.4030601@oracle.com> <5451F952.20205@oracle.com> Message-ID: <5452087B.6030306@oracle.com> On 30/10/2014 6:39 PM, Albert Noll wrote: > On 10/29/2014 06:00 PM, Eric McCorkle wrote: >> I need a second for hotspot changes, if I recall? > For simple changes, 1 review is enough. Runtime requires 2 reviewers - can't speak for other teams. "simple" is too subjective. David > Best, > Albert > >> On 10/29/14 12:20, Coleen Phillimore wrote: >>> Looks good, Eric. >>> >>> thanks, >>> Coleen >>> >>> On 10/29/14, 10:59 AM, Eric McCorkle wrote: >>>> Hello, >>>> >>>> Please review this simple change which addresses a failure condition in >>>> the method parameter reflection implementation. In the initial >>>> implementation of method parameter reflection, a parameter with a >>>> parameter_name index of 0 denoted a parameter with no name, and the VM >>>> translated this into the empty string when creating the Parameter >>>> object >>>> to return to Java code. However, towards the end of the 8 cycle, the >>>> spec was updated to state that a zero parameter_name index should >>>> denote >>>> a parameter with no name, and should result in Parameter.getName() >>>> returning an empty string, whereas the empty string /constant/ is >>>> expressly forbidden as a parameter name, and should result in >>>> MalformedParametersException. The reflection API was updated to >>>> reflect >>>> this behavior, but it seems the VM still translates a parameter_name >>>> index of 0 into the empty string. This patch removes that, >>>> resulting in >>>> correct behavior of the reflection API for parameters with no name. >>>> >>>> The webrev is here: >>>> http://cr.openjdk.java.net/~emc/8058322/ >>>> >>>> The bug is here: >>>> https://bugs.openjdk.java.net/browse/JDK-8058322 > From david.holmes at oracle.com Thu Oct 30 09:50:52 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Oct 2014 19:50:52 +1000 Subject: Review request for 8058322: Zero name_index item of MethodParameters attribute cause MalformedParameterException In-Reply-To: <5452087B.6030306@oracle.com> References: <545100EC.5000204@oracle.com> <545113BA.6010504@oracle.com> <54511D28.4030601@oracle.com> <5451F952.20205@oracle.com> <5452087B.6030306@oracle.com> Message-ID: <545209FC.8020703@oracle.com> May as well try to review this now ... Erik, given: 814 name = NULL; 815 } 816 817 Handle rh = java_lang_reflect_Parameter::create(CHECK_NULL); 818 java_lang_reflect_Parameter::set_name(rh(), name()); How is name() handled when name is NULL? Is it some implicit conversion operator at play? Thanks, David On 30/10/2014 7:44 PM, David Holmes wrote: > On 30/10/2014 6:39 PM, Albert Noll wrote: >> On 10/29/2014 06:00 PM, Eric McCorkle wrote: >>> I need a second for hotspot changes, if I recall? >> For simple changes, 1 review is enough. > > Runtime requires 2 reviewers - can't speak for other teams. "simple" is > too subjective. > > David > >> Best, >> Albert >> >>> On 10/29/14 12:20, Coleen Phillimore wrote: >>>> Looks good, Eric. >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 10/29/14, 10:59 AM, Eric McCorkle wrote: >>>>> Hello, >>>>> >>>>> Please review this simple change which addresses a failure >>>>> condition in >>>>> the method parameter reflection implementation. In the initial >>>>> implementation of method parameter reflection, a parameter with a >>>>> parameter_name index of 0 denoted a parameter with no name, and the VM >>>>> translated this into the empty string when creating the Parameter >>>>> object >>>>> to return to Java code. However, towards the end of the 8 cycle, the >>>>> spec was updated to state that a zero parameter_name index should >>>>> denote >>>>> a parameter with no name, and should result in Parameter.getName() >>>>> returning an empty string, whereas the empty string /constant/ is >>>>> expressly forbidden as a parameter name, and should result in >>>>> MalformedParametersException. The reflection API was updated to >>>>> reflect >>>>> this behavior, but it seems the VM still translates a parameter_name >>>>> index of 0 into the empty string. This patch removes that, >>>>> resulting in >>>>> correct behavior of the reflection API for parameters with no name. >>>>> >>>>> The webrev is here: >>>>> http://cr.openjdk.java.net/~emc/8058322/ >>>>> >>>>> The bug is here: >>>>> https://bugs.openjdk.java.net/browse/JDK-8058322 >> From dmitry.samersoff at oracle.com Thu Oct 30 11:16:50 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 30 Oct 2014 14:16:50 +0300 Subject: 2-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <54518EE1.9040208@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> Message-ID: <54521E22.3000504@oracle.com> Serguei, Looks good for me! -Dmitry On 2014-10-30 04:05, serguei.spitsyn at oracle.com wrote: > The updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ > > > The changes are: > - added a comment recommended by Staffan > - removed the ignore_wrong_phase() call from function classSignature() > > The classSignature() function is called in 16 places. > Most of them do not tolerate the NULL in place of returned signature and > will crash. > I'm not comfortable to fix all the occurrences now and suggest to return > to this > issue after gaining experience with more failure cases that are still > expected. > The failure with the classSignature() involved was observed only once in > the nightly > and should be extremely rare reproducible. > I'll file a placeholder bug if necessary. > > Thanks, > Serguei > > On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6988950 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >> >> >> >> Summary: >> >> The failing scenario: >> The debugger and the debuggee are well aware a VM shutdown has >> been started in the target process. >> The debugger at this point is not expected to send any commands >> to the JDWP agent. >> However, the JDI layer (debugger side) and the jdwp agent >> (debuggee side) >> are not in sync with the consumer layers. >> >> One reason is because the test debugger does not invoke the JDI >> method VirtualMachine.dispose(). >> Another reason is that the Debugger and the debuggee processes >> are uneasy to sync in general. >> >> As a result the following steps are possible: >> - The test debugger sends a 'quit' command to the test debuggee >> - The debuggee is normally exiting >> - The jdwp backend reports (over the jdwp protocol) an >> anonymous class unload event >> - The JDI InternalEventHandler thread handles the >> ClassUnloadEvent event >> - The InternalEventHandler wants to uncache the matching >> reference type. >> If there is more than one class with the same host class >> signature, it can't distinguish them, >> and so, deletes all references and re-retrieves them again >> (see tracing below): >> MY_TRACE: JDI: >> VirtualMachineImpl.retrieveClassesBySignature: >> sig=Ljava/lang/invoke/LambdaForm$DMH; >> - The jdwp backend debugLoop_run() gets the command from JDI >> and calls the functions >> classesForSignature() and classStatus() recursively. >> - The classStatus() makes a call to the JVMTI GetClassStatus() >> and gets the JVMTI_ERROR_WRONG_PHASE >> - As a result the jdwp backend reports the JVMTI error to the >> JDI, and so, the test fails >> >> For details, see the analysis in bug report closed as a dup of >> the bug 6988950: >> https://bugs.openjdk.java.net/browse/JDK-8024865 >> >> Some similar cases can be found in the two bug reports (6988950 >> and 8024865) describing this issue. >> >> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as >> it is normal at the VM shutdown. >> The original jdwp backend implementation had a similar approach >> for the raw monitor functions. >> Threy use the ignore_vm_death() to workaround the >> JVMTI_ERROR_WRONG_PHASE errors. >> For reference, please, see the file: src/share/back/util.c >> >> >> Testing: >> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >> >> >> Thanks, >> Serguei >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From eric.mccorkle at oracle.com Thu Oct 30 14:06:58 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 30 Oct 2014 10:06:58 -0400 Subject: Review request for 8058322: Zero name_index item of MethodParameters attribute cause MalformedParameterException In-Reply-To: <545209FC.8020703@oracle.com> References: <545100EC.5000204@oracle.com> <545113BA.6010504@oracle.com> <54511D28.4030601@oracle.com> <5451F952.20205@oracle.com> <5452087B.6030306@oracle.com> <545209FC.8020703@oracle.com> Message-ID: <54524602.40902@oracle.com> On 10/30/14 05:50, David Holmes wrote: > May as well try to review this now ... > > Erik, given: > > 814 name = NULL; > 815 } > 816 > 817 Handle rh = java_lang_reflect_Parameter::create(CHECK_NULL); > 818 java_lang_reflect_Parameter::set_name(rh(), name()); > > How is name() handled when name is NULL? Is it some implicit conversion > operator at play? name() == NULL when name == NULL. The end result is that the Java reflection code gets a Parameter object with name == null, which is what we want. > Thanks, > David > > On 30/10/2014 7:44 PM, David Holmes wrote: >> On 30/10/2014 6:39 PM, Albert Noll wrote: >>> On 10/29/2014 06:00 PM, Eric McCorkle wrote: >>>> I need a second for hotspot changes, if I recall? >>> For simple changes, 1 review is enough. >> >> Runtime requires 2 reviewers - can't speak for other teams. "simple" is >> too subjective. >> >> David >> >>> Best, >>> Albert >>> >>>> On 10/29/14 12:20, Coleen Phillimore wrote: >>>>> Looks good, Eric. >>>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>> On 10/29/14, 10:59 AM, Eric McCorkle wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this simple change which addresses a failure >>>>>> condition in >>>>>> the method parameter reflection implementation. In the initial >>>>>> implementation of method parameter reflection, a parameter with a >>>>>> parameter_name index of 0 denoted a parameter with no name, and >>>>>> the VM >>>>>> translated this into the empty string when creating the Parameter >>>>>> object >>>>>> to return to Java code. However, towards the end of the 8 cycle, the >>>>>> spec was updated to state that a zero parameter_name index should >>>>>> denote >>>>>> a parameter with no name, and should result in Parameter.getName() >>>>>> returning an empty string, whereas the empty string /constant/ is >>>>>> expressly forbidden as a parameter name, and should result in >>>>>> MalformedParametersException. The reflection API was updated to >>>>>> reflect >>>>>> this behavior, but it seems the VM still translates a parameter_name >>>>>> index of 0 into the empty string. This patch removes that, >>>>>> resulting in >>>>>> correct behavior of the reflection API for parameters with no name. >>>>>> >>>>>> The webrev is here: >>>>>> http://cr.openjdk.java.net/~emc/8058322/ >>>>>> >>>>>> The bug is here: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8058322 >>> From eric.mccorkle at oracle.com Thu Oct 30 14:56:45 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 30 Oct 2014 10:56:45 -0400 Subject: Review request for 8058313: Mismatch of method descriptor and MethodParameters.parameters_count should cause MalformedParameterException In-Reply-To: <54518820.50700@oracle.com> References: <54516C9A.7070404@oracle.com> <54518820.50700@oracle.com> Message-ID: <545251AD.8050208@oracle.com> On 10/29/14 20:36, Jiangli Zhou wrote: > Hi Eric, > > I wonder if we could specialize this particular case and avoid changing > the parsing code. How about setting the _has_method_parameters flag in > the ConstMethod when encounter such MethodParameter, and changing > JVM_GetMethodParameters() to return non-NULL value for such case when > _has_method_parameters is true but method_parameters_length is 0. Would > that work? Which parser are you talking about? The inline tables parser, or the class file parser. The class file parser has to change, because it was previously ignoring MethodParameters attributes with parameter_count 0. I don't think your proposal will work. The inline tables' offsets are all dependent on what inline tables are actually present. If _has_method_parameters is set, then the inline tables code expects the last u2 of the inline tables to be a u2 indicating the number of method parameters entries, preceeded by the array of method parameters data. If _has_method_parameters is false, then it expects that there is no method parameters information at all (including no length field). If you were to set _has_method_parameters, but not store any information in the inline table, then it would cause errors for all the rest of the inline tables. What I do for the parameter_count = 0 case is just store a 0 u2 for zero-length method parameters information, and no data. All the existing inline tables code works fine with this case, so there aren't any serious changes to the inline tables code (other than allowing method parameters information to be stored when the array is length 0). But you have to make some change to the inline table code, otherwise the information won't be stored. > Thanks, > Jiangli > > On 10/29/2014 03:39 PM, Eric McCorkle wrote: >> Hello, >> >> Please review this fix for parameter reflection which addresses hotspot >> falsely ignoring zero-length MethodParameter attributes. The JVMS >> allows a MethodParameters attribute with parameter_count = 0, and the >> parameter reflection spec states that a MalformedParametersException >> should be thrown if parameter_count does not match the number of real >> parameters to a method. Hotspot currently ignores MethodParameters >> attributes with parameter_count = 0; however, in a case where a (bad) >> MethodParameters attribute has parameter_count = 0, but the method has a >> nonzero number of real parameters, hotspot will return null from >> JVM_GetMethodParameters, the result being that a >> MalformedParametersException is not thrown (rather, the reflection API >> acts like there is no MethodParameters attribute). >> >> This patch causes hotspot to record the fact that a zero-length >> MethodParameters attribute does exist, causing the exception to be >> thrown when it should be. >> >> The bug is here: >> https://bugs.openjdk.java.net/browse/JDK-8058313 >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8058313/ > From albert.noll at oracle.com Thu Oct 30 15:06:44 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 30 Oct 2014 16:06:44 +0100 Subject: [8u40] RFR(): backport of JDK-8034775 In-Reply-To: <54172930.20600@oracle.com> References: <541694D9.2020200@oracle.com> <54172930.20600@oracle.com> Message-ID: <54525404.7060303@oracle.com> Hi Vladimir, you are right. I identified the following related patches. The listed patches apply cleanly in the following order: https://bugs.openjdk.java.net/browse/JDK-8034775 http://cr.openjdk.java.net/~anoll/8034775/webrev.01/ http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9a83b7b3e37c https://bugs.openjdk.java.net/browse/JDK-8036091 http://cr.openjdk.java.net/~anoll/8036091/webrev.01/ http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a5f0657a1666 https://bugs.openjdk.java.net/browse/JDK-8038393 http://cr.openjdk.java.net/~iignatyev/8038393/webrev.00/ http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/824be221cabe https://bugs.openjdk.java.net/browse/JDK-8041992 http://cr.openjdk.java.net/~anoll/8041992/webrev.00/ http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c6d29f2731d5 https://bugs.openjdk.java.net/browse/JDK-8042431 http://cr.openjdk.java.net/~anoll/8042431/webrev.03/ http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/fef9b88e2585 Thanks, Albert On 09/15/2014 08:00 PM, Vladimir Kozlov wrote: > Albert, > > 8034775 had bugs tail, you need to collect all related fixes together > (several changesets with one push). > > Thanks, > Vladimir > > On 9/15/14 12:27 AM, Albert wrote: >> Hi, >> >> please review the following backport: >> >> https://bugs.openjdk.java.net/browse/JDK-8034775 >> http://cr.openjdk.java.net/~anoll/8034775/webrev.01/ >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9a83b7b3e37c >> >> The changes were pushed to 9 some weeks ago and nightly testing >> showed no problems. All changes apply cleanly to 8u40. >> >> Thanks, >> Albert >> >> From albert.noll at oracle.com Thu Oct 30 15:25:27 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 30 Oct 2014 16:25:27 +0100 Subject: RFR 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <54514E76.1060707@oracle.com> References: <54514E76.1060707@oracle.com> Message-ID: <54525867.1050402@oracle.com> Hi Coleen, the changes look fine to me as well (not a reviewer). Thanks for fixing this. Best, Albert On 10/29/2014 09:30 PM, Coleen Phillimore wrote: > Summary: Stop allocating compiler profiling metadata when metaspace is > full. > > open webrev at http://cr.openjdk.java.net/~coleenp/8037842/ > bug link https://bugs.openjdk.java.net/browse/JDK-8037842 > > Tested with test case in the report with prints in the JVM and test. > I can't add this test though, there seems to be sketchy things going > on with metaspace high water marks and it prints out too much before > getting the compiler message for jtreg to deal with. And it may time > out and has some timing issues. > > Also ran jtreg, jck, nsk.quick.testlist tests. > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Oct 30 16:01:03 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 30 Oct 2014 12:01:03 -0400 Subject: RFR 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop In-Reply-To: <54525867.1050402@oracle.com> References: <54514E76.1060707@oracle.com> <54525867.1050402@oracle.com> Message-ID: <545260BF.1060304@oracle.com> Thank you Albert. Coleen On 10/30/2014 11:25 AM, Albert Noll wrote: > Hi Coleen, > > the changes look fine to me as well (not a reviewer). Thanks for > fixing this. > > Best, > Albert > > On 10/29/2014 09:30 PM, Coleen Phillimore wrote: >> Summary: Stop allocating compiler profiling metadata when metaspace >> is full. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8037842/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8037842 >> >> Tested with test case in the report with prints in the JVM and >> test. I can't add this test though, there seems to be sketchy >> things going on with metaspace high water marks and it prints out too >> much before getting the compiler message for jtreg to deal with. And >> it may time out and has some timing issues. >> >> Also ran jtreg, jck, nsk.quick.testlist tests. >> >> Thanks, >> Coleen > From vladimir.kozlov at oracle.com Thu Oct 30 16:19:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Oct 2014 09:19:27 -0700 Subject: [8u40] RFR(): backport of JDK-8034775 In-Reply-To: <54525404.7060303@oracle.com> References: <541694D9.2020200@oracle.com> <54172930.20600@oracle.com> <54525404.7060303@oracle.com> Message-ID: <5452650F.8020307@oracle.com> Thank you, Albert for collecting all related fixes. These look good. Thanks, Vladimir On 10/30/14 8:06 AM, Albert Noll wrote: > Hi Vladimir, > > you are right. I identified the following related patches. The listed patches apply cleanly in the following order: > > > https://bugs.openjdk.java.net/browse/JDK-8034775 > http://cr.openjdk.java.net/~anoll/8034775/webrev.01/ > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9a83b7b3e37c > > https://bugs.openjdk.java.net/browse/JDK-8036091 > http://cr.openjdk.java.net/~anoll/8036091/webrev.01/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a5f0657a1666 > > https://bugs.openjdk.java.net/browse/JDK-8038393 > http://cr.openjdk.java.net/~iignatyev/8038393/webrev.00/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/824be221cabe > > https://bugs.openjdk.java.net/browse/JDK-8041992 > http://cr.openjdk.java.net/~anoll/8041992/webrev.00/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c6d29f2731d5 > > https://bugs.openjdk.java.net/browse/JDK-8042431 > http://cr.openjdk.java.net/~anoll/8042431/webrev.03/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/fef9b88e2585 > > Thanks, > Albert > > On 09/15/2014 08:00 PM, Vladimir Kozlov wrote: >> Albert, >> >> 8034775 had bugs tail, you need to collect all related fixes together (several changesets with one push). >> >> Thanks, >> Vladimir >> >> On 9/15/14 12:27 AM, Albert wrote: >>> Hi, >>> >>> please review the following backport: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8034775 >>> http://cr.openjdk.java.net/~anoll/8034775/webrev.01/ >>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9a83b7b3e37c >>> >>> The changes were pushed to 9 some weeks ago and nightly testing showed no problems. All changes apply cleanly to 8u40. >>> >>> Thanks, >>> Albert >>> >>> > From eric.mccorkle at oracle.com Thu Oct 30 17:19:03 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 30 Oct 2014 13:19:03 -0400 Subject: Review request for 8058322: Zero name_index item of MethodParameters attribute cause MalformedParameterException In-Reply-To: <545209FC.8020703@oracle.com> References: <545100EC.5000204@oracle.com> <545113BA.6010504@oracle.com> <54511D28.4030601@oracle.com> <5451F952.20205@oracle.com> <5452087B.6030306@oracle.com> <545209FC.8020703@oracle.com> Message-ID: <54527307.9070601@oracle.com> I forgot to mention, there is a test for this change, but it has to be added to the jdk repo. Thus, I will add it after the change propagates. I have created the following issue to track this: https://bugs.openjdk.java.net/browse/JDK-8062556 On 10/30/14 05:50, David Holmes wrote: > May as well try to review this now ... > > Erik, given: > > 814 name = NULL; > 815 } > 816 > 817 Handle rh = java_lang_reflect_Parameter::create(CHECK_NULL); > 818 java_lang_reflect_Parameter::set_name(rh(), name()); > > How is name() handled when name is NULL? Is it some implicit conversion > operator at play? > > Thanks, > David > > On 30/10/2014 7:44 PM, David Holmes wrote: >> On 30/10/2014 6:39 PM, Albert Noll wrote: >>> On 10/29/2014 06:00 PM, Eric McCorkle wrote: >>>> I need a second for hotspot changes, if I recall? >>> For simple changes, 1 review is enough. >> >> Runtime requires 2 reviewers - can't speak for other teams. "simple" is >> too subjective. >> >> David >> >>> Best, >>> Albert >>> >>>> On 10/29/14 12:20, Coleen Phillimore wrote: >>>>> Looks good, Eric. >>>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>> On 10/29/14, 10:59 AM, Eric McCorkle wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this simple change which addresses a failure >>>>>> condition in >>>>>> the method parameter reflection implementation. In the initial >>>>>> implementation of method parameter reflection, a parameter with a >>>>>> parameter_name index of 0 denoted a parameter with no name, and >>>>>> the VM >>>>>> translated this into the empty string when creating the Parameter >>>>>> object >>>>>> to return to Java code. However, towards the end of the 8 cycle, the >>>>>> spec was updated to state that a zero parameter_name index should >>>>>> denote >>>>>> a parameter with no name, and should result in Parameter.getName() >>>>>> returning an empty string, whereas the empty string /constant/ is >>>>>> expressly forbidden as a parameter name, and should result in >>>>>> MalformedParametersException. The reflection API was updated to >>>>>> reflect >>>>>> this behavior, but it seems the VM still translates a parameter_name >>>>>> index of 0 into the empty string. This patch removes that, >>>>>> resulting in >>>>>> correct behavior of the reflection API for parameters with no name. >>>>>> >>>>>> The webrev is here: >>>>>> http://cr.openjdk.java.net/~emc/8058322/ >>>>>> >>>>>> The bug is here: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8058322 >>> From eric.mccorkle at oracle.com Thu Oct 30 17:19:53 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 30 Oct 2014 13:19:53 -0400 Subject: Review request for 8058313: Mismatch of method descriptor and MethodParameters.parameters_count should cause MalformedParameterException In-Reply-To: <54516C9A.7070404@oracle.com> References: <54516C9A.7070404@oracle.com> Message-ID: <54527339.5000907@oracle.com> There is a test for this, which needs to be added to the jdk repo after the change has propagated. I have created the following issue to track this: https://bugs.openjdk.java.net/browse/JDK-8062556 On 10/29/14 18:39, Eric McCorkle wrote: > Hello, > > Please review this fix for parameter reflection which addresses hotspot > falsely ignoring zero-length MethodParameter attributes. The JVMS > allows a MethodParameters attribute with parameter_count = 0, and the > parameter reflection spec states that a MalformedParametersException > should be thrown if parameter_count does not match the number of real > parameters to a method. Hotspot currently ignores MethodParameters > attributes with parameter_count = 0; however, in a case where a (bad) > MethodParameters attribute has parameter_count = 0, but the method has a > nonzero number of real parameters, hotspot will return null from > JVM_GetMethodParameters, the result being that a > MalformedParametersException is not thrown (rather, the reflection API > acts like there is no MethodParameters attribute). > > This patch causes hotspot to record the fact that a zero-length > MethodParameters attribute does exist, causing the exception to be > thrown when it should be. > > The bug is here: > https://bugs.openjdk.java.net/browse/JDK-8058313 > > The webrev is here: > http://cr.openjdk.java.net/~emc/8058313/ > From joe.darcy at oracle.com Thu Oct 30 17:39:37 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 30 Oct 2014 10:39:37 -0700 Subject: Review request for 8058313: Mismatch of method descriptor and MethodParameters.parameters_count should cause MalformedParameterException In-Reply-To: <54527339.5000907@oracle.com> References: <54516C9A.7070404@oracle.com> <54527339.5000907@oracle.com> Message-ID: <545277D9.7030203@oracle.com> Can't the hotspot and jdk portions of a fix be pushed together now? -Joe On 10/30/2014 10:19 AM, Eric McCorkle wrote: > There is a test for this, which needs to be added to the jdk repo after > the change has propagated. I have created the following issue to track > this: https://bugs.openjdk.java.net/browse/JDK-8062556 > > On 10/29/14 18:39, Eric McCorkle wrote: >> Hello, >> >> Please review this fix for parameter reflection which addresses hotspot >> falsely ignoring zero-length MethodParameter attributes. The JVMS >> allows a MethodParameters attribute with parameter_count = 0, and the >> parameter reflection spec states that a MalformedParametersException >> should be thrown if parameter_count does not match the number of real >> parameters to a method. Hotspot currently ignores MethodParameters >> attributes with parameter_count = 0; however, in a case where a (bad) >> MethodParameters attribute has parameter_count = 0, but the method has a >> nonzero number of real parameters, hotspot will return null from >> JVM_GetMethodParameters, the result being that a >> MalformedParametersException is not thrown (rather, the reflection API >> acts like there is no MethodParameters attribute). >> >> This patch causes hotspot to record the fact that a zero-length >> MethodParameters attribute does exist, causing the exception to be >> thrown when it should be. >> >> The bug is here: >> https://bugs.openjdk.java.net/browse/JDK-8058313 >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8058313/ >> From jiangli.zhou at oracle.com Thu Oct 30 17:51:12 2014 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 30 Oct 2014 10:51:12 -0700 Subject: Review request for 8058313: Mismatch of method descriptor and MethodParameters.parameters_count should cause MalformedParameterException In-Reply-To: <545251AD.8050208@oracle.com> References: <54516C9A.7070404@oracle.com> <54518820.50700@oracle.com> <545251AD.8050208@oracle.com> Message-ID: <54527A90.4030503@oracle.com> Hi Eric, On 10/30/2014 07:56 AM, Eric McCorkle wrote: > On 10/29/14 20:36, Jiangli Zhou wrote: >> Hi Eric, >> >> I wonder if we could specialize this particular case and avoid changing >> the parsing code. How about setting the _has_method_parameters flag in >> the ConstMethod when encounter such MethodParameter, and changing >> JVM_GetMethodParameters() to return non-NULL value for such case when >> _has_method_parameters is true but method_parameters_length is 0. Would >> that work? > Which parser are you talking about? The inline tables parser, or the > class file parser. The class file parser has to change, because it was > previously ignoring MethodParameters attributes with parameter_count 0. It's the class parsing changes that I was referring to, mostly relate to the initialization and checking against method_parameters_length. It's a bit awkward to include the 0 case but also skipping it in the loop. For example, the following code in classFileParser.cpp changed ">" to ">=" in the if check, but has no real effect and is not need. 2486 // Copy method parameters 2487 if (method_parameters_length >= 0) { 2488 MethodParametersElement* elem = m->constMethod()->method_parameters_start(); 2489 for (int i = 0; i < method_parameters_length; i++) { 2490 elem[i].name_cp_index = Bytes::get_Java_u2(method_parameters_data); 2491 method_parameters_data += 2; 2492 elem[i].flags = Bytes::get_Java_u2(method_parameters_data); 2493 method_parameters_data += 2; 2494 } 2495 } > > I don't think your proposal will work. The inline tables' offsets are > all dependent on what inline tables are actually present. If > _has_method_parameters is set, then the inline tables code expects the > last u2 of the inline tables to be a u2 indicating the number of method > parameters entries, preceeded by the array of method parameters data. > If _has_method_parameters is false, then it expects that there is no > method parameters information at all (including no length field). If > you were to set _has_method_parameters, but not store any information in > the inline table, then it would cause errors for all the rest of the > inline tables. Thank you for reminding me of the complexity of the inlined table calculation in the ConstMethod. My proposal would require tweaks in that area to correctly compute the table sizes. As it's easy to introduce bugs in that area, it's not worth to change the table calculation code for this purpose. I agree my proposal is not a better choice in this case. > What I do for the parameter_count = 0 case is just store > a 0 u2 for zero-length method parameters information, and no data. All > the existing inline tables code works fine with this case, so there > aren't any serious changes to the inline tables code (other than > allowing method parameters information to be stored when the array is > length 0). But you have to make some change to the inline table code, > otherwise the information won't be stored. Ok. Could you please add comments to the change in constMethod.cpp to explain above? In jvm.cpp, since -1 represents no method parameter now. Maybe checking against explicity and add comments for the 0-length case. JVM_ENTRY(jobjectArray, JVM_GetMethodParameters(JNIEnv *env, jobject method)) { ... // No method parameter if (num_params == -1) { return (jobjectArray)NULL; } /* handle the rest here */ // make sure all the symbols are properly formatted for (int i = 0; i < num_params; i++) { ... } Thanks, Jiangli > >> Thanks, >> Jiangli >> >> On 10/29/2014 03:39 PM, Eric McCorkle wrote: >>> Hello, >>> >>> Please review this fix for parameter reflection which addresses hotspot >>> falsely ignoring zero-length MethodParameter attributes. The JVMS >>> allows a MethodParameters attribute with parameter_count = 0, and the >>> parameter reflection spec states that a MalformedParametersException >>> should be thrown if parameter_count does not match the number of real >>> parameters to a method. Hotspot currently ignores MethodParameters >>> attributes with parameter_count = 0; however, in a case where a (bad) >>> MethodParameters attribute has parameter_count = 0, but the method has a >>> nonzero number of real parameters, hotspot will return null from >>> JVM_GetMethodParameters, the result being that a >>> MalformedParametersException is not thrown (rather, the reflection API >>> acts like there is no MethodParameters attribute). >>> >>> This patch causes hotspot to record the fact that a zero-length >>> MethodParameters attribute does exist, causing the exception to be >>> thrown when it should be. >>> >>> The bug is here: >>> https://bugs.openjdk.java.net/browse/JDK-8058313 >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8058313/ From serguei.spitsyn at oracle.com Thu Oct 30 19:07:53 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 30 Oct 2014 12:07:53 -0700 Subject: 2-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <54521E22.3000504@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <54521E22.3000504@oracle.com> Message-ID: <54528C89.3060104@oracle.com> Thanks, Dmitry! Serguei On 10/30/14 4:16 AM, Dmitry Samersoff wrote: > Serguei, > > Looks good for me! > > -Dmitry > > On 2014-10-30 04:05, serguei.spitsyn at oracle.com wrote: >> The updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >> >> >> The changes are: >> - added a comment recommended by Staffan >> - removed the ignore_wrong_phase() call from function classSignature() >> >> The classSignature() function is called in 16 places. >> Most of them do not tolerate the NULL in place of returned signature and >> will crash. >> I'm not comfortable to fix all the occurrences now and suggest to return >> to this >> issue after gaining experience with more failure cases that are still >> expected. >> The failure with the classSignature() involved was observed only once in >> the nightly >> and should be extremely rare reproducible. >> I'll file a placeholder bug if necessary. >> >> Thanks, >> Serguei >> >> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>> >>> >>> >>> Summary: >>> >>> The failing scenario: >>> The debugger and the debuggee are well aware a VM shutdown has >>> been started in the target process. >>> The debugger at this point is not expected to send any commands >>> to the JDWP agent. >>> However, the JDI layer (debugger side) and the jdwp agent >>> (debuggee side) >>> are not in sync with the consumer layers. >>> >>> One reason is because the test debugger does not invoke the JDI >>> method VirtualMachine.dispose(). >>> Another reason is that the Debugger and the debuggee processes >>> are uneasy to sync in general. >>> >>> As a result the following steps are possible: >>> - The test debugger sends a 'quit' command to the test debuggee >>> - The debuggee is normally exiting >>> - The jdwp backend reports (over the jdwp protocol) an >>> anonymous class unload event >>> - The JDI InternalEventHandler thread handles the >>> ClassUnloadEvent event >>> - The InternalEventHandler wants to uncache the matching >>> reference type. >>> If there is more than one class with the same host class >>> signature, it can't distinguish them, >>> and so, deletes all references and re-retrieves them again >>> (see tracing below): >>> MY_TRACE: JDI: >>> VirtualMachineImpl.retrieveClassesBySignature: >>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>> - The jdwp backend debugLoop_run() gets the command from JDI >>> and calls the functions >>> classesForSignature() and classStatus() recursively. >>> - The classStatus() makes a call to the JVMTI GetClassStatus() >>> and gets the JVMTI_ERROR_WRONG_PHASE >>> - As a result the jdwp backend reports the JVMTI error to the >>> JDI, and so, the test fails >>> >>> For details, see the analysis in bug report closed as a dup of >>> the bug 6988950: >>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>> >>> Some similar cases can be found in the two bug reports (6988950 >>> and 8024865) describing this issue. >>> >>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as >>> it is normal at the VM shutdown. >>> The original jdwp backend implementation had a similar approach >>> for the raw monitor functions. >>> Threy use the ignore_vm_death() to workaround the >>> JVMTI_ERROR_WRONG_PHASE errors. >>> For reference, please, see the file: src/share/back/util.c >>> >>> >>> Testing: >>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> > From albert.noll at oracle.com Thu Oct 30 20:08:22 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 30 Oct 2014 21:08:22 +0100 Subject: [8u40] Bulk backport request: 8040798, 8042570, 8042428, 8043158 Message-ID: <54529AB6.6050001@oracle.com> Hi, please review this request to backport the following fixes. These patches fix JDK-8055420, which appears only in 8u, and not in 9. I tested the 8u version and the bug is not reproducible anymore. (1) https://bugs.openjdk.java.net/browse/JDK-8040798 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/48c15b47a4f1 Unfortunately, this changeset does not apply cleanly due to the changes of JDK-8025856. I resolved this conflict manually, since backporting JDK-8025856 results in other conflicts. The mercurial output is: @@ -387,7 +387,7 @@ void SimpleThresholdPolicy::method_back_branch_event(methodHandle mh, methodHandle imh, int bci, CompLevel level, nmethod* nm, JavaThread* thread) { // If the method is already compiling, quickly bail out. - if (is_compilation_enabled() && !CompileBroker::compilation_is_in_queue(mh, bci)) { + if (is_compilation_enabled() && !CompileBroker::compilation_is_in_queue(mh)) { // Use loop event as an opportunity to also check there's been // enough calls. CompLevel cur_level = comp_level(mh()); The change in the comment "// Use loop event as an opportunity to also check there's been" causes the conflict. (2) https://bugs.openjdk.java.net/browse/JDK-8042570 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8fddb780f3a7 (3) https://bugs.openjdk.java.net/browse/JDK-8042428 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6786f914240e (4) https://bugs.openjdk.java.net/browse/JDK-8043158 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/98a3a2dea3b9 Thanks, Albert From vladimir.kozlov at oracle.com Thu Oct 30 20:25:46 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Oct 2014 13:25:46 -0700 Subject: [8u40] Bulk backport request: 8040798, 8042570, 8042428, 8043158 In-Reply-To: <54529AB6.6050001@oracle.com> References: <54529AB6.6050001@oracle.com> Message-ID: <54529ECA.9050607@oracle.com> Okay, this is good. Thanks, Vladimir On 10/30/14 1:08 PM, Albert Noll wrote: > Hi, > > please review this request to backport the following fixes. These > patches fix JDK-8055420, which appears only in 8u, and not in 9. I > tested the 8u version and the bug is not reproducible anymore. > > (1) > https://bugs.openjdk.java.net/browse/JDK-8040798 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/48c15b47a4f1 > Unfortunately, this changeset does not apply cleanly due to the changes > of JDK-8025856. I resolved this conflict manually, since backporting > JDK-8025856 results in other conflicts. The mercurial output is: > > @@ -387,7 +387,7 @@ > void SimpleThresholdPolicy::method_back_branch_event(methodHandle mh, > methodHandle imh, > int bci, > CompLevel level, nmethod* nm, JavaThread* thread) { > // If the method is already compiling, quickly bail out. > - if (is_compilation_enabled() && > !CompileBroker::compilation_is_in_queue(mh, bci)) { > + if (is_compilation_enabled() && > !CompileBroker::compilation_is_in_queue(mh)) { > // Use loop event as an opportunity to also check there's been > // enough calls. > CompLevel cur_level = comp_level(mh()); > > The change in the comment "// Use loop event as an opportunity to also > check there's been" causes the conflict. > > (2) > https://bugs.openjdk.java.net/browse/JDK-8042570 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8fddb780f3a7 > > (3) > https://bugs.openjdk.java.net/browse/JDK-8042428 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6786f914240e > > (4) > https://bugs.openjdk.java.net/browse/JDK-8043158 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/98a3a2dea3b9 > > Thanks, > Albert From albert.noll at oracle.com Thu Oct 30 20:34:21 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 30 Oct 2014 21:34:21 +0100 Subject: [8u40] Bulk backport request: 8040798, 8042570, 8042428, 8043158 In-Reply-To: <54529ECA.9050607@oracle.com> References: <54529AB6.6050001@oracle.com> <54529ECA.9050607@oracle.com> Message-ID: <5452A0CD.2040705@oracle.com> Thank you, Vladimir. Best, Albert On 10/30/2014 09:25 PM, Vladimir Kozlov wrote: > Okay, this is good. > > Thanks, > Vladimir > > On 10/30/14 1:08 PM, Albert Noll wrote: >> Hi, >> >> please review this request to backport the following fixes. These >> patches fix JDK-8055420, which appears only in 8u, and not in 9. I >> tested the 8u version and the bug is not reproducible anymore. >> >> (1) >> https://bugs.openjdk.java.net/browse/JDK-8040798 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/48c15b47a4f1 >> Unfortunately, this changeset does not apply cleanly due to the changes >> of JDK-8025856. I resolved this conflict manually, since backporting >> JDK-8025856 results in other conflicts. The mercurial output is: >> >> @@ -387,7 +387,7 @@ >> void SimpleThresholdPolicy::method_back_branch_event(methodHandle mh, >> methodHandle imh, >> int bci, >> CompLevel level, nmethod* nm, JavaThread* thread) { >> // If the method is already compiling, quickly bail out. >> - if (is_compilation_enabled() && >> !CompileBroker::compilation_is_in_queue(mh, bci)) { >> + if (is_compilation_enabled() && >> !CompileBroker::compilation_is_in_queue(mh)) { >> // Use loop event as an opportunity to also check there's been >> // enough calls. >> CompLevel cur_level = comp_level(mh()); >> >> The change in the comment "// Use loop event as an opportunity to also >> check there's been" causes the conflict. >> >> (2) >> https://bugs.openjdk.java.net/browse/JDK-8042570 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8fddb780f3a7 >> >> (3) >> https://bugs.openjdk.java.net/browse/JDK-8042428 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6786f914240e >> >> (4) >> https://bugs.openjdk.java.net/browse/JDK-8043158 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/98a3a2dea3b9 >> >> Thanks, >> Albert From albert.noll at oracle.com Thu Oct 30 20:34:46 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 30 Oct 2014 21:34:46 +0100 Subject: [8u40] RFR(): backport of JDK-8034775 In-Reply-To: <5452650F.8020307@oracle.com> References: <541694D9.2020200@oracle.com> <54172930.20600@oracle.com> <54525404.7060303@oracle.com> <5452650F.8020307@oracle.com> Message-ID: <5452A0E6.6020401@oracle.com> Thank you, Vladimir. Best, Albert On 10/30/2014 05:19 PM, Vladimir Kozlov wrote: > Thank you, Albert for collecting all related fixes. > > These look good. > > Thanks, > Vladimir > > On 10/30/14 8:06 AM, Albert Noll wrote: >> Hi Vladimir, >> >> you are right. I identified the following related patches. The listed >> patches apply cleanly in the following order: >> >> >> https://bugs.openjdk.java.net/browse/JDK-8034775 >> http://cr.openjdk.java.net/~anoll/8034775/webrev.01/ >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9a83b7b3e37c >> >> https://bugs.openjdk.java.net/browse/JDK-8036091 >> http://cr.openjdk.java.net/~anoll/8036091/webrev.01/ >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a5f0657a1666 >> >> https://bugs.openjdk.java.net/browse/JDK-8038393 >> http://cr.openjdk.java.net/~iignatyev/8038393/webrev.00/ >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/824be221cabe >> >> https://bugs.openjdk.java.net/browse/JDK-8041992 >> http://cr.openjdk.java.net/~anoll/8041992/webrev.00/ >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c6d29f2731d5 >> >> https://bugs.openjdk.java.net/browse/JDK-8042431 >> http://cr.openjdk.java.net/~anoll/8042431/webrev.03/ >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/fef9b88e2585 >> >> Thanks, >> Albert >> >> On 09/15/2014 08:00 PM, Vladimir Kozlov wrote: >>> Albert, >>> >>> 8034775 had bugs tail, you need to collect all related fixes >>> together (several changesets with one push). >>> >>> Thanks, >>> Vladimir >>> >>> On 9/15/14 12:27 AM, Albert wrote: >>>> Hi, >>>> >>>> please review the following backport: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8034775 >>>> http://cr.openjdk.java.net/~anoll/8034775/webrev.01/ >>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9a83b7b3e37c >>>> >>>> The changes were pushed to 9 some weeks ago and nightly testing >>>> showed no problems. All changes apply cleanly to 8u40. >>>> >>>> Thanks, >>>> Albert >>>> >>>> >> From serguei.spitsyn at oracle.com Thu Oct 30 20:35:27 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 30 Oct 2014 13:35:27 -0700 Subject: 2-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <545294C0.4010204@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <54521E22.3000504@oracle.com> <54528C33.7000004@oracle.com> <545294C0.4010204@oracle.com> Message-ID: <5452A10F.2080104@oracle.com> As we started this discussion I've added the open mailing lists back. :) On 10/30/14 12:42 PM, Daniel D. Daugherty wrote: > On 10/30/14 1:06 PM, serguei.spitsyn at oracle.com wrote: >> Staffan and Dan, >> >> Do you have anything to say? > > It feels like we're suppressing a symptom rather than dealing with > the underlying cause. However, I haven't been close to this bug > for years so my memories are rusty here. I agree. It feels that not all the aspects of the shutdown sequence were equally designed in the JDI + jdwp agent. There can be shutdown races between the debugger + JDI and debuggee + jdwp agent. I do not see patterns in the code to recognize the shutdown and bail out gracefully. > > One question: > > line 1051: if (debugInit_isInitComplete() && error == > JVMTI_ERROR_WRONG_PHASE) { > The debugInit_isInitComplete() check means that we only do > this suppression in the live phase or later, right? Perhaps > we should do this only when we are post live phase... Agreed. It is exactly the case. In normal case the debugInit_isInitComplete() returns true after VM_INIT event was received. Some agent flag can enforce to postpone the agent initialization until an Exception event is received. In all cases, the initialization happens in the live phase or later (not sure, it can happen in the dead phase). Encountering the JVMTI WRONG_PHASE error means the VM entered the VM_DEAD phase. This must be a signal to start an agent shutdown. At this point, I'm not ready to redesign this in the agent. This fix is only a workaround for nightly stabilization. > > Maybe a flag set at the beginning of the VMDeath event handler > would be better. There is already a global flag: gdata->vmDead I've already tried to use it, but it did not work for me. Let me check it more. > > >> Is it Ok to push this? > > I'm OK with it, but I'm just one voice... Thanks! You raised good points. > > >> Dan, should I count on you as a reviewer? > > Yes, I've reviewed the changes at this point. Ok. > > >> I will also need to backport this to 8u40. > > You might want to let this bake for a couple of weeks first... Sure. Thanks, Serguei > > Dan > > >> >> Thanks! >> Serguei >> >> On 10/30/14 4:16 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> Looks good for me! >>> >>> -Dmitry >>> >>> On 2014-10-30 04:05, serguei.spitsyn at oracle.com wrote: >>>> The updated webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>> >>>> >>>> >>>> The changes are: >>>> - added a comment recommended by Staffan >>>> - removed the ignore_wrong_phase() call from function >>>> classSignature() >>>> >>>> The classSignature() function is called in 16 places. >>>> Most of them do not tolerate the NULL in place of returned >>>> signature and >>>> will crash. >>>> I'm not comfortable to fix all the occurrences now and suggest to >>>> return >>>> to this >>>> issue after gaining experience with more failure cases that are still >>>> expected. >>>> The failure with the classSignature() involved was observed only >>>> once in >>>> the nightly >>>> and should be extremely rare reproducible. >>>> I'll file a placeholder bug if necessary. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>> >>>>> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> The failing scenario: >>>>> The debugger and the debuggee are well aware a VM shutdown has >>>>> been started in the target process. >>>>> The debugger at this point is not expected to send any commands >>>>> to the JDWP agent. >>>>> However, the JDI layer (debugger side) and the jdwp agent >>>>> (debuggee side) >>>>> are not in sync with the consumer layers. >>>>> >>>>> One reason is because the test debugger does not invoke the JDI >>>>> method VirtualMachine.dispose(). >>>>> Another reason is that the Debugger and the debuggee processes >>>>> are uneasy to sync in general. >>>>> >>>>> As a result the following steps are possible: >>>>> - The test debugger sends a 'quit' command to the test >>>>> debuggee >>>>> - The debuggee is normally exiting >>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>> anonymous class unload event >>>>> - The JDI InternalEventHandler thread handles the >>>>> ClassUnloadEvent event >>>>> - The InternalEventHandler wants to uncache the matching >>>>> reference type. >>>>> If there is more than one class with the same host class >>>>> signature, it can't distinguish them, >>>>> and so, deletes all references and re-retrieves them again >>>>> (see tracing below): >>>>> MY_TRACE: JDI: >>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>> - The jdwp backend debugLoop_run() gets the command from JDI >>>>> and calls the functions >>>>> classesForSignature() and classStatus() recursively. >>>>> - The classStatus() makes a call to the JVMTI >>>>> GetClassStatus() >>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>> - As a result the jdwp backend reports the JVMTI error to the >>>>> JDI, and so, the test fails >>>>> >>>>> For details, see the analysis in bug report closed as a dup of >>>>> the bug 6988950: >>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>> >>>>> Some similar cases can be found in the two bug reports (6988950 >>>>> and 8024865) describing this issue. >>>>> >>>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE >>>>> error as >>>>> it is normal at the VM shutdown. >>>>> The original jdwp backend implementation had a similar approach >>>>> for the raw monitor functions. >>>>> Threy use the ignore_vm_death() to workaround the >>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>> For reference, please, see the file: src/share/back/util.c >>>>> >>>>> >>>>> Testing: >>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>> tests >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>> >> > From david.holmes at oracle.com Thu Oct 30 22:52:20 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 31 Oct 2014 08:52:20 +1000 Subject: Review request for 8058313: Mismatch of method descriptor and MethodParameters.parameters_count should cause MalformedParameterException In-Reply-To: <545277D9.7030203@oracle.com> References: <54516C9A.7070404@oracle.com> <54527339.5000907@oracle.com> <545277D9.7030203@oracle.com> Message-ID: <5452C124.9020907@oracle.com> On 31/10/2014 3:39 AM, Joe Darcy wrote: > Can't the hotspot and jdk portions of a fix be pushed together now? Yes! Eric you can push hotspot and jdk test change together into whichever team forest you are using. David > -Joe > > On 10/30/2014 10:19 AM, Eric McCorkle wrote: >> There is a test for this, which needs to be added to the jdk repo after >> the change has propagated. I have created the following issue to track >> this: https://bugs.openjdk.java.net/browse/JDK-8062556 >> >> On 10/29/14 18:39, Eric McCorkle wrote: >>> Hello, >>> >>> Please review this fix for parameter reflection which addresses hotspot >>> falsely ignoring zero-length MethodParameter attributes. The JVMS >>> allows a MethodParameters attribute with parameter_count = 0, and the >>> parameter reflection spec states that a MalformedParametersException >>> should be thrown if parameter_count does not match the number of real >>> parameters to a method. Hotspot currently ignores MethodParameters >>> attributes with parameter_count = 0; however, in a case where a (bad) >>> MethodParameters attribute has parameter_count = 0, but the method has a >>> nonzero number of real parameters, hotspot will return null from >>> JVM_GetMethodParameters, the result being that a >>> MalformedParametersException is not thrown (rather, the reflection API >>> acts like there is no MethodParameters attribute). >>> >>> This patch causes hotspot to record the fact that a zero-length >>> MethodParameters attribute does exist, causing the exception to be >>> thrown when it should be. >>> >>> The bug is here: >>> https://bugs.openjdk.java.net/browse/JDK-8058313 >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8058313/ >>> > From david.holmes at oracle.com Thu Oct 30 22:54:55 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 31 Oct 2014 08:54:55 +1000 Subject: Review request for 8058322: Zero name_index item of MethodParameters attribute cause MalformedParameterException In-Reply-To: <54527307.9070601@oracle.com> References: <545100EC.5000204@oracle.com> <545113BA.6010504@oracle.com> <54511D28.4030601@oracle.com> <5451F952.20205@oracle.com> <5452087B.6030306@oracle.com> <545209FC.8020703@oracle.com> <54527307.9070601@oracle.com> Message-ID: <5452C1BF.9020204@oracle.com> On 31/10/2014 3:19 AM, Eric McCorkle wrote: > I forgot to mention, there is a test for this change, but it has to be > added to the jdk repo. Thus, I will add it after the change propagates. No you can push the test (once it is reviewed) and the hotspot changes together into the team forest. You have to do full JDK builds via JPRT these days (use -testset hotspot). PS. Code change reviewed, so if you add the test to the webrev we can review that too. Thanks, David > I have created the following issue to track this: > https://bugs.openjdk.java.net/browse/JDK-8062556 > > On 10/30/14 05:50, David Holmes wrote: >> May as well try to review this now ... >> >> Erik, given: >> >> 814 name = NULL; >> 815 } >> 816 >> 817 Handle rh = java_lang_reflect_Parameter::create(CHECK_NULL); >> 818 java_lang_reflect_Parameter::set_name(rh(), name()); >> >> How is name() handled when name is NULL? Is it some implicit conversion >> operator at play? >> >> Thanks, >> David >> >> On 30/10/2014 7:44 PM, David Holmes wrote: >>> On 30/10/2014 6:39 PM, Albert Noll wrote: >>>> On 10/29/2014 06:00 PM, Eric McCorkle wrote: >>>>> I need a second for hotspot changes, if I recall? >>>> For simple changes, 1 review is enough. >>> >>> Runtime requires 2 reviewers - can't speak for other teams. "simple" is >>> too subjective. >>> >>> David >>> >>>> Best, >>>> Albert >>>> >>>>> On 10/29/14 12:20, Coleen Phillimore wrote: >>>>>> Looks good, Eric. >>>>>> >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>> On 10/29/14, 10:59 AM, Eric McCorkle wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this simple change which addresses a failure >>>>>>> condition in >>>>>>> the method parameter reflection implementation. In the initial >>>>>>> implementation of method parameter reflection, a parameter with a >>>>>>> parameter_name index of 0 denoted a parameter with no name, and >>>>>>> the VM >>>>>>> translated this into the empty string when creating the Parameter >>>>>>> object >>>>>>> to return to Java code. However, towards the end of the 8 cycle, the >>>>>>> spec was updated to state that a zero parameter_name index should >>>>>>> denote >>>>>>> a parameter with no name, and should result in Parameter.getName() >>>>>>> returning an empty string, whereas the empty string /constant/ is >>>>>>> expressly forbidden as a parameter name, and should result in >>>>>>> MalformedParametersException. The reflection API was updated to >>>>>>> reflect >>>>>>> this behavior, but it seems the VM still translates a parameter_name >>>>>>> index of 0 into the empty string. This patch removes that, >>>>>>> resulting in >>>>>>> correct behavior of the reflection API for parameters with no name. >>>>>>> >>>>>>> The webrev is here: >>>>>>> http://cr.openjdk.java.net/~emc/8058322/ >>>>>>> >>>>>>> The bug is here: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8058322 >>>> From eric.mccorkle at oracle.com Thu Oct 30 23:39:32 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 30 Oct 2014 19:39:32 -0400 Subject: Review request for 8058322: Zero name_index item of MethodParameters attribute cause MalformedParameterException In-Reply-To: <5452C1BF.9020204@oracle.com> References: <545100EC.5000204@oracle.com> <545113BA.6010504@oracle.com> <54511D28.4030601@oracle.com> <5451F952.20205@oracle.com> <5452087B.6030306@oracle.com> <545209FC.8020703@oracle.com> <54527307.9070601@oracle.com> <5452C1BF.9020204@oracle.com> Message-ID: <5452CC34.7010702@oracle.com> Thank you. The tests for this patch and the other hotspot patch that is currently under review (both deal with parameter reflection) are here: http://cr.openjdk.java.net/~emc/8062556/ Note that the rules forbid putting binaries in the jdk repo, so in order to test bad class files, we have to put the data in java files. On 10/30/14 18:54, David Holmes wrote: > On 31/10/2014 3:19 AM, Eric McCorkle wrote: >> I forgot to mention, there is a test for this change, but it has to be >> added to the jdk repo. Thus, I will add it after the change propagates. > > No you can push the test (once it is reviewed) and the hotspot changes > together into the team forest. You have to do full JDK builds via JPRT > these days (use -testset hotspot). > > PS. Code change reviewed, so if you add the test to the webrev we can > review that too. > > Thanks, > David > >> I have created the following issue to track this: >> https://bugs.openjdk.java.net/browse/JDK-8062556 >> >> On 10/30/14 05:50, David Holmes wrote: >>> May as well try to review this now ... >>> >>> Erik, given: >>> >>> 814 name = NULL; >>> 815 } >>> 816 >>> 817 Handle rh = java_lang_reflect_Parameter::create(CHECK_NULL); >>> 818 java_lang_reflect_Parameter::set_name(rh(), name()); >>> >>> How is name() handled when name is NULL? Is it some implicit conversion >>> operator at play? >>> >>> Thanks, >>> David >>> >>> On 30/10/2014 7:44 PM, David Holmes wrote: >>>> On 30/10/2014 6:39 PM, Albert Noll wrote: >>>>> On 10/29/2014 06:00 PM, Eric McCorkle wrote: >>>>>> I need a second for hotspot changes, if I recall? >>>>> For simple changes, 1 review is enough. >>>> >>>> Runtime requires 2 reviewers - can't speak for other teams. "simple" is >>>> too subjective. >>>> >>>> David >>>> >>>>> Best, >>>>> Albert >>>>> >>>>>> On 10/29/14 12:20, Coleen Phillimore wrote: >>>>>>> Looks good, Eric. >>>>>>> >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 10/29/14, 10:59 AM, Eric McCorkle wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review this simple change which addresses a failure >>>>>>>> condition in >>>>>>>> the method parameter reflection implementation. In the initial >>>>>>>> implementation of method parameter reflection, a parameter with a >>>>>>>> parameter_name index of 0 denoted a parameter with no name, and >>>>>>>> the VM >>>>>>>> translated this into the empty string when creating the Parameter >>>>>>>> object >>>>>>>> to return to Java code. However, towards the end of the 8 >>>>>>>> cycle, the >>>>>>>> spec was updated to state that a zero parameter_name index should >>>>>>>> denote >>>>>>>> a parameter with no name, and should result in Parameter.getName() >>>>>>>> returning an empty string, whereas the empty string /constant/ is >>>>>>>> expressly forbidden as a parameter name, and should result in >>>>>>>> MalformedParametersException. The reflection API was updated to >>>>>>>> reflect >>>>>>>> this behavior, but it seems the VM still translates a >>>>>>>> parameter_name >>>>>>>> index of 0 into the empty string. This patch removes that, >>>>>>>> resulting in >>>>>>>> correct behavior of the reflection API for parameters with no name. >>>>>>>> >>>>>>>> The webrev is here: >>>>>>>> http://cr.openjdk.java.net/~emc/8058322/ >>>>>>>> >>>>>>>> The bug is here: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8058322 >>>>> From eric.mccorkle at oracle.com Thu Oct 30 23:40:47 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 30 Oct 2014 19:40:47 -0400 Subject: Review request for 8058313: Mismatch of method descriptor and MethodParameters.parameters_count should cause MalformedParameterException In-Reply-To: <54527A90.4030503@oracle.com> References: <54516C9A.7070404@oracle.com> <54518820.50700@oracle.com> <545251AD.8050208@oracle.com> <54527A90.4030503@oracle.com> Message-ID: <5452CC7F.1090809@oracle.com> Thank you for the pointers. I have applied your changes and refreshed the webrev. http://cr.openjdk.java.net/~emc/8058313/ Also, I have posted the test for this and another patch here: http://cr.openjdk.java.net/~emc/8062556/ On 10/30/14 13:51, Jiangli Zhou wrote: > Hi Eric, > > On 10/30/2014 07:56 AM, Eric McCorkle wrote: >> On 10/29/14 20:36, Jiangli Zhou wrote: >>> Hi Eric, >>> >>> I wonder if we could specialize this particular case and avoid changing >>> the parsing code. How about setting the _has_method_parameters flag in >>> the ConstMethod when encounter such MethodParameter, and changing >>> JVM_GetMethodParameters() to return non-NULL value for such case when >>> _has_method_parameters is true but method_parameters_length is 0. Would >>> that work? >> Which parser are you talking about? The inline tables parser, or the >> class file parser. The class file parser has to change, because it was >> previously ignoring MethodParameters attributes with parameter_count 0. > > It's the class parsing changes that I was referring to, mostly relate to > the initialization and checking against method_parameters_length. It's a > bit awkward to include the 0 case but also skipping it in the loop. For > example, the following code in classFileParser.cpp changed ">" to ">=" > in the if check, but has no real effect and is not need. > > 2486 // Copy method parameters > 2487 if (method_parameters_length >= 0) { > 2488 MethodParametersElement* elem = > m->constMethod()->method_parameters_start(); > 2489 for (int i = 0; i < method_parameters_length; i++) { > 2490 elem[i].name_cp_index = > Bytes::get_Java_u2(method_parameters_data); > 2491 method_parameters_data += 2; > 2492 elem[i].flags = Bytes::get_Java_u2(method_parameters_data); > 2493 method_parameters_data += 2; > 2494 } > 2495 } > > >> >> I don't think your proposal will work. The inline tables' offsets are >> all dependent on what inline tables are actually present. If >> _has_method_parameters is set, then the inline tables code expects the >> last u2 of the inline tables to be a u2 indicating the number of method >> parameters entries, preceeded by the array of method parameters data. >> If _has_method_parameters is false, then it expects that there is no >> method parameters information at all (including no length field). If >> you were to set _has_method_parameters, but not store any information in >> the inline table, then it would cause errors for all the rest of the >> inline tables. > > Thank you for reminding me of the complexity of the inlined table > calculation in the ConstMethod. My proposal would require tweaks in that > area to correctly compute the table sizes. As it's easy to introduce > bugs in that area, it's not worth to change the table calculation code > for this purpose. I agree my proposal is not a better choice in this case. > >> What I do for the parameter_count = 0 case is just store >> a 0 u2 for zero-length method parameters information, and no data. All >> the existing inline tables code works fine with this case, so there >> aren't any serious changes to the inline tables code (other than >> allowing method parameters information to be stored when the array is >> length 0). But you have to make some change to the inline table code, >> otherwise the information won't be stored. > > Ok. Could you please add comments to the change in constMethod.cpp to > explain above? > > In jvm.cpp, since -1 represents no method parameter now. Maybe checking > against explicity and add comments for the 0-length case. > > JVM_ENTRY(jobjectArray, JVM_GetMethodParameters(JNIEnv *env, jobject > method)) > { > ... > // No method parameter > if (num_params == -1) { > return (jobjectArray)NULL; > } > > /* handle the rest here */ > // make sure all the symbols are properly formatted > for (int i = 0; i < num_params; i++) { > ... > } > > Thanks, > Jiangli > >> >>> Thanks, >>> Jiangli >>> >>> On 10/29/2014 03:39 PM, Eric McCorkle wrote: >>>> Hello, >>>> >>>> Please review this fix for parameter reflection which addresses hotspot >>>> falsely ignoring zero-length MethodParameter attributes. The JVMS >>>> allows a MethodParameters attribute with parameter_count = 0, and the >>>> parameter reflection spec states that a MalformedParametersException >>>> should be thrown if parameter_count does not match the number of real >>>> parameters to a method. Hotspot currently ignores MethodParameters >>>> attributes with parameter_count = 0; however, in a case where a (bad) >>>> MethodParameters attribute has parameter_count = 0, but the method >>>> has a >>>> nonzero number of real parameters, hotspot will return null from >>>> JVM_GetMethodParameters, the result being that a >>>> MalformedParametersException is not thrown (rather, the reflection API >>>> acts like there is no MethodParameters attribute). >>>> >>>> This patch causes hotspot to record the fact that a zero-length >>>> MethodParameters attribute does exist, causing the exception to be >>>> thrown when it should be. >>>> >>>> The bug is here: >>>> https://bugs.openjdk.java.net/browse/JDK-8058313 >>>> >>>> The webrev is here: >>>> http://cr.openjdk.java.net/~emc/8058313/ > From eric.mccorkle at oracle.com Thu Oct 30 23:41:23 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 30 Oct 2014 19:41:23 -0400 Subject: Review request: JDK-8062556: Add jdk tests for JDK-8058322 and JDK-8058313 Message-ID: <5452CCA3.5040001@oracle.com> Hello, Please review this patch which adds tests to the JDK test suite for two reflection bugs that require hotspot changes (JDK-8058322 and JDK-8058313) The webrev is here: http://cr.openjdk.java.net/~emc/8062556/ From david.holmes at oracle.com Fri Oct 31 01:59:17 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 31 Oct 2014 11:59:17 +1000 Subject: Review request: JDK-8062556: Add jdk tests for JDK-8058322 and JDK-8058313 In-Reply-To: <5452CCA3.5040001@oracle.com> References: <5452CCA3.5040001@oracle.com> Message-ID: <5452ECF5.7020607@oracle.com> Hi Erik, On 31/10/2014 9:41 AM, Eric McCorkle wrote: > Hello, > > Please review this patch which adds tests to the JDK test suite for two > reflection bugs that require hotspot changes (JDK-8058322 and JDK-8058313) > > The webrev is here: > http://cr.openjdk.java.net/~emc/8062556/ I second Brian's comment re the source of the bad classes. Your webrev is broken btw - no top-level html files. The new test needs a copyright year of 2014 not 2013. Thanks, David From brian.goetz at oracle.com Thu Oct 30 23:45:51 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 30 Oct 2014 19:45:51 -0400 Subject: Review request: JDK-8062556: Add jdk tests for JDK-8058322 and JDK-8058313 In-Reply-To: <5452CCA3.5040001@oracle.com> References: <5452CCA3.5040001@oracle.com> Message-ID: <5452CDAF.2020601@oracle.com> I realize you are just adding new bad class files to an existing test, so you're just copying the idiom in the test, but it would be 1000 times more helpful if the comments included a javap or similar listing or even a description of what (bad) class this byte[] array purports to be. Otherwise, how can anyone review that the test does what it claims, other than by hand-disassembling this byte array? On 10/30/2014 7:41 PM, Eric McCorkle wrote: > Hello, > > Please review this patch which adds tests to the JDK test suite for two > reflection bugs that require hotspot changes (JDK-8058322 and JDK-8058313) > > The webrev is here: > http://cr.openjdk.java.net/~emc/8062556/ > From manasthakur17 at gmail.com Fri Oct 31 13:40:03 2014 From: manasthakur17 at gmail.com (Manas Thakur) Date: Fri, 31 Oct 2014 19:10:03 +0530 Subject: Running modified hotspot Message-ID: <1F9353BF-50EC-48D4-BC1A-383543A25614@gmail.com> Hi I am new to hotspot development, but posting this question as I couldn?t solve my problem with existing material. I have built openjdk8 on a linux system. If I change something in the hotspot source (e.g., printing something), from where should I check the changed outputs. I don?t want to re-build the complete jdk again. At this point, I tried going inside "hotspot/make" and ran ?make debug?. From where am I supposed to run ?java? and ?java? so that I can see the changes in effect. I am not able to find ?gamma?, which used to be in openjdk7. Regards, Manas From eric.mccorkle at oracle.com Fri Oct 31 14:01:09 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 31 Oct 2014 10:01:09 -0400 Subject: Review request: JDK-8062556: Add jdk tests for JDK-8058322 and JDK-8058313 In-Reply-To: <5452ECF5.7020607@oracle.com> References: <5452CCA3.5040001@oracle.com> <5452ECF5.7020607@oracle.com> Message-ID: <54539625.7070302@oracle.com> I went through and added comments in the binary data indicating where the MethodParameters attributes are, and a breakdown of their contents. I went ahead and did this for all the bad class files, not just the new ones. There is a larger picture here: there's an outstanding task I filed around the time these tests were written to find a better way for langtools to run jtreg tests that involve bad class files. Unfortunately, doing that is rather difficult, as you can see. The only real way to do it is to generate a class file, convert it to signed bytes (you can't even use hex; you get an unsigned/signed byte conversion problem), then modify the data by hand. The intent is to replace this with a better method at some point. On 10/30/14 21:59, David Holmes wrote: > Hi Erik, > > On 31/10/2014 9:41 AM, Eric McCorkle wrote: >> Hello, >> >> Please review this patch which adds tests to the JDK test suite for two >> reflection bugs that require hotspot changes (JDK-8058322 and >> JDK-8058313) >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8062556/ > > I second Brian's comment re the source of the bad classes. > > Your webrev is broken btw - no top-level html files. > > The new test needs a copyright year of 2014 not 2013. > > Thanks, > David > From aleksey.shipilev at oracle.com Fri Oct 31 14:10:05 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 31 Oct 2014 17:10:05 +0300 Subject: Running modified hotspot In-Reply-To: <1F9353BF-50EC-48D4-BC1A-383543A25614@gmail.com> References: <1F9353BF-50EC-48D4-BC1A-383543A25614@gmail.com> Message-ID: <5453983D.7010609@oracle.com> On 10/31/2014 04:40 PM, Manas Thakur wrote: > I am new to hotspot development, but posting this question as I > couldn?t solve my problem with existing material. I have built > openjdk8 on a linux system. If I change something in the hotspot > source (e.g., printing something), from where should I check the > changed outputs. I don?t want to re-build the complete jdk again. Do "make images" from the forest root, then look for JDK binaries in build/*/images/j2sdk-image/. If you don't touch JDK, it will be "rebuilt" very fast. -Aleksey. From manasthakur17 at gmail.com Fri Oct 31 14:30:46 2014 From: manasthakur17 at gmail.com (Manas Thakur) Date: Fri, 31 Oct 2014 20:00:46 +0530 Subject: Running modified hotspot In-Reply-To: <5453983D.7010609@oracle.com> References: <1F9353BF-50EC-48D4-BC1A-383543A25614@gmail.com> <5453983D.7010609@oracle.com> Message-ID: <54539D16.3010106@gmail.com> Thanks a lot Aleksey. - Manas On Friday 31 October 2014 07:40 PM, Aleksey Shipilev wrote: > On 10/31/2014 04:40 PM, Manas Thakur wrote: >> I am new to hotspot development, but posting this question as I >> couldn?t solve my problem with existing material. I have built >> openjdk8 on a linux system. If I change something in the hotspot >> source (e.g., printing something), from where should I check the >> changed outputs. I don?t want to re-build the complete jdk again. > Do "make images" from the forest root, then look for JDK binaries in > build/*/images/j2sdk-image/. If you don't touch JDK, it will be > "rebuilt" very fast. > > -Aleksey. > > > From serguei.spitsyn at oracle.com Fri Oct 31 21:07:00 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 31 Oct 2014 14:07:00 -0700 Subject: 3-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <54518EE1.9040208@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> Message-ID: <5453F9F4.20309@oracle.com> It is 3-rd round of review for: https://bugs.openjdk.java.net/browse/JDK-6988950 New webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ Summary For failing scenario, please, refer to the 1-st round RFR below. I've found what is missed in the jdwp agent shutdown and decided to switch from a workaround to a real fix. The agent VM_DEATH callback sets the gdata field: gdata->vmDead = 1. The agent debugLoop_run() has a guard against the VM shutdown: 165 } else if (gdata->vmDead && 166 ((cmd->cmdSet) != JDWP_COMMAND_SET(VirtualMachine))) { 167 /* Protect the VM from calls while dead. 168 * VirtualMachine cmdSet quietly ignores some cmds 169 * after VM death, so, it sends it's own errors. 170 */ 171 outStream_setError(&out, JDWP_ERROR(VM_DEAD)); However, the guard above does not help much if the VM_DEATH event happens in the middle of a command execution. There is a lack of synchronization here. The fix introduces new lock (vmDeathLock) which does not allow to execute the commands and the VM_DEATH event callback concurrently. It should work well for any function that is used in implementation of the JDWP_COMMAND_SET(VirtualMachine) . Testing: Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests Thanks, Serguei On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: > The updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ > > > The changes are: > - added a comment recommended by Staffan > - removed the ignore_wrong_phase() call from function classSignature() > > The classSignature() function is called in 16 places. > Most of them do not tolerate the NULL in place of returned signature > and will crash. > I'm not comfortable to fix all the occurrences now and suggest to > return to this > issue after gaining experience with more failure cases that are still > expected. > The failure with the classSignature() involved was observed only once > in the nightly > and should be extremely rare reproducible. > I'll file a placeholder bug if necessary. > > Thanks, > Serguei > > On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6988950 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >> >> >> >> Summary: >> >> The failing scenario: >> The debugger and the debuggee are well aware a VM shutdown has >> been started in the target process. >> The debugger at this point is not expected to send any commands >> to the JDWP agent. >> However, the JDI layer (debugger side) and the jdwp agent >> (debuggee side) >> are not in sync with the consumer layers. >> >> One reason is because the test debugger does not invoke the JDI >> method VirtualMachine.dispose(). >> Another reason is that the Debugger and the debuggee processes >> are uneasy to sync in general. >> >> As a result the following steps are possible: >> - The test debugger sends a 'quit' command to the test debuggee >> - The debuggee is normally exiting >> - The jdwp backend reports (over the jdwp protocol) an >> anonymous class unload event >> - The JDI InternalEventHandler thread handles the >> ClassUnloadEvent event >> - The InternalEventHandler wants to uncache the matching >> reference type. >> If there is more than one class with the same host class >> signature, it can't distinguish them, >> and so, deletes all references and re-retrieves them again >> (see tracing below): >> MY_TRACE: JDI: >> VirtualMachineImpl.retrieveClassesBySignature: >> sig=Ljava/lang/invoke/LambdaForm$DMH; >> - The jdwp backend debugLoop_run() gets the command from JDI >> and calls the functions >> classesForSignature() and classStatus() recursively. >> - The classStatus() makes a call to the JVMTI GetClassStatus() >> and gets the JVMTI_ERROR_WRONG_PHASE >> - As a result the jdwp backend reports the JVMTI error to the >> JDI, and so, the test fails >> >> For details, see the analysis in bug report closed as a dup of >> the bug 6988950: >> https://bugs.openjdk.java.net/browse/JDK-8024865 >> >> Some similar cases can be found in the two bug reports (6988950 >> and 8024865) describing this issue. >> >> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error >> as it is normal at the VM shutdown. >> The original jdwp backend implementation had a similar approach >> for the raw monitor functions. >> Threy use the ignore_vm_death() to workaround the >> JVMTI_ERROR_WRONG_PHASE errors. >> For reference, please, see the file: src/share/back/util.c >> >> >> Testing: >> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >> >> >> Thanks, >> Serguei >> >