From kim.barrett at oracle.com Sat Aug 1 01:15:35 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 31 Jul 2015 21:15:35 -0400 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55BBB894.6090202@oracle.com> References: <55BBB894.6090202@oracle.com> Message-ID: <33BEC3CE-D779-4621-8980-8D35D9FBB0D4@oracle.com> On Jul 31, 2015, at 2:04 PM, gerard ziemski wrote: > > Please review this webrev 2 of the follow-up fixes including: > > - Adding DBL_MAX (requested by Kim Barrett) > > - Passing values by value, not pointer, to constraint functions. It was thought originally that me way want to ?fix? the values, but it was decided to be out of scope for the JEP. (requested by Coleen) > > - Add print_error_as_needed() utility function to range/constraint code to improve code robustness (requested by Coleen) > > - Remove debug code (requested by Kim Barrett) > > - Implement Flag::flag_error_str in .cpp file (requested by Kim Barrett) > > - Only check constraint if range passes (requested by Kim Barrett) > > - Merged with Sangheon Kim fix for "Add additional validation after heap creation? (JDK-8130459) > > > This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? > > > References: > > JEP 245: > https://bugs.openjdk.java.net/browse/JDK-8122937 > > bug: > https://bugs.openjdk.java.net/browse/JDK-8112746 > > webrev: > http://cr.openjdk.java.net/~gziemski/8112746_rev2/ Not a full review, for reasons that will be discussed below. I decided to stop and see if I can convince you to do something about the first couple of items before I go any further. ------------------------------------------------------------------------------ I really wish this had been broken up into separate issues with associated changesets, rather than one large combined changeset. I realize that breaking it up will be more work for you, but it would make a substantial difference in the quality of my review. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 71 "greater than ergonomic PLAB minimum size (" SIZE_FORMAT ")\n", Copy-paste bug: this should be "less than ... maximum". The formatting changes in the strings seem (mostly?) unnecessary, and make the review much more difficult. [Later] After trying and failing to review these changes (my eyes keep crossing) I'd really prefer the string formatting changes were reverted, unless there's some real change hiding in there that I'm failing to see. ------------------------------------------------------------------------------ src/share/vm/gc/g1/g1_globals.hpp 75 range(1.0, DBL_MAX) \ I vaguely recall an issue being raised about this causing problems with the output when dumping the option values and their ranges. Something about the printed value of DBL_MAX being excessively long. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp src/share/vm/runtime/commandLineFlagConstraintsGC.cpp src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp src/share/vm/runtime/commandLineFlagRangeList.cpp Duplicated print_error_if_needed. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.cpp 518 const char* Flag::flag_error_str(Flag::Error error) { 519 switch (error) { ... 528 default: return "NULL"; I think that default is a "should not reach here" situation? ------------------------------------------------------------------------------ From david.holmes at oracle.com Mon Aug 3 06:01:37 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Aug 2015 16:01:37 +1000 Subject: RFR: 8130212: Thread::current() might access freed memory on Solaris In-Reply-To: <55BAD972.302@oracle.com> References: <55B868A3.2080602@oracle.com> <55B86A54.7000708@oracle.com> <55B86AF8.9070104@oracle.com> <7F33558F-F6DF-4594-B35E-F72BCEAA1300@oracle.com> <55B952CF.2000109@oracle.com> <55B965AB.9050204@oracle.com> <55B9AAA5.6000704@oracle.com> <55BA6D28.2000407@oracle.com> <55BA9E3D.4080207@oracle.com> <55BAD972.302@oracle.com> Message-ID: <55BF03C1.9000902@oracle.com> Hi Vladimir, On 31/07/2015 12:12 PM, Vladimir Kozlov wrote: > > I can add a 32-bit version of the change but am not sure how to test it. > > Can we still easily build 32-bit Solaris or do I need to hack the build > > systems somehow? > > You have to build first 32-bit 8u60 (using 7u80, for example, as boot > jdk). And then use it as boot jdk for jdk9 32-bit build. Both builds > have to be configured with --with-target-bits=32. > > And there are no way to do that in JPRT as I know. Only manually :( > > If it is hard for you I will manage (will prepare patch later). > > So I am fine with current code if you don't want to spend more time on it. I tried applying my patch to jkd8u-dev and performing the 32-bit changes there to test it out. But when I did the 32-bit build the resulting binaries would not even run! > ./b00/se-solaris-i586-internal/images/j2sdk-image/bin/java -client -version Error: dl failure on line 893 Error: failed /scratch/dh198349/jdk8u-dev/build/b00/se-solaris-i586-internal/images/j2sdk-image/jre/lib/i386/client/libjvm.so, because ld.so.1: java: fatal: /scratch/dh198349/jdk8u-dev/build/b00/se-solaris-i586-internal/images/j2sdk-image/jre/lib/i386/client/libjvm.so: open failed: No such file or directory > find b00/se-solaris-i586-internal/images/j2sdk-image/ -name libjvm.so b00/se-solaris-i586-internal/images/j2sdk-image/jre/lib/i386/server/libjvm.so b00/se-solaris-i586-internal/images/j2sdk-image/jre/lib/i386/client/libjvm.so I have no idea what is going on. So, sorry, but I won't be doing the 32-bit variant. David ----- > Thanks, > Vladimir > > On 7/30/15 2:59 PM, David Holmes wrote: >> Hi Vladimir, >> >> On 31/07/2015 4:30 AM, Vladimir Kozlov wrote: >>> On 7/29/15 9:40 PM, David Holmes wrote: >>>> Hi Vladimir, >>>> >>>> On 30/07/2015 9:45 AM, Vladimir Kozlov wrote: >>>>> David, >>>>> >>>>> I don't see changes in macroAssembler_sparc.cpp for get_thread(). >>>> >>>> There's no need it already simply calls ThreadLocalStorage::thread >>>> (with an indirection for debug builds) >>> >>> You are right. >>> >>>> >>>>> Did you look what assembler is generated for thread() method?: >>>>> >>>>> inline Thread* ThreadLocalStorage::thread() { >>>>> return _thr_current; >>>>> } >>>> >>>> In the object file it generates code of the form (for x86): >>>> >>>> leaq +0x0(%rip),%rdi >>>> >>>> followed by a call that is translated as a call to _tls_get_addr. But >>>> there is a lot of link-edit time manipulation of >>>> the code. I don't know how to find the exact runtime code. >>> >>> Yes, I realized it will be difficult to reproduce what C++ compiler and >>> liker will do. >>> >>>> >>>>> >>>>> It would be nice to avoid runtime call in assembler if we know address >>>>> of _thr_current. >>>> >>>> But the address itself would be a per-thread variable that we'd need >>>> to get from somewhere ?? >>> >>> Yes, yes, it is true. And we want to avoid any tables which led to this >>> problem. >>> Okay, since it is slow path we can do call. >>> >>> Last thing. Can you preserve separate versions for 32- and 64-bits? >>> Sometimes I have to build 32-bit Sol-x86 for debugging with dbx. >> >> I was under the impression that 32-bit Solaris support had been flagged >> for deletion. >> >> I can add a 32-bit version of the change but am not sure how to test it. >> Can we still easily build 32-bit Solaris or do I need to hack the build >> systems somehow? >> >> Thanks, >> David >> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 7/29/15 3:38 PM, Christian Thalinger wrote: >>>>>> >>>>>>> On Jul 29, 2015, at 3:25 PM, David Holmes >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 30/07/2015 1:28 AM, Christian Thalinger wrote: >>>>>>>> Now that threadLS_solaris_sparc.{cpp,hpp} and >>>>>>>> threadLS_solaris_x86.{cpp,hop} look exactly the same it would be >>>>>>>> nice to merge them into threadLS_solaris.{cpp,hpp}. >>>>>>> >>>>>>> In the next phase: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8132510 >>>>>>> >>>>>>> these files will disappear completely. Can this wait till then? >>>>>> >>>>>> Yes. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>>> On Jul 28, 2015, at 10:56 PM, David Holmes >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Moved to hotspot-dev so the compiler folk also see this for the >>>>>>>>> MacroAssembler changes. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 29/07/2015 3:53 PM, David Holmes wrote: >>>>>>>>>> I forgot to credit Dave Dice with the suggestion to modernize >>>>>>>>>> this >>>>>>>>>> code. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 29/07/2015 3:46 PM, David Holmes wrote: >>>>>>>>>>> Summary: replace complex custom code for maintaining >>>>>>>>>>> ThreadLocalStorage >>>>>>>>>>> with compiler supported thread-local variables (Solaris only) >>>>>>>>>>> >>>>>>>>>>> This is a non-public bug so let me explain with some >>>>>>>>>>> background, the >>>>>>>>>>> bug, and then the fix - which involves lots of complex-code >>>>>>>>>>> deletion and >>>>>>>>>>> addition of some very simple code. :) >>>>>>>>>>> >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8130212/webrev/ >>>>>>>>>>> >>>>>>>>>>> In various parts of the runtime and in compiler generated >>>>>>>>>>> code we >>>>>>>>>>> need >>>>>>>>>>> to get a reference to the (VM-level) Thread* of the currently >>>>>>>>>>> executing >>>>>>>>>>> thread. This is what Thread::current() returns. For performance >>>>>>>>>>> reasons >>>>>>>>>>> we also have a fast-path on 64-bit where the Thread* is stashed >>>>>>>>>>> away in >>>>>>>>>>> a register (g7 on sparc, r15 on x64). >>>>>>>>>>> >>>>>>>>>>> So Thread::current() is actually a slow-path mechanism and it >>>>>>>>>>> delegates >>>>>>>>>>> to ThreadLocalStorage::thread(). >>>>>>>>>>> >>>>>>>>>>> On some systems ThreadLocalStorage::thread utilizes a caching >>>>>>>>>>> mechanism >>>>>>>>>>> to try and speed up access to the current thread. Otherwise it >>>>>>>>>>> calls >>>>>>>>>>> into yet another "slow" path which uses the available platform >>>>>>>>>>> thread-specific-storage APIs. >>>>>>>>>>> >>>>>>>>>>> Compiled code also has a slow-path get_thread() method which >>>>>>>>>>> uses >>>>>>>>>>> assembly code to invoke the same platform >>>>>>>>>>> thread-specific-storage >>>>>>>>>>> APIs >>>>>>>>>>> (in some cases - on sparc it simply calls >>>>>>>>>>> ThreadLocalStorage::thread()). >>>>>>>>>>> >>>>>>>>>>> On Solaris 64-bit (which is all we support today) there is a >>>>>>>>>>> simple >>>>>>>>>>> 1-level thread cache which is an array of Thread*. If a thread >>>>>>>>>>> doesn't >>>>>>>>>>> find itself in the slot for the hash of its id it inserts itself >>>>>>>>>>> there. >>>>>>>>>>> As a thread terminates it clears out its ThreadLocalStorage >>>>>>>>>>> values >>>>>>>>>>> including any cached reference. >>>>>>>>>>> >>>>>>>>>>> The bug is that we have potential for a read-after-free error >>>>>>>>>>> due to >>>>>>>>>>> this code: >>>>>>>>>>> >>>>>>>>>>> 46 uintptr_t raw = pd_raw_thread_id(); >>>>>>>>>>> 47 int ix = pd_cache_index(raw); // hashes id >>>>>>>>>>> 48 Thread* candidate = >>>>>>>>>>> ThreadLocalStorage::_get_thread_cache[ix]; >>>>>>>>>>> 49 if (candidate->self_raw_id() == raw) { >>>>>>>>>>> 50 // hit >>>>>>>>>>> 51 return candidate; >>>>>>>>>>> 52 } else { >>>>>>>>>>> 53 return >>>>>>>>>>> ThreadLocalStorage::get_thread_via_cache_slowly(raw, >>>>>>>>>>> ix); >>>>>>>>>>> 54 } >>>>>>>>>>> >>>>>>>>>>> The problem is that the value read as candidate could be a >>>>>>>>>>> thread >>>>>>>>>>> that >>>>>>>>>>> (after line 48) terminated and was freed. But line #49 then >>>>>>>>>>> reads >>>>>>>>>>> the >>>>>>>>>>> raw id of that thread, which is then a read-after-free - >>>>>>>>>>> which is >>>>>>>>>>> a "Bad >>>>>>>>>>> Thing (TM)". >>>>>>>>>>> >>>>>>>>>>> There's no simple fix for the caching code - you would need a >>>>>>>>>>> completely >>>>>>>>>>> different approach (or synchronization that would nullify the >>>>>>>>>>> whole >>>>>>>>>>> point of the cache). >>>>>>>>>>> >>>>>>>>>>> Now all this ThreadLocalStorage code is pretty old and was >>>>>>>>>>> put in >>>>>>>>>>> place >>>>>>>>>>> to deal with inadequacies of the system provided >>>>>>>>>>> thread-specific-storage >>>>>>>>>>> API. In fact on Solaris we even by-pass the public API >>>>>>>>>>> (thr_getspecific/thr_setspecific) when we can and implement our >>>>>>>>>>> own >>>>>>>>>>> version using lower-level APIs available in the T1/T2 threading >>>>>>>>>>> libraries! >>>>>>>>>>> >>>>>>>>>>> In mid-2015 things have changed considerably and we have >>>>>>>>>>> reliable >>>>>>>>>>> and >>>>>>>>>>> performant support for thread-local variables at the C+ >>>>>>>>>>> language-level. >>>>>>>>>>> So the way to maintain the current thread is simply using: >>>>>>>>>>> >>>>>>>>>>> // Declaration of thread-local variable >>>>>>>>>>> static __thread Thread * _thr_current >>>>>>>>>>> >>>>>>>>>>> inline Thread* ThreadLocalStorage::thread() { >>>>>>>>>>> return _thr_current; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> inline void ThreadLocalStorage::set_thread(Thread* thread) { >>>>>>>>>>> _thr_current = thread; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> And all the complex ThreadLocalStorage code with caching etc all >>>>>>>>>>> vanishes! >>>>>>>>>>> >>>>>>>>>>> For my next trick I plan to try and remove the >>>>>>>>>>> ThreadLocalStorage >>>>>>>>>>> class >>>>>>>>>>> completely by using language-based thread-locals on all >>>>>>>>>>> platforms. But >>>>>>>>>>> for now this is just Solaris and so we still need the >>>>>>>>>>> ThreadLocalStorage >>>>>>>>>>> API. However a lot of that API is not needed any more on Solaris >>>>>>>>>>> so I >>>>>>>>>>> have excluded it from there in the shared code (ifndef SOLARIS). >>>>>>>>>>> But to >>>>>>>>>>> avoid changing other shared-code callsites of ThreadLocalStorage >>>>>>>>>>> I've >>>>>>>>>>> kept part of the API with trivial implementations on Solaris. >>>>>>>>>>> >>>>>>>>>>> Testing: JPRT >>>>>>>>>>> All hotspot regression tests >>>>>>>>>>> >>>>>>>>>>> I'm happy to run more tests but the nice thing about such >>>>>>>>>>> low-level code >>>>>>>>>>> is that if it is broken, it is always broken :) Every use of >>>>>>>>>>> Thread::current or MacroAssembler::get_thread now hits this >>>>>>>>>>> code. >>>>>>>>>>> >>>>>>>>>>> Performance: I've run a basic set of benchmarks that is readily >>>>>>>>>>> available to me on our performance testing system. The best >>>>>>>>>>> way to >>>>>>>>>>> describe the result is neutral. There are some slight wins, and >>>>>>>>>>> some >>>>>>>>>>> slight losses, with most showing no statistical difference. And >>>>>>>>>>> even the >>>>>>>>>>> "wins" and "losses" are within the natural variations of the >>>>>>>>>>> benchmarks. >>>>>>>>>>> So a lot of complex code has been replaced by simple code and we >>>>>>>>>>> haven't >>>>>>>>>>> lost any observable performance - which seems like a win to me. >>>>>>>>>>> >>>>>>>>>>> Also product mode x64 libjvm.so has shrunk by 921KB - which is a >>>>>>>>>>> little >>>>>>>>>>> surprising but very nice. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>> >>>>>> From sgehwolf at redhat.com Mon Aug 3 08:24:34 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 03 Aug 2015 10:24:34 +0200 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. In-Reply-To: References: <1438175342.3485.37.camel@redhat.com> <55B9ACF1.60004@oracle.com> <1438255696.3396.39.camel@redhat.com> <1438262048.3396.49.camel@redhat.com> <1438267938.3396.71.camel@redhat.com> <1438272357.13884.15.camel@redhat.com> Message-ID: <1438590274.3321.9.camel@redhat.com> On Fri, 2015-07-31 at 17:04 +0200, Volker Simonis wrote: > > > On Thu, Jul 30, 2015 at 6:05 PM, Severin Gehwolf > wrote: > On Thu, 2015-07-30 at 16:52 +0200, Severin Gehwolf wrote: > > > >> If a normal thread doesn't honor the > -XX:ThreadStackSize settings I'd > > > >> consider that a bug and fix that one first. > > > > > > > > By fixing it you mean in jdk or hotspot code? Any > suggestions? > > > > > > > > > > I mean in the hostspot code. But of coarse only if the > above tests > > > show that the settings are not honored by the VM. > > > > OK. > > So I did more experimentation with this and here is what I > found. Any > JVM with -Xint fall back to the bigger of > os::Linux::min_stack_allowed > as set in src/os_cpu/linux_$CPU/vm/os_linux_$CPU.cpp and the > following > calculation coming from os::init_2 for the reproducer in [1]: > > MAX2(os::Linux::min_stack_allowed, > (size_t)(StackYellowPages+StackRedPages > +StackShadowPages) * Linux::page_size() + > (2*BytesPerWord COMPILER2_PRESENT(+1)) * > Linux::vm_default_page_size()); > > It can be fairly easy reproduced with: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/ZeroStackOverflowTest.java > > The following produces a stack overflow for me on x86_64: > /path/to/java -Xint ZeroStackOverflowTest 1280 > If I change this to: > /path/to/java -Xint -XX:ThreadStackSize=2028 > ZeroStackOverflowTest 1280 > nothing changes. I.e. the stack overflow still happens at > ~1266'th call. > > > > I don't understand what you want to prove with this test. If you > create a thread yourself with a given stack size (like in your > example) then of course the -XX:ThreadStackSize setting will have no > impact. That's exactly how it should work if YOU specify the stack > size in the Thread constructor. Sorry, I confused your statement it seems: "If a normal thread doesn't honor the -XX:ThreadStackSize settings I'd consider that a bug and fix that one first." I took the above as "a thread created with the 4-arg constructor should honor -XX:ThreadStackSize as well". That it does not (apparently by design). Nevertheless, it seems nonsense to me to specify the stack size via Java code since it seems rather JVM specific. Some JDK code does that. > I took your reproducer and run it in a Java debugger with a breakpoint > in java.lang.Thread.. I only see that the various compiler > threads and the sweeper and service threads are created - all of them > without specifying a thread size. > > > I've also run your reproduce in gdb with a breakpoint in > os::create_thread(). Here you will see all the threads which are > created by the VM (including the main thread) and all of them are > created with 'stack_size=0' which means default stack size. For > Java-threads, the default stack size is the one you give with > -Xss/-XX:ThreadStackSize > > case os::java_thread: > // Java threads use ThreadStackSize which default value can be > // changed with the flag -Xss > assert(JavaThread::stack_size_at_create() > 0, "this should be > set"); > stack_size = JavaThread::stack_size_at_create(); > break; > > > If this is not working for Zero you should analyze that problem. > > > But your reproducer is definitely not creating a Java thread with a > custom stack size. Fair enough. I'll have another look. Thanks for your feedback. Cheers, Severin From dmitry.dmitriev at oracle.com Mon Aug 3 12:08:26 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Mon, 3 Aug 2015 15:08:26 +0300 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55BBB894.6090202@oracle.com> References: <55BBB894.6090202@oracle.com> Message-ID: <55BF59BA.7080105@oracle.com> Hello Gerard, As Kim mention, I have one concern about new upper range for G1ConcMarkStepDurationMillis which now equal to "DBL_MAX". This value can be very huge. For example, I check it on my Linux-x64 and got value which is more than 300 characters long. Moreover we can not pass that huge value to the JVM since JVM can process only values which less than 256 characters long. Otherwise it will report that option is improperly specified. And also output of "-XX:+PrintFlagsRanges" looks strange with this very long value :) I think that upper range can be lowered for that flag without impacting users. For example we can use very big value for that option, e.g. 10000000000000000000.0 (i.e. something between (double)max_intx and (double)max_uintx). G1ConcMarkStepDurationMillis is a duration in milliseconds, so max value 10000000000000000000.0 will represent duration equal to (((10000000000000000000.0 / 1000) / 3600 seconds) / 24 hours) / 365 days = ~317097919 years. I think that this will be enough for all. Regards, Dmitry On 31.07.2015 21:04, gerard ziemski wrote: > Please review this webrev 2 of the follow-up fixes including: > > - Adding DBL_MAX (requested by Kim Barrett) > > - Passing values by value, not pointer, to constraint functions. It was thought originally that me way want to ?fix? the values, but it was decided to be out of scope for the JEP. (requested by Coleen) > > - Add print_error_as_needed() utility function to range/constraint code to improve code robustness (requested by Coleen) > > - Remove debug code (requested by Kim Barrett) > > - Implement Flag::flag_error_str in .cpp file (requested by Kim Barrett) > > - Only check constraint if range passes (requested by Kim Barrett) > > - Merged with Sangheon Kim fix for "Add additional validation after heap creation? (JDK-8130459) > > > This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? > > > References: > > JEP 245:https://bugs.openjdk.java.net/browse/JDK-8122937 > bug:https://bugs.openjdk.java.net/browse/JDK-8112746 > webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev2/ > From matthias.baesken at sap.com Mon Aug 3 14:05:09 2015 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 3 Aug 2015 14:05:09 +0000 Subject: Remaining space between literal and identifier - issue Message-ID: <98C2119538350A4E92B3DD08E7B4146801981A2006@DEWDFEMB14B.global.corp.sap> Hello, in "8081202 C++11 requires a space between literal and identifier", see http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018665.html a number of places in hotspot coding with missing spaces between literals and identifiers were already fixed. When experimenting with Visual Studio 2015 (which refuses compiling such code) , I noticed that this fix is missing here : hotspot/src/share/vm/interpreter/interpreterRuntime.cpp The following small diff is fixing the remaining issue. 1306c1306 < tty->print_cr("argument handler #%d at "PTR_FORMAT" for fingerprint " UINT64_FORMAT, --- > tty->print_cr("argument handler #%d at " PTR_FORMAT " for fingerprint " UINT64_FORMAT, 1316c1316 < tty->print_cr("duplicate argument handler #%d for fingerprint " UINT64_FORMAT "(old: "PTR_FORMAT", new : "PTR_FORMAT")", --- > tty->print_cr("duplicate argument handler #%d for fingerprint " UINT64_FORMAT "(old: " PTR_FORMAT ", new : " PTR_FORMAT ")", Could you please add the small fix ? Thanks, Matthias From gerard.ziemski at oracle.com Mon Aug 3 14:29:35 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Mon, 03 Aug 2015 09:29:35 -0500 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55BF59BA.7080105@oracle.com> References: <55BBB894.6090202@oracle.com> <55BF59BA.7080105@oracle.com> Message-ID: <55BF7ACF.1000304@oracle.com> hi Dmitry, Kim, Agree, the value looks ridiculous, though test/runtime/CommandLine/OptionsValidation test seems to work just fine with it. So I originally had G1ConcMarkStepDurationMillis range defined as "range(0, (double)max_uintx)", but the request was to use mathematically correct bound, ie. DBL_MAX, as any other value would have to be carefully determined as it's a user limiting change. Sangheon, is currently working on JDK-8059555, so maybe I should leave this flag to him, since it's a GC flag and he already indicated that he thinks he will need DBL_MAX for other flags? It looks like Sangheon will be faced with the same kind of issue for other flags, so maybe we should leave this issue up to him and have a single discussion about this and other flags at the same time? Sanghon, is it OK if I take this particular change out and you and GC team will handle it as you find appropriate while you work on JDK-8059555? cheers On 08/03/2015 07:08 AM, Dmitry Dmitriev wrote: > Hello Gerard, > > As Kim mention, I have one concern about new upper range for > G1ConcMarkStepDurationMillis which now equal to "DBL_MAX". This value > can be very huge. For example, I check it on my Linux-x64 and got > value which is more than 300 characters long. Moreover we can not pass > that huge value to the JVM since JVM can process only values which > less than 256 characters long. Otherwise it will report that option is > improperly specified. And also output of "-XX:+PrintFlagsRanges" looks > strange with this very long value :) > I think that upper range can be lowered for that flag without > impacting users. For example we can use very big value for that > option, e.g. 10000000000000000000.0 (i.e. something between > (double)max_intx and (double)max_uintx). G1ConcMarkStepDurationMillis > is a duration in milliseconds, so max value 10000000000000000000.0 > will represent duration equal to (((10000000000000000000.0 / 1000) / > 3600 seconds) / 24 hours) / 365 days = ~317097919 years. I think that > this will be enough for all. > > Regards, > Dmitry > > On 31.07.2015 21:04, gerard ziemski wrote: >> Please review this webrev 2 of the follow-up fixes including: >> >> - Adding DBL_MAX (requested by Kim Barrett) >> >> - Passing values by value, not pointer, to constraint functions. It was thought originally that me way want to ?fix? the values, but it was decided to be out of scope for the JEP. (requested by Coleen) >> >> - Add print_error_as_needed() utility function to range/constraint code to improve code robustness (requested by Coleen) >> >> - Remove debug code (requested by Kim Barrett) >> >> - Implement Flag::flag_error_str in .cpp file (requested by Kim Barrett) >> >> - Only check constraint if range passes (requested by Kim Barrett) >> >> - Merged with Sangheon Kim fix for "Add additional validation after heap creation? (JDK-8130459) >> >> >> This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? >> >> >> References: >> >> JEP 245:https://bugs.openjdk.java.net/browse/JDK-8122937 >> bug:https://bugs.openjdk.java.net/browse/JDK-8112746 >> webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev2/ >> > From sangheon.kim at oracle.com Mon Aug 3 14:54:25 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 03 Aug 2015 07:54:25 -0700 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55BF7ACF.1000304@oracle.com> References: <55BBB894.6090202@oracle.com> <55BF59BA.7080105@oracle.com> <55BF7ACF.1000304@oracle.com> Message-ID: <55BF80A1.8030301@oracle.com> Hi Gerard, On 08/03/2015 07:29 AM, gerard ziemski wrote: > hi Dmitry, Kim, > > Agree, the value looks ridiculous, though > test/runtime/CommandLine/OptionsValidation test seems to work just > fine with it. > > So I originally had G1ConcMarkStepDurationMillis range defined as > "range(0, (double)max_uintx)", but the request was to use > mathematically correct bound, ie. DBL_MAX, as any other value would > have to be carefully determined as it's a user limiting change. > > Sangheon, is currently working on JDK-8059555, so maybe I should leave > this flag to him, since it's a GC flag and he already indicated that > he thinks he will need DBL_MAX for other flags? It looks like Sangheon > will be faced with the same kind of issue for other flags, so maybe we > should leave this issue up to him and have a single discussion about > this and other flags at the same time? > > Sanghon, is it OK if I take this particular change out and you and GC > team will handle it as you find appropriate while you work on JDK-8059555? Okay, I will take this DBL_MAX part from 8078555 (not 8059555). Actually I remember that Dmitry already mentioned the possible problem of DBL_MAX. So I was waiting the result here after asking you in separate email. :) Thanks, Sangheon > > > cheers > > > On 08/03/2015 07:08 AM, Dmitry Dmitriev wrote: >> Hello Gerard, >> >> As Kim mention, I have one concern about new upper range for >> G1ConcMarkStepDurationMillis which now equal to "DBL_MAX". This value >> can be very huge. For example, I check it on my Linux-x64 and got >> value which is more than 300 characters long. Moreover we can not >> pass that huge value to the JVM since JVM can process only values >> which less than 256 characters long. Otherwise it will report that >> option is improperly specified. And also output of >> "-XX:+PrintFlagsRanges" looks strange with this very long value :) >> I think that upper range can be lowered for that flag without >> impacting users. For example we can use very big value for that >> option, e.g. 10000000000000000000.0 (i.e. something between >> (double)max_intx and (double)max_uintx). G1ConcMarkStepDurationMillis >> is a duration in milliseconds, so max value 10000000000000000000.0 >> will represent duration equal to (((10000000000000000000.0 / 1000) / >> 3600 seconds) / 24 hours) / 365 days = ~317097919 years. I think that >> this will be enough for all. >> >> Regards, >> Dmitry >> >> On 31.07.2015 21:04, gerard ziemski wrote: >>> Please review this webrev 2 of the follow-up fixes including: >>> >>> - Adding DBL_MAX (requested by Kim Barrett) >>> >>> - Passing values by value, not pointer, to constraint functions. It was thought originally that me way want to ?fix? the values, but it was decided to be out of scope for the JEP. (requested by Coleen) >>> >>> - Add print_error_as_needed() utility function to range/constraint code to improve code robustness (requested by Coleen) >>> >>> - Remove debug code (requested by Kim Barrett) >>> >>> - Implement Flag::flag_error_str in .cpp file (requested by Kim Barrett) >>> >>> - Only check constraint if range passes (requested by Kim Barrett) >>> >>> - Merged with Sangheon Kim fix for "Add additional validation after heap creation? (JDK-8130459) >>> >>> >>> This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? >>> >>> >>> References: >>> >>> JEP 245:https://bugs.openjdk.java.net/browse/JDK-8122937 >>> bug:https://bugs.openjdk.java.net/browse/JDK-8112746 >>> webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev2/ >>> >> > From gerard.ziemski at oracle.com Mon Aug 3 16:11:42 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Mon, 03 Aug 2015 11:11:42 -0500 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <33BEC3CE-D779-4621-8980-8D35D9FBB0D4@oracle.com> References: <55BBB894.6090202@oracle.com> <33BEC3CE-D779-4621-8980-8D35D9FBB0D4@oracle.com> Message-ID: <55BF92BE.2050702@oracle.com> Thank you for the review. On 07/31/2015 08:15 PM, Kim Barrett wrote: > On Jul 31, 2015, at 2:04 PM, gerard ziemski wrote: >> Please review this webrev 2 of the follow-up fixes including: >> >> - Adding DBL_MAX (requested by Kim Barrett) >> >> - Passing values by value, not pointer, to constraint functions. It was thought originally that me way want to ?fix? the values, but it was decided to be out of scope for the JEP. (requested by Coleen) >> >> - Add print_error_as_needed() utility function to range/constraint code to improve code robustness (requested by Coleen) >> >> - Remove debug code (requested by Kim Barrett) >> >> - Implement Flag::flag_error_str in .cpp file (requested by Kim Barrett) >> >> - Only check constraint if range passes (requested by Kim Barrett) >> >> - Merged with Sangheon Kim fix for "Add additional validation after heap creation? (JDK-8130459) >> >> >> This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? >> >> >> References: >> >> JEP 245: >> https://bugs.openjdk.java.net/browse/JDK-8122937 >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8112746 >> >> webrev: >> http://cr.openjdk.java.net/~gziemski/8112746_rev2/ > Not a full review, for reasons that will be discussed below. I > decided to stop and see if I can convince you to do something about > the first couple of items before I go any further. > > ------------------------------------------------------------------------------ > I really wish this had been broken up into separate issues with > associated changesets, rather than one large combined changeset. > > I realize that breaking it up will be more work for you, but it would > make a substantial difference in the quality of my review. Yes, I thought about that, and the more work for myself is not the big concern here - it's more work for everyone. I am not a commitrer, so I would need a sponsor for very single change, and lastly each change requires vigorous testing, which takes a long while and uses JPRT/RBT resources. I would prefer if we made one last effort here and clear up this backlog if that's OK. > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 71 "greater than ergonomic PLAB minimum size (" SIZE_FORMAT ")\n", > > Copy-paste bug: this should be "less than ... maximum". Fixed. > > The formatting changes in the strings seem (mostly?) unnecessary, and > make the review much more difficult. > > [Later] After trying and failing to review these changes (my eyes > keep crossing) I'd really prefer the string formatting changes were > reverted, unless there's some real change hiding in there that I'm > failing to see. The string changes are to keep the code consistent and the biggest value here is to provide a patterneasy to apply for new constraints with clearily identified parts of strings that can be easily parsed and modified in parts, ie: print_error_if_needed(verbose, *- same for all flags* "Flag (" FORMAT ") must be", *- similar**for all flags with "Flag" and "FORMAT" that need to be filled in* "greater than on equal to Flag (" FORMAT ")\n"; *- **this may need to change substantially from flag to flag* "value, Flag);" *- similar for all**except for the actual "F**lag"* > > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/g1_globals.hpp > 75 range(1.0, DBL_MAX) \ > > I vaguely recall an issue being raised about this causing problems > with the output when dumping the option values and their ranges. > Something about the printed value of DBL_MAX being excessively long. Snagheon will take over this as discusses in other email. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp > src/share/vm/runtime/commandLineFlagRangeList.cpp > > Duplicated print_error_if_needed. Right, I wasn't sure whether to factor this method out or not. I decided to have it local because it's trivial, but I will factor it out into src/share/vm/runtime/commandLineFlagRangeList.hpp/.cpp though that will require all the constraint files to include the commandLineFlagRange.List.hpp > > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.cpp > 518 const char* Flag::flag_error_str(Flag::Error error) { > 519 switch (error) { > ... > 528 default: return "NULL"; > > I think that default is a "should not reach here" situation? Fixed. I will post a webrev shortly after testing. cheers From vladimir.kozlov at oracle.com Mon Aug 3 16:12:21 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 3 Aug 2015 09:12:21 -0700 Subject: RFR: 8130212: Thread::current() might access freed memory on Solaris In-Reply-To: <55BF03C1.9000902@oracle.com> References: <55B868A3.2080602@oracle.com> <55B86A54.7000708@oracle.com> <55B86AF8.9070104@oracle.com> <7F33558F-F6DF-4594-B35E-F72BCEAA1300@oracle.com> <55B952CF.2000109@oracle.com> <55B965AB.9050204@oracle.com> <55B9AAA5.6000704@oracle.com> <55BA6D28.2000407@oracle.com> <55BA9E3D.4080207@oracle.com> <55BAD972.302@oracle.com> <55BF03C1.9000902@oracle.com> Message-ID: <55BF92E5.1000406@oracle.com> Okay, you can skip 32-bit. Thank you for trying. Vladimir On 8/2/15 11:01 PM, David Holmes wrote: > Hi Vladimir, > > On 31/07/2015 12:12 PM, Vladimir Kozlov wrote: >> > I can add a 32-bit version of the change but am not sure how to test it. >> > Can we still easily build 32-bit Solaris or do I need to hack the build >> > systems somehow? >> >> You have to build first 32-bit 8u60 (using 7u80, for example, as boot >> jdk). And then use it as boot jdk for jdk9 32-bit build. Both builds >> have to be configured with --with-target-bits=32. >> >> And there are no way to do that in JPRT as I know. Only manually :( >> >> If it is hard for you I will manage (will prepare patch later). >> >> So I am fine with current code if you don't want to spend more time on it. > > I tried applying my patch to jkd8u-dev and performing the 32-bit changes there to test it out. But when I did the 32-bit > build the resulting binaries would not even run! > > > ./b00/se-solaris-i586-internal/images/j2sdk-image/bin/java -client -version > Error: dl failure on line 893 > Error: failed > /scratch/dh198349/jdk8u-dev/build/b00/se-solaris-i586-internal/images/j2sdk-image/jre/lib/i386/client/libjvm.so, because > ld.so.1: java: fatal: > /scratch/dh198349/jdk8u-dev/build/b00/se-solaris-i586-internal/images/j2sdk-image/jre/lib/i386/client/libjvm.so: open > failed: No such file or directory > > > find b00/se-solaris-i586-internal/images/j2sdk-image/ -name libjvm.so > b00/se-solaris-i586-internal/images/j2sdk-image/jre/lib/i386/server/libjvm.so > b00/se-solaris-i586-internal/images/j2sdk-image/jre/lib/i386/client/libjvm.so > > I have no idea what is going on. So, sorry, but I won't be doing the 32-bit variant. > > David > ----- > >> Thanks, >> Vladimir >> >> On 7/30/15 2:59 PM, David Holmes wrote: >>> Hi Vladimir, >>> >>> On 31/07/2015 4:30 AM, Vladimir Kozlov wrote: >>>> On 7/29/15 9:40 PM, David Holmes wrote: >>>>> Hi Vladimir, >>>>> >>>>> On 30/07/2015 9:45 AM, Vladimir Kozlov wrote: >>>>>> David, >>>>>> >>>>>> I don't see changes in macroAssembler_sparc.cpp for get_thread(). >>>>> >>>>> There's no need it already simply calls ThreadLocalStorage::thread >>>>> (with an indirection for debug builds) >>>> >>>> You are right. >>>> >>>>> >>>>>> Did you look what assembler is generated for thread() method?: >>>>>> >>>>>> inline Thread* ThreadLocalStorage::thread() { >>>>>> return _thr_current; >>>>>> } >>>>> >>>>> In the object file it generates code of the form (for x86): >>>>> >>>>> leaq +0x0(%rip),%rdi >>>>> >>>>> followed by a call that is translated as a call to _tls_get_addr. But >>>>> there is a lot of link-edit time manipulation of >>>>> the code. I don't know how to find the exact runtime code. >>>> >>>> Yes, I realized it will be difficult to reproduce what C++ compiler and >>>> liker will do. >>>> >>>>> >>>>>> >>>>>> It would be nice to avoid runtime call in assembler if we know address >>>>>> of _thr_current. >>>>> >>>>> But the address itself would be a per-thread variable that we'd need >>>>> to get from somewhere ?? >>>> >>>> Yes, yes, it is true. And we want to avoid any tables which led to this >>>> problem. >>>> Okay, since it is slow path we can do call. >>>> >>>> Last thing. Can you preserve separate versions for 32- and 64-bits? >>>> Sometimes I have to build 32-bit Sol-x86 for debugging with dbx. >>> >>> I was under the impression that 32-bit Solaris support had been flagged >>> for deletion. >>> >>> I can add a 32-bit version of the change but am not sure how to test it. >>> Can we still easily build 32-bit Solaris or do I need to hack the build >>> systems somehow? >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 7/29/15 3:38 PM, Christian Thalinger wrote: >>>>>>> >>>>>>>> On Jul 29, 2015, at 3:25 PM, David Holmes >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 30/07/2015 1:28 AM, Christian Thalinger wrote: >>>>>>>>> Now that threadLS_solaris_sparc.{cpp,hpp} and >>>>>>>>> threadLS_solaris_x86.{cpp,hop} look exactly the same it would be >>>>>>>>> nice to merge them into threadLS_solaris.{cpp,hpp}. >>>>>>>> >>>>>>>> In the next phase: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8132510 >>>>>>>> >>>>>>>> these files will disappear completely. Can this wait till then? >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>>> On Jul 28, 2015, at 10:56 PM, David Holmes >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Moved to hotspot-dev so the compiler folk also see this for the >>>>>>>>>> MacroAssembler changes. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 29/07/2015 3:53 PM, David Holmes wrote: >>>>>>>>>>> I forgot to credit Dave Dice with the suggestion to modernize >>>>>>>>>>> this >>>>>>>>>>> code. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 29/07/2015 3:46 PM, David Holmes wrote: >>>>>>>>>>>> Summary: replace complex custom code for maintaining >>>>>>>>>>>> ThreadLocalStorage >>>>>>>>>>>> with compiler supported thread-local variables (Solaris only) >>>>>>>>>>>> >>>>>>>>>>>> This is a non-public bug so let me explain with some >>>>>>>>>>>> background, the >>>>>>>>>>>> bug, and then the fix - which involves lots of complex-code >>>>>>>>>>>> deletion and >>>>>>>>>>>> addition of some very simple code. :) >>>>>>>>>>>> >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8130212/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> In various parts of the runtime and in compiler generated >>>>>>>>>>>> code we >>>>>>>>>>>> need >>>>>>>>>>>> to get a reference to the (VM-level) Thread* of the currently >>>>>>>>>>>> executing >>>>>>>>>>>> thread. This is what Thread::current() returns. For performance >>>>>>>>>>>> reasons >>>>>>>>>>>> we also have a fast-path on 64-bit where the Thread* is stashed >>>>>>>>>>>> away in >>>>>>>>>>>> a register (g7 on sparc, r15 on x64). >>>>>>>>>>>> >>>>>>>>>>>> So Thread::current() is actually a slow-path mechanism and it >>>>>>>>>>>> delegates >>>>>>>>>>>> to ThreadLocalStorage::thread(). >>>>>>>>>>>> >>>>>>>>>>>> On some systems ThreadLocalStorage::thread utilizes a caching >>>>>>>>>>>> mechanism >>>>>>>>>>>> to try and speed up access to the current thread. Otherwise it >>>>>>>>>>>> calls >>>>>>>>>>>> into yet another "slow" path which uses the available platform >>>>>>>>>>>> thread-specific-storage APIs. >>>>>>>>>>>> >>>>>>>>>>>> Compiled code also has a slow-path get_thread() method which >>>>>>>>>>>> uses >>>>>>>>>>>> assembly code to invoke the same platform >>>>>>>>>>>> thread-specific-storage >>>>>>>>>>>> APIs >>>>>>>>>>>> (in some cases - on sparc it simply calls >>>>>>>>>>>> ThreadLocalStorage::thread()). >>>>>>>>>>>> >>>>>>>>>>>> On Solaris 64-bit (which is all we support today) there is a >>>>>>>>>>>> simple >>>>>>>>>>>> 1-level thread cache which is an array of Thread*. If a thread >>>>>>>>>>>> doesn't >>>>>>>>>>>> find itself in the slot for the hash of its id it inserts itself >>>>>>>>>>>> there. >>>>>>>>>>>> As a thread terminates it clears out its ThreadLocalStorage >>>>>>>>>>>> values >>>>>>>>>>>> including any cached reference. >>>>>>>>>>>> >>>>>>>>>>>> The bug is that we have potential for a read-after-free error >>>>>>>>>>>> due to >>>>>>>>>>>> this code: >>>>>>>>>>>> >>>>>>>>>>>> 46 uintptr_t raw = pd_raw_thread_id(); >>>>>>>>>>>> 47 int ix = pd_cache_index(raw); // hashes id >>>>>>>>>>>> 48 Thread* candidate = >>>>>>>>>>>> ThreadLocalStorage::_get_thread_cache[ix]; >>>>>>>>>>>> 49 if (candidate->self_raw_id() == raw) { >>>>>>>>>>>> 50 // hit >>>>>>>>>>>> 51 return candidate; >>>>>>>>>>>> 52 } else { >>>>>>>>>>>> 53 return >>>>>>>>>>>> ThreadLocalStorage::get_thread_via_cache_slowly(raw, >>>>>>>>>>>> ix); >>>>>>>>>>>> 54 } >>>>>>>>>>>> >>>>>>>>>>>> The problem is that the value read as candidate could be a >>>>>>>>>>>> thread >>>>>>>>>>>> that >>>>>>>>>>>> (after line 48) terminated and was freed. But line #49 then >>>>>>>>>>>> reads >>>>>>>>>>>> the >>>>>>>>>>>> raw id of that thread, which is then a read-after-free - >>>>>>>>>>>> which is >>>>>>>>>>>> a "Bad >>>>>>>>>>>> Thing (TM)". >>>>>>>>>>>> >>>>>>>>>>>> There's no simple fix for the caching code - you would need a >>>>>>>>>>>> completely >>>>>>>>>>>> different approach (or synchronization that would nullify the >>>>>>>>>>>> whole >>>>>>>>>>>> point of the cache). >>>>>>>>>>>> >>>>>>>>>>>> Now all this ThreadLocalStorage code is pretty old and was >>>>>>>>>>>> put in >>>>>>>>>>>> place >>>>>>>>>>>> to deal with inadequacies of the system provided >>>>>>>>>>>> thread-specific-storage >>>>>>>>>>>> API. In fact on Solaris we even by-pass the public API >>>>>>>>>>>> (thr_getspecific/thr_setspecific) when we can and implement our >>>>>>>>>>>> own >>>>>>>>>>>> version using lower-level APIs available in the T1/T2 threading >>>>>>>>>>>> libraries! >>>>>>>>>>>> >>>>>>>>>>>> In mid-2015 things have changed considerably and we have >>>>>>>>>>>> reliable >>>>>>>>>>>> and >>>>>>>>>>>> performant support for thread-local variables at the C+ >>>>>>>>>>>> language-level. >>>>>>>>>>>> So the way to maintain the current thread is simply using: >>>>>>>>>>>> >>>>>>>>>>>> // Declaration of thread-local variable >>>>>>>>>>>> static __thread Thread * _thr_current >>>>>>>>>>>> >>>>>>>>>>>> inline Thread* ThreadLocalStorage::thread() { >>>>>>>>>>>> return _thr_current; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> inline void ThreadLocalStorage::set_thread(Thread* thread) { >>>>>>>>>>>> _thr_current = thread; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> And all the complex ThreadLocalStorage code with caching etc all >>>>>>>>>>>> vanishes! >>>>>>>>>>>> >>>>>>>>>>>> For my next trick I plan to try and remove the >>>>>>>>>>>> ThreadLocalStorage >>>>>>>>>>>> class >>>>>>>>>>>> completely by using language-based thread-locals on all >>>>>>>>>>>> platforms. But >>>>>>>>>>>> for now this is just Solaris and so we still need the >>>>>>>>>>>> ThreadLocalStorage >>>>>>>>>>>> API. However a lot of that API is not needed any more on Solaris >>>>>>>>>>>> so I >>>>>>>>>>>> have excluded it from there in the shared code (ifndef SOLARIS). >>>>>>>>>>>> But to >>>>>>>>>>>> avoid changing other shared-code callsites of ThreadLocalStorage >>>>>>>>>>>> I've >>>>>>>>>>>> kept part of the API with trivial implementations on Solaris. >>>>>>>>>>>> >>>>>>>>>>>> Testing: JPRT >>>>>>>>>>>> All hotspot regression tests >>>>>>>>>>>> >>>>>>>>>>>> I'm happy to run more tests but the nice thing about such >>>>>>>>>>>> low-level code >>>>>>>>>>>> is that if it is broken, it is always broken :) Every use of >>>>>>>>>>>> Thread::current or MacroAssembler::get_thread now hits this >>>>>>>>>>>> code. >>>>>>>>>>>> >>>>>>>>>>>> Performance: I've run a basic set of benchmarks that is readily >>>>>>>>>>>> available to me on our performance testing system. The best >>>>>>>>>>>> way to >>>>>>>>>>>> describe the result is neutral. There are some slight wins, and >>>>>>>>>>>> some >>>>>>>>>>>> slight losses, with most showing no statistical difference. And >>>>>>>>>>>> even the >>>>>>>>>>>> "wins" and "losses" are within the natural variations of the >>>>>>>>>>>> benchmarks. >>>>>>>>>>>> So a lot of complex code has been replaced by simple code and we >>>>>>>>>>>> haven't >>>>>>>>>>>> lost any observable performance - which seems like a win to me. >>>>>>>>>>>> >>>>>>>>>>>> Also product mode x64 libjvm.so has shrunk by 921KB - which is a >>>>>>>>>>>> little >>>>>>>>>>>> surprising but very nice. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>> >>>>>>> From kim.barrett at oracle.com Mon Aug 3 20:07:36 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 3 Aug 2015 16:07:36 -0400 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55BF7ACF.1000304@oracle.com> References: <55BBB894.6090202@oracle.com> <55BF59BA.7080105@oracle.com> <55BF7ACF.1000304@oracle.com> Message-ID: <1917880F-00C8-46AE-B341-4D3796C70782@oracle.com> On Aug 3, 2015, at 10:29 AM, gerard ziemski wrote: > > So I originally had G1ConcMarkStepDurationMillis range defined as "range(0, (double)max_uintx)", but the request was to use mathematically correct bound, ie. DBL_MAX, as any other value would have to be carefully determined as it's a user limiting change. > > Sangheon, is currently working on JDK-8059555, so maybe I should leave this flag to him, since it's a GC flag and he already indicated that he thinks he will need DBL_MAX for other flags? It looks like Sangheon will be faced with the same kind of issue for other flags, so maybe we should leave this issue up to him and have a single discussion about this and other flags at the same time? > > Sanghon, is it OK if I take this particular change out and you and GC team will handle it as you find appropriate while you work on JDK-8059555? This seems like a good plan for addressing this issue. From kim.barrett at oracle.com Mon Aug 3 20:26:39 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 3 Aug 2015 16:26:39 -0400 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55BF92BE.2050702@oracle.com> References: <55BBB894.6090202@oracle.com> <33BEC3CE-D779-4621-8980-8D35D9FBB0D4@oracle.com> <55BF92BE.2050702@oracle.com> Message-ID: <1A3F18CD-B3B9-4DA4-A2C2-8E7D30D28D61@oracle.com> On Aug 3, 2015, at 12:11 PM, gerard ziemski wrote: > > On 07/31/2015 08:15 PM, Kim Barrett wrote: >> On Jul 31, 2015, at 2:04 PM, gerard ziemski >>> >>> https://bugs.openjdk.java.net/browse/JDK-8122937 >>> >>> >>> bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8112746 >>> >>> >>> webrev: >>> >>> http://cr.openjdk.java.net/~gziemski/8112746_rev2/ >> Not a full review, for reasons that will be discussed below. I >> decided to stop and see if I can convince you to do something about >> the first couple of items before I go any further. >> >> ------------------------------------------------------------------------------ >> I really wish this had been broken up into separate issues with >> associated changesets, rather than one large combined changeset. >> >> I realize that breaking it up will be more work for you, but it would >> make a substantial difference in the quality of my review. >> > > Yes, I thought about that, and the more work for myself is not the big concern here - it's more work for everyone. I am not a commitrer, so I would need a sponsor for very single change, and lastly each change requires vigorous testing, which takes a long while and uses JPRT/RBT resources. I would prefer if we made one last effort here and clear up this backlog if that's OK. Sponsoring a reviewed and well tested change is usually not a big deal for the sponsor; I'm happy to do it for you, especially now that we're both normally operating in the same repository. I understand the testing overhead, though different kinds of changes might require different levels of testing. That said, I went ahead and made my way through the existing webrev, with comments below. Your explanation of the rationale behind the string formatting changes was helpful; still difficult to review, but at least now I know why I'm working so hard :-) ------------------------------------------------------------------------------ > - Passing values by value, not pointer, to constraint functions. It > was thought originally that me way want to ?fix? the values, but it > was decided to be out of scope for the JEP. (requested by Coleen) I keep waffling about this, so I'll go ahead an mention it, even though I don't yet have a strong opinion either way. For the writer of a constraint function, not needing to deal with a pointer is clearly better. However, I actually kind of thought it was a feature that the values were passed by pointer reference rather than by value (though the pointer should be const-qualified if no "fixup" capability is intended). That prevents certain kinds of bugs due to implicit conversions; the types involved here provide pretty much all conversions between pairs of types. I'm also concerned about bugs resulting from reversal of the value and verbose arguments, especially since their order is not consistent throughout the internal APIs. There are two different pathways to these constraint functions, one of which is still using (and needs to use) pointers. This change dereferences these pointers, rather than taking the address of values on the other path. So which approach is used is a wash from the caller's perspective. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp Pre-existing issue: It seems like there is a lot of very similar parameterized boiler-plate code here, and that using macros or templates could significantly reduce the amount of source code. Of course, it would be important to accomplish such a shortening without involving infrastructure that is itself overly complex, but I don't think anything particularly tricky should be needed here. This can be left for a later cleanup, or even ignored if nobody else is bothered by it. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 66 static Flag::Error MaxPLABSizeBounds(const char* name, bool verbose, size_t value) { ... 71 "greater than ergonomic PLAB minimum size (" SIZE_FORMAT ")\n", 72 name, value, PLAB::min_size()); In addition to the copy-paste error already mentioned for line 71, on line 72 PLAB::min_size() should be PLAB::max_size(). ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 79 static Flag::Error MinMaxPLABSizeBounds(const char* name, bool verbose, size_t value) { 80 if (MinPLABSizeBounds(name, verbose, value) == Flag::SUCCESS) { 81 return MaxPLABSizeBounds(name, verbose, value); 82 } 83 return Flag::VIOLATES_CONSTRAINT; 84 } I think it would be more maintainable to capture the result of MinPLABSizeBounds in a "status" variable. If status is SUCCESS, set status to result of MaxPLABSizeBounds. Return status. This eliminates assumptions about possible MinPLABSizeBounds results. But see later comment about these helper functions. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 53 static Flag::Error MinPLABSizeBounds(const char* name, bool verbose, size_t value) { 66 static Flag::Error MaxPLABSizeBounds(const char* name, bool verbose, size_t value) { 79 static Flag::Error MinMaxPLABSizeBounds(const char* name, bool verbose, size_t value) { 86 Flag::Error YoungPLABSizeConstraintFunc(bool verbose, size_t value) { Pre-existing issue: While I'm all for using helper functions to break things up into bite-sized chunks, in this case I think the helper functions are actually making the code longer and more complicated. A helper for the two calls to print_error_if_needed might be useful if this approach were taken. Please take this as a suggestion to look at, rather than a required change. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 53 static Flag::Error MinPLABSizeBounds(const char* name, bool verbose, size_t value) { 54 #if INCLUDE_ALL_GCS 55 if ((UseConcMarkSweepGC || UseG1GC) && (value < PLAB::min_size())) { 56 print_error_if_needed(verbose, 57 "%s (" SIZE_FORMAT ") must be " 58 "greater than ergonomic PLAB minimum size (" SIZE_FORMAT ")\n", Pre-existing defect: Message says "greater than" but test is "greater or equal". The obvious fix to the previously mentioned problems in MaxPLABSizeBounds would have a similar problem. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp src/share/vm/runtime/commandLineFlagRangeList.cpp Compiler and GC constraint functions consistently use error messages of the form: () ... In this file the error messages are of the form = The range checking functions also use the second form. These should all be consistent. ------------------------------------------------------------------------------ From sangheon.kim at oracle.com Mon Aug 3 21:01:45 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 03 Aug 2015 14:01:45 -0700 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <1A3F18CD-B3B9-4DA4-A2C2-8E7D30D28D61@oracle.com> References: <55BBB894.6090202@oracle.com> <33BEC3CE-D779-4621-8980-8D35D9FBB0D4@oracle.com> <55BF92BE.2050702@oracle.com> <1A3F18CD-B3B9-4DA4-A2C2-8E7D30D28D61@oracle.com> Message-ID: <55BFD6B9.6030902@oracle.com> Hi Kim, Let me answer some of your comments. > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 79 static Flag::Error MinMaxPLABSizeBounds(const char* name, bool verbose, size_t value) { > 80 if (MinPLABSizeBounds(name, verbose, value) == Flag::SUCCESS) { > 81 return MaxPLABSizeBounds(name, verbose, value); > 82 } > 83 return Flag::VIOLATES_CONSTRAINT; > 84 } > > I think it would be more maintainable to capture the result of > MinPLABSizeBounds in a "status" variable. If status is SUCCESS, set > status to result of MaxPLABSizeBounds. Return status. This > eliminates assumptions about possible MinPLABSizeBounds results. > > But see later comment about these helper functions. MinPLABSizeBounds() and MaxPLABSizeBounds() will be used together or separately from followed changes. > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 53 static Flag::Error MinPLABSizeBounds(const char* name, bool verbose, size_t value) { > 66 static Flag::Error MaxPLABSizeBounds(const char* name, bool verbose, size_t value) { > 79 static Flag::Error MinMaxPLABSizeBounds(const char* name, bool verbose, size_t value) { > 86 Flag::Error YoungPLABSizeConstraintFunc(bool verbose, size_t value) { > > Pre-existing issue: > While I'm all for using helper functions to break things up into > bite-sized chunks, in this case I think the helper functions are > actually making the code longer and more complicated. Actually 8078555 which is GC part flag implementation will utilize these helper functions for OldPLABSize, CMSOldPLABMin, CMSOldPLABMax. When I suggested '8130459: Add additional validation after heap creation', I mentioned that adding YoungPLABSizeConstraintFunc() as an example. I didn't expected that these helper functions would reviewed again. :) > A helper for > the two calls to print_error_if_needed might be useful if this > approach were taken. > > Please take this as a suggestion to look at, rather than a required > change. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 53 static Flag::Error MinPLABSizeBounds(const char* name, bool verbose, size_t value) { > 54 #if INCLUDE_ALL_GCS > 55 if ((UseConcMarkSweepGC || UseG1GC) && (value < PLAB::min_size())) { > 56 print_error_if_needed(verbose, > 57 "%s (" SIZE_FORMAT ") must be " > 58 "greater than ergonomic PLAB minimum size (" SIZE_FORMAT ")\n", > > Pre-existing defect: > Message says "greater than" but test is "greater or equal". > > The obvious fix to the previously mentioned problems in > MaxPLABSizeBounds would have a similar problem. I already fixed this and let me get reviews from 8078555 later. Thanks, Sangheon On 08/03/2015 01:26 PM, Kim Barrett wrote: > On Aug 3, 2015, at 12:11 PM, gerard ziemski wrote: >> On 07/31/2015 08:15 PM, Kim Barrett wrote: >>> On Jul 31, 2015, at 2:04 PM, gerard ziemski >>>> https://bugs.openjdk.java.net/browse/JDK-8122937 >>>> >>>> >>>> bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8112746 >>>> >>>> >>>> webrev: >>>> >>>> http://cr.openjdk.java.net/~gziemski/8112746_rev2/ >>> Not a full review, for reasons that will be discussed below. I >>> decided to stop and see if I can convince you to do something about >>> the first couple of items before I go any further. >>> >>> ------------------------------------------------------------------------------ >>> I really wish this had been broken up into separate issues with >>> associated changesets, rather than one large combined changeset. >>> >>> I realize that breaking it up will be more work for you, but it would >>> make a substantial difference in the quality of my review. >>> >> Yes, I thought about that, and the more work for myself is not the big concern here - it's more work for everyone. I am not a commitrer, so I would need a sponsor for very single change, and lastly each change requires vigorous testing, which takes a long while and uses JPRT/RBT resources. I would prefer if we made one last effort here and clear up this backlog if that's OK. > Sponsoring a reviewed and well tested change is usually not a big deal > for the sponsor; I'm happy to do it for you, especially now that we're > both normally operating in the same repository. I understand the > testing overhead, though different kinds of changes might require > different levels of testing. > > That said, I went ahead and made my way through the existing webrev, > with comments below. Your explanation of the rationale behind the > string formatting changes was helpful; still difficult to review, but > at least now I know why I'm working so hard :-) > > ------------------------------------------------------------------------------ >> - Passing values by value, not pointer, to constraint functions. It >> was thought originally that me way want to ?fix? the values, but it >> was decided to be out of scope for the JEP. (requested by Coleen) > I keep waffling about this, so I'll go ahead an mention it, even > though I don't yet have a strong opinion either way. > > For the writer of a constraint function, not needing to deal with a > pointer is clearly better. > > However, I actually kind of thought it was a feature that the values > were passed by pointer reference rather than by value (though the > pointer should be const-qualified if no "fixup" capability is > intended). That prevents certain kinds of bugs due to implicit > conversions; the types involved here provide pretty much all > conversions between pairs of types. I'm also concerned about bugs > resulting from reversal of the value and verbose arguments, especially > since their order is not consistent throughout the internal APIs. > > There are two different pathways to these constraint functions, one of > which is still using (and needs to use) pointers. This change > dereferences these pointers, rather than taking the address of values > on the other path. So which approach is used is a wash from the > caller's perspective. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > > Pre-existing issue: > It seems like there is a lot of very similar parameterized > boiler-plate code here, and that using macros or templates could > significantly reduce the amount of source code. Of course, it would > be important to accomplish such a shortening without involving > infrastructure that is itself overly complex, but I don't think > anything particularly tricky should be needed here. > > This can be left for a later cleanup, or even ignored if nobody else > is bothered by it. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 66 static Flag::Error MaxPLABSizeBounds(const char* name, bool verbose, size_t value) { > ... > 71 "greater than ergonomic PLAB minimum size (" SIZE_FORMAT ")\n", > 72 name, value, PLAB::min_size()); > > In addition to the copy-paste error already mentioned for line 71, on > line 72 PLAB::min_size() should be PLAB::max_size(). > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 79 static Flag::Error MinMaxPLABSizeBounds(const char* name, bool verbose, size_t value) { > 80 if (MinPLABSizeBounds(name, verbose, value) == Flag::SUCCESS) { > 81 return MaxPLABSizeBounds(name, verbose, value); > 82 } > 83 return Flag::VIOLATES_CONSTRAINT; > 84 } > > I think it would be more maintainable to capture the result of > MinPLABSizeBounds in a "status" variable. If status is SUCCESS, set > status to result of MaxPLABSizeBounds. Return status. This > eliminates assumptions about possible MinPLABSizeBounds results. > > But see later comment about these helper functions. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 53 static Flag::Error MinPLABSizeBounds(const char* name, bool verbose, size_t value) { > 66 static Flag::Error MaxPLABSizeBounds(const char* name, bool verbose, size_t value) { > 79 static Flag::Error MinMaxPLABSizeBounds(const char* name, bool verbose, size_t value) { > 86 Flag::Error YoungPLABSizeConstraintFunc(bool verbose, size_t value) { > > Pre-existing issue: > While I'm all for using helper functions to break things up into > bite-sized chunks, in this case I think the helper functions are > actually making the code longer and more complicated. A helper for > the two calls to print_error_if_needed might be useful if this > approach were taken. > > Please take this as a suggestion to look at, rather than a required > change. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 53 static Flag::Error MinPLABSizeBounds(const char* name, bool verbose, size_t value) { > 54 #if INCLUDE_ALL_GCS > 55 if ((UseConcMarkSweepGC || UseG1GC) && (value < PLAB::min_size())) { > 56 print_error_if_needed(verbose, > 57 "%s (" SIZE_FORMAT ") must be " > 58 "greater than ergonomic PLAB minimum size (" SIZE_FORMAT ")\n", > > Pre-existing defect: > Message says "greater than" but test is "greater or equal". > > The obvious fix to the previously mentioned problems in > MaxPLABSizeBounds would have a similar problem. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp > src/share/vm/runtime/commandLineFlagRangeList.cpp > > Compiler and GC constraint functions consistently use error messages > of the form: > > () ... > > In this file the error messages are of the form > > = > > The range checking functions also use the second form. > > These should all be consistent. > > ------------------------------------------------------------------------------ > From kim.barrett at oracle.com Mon Aug 3 21:50:27 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 3 Aug 2015 17:50:27 -0400 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55BFD6B9.6030902@oracle.com> References: <55BBB894.6090202@oracle.com> <33BEC3CE-D779-4621-8980-8D35D9FBB0D4@oracle.com> <55BF92BE.2050702@oracle.com> <1A3F18CD-B3B9-4DA4-A2C2-8E7D30D28D61@oracle.com> <55BFD6B9.6030902@oracle.com> Message-ID: <5F44F308-8FF6-41C8-9ADB-BD0F4B07D280@oracle.com> On Aug 3, 2015, at 5:01 PM, sangheon.kim wrote: > >> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >> 53 static Flag::Error MinPLABSizeBounds(const char* name, bool verbose, size_t value) { >> 66 static Flag::Error MaxPLABSizeBounds(const char* name, bool verbose, size_t value) { >> 79 static Flag::Error MinMaxPLABSizeBounds(const char* name, bool verbose, size_t value) { >> 86 Flag::Error YoungPLABSizeConstraintFunc(bool verbose, size_t value) { >> >> Pre-existing issue: >> While I'm all for using helper functions to break things up into >> bite-sized chunks, in this case I think the helper functions are >> actually making the code longer and more complicated. > Actually 8078555 which is GC part flag implementation will utilize these helper functions for OldPLABSize, CMSOldPLABMin, CMSOldPLABMax. > When I suggested '8130459: Add additional validation after heap creation', I mentioned that adding YoungPLABSizeConstraintFunc() as an example. Ah, that explains it. Thanks. From volker.simonis at gmail.com Tue Aug 4 13:40:53 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 4 Aug 2015 15:40:53 +0200 Subject: RFR (XXS): 8132969: C++11 requires a space between literal and identifier Message-ID: Hi Matthias, the change looks good. I've opened: https://bugs.openjdk.java.net/browse/JDK-8132969 for it and created a webrev: http://cr.openjdk.java.net/~simonis/webrevs/2015/8132969/ We still need a second reviewer who can sponsor the change. Thanks, Volker On Mon, Aug 3, 2015 at 4:05 PM, Baesken, Matthias wrote: > Hello, in > > "8081202 C++11 requires a space between literal and identifier", see > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018665.html > > a number of places in hotspot coding with missing spaces between literals and identifiers were already fixed. > > When experimenting with Visual Studio 2015 (which refuses compiling such code) , I noticed that this fix is missing here : > > hotspot/src/share/vm/interpreter/interpreterRuntime.cpp > > The following small diff is fixing the remaining issue. > > > 1306c1306 > < tty->print_cr("argument handler #%d at "PTR_FORMAT" for fingerprint " UINT64_FORMAT, > --- >> tty->print_cr("argument handler #%d at " PTR_FORMAT " for fingerprint " UINT64_FORMAT, > 1316c1316 > < tty->print_cr("duplicate argument handler #%d for fingerprint " UINT64_FORMAT "(old: "PTR_FORMAT", new : "PTR_FORMAT")", > --- >> tty->print_cr("duplicate argument handler #%d for fingerprint " UINT64_FORMAT "(old: " PTR_FORMAT ", new : " PTR_FORMAT ")", > > > Could you please add the small fix ? > > Thanks, Matthias From christian.tornqvist at oracle.com Tue Aug 4 13:44:19 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 4 Aug 2015 09:44:19 -0400 Subject: RFR (XXS): 8132969: C++11 requires a space between literal and identifier In-Reply-To: References: Message-ID: <024701d0cebb$aa73daf0$ff5b90d0$@oracle.com> This looks good, thanks for fixing this. I can sponsor the change for you. Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Tuesday, August 4, 2015 9:41 AM To: Baesken, Matthias Cc: hotspot-dev at openjdk.java.net Subject: RFR (XXS): 8132969: C++11 requires a space between literal and identifier Hi Matthias, the change looks good. I've opened: https://bugs.openjdk.java.net/browse/JDK-8132969 for it and created a webrev: http://cr.openjdk.java.net/~simonis/webrevs/2015/8132969/ We still need a second reviewer who can sponsor the change. Thanks, Volker On Mon, Aug 3, 2015 at 4:05 PM, Baesken, Matthias wrote: > Hello, in > > "8081202 C++11 requires a space between literal and identifier", see > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018665.htm > l > > a number of places in hotspot coding with missing spaces between literals and identifiers were already fixed. > > When experimenting with Visual Studio 2015 (which refuses compiling such code) , I noticed that this fix is missing here : > > hotspot/src/share/vm/interpreter/interpreterRuntime.cpp > > The following small diff is fixing the remaining issue. > > > 1306c1306 > < tty->print_cr("argument handler #%d at "PTR_FORMAT" for fingerprint " UINT64_FORMAT, > --- >> tty->print_cr("argument handler #%d at " PTR_FORMAT " for >> fingerprint " UINT64_FORMAT, > 1316c1316 > < tty->print_cr("duplicate argument handler #%d for fingerprint " UINT64_FORMAT "(old: "PTR_FORMAT", new : "PTR_FORMAT")", > --- >> tty->print_cr("duplicate argument handler #%d for fingerprint " >> UINT64_FORMAT "(old: " PTR_FORMAT ", new : " PTR_FORMAT ")", > > > Could you please add the small fix ? > > Thanks, Matthias From volker.simonis at gmail.com Tue Aug 4 13:47:48 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 4 Aug 2015 15:47:48 +0200 Subject: RFR (XXS): 8132969: C++11 requires a space between literal and identifier In-Reply-To: <024701d0cebb$aa73daf0$ff5b90d0$@oracle.com> References: <024701d0cebb$aa73daf0$ff5b90d0$@oracle.com> Message-ID: Thanks a lot Christian! Volker On Tue, Aug 4, 2015 at 3:44 PM, Christian Tornqvist wrote: > This looks good, thanks for fixing this. I can sponsor the change for you. > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis > Sent: Tuesday, August 4, 2015 9:41 AM > To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net > Subject: RFR (XXS): 8132969: C++11 requires a space between literal and identifier > > Hi Matthias, > > the change looks good. I've opened: > > https://bugs.openjdk.java.net/browse/JDK-8132969 > > for it and created a webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8132969/ > > We still need a second reviewer who can sponsor the change. > > Thanks, > Volker > > > On Mon, Aug 3, 2015 at 4:05 PM, Baesken, Matthias wrote: >> Hello, in >> >> "8081202 C++11 requires a space between literal and identifier", see >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018665.htm >> l >> >> a number of places in hotspot coding with missing spaces between literals and identifiers were already fixed. >> >> When experimenting with Visual Studio 2015 (which refuses compiling such code) , I noticed that this fix is missing here : >> >> hotspot/src/share/vm/interpreter/interpreterRuntime.cpp >> >> The following small diff is fixing the remaining issue. >> >> >> 1306c1306 >> < tty->print_cr("argument handler #%d at "PTR_FORMAT" for fingerprint " UINT64_FORMAT, >> --- >>> tty->print_cr("argument handler #%d at " PTR_FORMAT " for >>> fingerprint " UINT64_FORMAT, >> 1316c1316 >> < tty->print_cr("duplicate argument handler #%d for fingerprint " UINT64_FORMAT "(old: "PTR_FORMAT", new : "PTR_FORMAT")", >> --- >>> tty->print_cr("duplicate argument handler #%d for fingerprint " >>> UINT64_FORMAT "(old: " PTR_FORMAT ", new : " PTR_FORMAT ")", >> >> >> Could you please add the small fix ? >> >> Thanks, Matthias > From gerard.ziemski at oracle.com Tue Aug 4 17:25:05 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Tue, 04 Aug 2015 12:25:05 -0500 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <1A3F18CD-B3B9-4DA4-A2C2-8E7D30D28D61@oracle.com> References: <55BBB894.6090202@oracle.com> <33BEC3CE-D779-4621-8980-8D35D9FBB0D4@oracle.com> <55BF92BE.2050702@oracle.com> <1A3F18CD-B3B9-4DA4-A2C2-8E7D30D28D61@oracle.com> Message-ID: <55C0F571.7060107@oracle.com> Thank you for the review.Comments in-line. On 08/03/2015 03:26 PM, Kim Barrett wrote: > On Aug 3, 2015, at 12:11 PM, gerard ziemski wrote: >> On 07/31/2015 08:15 PM, Kim Barrett wrote: >>> On Jul 31, 2015, at 2:04 PM, gerard ziemski >>>> https://bugs.openjdk.java.net/browse/JDK-8122937 >>>> >>>> >>>> bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8112746 >>>> >>>> >>>> webrev: >>>> >>>> http://cr.openjdk.java.net/~gziemski/8112746_rev2/ >>> Not a full review, for reasons that will be discussed below. I >>> decided to stop and see if I can convince you to do something about >>> the first couple of items before I go any further. >>> >>> ------------------------------------------------------------------------------ >>> I really wish this had been broken up into separate issues with >>> associated changesets, rather than one large combined changeset. >>> >>> I realize that breaking it up will be more work for you, but it would >>> make a substantial difference in the quality of my review. >>> >> Yes, I thought about that, and the more work for myself is not the big concern here - it's more work for everyone. I am not a commitrer, so I would need a sponsor for very single change, and lastly each change requires vigorous testing, which takes a long while and uses JPRT/RBT resources. I would prefer if we made one last effort here and clear up this backlog if that's OK. > Sponsoring a reviewed and well tested change is usually not a big deal > for the sponsor; I'm happy to do it for you, especially now that we're > both normally operating in the same repository. I understand the > testing overhead, though different kinds of changes might require > different levels of testing. > > That said, I went ahead and made my way through the existing webrev, > with comments below. Your explanation of the rationale behind the > string formatting changes was helpful; still difficult to review, but > at least now I know why I'm working so hard :-) > > ------------------------------------------------------------------------------ >> - Passing values by value, not pointer, to constraint functions. It >> was thought originally that me way want to ?fix? the values, but it >> was decided to be out of scope for the JEP. (requested by Coleen) > I keep waffling about this, so I'll go ahead an mention it, even > though I don't yet have a strong opinion either way. > > For the writer of a constraint function, not needing to deal with a > pointer is clearly better. > > However, I actually kind of thought it was a feature that the values > were passed by pointer reference rather than by value (though the > pointer should be const-qualified if no "fixup" capability is > intended). That prevents certain kinds of bugs due to implicit > conversions; the types involved here provide pretty much all > conversions between pairs of types. I'm also concerned about bugs > resulting from reversal of the value and verbose arguments, especially > since their order is not consistent throughout the internal APIs. > > There are two different pathways to these constraint functions, one of > which is still using (and needs to use) pointers. This change > dereferences these pointers, rather than taking the address of values > on the other path. So which approach is used is a wash from the > caller's perspective. Made the "value,verbose" usage consistent in the APIs. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > > Pre-existing issue: > It seems like there is a lot of very similar parameterized > boiler-plate code here, and that using macros or templates could > significantly reduce the amount of source code. Of course, it would > be important to accomplish such a shortening without involving > infrastructure that is itself overly complex, but I don't think > anything particularly tricky should be needed here. > > This can be left for a later cleanup, or even ignored if nobody else > is bothered by it. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 66 static Flag::Error MaxPLABSizeBounds(const char* name, bool verbose, size_t value) { > ... > 71 "greater than ergonomic PLAB minimum size (" SIZE_FORMAT ")\n", > 72 name, value, PLAB::min_size()); > > In addition to the copy-paste error already mentioned for line 71, on > line 72 PLAB::min_size() should be PLAB::max_size(). > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 79 static Flag::Error MinMaxPLABSizeBounds(const char* name, bool verbose, size_t value) { > 80 if (MinPLABSizeBounds(name, verbose, value) == Flag::SUCCESS) { > 81 return MaxPLABSizeBounds(name, verbose, value); > 82 } > 83 return Flag::VIOLATES_CONSTRAINT; > 84 } > > I think it would be more maintainable to capture the result of > MinPLABSizeBounds in a "status" variable. If status is SUCCESS, set > status to result of MaxPLABSizeBounds. Return status. This > eliminates assumptions about possible MinPLABSizeBounds results. > > But see later comment about these helper functions. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 53 static Flag::Error MinPLABSizeBounds(const char* name, bool verbose, size_t value) { > 66 static Flag::Error MaxPLABSizeBounds(const char* name, bool verbose, size_t value) { > 79 static Flag::Error MinMaxPLABSizeBounds(const char* name, bool verbose, size_t value) { > 86 Flag::Error YoungPLABSizeConstraintFunc(bool verbose, size_t value) { > > Pre-existing issue: > While I'm all for using helper functions to break things up into > bite-sized chunks, in this case I think the helper functions are > actually making the code longer and more complicated. A helper for > the two calls to print_error_if_needed might be useful if this > approach were taken. > > Please take this as a suggestion to look at, rather than a required > change. Sangheon said he will take a look at those. > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 53 static Flag::Error MinPLABSizeBounds(const char* name, bool verbose, size_t value) { > 54 #if INCLUDE_ALL_GCS > 55 if ((UseConcMarkSweepGC || UseG1GC) && (value < PLAB::min_size())) { > 56 print_error_if_needed(verbose, > 57 "%s (" SIZE_FORMAT ") must be " > 58 "greater than ergonomic PLAB minimum size (" SIZE_FORMAT ")\n", > > Pre-existing defect: > Message says "greater than" but test is "greater or equal". > > The obvious fix to the previously mentioned problems in > MaxPLABSizeBounds would have a similar problem. Fixed. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp > src/share/vm/runtime/commandLineFlagRangeList.cpp > > Compiler and GC constraint functions consistently use error messages > of the form: > > () ... > > In this file the error messages are of the form > > = > > The range checking functions also use the second form. > > These should all be consistent. > > ------------------------------------------------------------------------------ Fixed. cheers From coleen.phillimore at oracle.com Tue Aug 4 17:35:52 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 04 Aug 2015 13:35:52 -0400 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55BF92BE.2050702@oracle.com> References: <55BBB894.6090202@oracle.com> <33BEC3CE-D779-4621-8980-8D35D9FBB0D4@oracle.com> <55BF92BE.2050702@oracle.com> Message-ID: <55C0F7F8.8090208@oracle.com> I've reviewed this code. My only two comments are from two replies in this thread: >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp >> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >> src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp >> src/share/vm/runtime/commandLineFlagRangeList.cpp >> >> Duplicated print_error_if_needed. > > Right, I wasn't sure whether to factor this method out or not. I > decided to have it local because it's trivial, but I will factor it > out into src/share/vm/runtime/commandLineFlagRangeList.hpp/.cpp though > that will require all the constraint files to include the > commandLineFlagRange.List.hpp > Yes, please factor out the error message functions. > ------------------------------------------------------------------------------ >> - Passing values by value, not pointer, to constraint functions. It >> was thought originally that me way want to ?fix? the values, but it >> was decided to be out of scope for the JEP. (requested by Coleen) > I keep waffling about this, so I'll go ahead an mention it, even > though I don't yet have a strong opinion either way. > > For the writer of a constraint function, not needing to deal with a > pointer is clearly better. > > However, I actually kind of thought it was a feature that the values > were passed by pointer reference rather than by value (though the > pointer should be const-qualified if no "fixup" capability is > intended). That prevents certain kinds of bugs due to implicit > conversions; the types involved here provide pretty much all > conversions between pairs of types. I'm also concerned about bugs > resulting from reversal of the value and verbose arguments, especially > since their order is not consistent throughout the internal APIs. > > There are two different pathways to these constraint functions, one of > which is still using (and needs to use) pointers. This change > dereferences these pointers, rather than taking the address of values > on the other path. So which approach is used is a wash from the > caller's perspective. I don't see the path where we need to pass pointers and where this change dereferences these pointers. I think it's an improvement not to have these pointers and dereferenced when used. I like this change. I agree with the concern about bugs reversing the arguments, particularly since the constraint function has arguments in the opposite order: - Flag::Error apply_size_t(size_t* value, bool verbose) { + Flag::Error apply_size_t(size_t value, bool verbose) { return _constraint(verbose, value); } }; Would it be difficult to switch the order of arguments with these apply* functions so they match? Otherwise, unfortunately in C++ we have lots of places where we have to worry about implicit conversions with parameter passing in the code, and I would prefer using enums to defeat parameter type ambiguity than passing as a pointer where one isn't needed. But I don't think the risk of bugs with this code at this moment needs to do something about it. If there were 5 'int' convertible parameters (or 4 bools), I would agree more strongly with you. Thanks, Coleen From gerard.ziemski at oracle.com Tue Aug 4 17:52:09 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Tue, 04 Aug 2015 12:52:09 -0500 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55C0F7F8.8090208@oracle.com> References: <55BBB894.6090202@oracle.com> <33BEC3CE-D779-4621-8980-8D35D9FBB0D4@oracle.com> <55BF92BE.2050702@oracle.com> <55C0F7F8.8090208@oracle.com> Message-ID: <55C0FBC9.8020009@oracle.com> Thank you for the review. On 08/04/2015 12:35 PM, Coleen Phillimore wrote: > > I've reviewed this code. My only two comments are from two replies in > this thread: > >>> ------------------------------------------------------------------------------ >>> src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp >>> src/share/vm/runtime/commandLineFlagRangeList.cpp >>> >>> Duplicated print_error_if_needed. >> >> Right, I wasn't sure whether to factor this method out or not. I >> decided to have it local because it's trivial, but I will factor it >> out into src/share/vm/runtime/commandLineFlagRangeList.hpp/.cpp >> though that will require all the constraint files to include the >> commandLineFlagRange.List.hpp >> > > Yes, please factor out the error message functions. Done. > >> ------------------------------------------------------------------------------ >>> - Passing values by value, not pointer, to constraint functions. It >>> was thought originally that me way want to ?fix? the values, but it >>> was decided to be out of scope for the JEP. (requested by Coleen) >> I keep waffling about this, so I'll go ahead an mention it, even >> though I don't yet have a strong opinion either way. >> >> For the writer of a constraint function, not needing to deal with a >> pointer is clearly better. >> >> However, I actually kind of thought it was a feature that the values >> were passed by pointer reference rather than by value (though the >> pointer should be const-qualified if no "fixup" capability is >> intended). That prevents certain kinds of bugs due to implicit >> conversions; the types involved here provide pretty much all >> conversions between pairs of types. I'm also concerned about bugs >> resulting from reversal of the value and verbose arguments, especially >> since their order is not consistent throughout the internal APIs. >> >> There are two different pathways to these constraint functions, one of >> which is still using (and needs to use) pointers. This change >> dereferences these pointers, rather than taking the address of values >> on the other path. So which approach is used is a wash from the >> caller's perspective. > > I don't see the path where we need to pass pointers and where this > change dereferences these pointers. I think it's an improvement not > to have these pointers and dereferenced when used. I like this change. > > I agree with the concern about bugs reversing the arguments, > particularly since the constraint function has arguments in the > opposite order: > > - Flag::Error apply_size_t(size_t* value, bool verbose) { > + Flag::Error apply_size_t(size_t value, bool verbose) { > return _constraint(verbose, value); > } > }; > > Would it be difficult to switch the order of arguments with these apply* functions so they match? > > Otherwise, unfortunately in C++ we have lots of places where we have to worry about implicit conversions with parameter passing in the code, and I would prefer using enums to defeat parameter type ambiguity than passing as a pointer where one isn't needed. But I don't think the risk of bugs with this code at this moment needs to do something about it. If there were 5 'int' convertible parameters (or 4 bools), I would agree more strongly with you. Done as well, I changed the APIs to a consistent form of "Api(..., value, verbose)". I will post webrev3 after testingis done. cheers From kim.barrett at oracle.com Tue Aug 4 18:32:17 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 4 Aug 2015 14:32:17 -0400 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55C0F7F8.8090208@oracle.com> References: <55BBB894.6090202@oracle.com> <33BEC3CE-D779-4621-8980-8D35D9FBB0D4@oracle.com> <55BF92BE.2050702@oracle.com> <55C0F7F8.8090208@oracle.com> Message-ID: On Aug 4, 2015, at 1:35 PM, Coleen Phillimore wrote: > >>> - Passing values by value, not pointer, to constraint functions. It >>> was thought originally that me way want to ?fix? the values, but it >>> was decided to be out of scope for the JEP. (requested by Coleen) >>> >> I keep waffling about this, so I'll go ahead an mention it, even >> though I don't yet have a strong opinion either way. >> >> For the writer of a constraint function, not needing to deal with a >> pointer is clearly better. >> >> However, I actually kind of thought it was a feature that the values >> were passed by pointer reference rather than by value (though the >> pointer should be const-qualified if no "fixup" capability is >> intended). That prevents certain kinds of bugs due to implicit >> conversions; the types involved here provide pretty much all >> conversions between pairs of types. I'm also concerned about bugs >> resulting from reversal of the value and verbose arguments, especially >> since their order is not consistent throughout the internal APIs. >> >> There are two different pathways to these constraint functions, one of >> which is still using (and needs to use) pointers. This change >> dereferences these pointers, rather than taking the address of values >> on the other path. So which approach is used is a wash from the >> caller's perspective. >> > > I don't see the path where we need to pass pointers and where this change dereferences these pointers. I think it's an improvement not to have these pointers and dereferenced when used. I like this change. See the apply_constraint_and_check_range_XXX (static) functions in globals.cpp. Hm, these functions don?t modify the pointer value either, so could either be called with a non-pointer. And I see another thing there that I don?t understand. I guess I have some more comments to write up. > I agree with the concern about bugs reversing the arguments, particularly since the constraint function has arguments in the opposite order: > > - Flag::Error apply_size_t(size_t* value, bool verbose) { > + Flag::Error apply_size_t(size_t value, bool verbose) { > return _constraint(verbose, value); > } > }; > > Would it be difficult to switch the order of arguments with these apply* functions so they match? Yes, that?s what I was worried about. Gerard says he?s fixed that inconsistency though. > Otherwise, unfortunately in C++ we have lots of places where we have to worry about implicit conversions with parameter passing in the code, and I would prefer using enums to defeat parameter type ambiguity than passing as a pointer where one isn't needed. But I don't think the risk of bugs with this code at this moment needs to do something about it. If there were 5 'int' convertible parameters (or 4 bools), I would agree more strongly with you. I did say I was waffling about this. With the argument order inconsistency going away, and having looked again at the places where pointers are still used (with further suggestions there forthcoming), I think the benefit for writers of constraint functions pretty strongly outweighs my concerns, and I?m ok with this change. From kim.barrett at oracle.com Tue Aug 4 18:46:30 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 4 Aug 2015 14:46:30 -0400 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55BBB894.6090202@oracle.com> References: <55BBB894.6090202@oracle.com> Message-ID: On Jul 31, 2015, at 2:04 PM, gerard ziemski wrote: > > Please review this webrev 2 of the follow-up fixes including: > > [?] > bug: > https://bugs.openjdk.java.net/browse/JDK-8112746 > > webrev: > http://cr.openjdk.java.net/~gziemski/8112746_rev2/ A couple more comments: ------------------------------------------------------------------------------ > - Passing values by value, not pointer, to constraint functions. It > was thought originally that me way want to ?fix? the values, but it > was decided to be out of scope for the JEP. (requested by Coleen) In src/share/vm/runtime/globals.cpp I think all the (static) apply_constraint_and_check_range_xxx helper functions should be similarly changed to take the new_value argument by value. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.cpp 854 Flag::Error CommandLineFlagsEx::intAtPut(CommandLineFlagWithType flag, int value, Flag::Flags origin) { This function is missing call to apply_constraint_and_check_range_int. Similarly, 900 Flag::Error CommandLineFlagsEx::uintAtPut(CommandLineFlagWithType flag, uint value, Flag::Flags origin) { is missing call to apply_constraint_and_check_range_uint. ------------------------------------------------------------------------------ From gerard.ziemski at oracle.com Tue Aug 4 19:30:38 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Tue, 04 Aug 2015 14:30:38 -0500 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: References: <55BBB894.6090202@oracle.com> Message-ID: <55C112DE.1080205@oracle.com> Big thank you for this review!Comments in-line. On 08/04/2015 01:46 PM, Kim Barrett wrote: > On Jul 31, 2015, at 2:04 PM, gerard ziemski wrote: >> Please review this webrev 2 of the follow-up fixes including: >> >> [?] >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8112746 >> >> webrev: >> http://cr.openjdk.java.net/~gziemski/8112746_rev2/ > A couple more comments: > > ------------------------------------------------------------------------------ >> - Passing values by value, not pointer, to constraint functions. It >> was thought originally that me way want to ?fix? the values, but it >> was decided to be out of scope for the JEP. (requested by Coleen) > In src/share/vm/runtime/globals.cpp > > I think all the (static) apply_constraint_and_check_range_xxx helper > functions should be similarly changed to take the new_value argument > by value. Fixed. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.cpp > > 854 Flag::Error CommandLineFlagsEx::intAtPut(CommandLineFlagWithType flag, int value, Flag::Flags origin) { > > This function is missing call to apply_constraint_and_check_range_int. > > Similarly, > > 900 Flag::Error CommandLineFlagsEx::uintAtPut(CommandLineFlagWithType flag, uint value, Flag::Flags origin) { > > is missing call to apply_constraint_and_check_range_uint. Big thanks for this one - I was just investigating why I didn't see my intx constraint functionsfiring. Fixed. cheers From rednaxelafx at gmail.com Wed Aug 5 00:02:30 2015 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 4 Aug 2015 17:02:30 -0700 Subject: Why is result type of arraylength bytecode declared as T_VOID in bytecodes.cpp? Message-ID: Hi HotSpot team, Digging through history again. Does anybody recall the reason for the arraylength bytecode to be declared as having a result type of T_VOID in bytecodes.cpp, e.g. def(_arraylength , "arraylength" , "b" , NULL , T_VOID , 0, true ); ...while the xaload family of bytecodes declare the result type as appropriate, e.g. def(_iaload , "iaload" , "b" , NULL , T_INT , -1, true ); def(_laload , "laload" , "b" , NULL , T_LONG , 0, true ); def(_faload , "faload" , "b" , NULL , T_FLOAT , -1, true ); def(_daload , "daload" , "b" , NULL , T_DOUBLE , 0, true ); def(_aaload , "aaload" , "b" , NULL , T_OBJECT , -1, true ); def(_baload , "baload" , "b" , NULL , T_INT , -1, true ); def(_caload , "caload" , "b" , NULL , T_INT , -1, true ); def(_saload , "saload" , "b" , NULL , T_INT , -1, true ); Just curious if there's any peculiar history behind this difference. This information can only be accessed through Bytecodes::result_type(code), and it only used in 3 places: 2 of which are deoptimization related, and the other is in C2's GraphKit::compute_stack_effects(). If Bytecodes::result_type(Bytecodes::_arraylength) returns T_INT, then the special handling in C2's GraphKit::compute_stack_effects() wouldn't be needed: bool GraphKit::compute_stack_effects(int& inputs, int& depth) { Bytecodes::Code code = java_bc(); if (code == Bytecodes::_wide) { code = method()->java_code_at_bci(bci() + 1); } BasicType rtype = T_ILLEGAL; int rsize = 0; if (code != Bytecodes::_illegal) { depth = Bytecodes::depth(code); // checkcast=0, athrow=-1 rtype = Bytecodes::result_type(code); // checkcast=P, athrow=V if (rtype < T_CONFLICT) rsize = type2size[rtype]; } switch (code) { // ... case Bytecodes::_arraylength: inputs = 1; break; // special cased here // ... default: // bytecode produces a typed result inputs = rsize - depth; // but arraylength could be handled here if rsize were correct assert(inputs >= 0, ""); break; } return true; } Thanks, Kris From derek.white at oracle.com Fri Aug 7 02:46:56 2015 From: derek.white at oracle.com (Derek White) Date: Thu, 6 Aug 2015 22:46:56 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55B1119D.4030802@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> <55B1119D.4030802@oracle.com> Message-ID: <55C41C20.90208@oracle.com> Another RFR. I've updated based on David and Kim's last comments. http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/ https://bugs.openjdk.java.net/browse/JDK-8066821 I also have a webrev of webrev.06 vs. webrev.07: http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/ [This webrev is confused about CommandLineOptionTest.java. I double-checked with a recursive diff and the only differences are in arguments.cpp and arguments.hpp.] Thanks for looking! - Derek On 7/23/15 12:09 PM, Derek White wrote: > On 7/20/15 10:03 PM, David Holmes wrote: >> On 21/07/2015 3:02 AM, Derek White wrote: >>> Hi David, >>> >>> Thanks for looking this over. >>> >>> On 7/20/15 5:29 AM, David Holmes wrote: >>>> Hi Derek, >>>> >>>> Sorry but I'm finding this a bit confused and inconsistent. Comments >>>> below. >>>> >>>> On 18/07/2015 3:30 AM, Derek White wrote: >>>>> Request for review: >>>>> >>>>> [This updated webrev is being sent to wider audience, and has been >>>>> merged with Gerard's option constraints check-in. Also factored out >>>>> -XX:+AggressiveHeap processing into it's own chapter. I mean function >>>>> :-)] >>>>> >>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.06/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>> >>>> argument.cpp: >>>> >>>> 258 * been not scheduled). >>>> >>>> -> not been scheduled >>> >>> OK. >>>> 260 * OBSOLETE: An option may be removed (and deleted from >>>> globals.hpp), but still be accepted on the command >>>> 261 * line. A warning is printed to let the user know >>>> that support may be removed in the future. >>>> >>>> >>>> Isn't this the stronger case that support has already been removed >>>> (the option does nothing) and it will be removed at the next major >>>> release. At the start of a major release we should be able to delete >>>> all entries from the obsolete table - else it wasn't obsolete but >>>> deprecated. >>>> >>>> Not sure "obsolete" is the right term here - obsolete things still >>>> function. For us an obsolete option does nothing (it exists only in >>>> the obsolete table). >>> It's not a great name, but that what the previous code called it. >>> It's a >>> "I'll pretend you didn't say that" option, like when a teenager >>> hears an >>> adult use out-of-date slang ("groovy!"). How about a "condescending" >>> option :-) >> >> Name aside you didn't comment on my main comment here: an obsolete >> option has already been removed from globals etc and does nothing. > > Ahh, OK. I must have been confusing in tense. I'll rewrite to be more > direct. >>>> >>>> 276 * Tests: Aliases are tested in VMAliasOptions.java. >>>> 277 * Deprecated options are tested in >>>> VMDeprecatedOptions.java. >>>> 278 * Obsolete options are tested in various files. >>>> >>>> We don't normally document this kind of thing in the source. >>> >>> I'm trying to head off unnecessary one-off test files for each alias >>> and >>> deprecated option. For example TestNoParNew.java and >>> TestDefaultMaxRAMFraction.java. And I think that there should be one >>> test file for obsolete options also (perhaps expanding >>> ObsoleteFlagErrorMessage.java), instead of a bunch of separate test >>> files, but that is not in this webrev. >> >> Sounds fine but again we don't normally document test strategies in >> the source code. > Normally I'd agree but I'm trying to change current practice of tests > popping up on the corpses of dead or dying options like mushrooms in a > forest. I'm doubly adamant if I can add that last sentence to the > comment :-) >> >>>> 281 // Obsolete or deprecated -XX flag. >>>> >>>> I can tell this is going to get confusing already. >>>> >>>> 284 JDK_Version obsoleted_in; // When the warning started (obsolete >>>> or deprecated). >>>> >>>> But there is a difference: deprecated == warn but still process; >>>> obsolete == warn and ignore. >>> Yes, but the SpecialFlag type is concerned with the common aspect of >>> warning. The "ignore" or "process" aspects are handled by the different >>> functions that look up the obsolete_jvm_flags and deprecated_jvm_flags >>> arrays. >> >> So that variable should really be obsoleted_or_deprecated_in ? > > OK, I see now. It was right in front of me. Maybe "warning_started_in" > is simpler. >> >>>> >>>> 288 // When a flag is eliminated, it can be added to this list in >>>> order to >>>> 289 // continue accepting this flag on the command-line, while >>>> issuing a warning >>>> 290 // and ignoring the value. Once the JDK version reaches the >>>> 'accept_until' >>>> 291 // limit, we flatly refuse to admit the existence of the flag. >>>> 292 static SpecialFlag const obsolete_jvm_flags[] = { >>>> >>>> When a flag is eliminated it is gone from this table. As soon as the >>>> accept_until version is the current version we wipe the table of all >>>> such entries. This should be one of the first things done in a new >>>> release. >>> >>> I completely agree that this is a great plan. But until this April we >>> still had obsolete flags listed for JDK 5! The obsolete_jvm_flags table >>> did the right thing until the process caught up. In any case, this >>> webrev doesn't really change the behavior of the obsolete_jvm_flags >>> table. >> >> But what you are seeing before April is the result of hotspot express >> (at least in a large part). Now that we don't have to support that we >> don't have legacy lists to maintain. The code could even be changed >> upon detecting that current JDK version == "until" version to report >> "Hey you forgot to update the table!" ;-) > OK, that history makes more sense. >> My point is that the comments should reflect how we intend to use >> these, not give the impression that keeping eliminated options in the >> table is the expected thing to do. > > OK, I'll update the comments both here and up above to describe the > presumably common "deprecated"->"obsolete" lifecycle. >>>> >>>> 320 // When a flag is deprecated, it can be added to this list in >>>> order to issuing a warning when the flag is used. >>>> 321 // Once the JDK version reaches the 'accept_until' limit, we >>>> flatly refuse to admit the existence of the flag. >>>> 322 static SpecialFlag const deprecated_jvm_flags[] = { >>>> >>>> A deprecated flag should be obsoleted before it reaches the >>>> accept_until limit. >>> That's a policy that's under discussion on hotspot-runtime-dev. There >>> are certainly option lifecycles that have been approved by our internal >>> process that don't follow this proposed policy. The mechanism in this >>> webrev was concerned about supporting the plethora of current >>> lifecycles, for better or worse. >> >> But again comments should reflect expected usage - if we reach the >> "until" version of a deprecated option that wasn't obsoleted then >> something has probably gone wrong. > > OK. >>>> Which suggests that when we start a new version we wipe the obsoleted >>>> table and move the deprecated options into it. >>> I can add documentation to describe this case. >>> >>> If we decide that we'll always treat a deprecated or aliased option as >>> obsolete for one extra release, then it might make sense to have a >>> combined option lifecycle table. But for now I like the fact that >>> options in deprecated_jvm_flags should always have a real variable >>> defined in globals.hpp (etc), and options in obsolete_jvm_flags should >>> never have a global variable. >> >> Yes I like that too. >>> >>>> 776 case 1: { >>>> 777 if (warn) { >>>> 778 char version[256]; >>>> 779 since.to_string(version, sizeof(version)); >>>> 780 if (real_name != arg) { >>>> 781 warning("Option %s was deprecated in version %s and >>>> will likely be removed in a future release. Use option %s instead.", >>>> 782 arg, version, real_name); >>>> 783 } else { >>>> 784 warning("Option %s was deprecated in version %s and >>>> will likely be removed in a future release.", >>>> 785 arg, version); >>>> 786 } >>>> >>>> This isn't distinguishing between deprecated and obsoleted ??? >>> >>> Yes, handle_aliases_and_deprecation() doesn't handle obsolete options >>> (or it would have had a longer name :-) Maybe it should handle that >>> case, but it would have complicated the control flow in the caller. I >>> have another proposed change in the works that simplifies the caller >>> quite a bit that would make the refactoring simpler. >> >> I need to think more on that. It is hard to see the overall control >> flow for argument processing. > > Yes it is hard to see. Currently options are parsed into tokens in a > couple of places. It's roughly either: > [+][-]arg > or: > arg[:]=[value] > > But not all of the code handles ":=". Furthermore option processing > figures out the type of the argument by repeatedly trying to scanf > "value" to see if it looks like floating point, or an integer, or > maybe just text. I think we should first parsing out the arg name, get > the Flag, and ask the Flag what type it is. This would make it much > easier to handle aliases, deprecation, and obsoleting options in one > place. > > I have a workspace that does this but I suspect there could be slight > differences in how errors would be reported. >> >> Thanks, >> David > Thanks for looking at this again. It's heading in the right direction! > - Derek > From serguei.spitsyn at oracle.com Fri Aug 7 10:19:20 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 07 Aug 2015 03:19:20 -0700 Subject: RFR(S) 8033577: Message-ID: <55C48628.3000407@oracle.com> Please, review the jdk 9 fix for: https://bugs.openjdk.java.net/browse/JDK-8033577 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8033577-dtrace-parfait1.1/ Summary: The fix includes: - the parfait fixes listed in the bug report and - a couple of adjustments for the bsd version to match the solaris version Testing: The JPRT build Thanks, Serguei From serguei.spitsyn at oracle.com Fri Aug 7 10:21:46 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 07 Aug 2015 03:21:46 -0700 Subject: RFR(S) 8033577: [parfait] warnings from b128 for hotspot/src/os/solaris/dtrace: Unportable format string argument mismatch In-Reply-To: <55C48628.3000407@oracle.com> References: <55C48628.3000407@oracle.com> Message-ID: <55C486BA.9030005@oracle.com> Re-posting this with the updated subject line. Please, review the jdk 9 fix for: https://bugs.openjdk.java.net/browse/JDK-8033577 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8033577-dtrace-parfait1.1/ Summary: The fix includes: - the parfait fixes listed in the bug report and - a couple of adjustments for the bsd version to match the solaris version Testing: The JPRT build Thanks, Serguei From serguei.spitsyn at oracle.com Fri Aug 7 10:25:36 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 07 Aug 2015 03:25:36 -0700 Subject: RFR(S) 8080401: Uninitialised variable in hotspot/src/os/solaris/dtrace/ Message-ID: <55C487A0.9040904@oracle.com> Please, review the jdk 9 fix for: https://bugs.openjdk.java.net/browse/JDK-8080401 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8080401-dtrace-parfait2.1/ Summary: The fix includes the parfait issues listed in the bug report. Testing: The JPRT build Thanks, Serguei From staffan.larsen at oracle.com Fri Aug 7 11:22:52 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 7 Aug 2015 13:22:52 +0200 Subject: RFR(S) 8080401: Uninitialised variable in hotspot/src/os/solaris/dtrace/ In-Reply-To: <55C487A0.9040904@oracle.com> References: <55C487A0.9040904@oracle.com> Message-ID: <6A4AA882-4BAC-47D1-A0B5-A522B3096EDC@oracle.com> Looks good! Thanks, /Staffan > On 7 aug 2015, at 12:25, serguei.spitsyn at oracle.com wrote: > > > Please, review the jdk 9 fix for: > https://bugs.openjdk.java.net/browse/JDK-8080401 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8080401-dtrace-parfait2.1/ > > > Summary: > > The fix includes the parfait issues listed in the bug report. > > > Testing: > The JPRT build > > > Thanks, > Serguei From staffan.larsen at oracle.com Fri Aug 7 11:23:46 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 7 Aug 2015 13:23:46 +0200 Subject: RFR(S) 8033577: [parfait] warnings from b128 for hotspot/src/os/solaris/dtrace: Unportable format string argument mismatch In-Reply-To: <55C486BA.9030005@oracle.com> References: <55C48628.3000407@oracle.com> <55C486BA.9030005@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 7 aug 2015, at 12:21, serguei.spitsyn at oracle.com wrote: > > Re-posting this with the updated subject line. > > Please, review the jdk 9 fix for: > https://bugs.openjdk.java.net/browse/JDK-8033577 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8033577-dtrace-parfait1.1/ > > > Summary: > The fix includes: > - the parfait fixes listed in the bug report and > - a couple of adjustments for the bsd version to match the solaris > version > > > Testing: > The JPRT build > > > Thanks, > Serguei > > > From serguei.spitsyn at oracle.com Fri Aug 7 11:25:48 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Aug 2015 04:25:48 -0700 Subject: RFR(S) 8080401: Uninitialised variable in hotspot/src/os/solaris/dtrace/ In-Reply-To: <6A4AA882-4BAC-47D1-A0B5-A522B3096EDC@oracle.com> References: <55C487A0.9040904@oracle.com> <6A4AA882-4BAC-47D1-A0B5-A522B3096EDC@oracle.com> Message-ID: <55C495BC.6070503@oracle.com> Thanks, Staffan! Serguei On 8/7/15 04:22, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 7 aug 2015, at 12:25, serguei.spitsyn at oracle.com wrote: >> >> >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8080401 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8080401-dtrace-parfait2.1/ >> >> >> Summary: >> >> The fix includes the parfait issues listed in the bug report. >> >> >> Testing: >> The JPRT build >> >> >> Thanks, >> Serguei From serguei.spitsyn at oracle.com Fri Aug 7 11:26:03 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Aug 2015 04:26:03 -0700 Subject: RFR(S) 8033577: [parfait] warnings from b128 for hotspot/src/os/solaris/dtrace: Unportable format string argument mismatch In-Reply-To: References: <55C48628.3000407@oracle.com> <55C486BA.9030005@oracle.com> Message-ID: <55C495CB.4040203@oracle.com> Thanks, Staffan! Serguei On 8/7/15 04:23, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 7 aug 2015, at 12:21, serguei.spitsyn at oracle.com wrote: >> >> Re-posting this with the updated subject line. >> >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8033577 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8033577-dtrace-parfait1.1/ >> >> >> Summary: >> The fix includes: >> - the parfait fixes listed in the bug report and >> - a couple of adjustments for the bsd version to match the solaris >> version >> >> >> Testing: >> The JPRT build >> >> >> Thanks, >> Serguei >> >> >> From dmitry.samersoff at oracle.com Fri Aug 7 12:11:22 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 07 Aug 2015 15:11:22 +0300 Subject: RFR(S) 8033577: [parfait] warnings from b128 for hotspot/src/os/solaris/dtrace: Unportable format string argument mismatch In-Reply-To: <55C486BA.9030005@oracle.com> References: <55C48628.3000407@oracle.com> <55C486BA.9030005@oracle.com> Message-ID: <55C4A06A.3030203@oracle.com> Looks good for me. On 2015-08-07 13:21, serguei.spitsyn at oracle.com wrote: > Re-posting this with the updated subject line. > > Please, review the jdk 9 fix for: > https://bugs.openjdk.java.net/browse/JDK-8033577 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8033577-dtrace-parfait1.1/ > > > > Summary: > The fix includes: > - the parfait fixes listed in the bug report and > - a couple of adjustments for the bsd version to match the solaris > version > > > Testing: > The JPRT build > > > 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 volker.simonis at gmail.com Fri Aug 7 12:39:58 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 7 Aug 2015 14:39:58 +0200 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: <55AD0339.2060606@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> <55AD0339.2060606@oracle.com> Message-ID: On Mon, Jul 20, 2015 at 4:18 PM, Daniel D. Daugherty wrote: > On 7/17/15 4:58 PM, Volker Simonis wrote: > > > > On Saturday, July 18, 2015, Daniel D. Daugherty > wrote: >> >> On 7/16/15 9:18 AM, Langer, Christoph wrote: >>> >>> Hi all, >>> >>> >>> >>> I don't know if this mailing list is the right one for this issue. Let me >>> know if I should post it elsewhere. >>> >>> >>> >>> I have prepared a fix for an issue with /tmp/hsperfdata files. >>> >>> >>> >>> Please review this change. I also need a sponsor. >>> >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8130910 >>> >>> Change: http://cr.openjdk.java.net/~simonis/webrevs/2015/8130910/ >> >> >> src/os/aix/vm/perfMemory_aix.cpp >> No comments. >> >> src/os/bsd/vm/perfMemory_bsd.cpp >> No comments. >> >> src/os/linux/vm/perfMemory_linux.cpp >> No comments. >> >> src/os/solaris/vm/perfMemory_solaris.cpp >> No comments. >> >> >> I think I'm OK with the code changes above, but I need more >> time to mull on them. I also need time to mull on the stuff >> down below. >> > Hi Dan, > > thanks for looking at this change. > > Maybe I can add some more context here. Christoph detected this issue when > somebody who ran the VM in a security context with a umask which masked out > all the executable bits of newly created files complained about the stale > files in the current working directory. > > > Thanks for the context. > > > > I think that Chritoph's change is good > > > I concur that the change is good. I'm simply mulling on potential > side effects. > Hi Dan, have you come to a conclusion? Regards, Volker > > and I also share his doubts about changing the current working directory. I > think this is questionable because it can have non-local side effects but I > think this should be fixed in a follow up change. > > > Changing the working directory can definitely have non-local side > effects, but the change of directory is a necessary part of the > secure file system object creation protocol. Jerry has a good > comment that explains what APIs we would rather use than changing > the current working directory, but those APIs don't exist on all > platforms (yet). > > 348 // NOTE: The code below uses fchdir(), open() and unlink() because > 349 // fdopendir(), openat() and unlinkat() are not supported on all > 350 // versions. Once the support for fdopendir(), openat() and unlinkat() > 351 // is available on all supported versions the code can be changed > 352 // to use these functions. > 353 > 354 // Open the directory of the given path, validate it and set the > 355 // current working directory to it. > 356 // Return a DIR * of the open directory and the saved cwd fd. > 357 // > 358 static DIR *open_directory_secure_cwd(const char* dirname, int > *saved_cwd_fd) { > > The protocol is basically: > > open_directory_secure_cwd() > do operations to files in the directory using relative paths > close_directory_secure_cwd() > > The alternative of using full paths is difficult to do safely without > exposure to attacks along exposed path elements. > > Dan > > > > Thanks, > Volker > >> Will get back to this next week. >> >> Dan >> >> >>> >>> >>> >>> The problem is that for creating a file in /tmp/hsperfdata_, an >>> fchdir to this directory is attempted. In case there's no execute permission >>> on /tmp/hsperfdata_, the fchdir fails. As its return code is not >>> checked up to now, the process would stay in its current working directory >>> and create the file in there. The location stored for cleaning up at the end >>> of the VM is also remembered as /tmp/hsperfdata... so the file would remain >>> left over eventually. There are several checks for the hsperfdata location >>> in place but nothing would hit and prevent the fchdir attempt beforehand in >>> this case. >>> >>> >>> >>> I fixed it by handling fchdir return code and in case of failure closing >>> the handles and returning NULL. In that case we wouldn't have shared >>> PerfMemory but I think that is ok then. >>> >>> >>> >>> I thought about a testcase but it would involve messing around with >>> /tmp/hsperfdata permissions which can have effects on other running JVMs, >>> too, which I consider a bit dangerous. >>> >>> >>> >>> Generally I don't know if it is a good idea to do an fchdir at all but I >>> don't know so much about the backgrounds of it... maybe someone wants to >>> comment on that as well. >>> >>> >>> >>> Thanks and best regards, >>> >>> Christoph >>> >>> >>> >> > From serguei.spitsyn at oracle.com Fri Aug 7 13:33:41 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Aug 2015 06:33:41 -0700 Subject: RFR(S) 8033577: [parfait] warnings from b128 for hotspot/src/os/solaris/dtrace: Unportable format string argument mismatch In-Reply-To: <55C4A06A.3030203@oracle.com> References: <55C48628.3000407@oracle.com> <55C486BA.9030005@oracle.com> <55C4A06A.3030203@oracle.com> Message-ID: <55C4B3B5.8060606@oracle.com> Thanks, Dmitry! May I ask you to look at another parfait fix (8080401)? I hope, it is simple enough. Thanks, Serguei On 8/7/15 05:11, Dmitry Samersoff wrote: > Looks good for me. > > On 2015-08-07 13:21, serguei.spitsyn at oracle.com wrote: >> Re-posting this with the updated subject line. >> >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8033577 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8033577-dtrace-parfait1.1/ >> >> >> >> Summary: >> The fix includes: >> - the parfait fixes listed in the bug report and >> - a couple of adjustments for the bsd version to match the solaris >> version >> >> >> Testing: >> The JPRT build >> >> >> Thanks, >> Serguei >> >> >> > From dmitry.samersoff at oracle.com Fri Aug 7 13:45:49 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 07 Aug 2015 16:45:49 +0300 Subject: RFR(S) 8080401: Uninitialised variable in hotspot/src/os/solaris/dtrace/ In-Reply-To: <55C487A0.9040904@oracle.com> References: <55C487A0.9040904@oracle.com> Message-ID: <55C4B68D.6040501@oracle.com> Serguei, Looks good for me. It might be better to use (uint64_t) -1 for initialization of pc_diff in libjvm_db.c -Dmitry On 2015-08-07 13:25, serguei.spitsyn at oracle.com wrote: > > Please, review the jdk 9 fix for: > https://bugs.openjdk.java.net/browse/JDK-8080401 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8080401-dtrace-parfait2.1/ > > > > Summary: > > The fix includes the parfait issues listed in the bug report. > > > Testing: > The JPRT build > > > 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 coleen.phillimore at oracle.com Fri Aug 7 13:49:57 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 07 Aug 2015 09:49:57 -0400 Subject: RFR(S) 8033577: [parfait] warnings from b128 for hotspot/src/os/solaris/dtrace: Unportable format string argument mismatch In-Reply-To: <55C486BA.9030005@oracle.com> References: <55C48628.3000407@oracle.com> <55C486BA.9030005@oracle.com> Message-ID: <55C4B785.5040007@oracle.com> In nmethod, there is still an _oops_offset as well as _metadata_offset. I don't know if this code needs it though. Coleen On 8/7/15 6:21 AM, serguei.spitsyn at oracle.com wrote: > Re-posting this with the updated subject line. > > Please, review the jdk 9 fix for: > https://bugs.openjdk.java.net/browse/JDK-8033577 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8033577-dtrace-parfait1.1/ > > > > Summary: > The fix includes: > - the parfait fixes listed in the bug report and > - a couple of adjustments for the bsd version to match the solaris > version > > > Testing: > The JPRT build > > > Thanks, > Serguei > > > From serguei.spitsyn at oracle.com Fri Aug 7 13:53:21 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Aug 2015 06:53:21 -0700 Subject: RFR(S) 8080401: Uninitialised variable in hotspot/src/os/solaris/dtrace/ In-Reply-To: <55C4B68D.6040501@oracle.com> References: <55C487A0.9040904@oracle.com> <55C4B68D.6040501@oracle.com> Message-ID: <55C4B851.1040908@oracle.com> On 8/7/15 06:45, Dmitry Samersoff wrote: > Serguei, > > Looks good for me. Thanks a lot! > > It might be better to use (uint64_t) -1 for initialization of pc_diff in > libjvm_db.c Thank you for the suggestion. It'd work but not that important. :) Thanks, Serguei > > -Dmitry > > On 2015-08-07 13:25, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8080401 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8080401-dtrace-parfait2.1/ >> >> >> >> Summary: >> >> The fix includes the parfait issues listed in the bug report. >> >> >> Testing: >> The JPRT build >> >> >> Thanks, >> Serguei > From serguei.spitsyn at oracle.com Fri Aug 7 13:54:40 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Aug 2015 06:54:40 -0700 Subject: RFR(S) 8033577: [parfait] warnings from b128 for hotspot/src/os/solaris/dtrace: Unportable format string argument mismatch In-Reply-To: <55C4B785.5040007@oracle.com> References: <55C48628.3000407@oracle.com> <55C486BA.9030005@oracle.com> <55C4B785.5040007@oracle.com> Message-ID: <55C4B8A0.1050705@oracle.com> Thanks, Coleen! I'll check it tomorrow. Thanks, Serguei On 8/7/15 06:49, Coleen Phillimore wrote: > > In nmethod, there is still an _oops_offset as well as > _metadata_offset. I don't know if this code needs it though. > > Coleen > > On 8/7/15 6:21 AM, serguei.spitsyn at oracle.com wrote: >> Re-posting this with the updated subject line. >> >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8033577 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8033577-dtrace-parfait1.1/ >> >> >> >> Summary: >> The fix includes: >> - the parfait fixes listed in the bug report and >> - a couple of adjustments for the bsd version to match the solaris >> version >> >> >> Testing: >> The JPRT build >> >> >> Thanks, >> Serguei >> >> >> > From daniel.daugherty at oracle.com Fri Aug 7 14:16:54 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 07 Aug 2015 08:16:54 -0600 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> <55AD0339.2060606@oracle.com> Message-ID: <55C4BDD6.5010409@oracle.com> Volker, Sorry I didn't get back to this thread before I went on vacation. I'll try to refresh the thread in my brain and get back to you guys shortly... Dan On 8/7/15 6:39 AM, Volker Simonis wrote: > On Mon, Jul 20, 2015 at 4:18 PM, Daniel D. Daugherty > wrote: >> On 7/17/15 4:58 PM, Volker Simonis wrote: >> >> >> >> On Saturday, July 18, 2015, Daniel D. Daugherty >> wrote: >>> On 7/16/15 9:18 AM, Langer, Christoph wrote: >>>> Hi all, >>>> >>>> >>>> >>>> I don't know if this mailing list is the right one for this issue. Let me >>>> know if I should post it elsewhere. >>>> >>>> >>>> >>>> I have prepared a fix for an issue with /tmp/hsperfdata files. >>>> >>>> >>>> >>>> Please review this change. I also need a sponsor. >>>> >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8130910 >>>> >>>> Change: http://cr.openjdk.java.net/~simonis/webrevs/2015/8130910/ >>> >>> src/os/aix/vm/perfMemory_aix.cpp >>> No comments. >>> >>> src/os/bsd/vm/perfMemory_bsd.cpp >>> No comments. >>> >>> src/os/linux/vm/perfMemory_linux.cpp >>> No comments. >>> >>> src/os/solaris/vm/perfMemory_solaris.cpp >>> No comments. >>> >>> >>> I think I'm OK with the code changes above, but I need more >>> time to mull on them. I also need time to mull on the stuff >>> down below. >>> >> Hi Dan, >> >> thanks for looking at this change. >> >> Maybe I can add some more context here. Christoph detected this issue when >> somebody who ran the VM in a security context with a umask which masked out >> all the executable bits of newly created files complained about the stale >> files in the current working directory. >> >> >> Thanks for the context. >> >> >> >> I think that Chritoph's change is good >> >> >> I concur that the change is good. I'm simply mulling on potential >> side effects. >> > Hi Dan, > > have you come to a conclusion? > > Regards, > Volker > >> and I also share his doubts about changing the current working directory. I >> think this is questionable because it can have non-local side effects but I >> think this should be fixed in a follow up change. >> >> >> Changing the working directory can definitely have non-local side >> effects, but the change of directory is a necessary part of the >> secure file system object creation protocol. Jerry has a good >> comment that explains what APIs we would rather use than changing >> the current working directory, but those APIs don't exist on all >> platforms (yet). >> >> 348 // NOTE: The code below uses fchdir(), open() and unlink() because >> 349 // fdopendir(), openat() and unlinkat() are not supported on all >> 350 // versions. Once the support for fdopendir(), openat() and unlinkat() >> 351 // is available on all supported versions the code can be changed >> 352 // to use these functions. >> 353 >> 354 // Open the directory of the given path, validate it and set the >> 355 // current working directory to it. >> 356 // Return a DIR * of the open directory and the saved cwd fd. >> 357 // >> 358 static DIR *open_directory_secure_cwd(const char* dirname, int >> *saved_cwd_fd) { >> >> The protocol is basically: >> >> open_directory_secure_cwd() >> do operations to files in the directory using relative paths >> close_directory_secure_cwd() >> >> The alternative of using full paths is difficult to do safely without >> exposure to attacks along exposed path elements. >> >> Dan >> >> >> >> Thanks, >> Volker >> >>> Will get back to this next week. >>> >>> Dan >>> >>> >>>> >>>> >>>> The problem is that for creating a file in /tmp/hsperfdata_, an >>>> fchdir to this directory is attempted. In case there's no execute permission >>>> on /tmp/hsperfdata_, the fchdir fails. As its return code is not >>>> checked up to now, the process would stay in its current working directory >>>> and create the file in there. The location stored for cleaning up at the end >>>> of the VM is also remembered as /tmp/hsperfdata... so the file would remain >>>> left over eventually. There are several checks for the hsperfdata location >>>> in place but nothing would hit and prevent the fchdir attempt beforehand in >>>> this case. >>>> >>>> >>>> >>>> I fixed it by handling fchdir return code and in case of failure closing >>>> the handles and returning NULL. In that case we wouldn't have shared >>>> PerfMemory but I think that is ok then. >>>> >>>> >>>> >>>> I thought about a testcase but it would involve messing around with >>>> /tmp/hsperfdata permissions which can have effects on other running JVMs, >>>> too, which I consider a bit dangerous. >>>> >>>> >>>> >>>> Generally I don't know if it is a good idea to do an fchdir at all but I >>>> don't know so much about the backgrounds of it... maybe someone wants to >>>> comment on that as well. >>>> >>>> >>>> >>>> Thanks and best regards, >>>> >>>> Christoph >>>> >>>> >>>> From serguei.spitsyn at oracle.com Fri Aug 7 15:02:50 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 07 Aug 2015 08:02:50 -0700 Subject: RFR(S) 8033577: [parfait] warnings from b128 for hotspot/src/os/solaris/dtrace: Unportable format string argument mismatch In-Reply-To: <55C4B785.5040007@oracle.com> References: <55C48628.3000407@oracle.com> <55C486BA.9030005@oracle.com> <55C4B785.5040007@oracle.com> Message-ID: <55C4C89A.3060408@oracle.com> Coleen, I've checked and found that the _metadata_offset is needed but the _oops_offset is not. The _metadata_offset is used in the libjvm_db only. Thanks, Srguei On 8/7/15 6:49 AM, Coleen Phillimore wrote: > > In nmethod, there is still an _oops_offset as well as > _metadata_offset. I don't know if this code needs it though. > > Coleen > > On 8/7/15 6:21 AM, serguei.spitsyn at oracle.com wrote: >> Re-posting this with the updated subject line. >> >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8033577 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8033577-dtrace-parfait1.1/ >> >> >> >> Summary: >> The fix includes: >> - the parfait fixes listed in the bug report and >> - a couple of adjustments for the bsd version to match the solaris >> version >> >> >> Testing: >> The JPRT build >> >> >> Thanks, >> Serguei >> >> >> > From coleen.phillimore at oracle.com Fri Aug 7 15:24:35 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 07 Aug 2015 11:24:35 -0400 Subject: RFR(S) 8033577: [parfait] warnings from b128 for hotspot/src/os/solaris/dtrace: Unportable format string argument mismatch In-Reply-To: <55C4C89A.3060408@oracle.com> References: <55C48628.3000407@oracle.com> <55C486BA.9030005@oracle.com> <55C4B785.5040007@oracle.com> <55C4C89A.3060408@oracle.com> Message-ID: <55C4CDB3.3010605@oracle.com> On 8/7/15 11:02 AM, serguei.spitsyn at oracle.com wrote: > Coleen, > > I've checked and found that the _metadata_offset is needed but the > _oops_offset is not. > The _metadata_offset is used in the libjvm_db only. Okay, this is fine then. Coleen > > Thanks, > Srguei > > On 8/7/15 6:49 AM, Coleen Phillimore wrote: >> >> In nmethod, there is still an _oops_offset as well as >> _metadata_offset. I don't know if this code needs it though. >> >> Coleen >> >> On 8/7/15 6:21 AM, serguei.spitsyn at oracle.com wrote: >>> Re-posting this with the updated subject line. >>> >>> Please, review the jdk 9 fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8033577 >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8033577-dtrace-parfait1.1/ >>> >>> >>> >>> Summary: >>> The fix includes: >>> - the parfait fixes listed in the bug report and >>> - a couple of adjustments for the bsd version to match the solaris >>> version >>> >>> >>> Testing: >>> The JPRT build >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> >> > From serguei.spitsyn at oracle.com Fri Aug 7 15:26:54 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 07 Aug 2015 08:26:54 -0700 Subject: RFR(S) 8033577: [parfait] warnings from b128 for hotspot/src/os/solaris/dtrace: Unportable format string argument mismatch In-Reply-To: <55C4CDB3.3010605@oracle.com> References: <55C48628.3000407@oracle.com> <55C486BA.9030005@oracle.com> <55C4B785.5040007@oracle.com> <55C4C89A.3060408@oracle.com> <55C4CDB3.3010605@oracle.com> Message-ID: <55C4CE3E.1070204@oracle.com> Thanks, Coleen! Serguei On 8/7/15 8:24 AM, Coleen Phillimore wrote: > > > On 8/7/15 11:02 AM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> I've checked and found that the _metadata_offset is needed but the >> _oops_offset is not. >> The _metadata_offset is used in the libjvm_db only. > > Okay, this is fine then. > Coleen > >> >> Thanks, >> Srguei >> >> On 8/7/15 6:49 AM, Coleen Phillimore wrote: >>> >>> In nmethod, there is still an _oops_offset as well as >>> _metadata_offset. I don't know if this code needs it though. >>> >>> Coleen >>> >>> On 8/7/15 6:21 AM, serguei.spitsyn at oracle.com wrote: >>>> Re-posting this with the updated subject line. >>>> >>>> Please, review the jdk 9 fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8033577 >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8033577-dtrace-parfait1.1/ >>>> >>>> >>>> >>>> Summary: >>>> The fix includes: >>>> - the parfait fixes listed in the bug report and >>>> - a couple of adjustments for the bsd version to match the solaris >>>> version >>>> >>>> >>>> Testing: >>>> The JPRT build >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>> >> > From gerard.ziemski at oracle.com Fri Aug 7 16:36:51 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Fri, 07 Aug 2015 11:36:51 -0500 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) Message-ID: <55C4DEA3.8090109@oracle.com> hi, Please review this webrev 3 of the follow-up fixes including: - Passing values by value, not pointer, to constraint functions. It was thought originally that me way want to ?fix? the values, but it was decided to be out of scope for the JEP. (requested by Coleen) - Add print_error_as_needed() utility function to range/constraint code to improve code robustness (requested by Coleen) - Remove debug code (requested by Kim Barrett) - Implement Flag::flag_error_str in .cpp file (requested by Kim Barrett) - Only check constraint if range passes (requested by Kim Barrett) - Merged with Sangheon Kim fix for "Add additional validation after heap creation? (JDK-8130459) Changes in webrev3 compared to webrev2: - Adding DBL_MAX - decided to let Sangheon handle this as part of his effort to add missing GC flags ranges/constraints - Do not bother checking for NULL in CommandLineFlagRangesList::check_ranges() and CommandLineFlagConstraintsList::check_constraints() - we crash on 32bit platforms if we do this, so can't do it. The problem exists because there are certain flags (ie. lp64_product) that have ranges (ie. ObjectAlignmentInBytes) that are defined as constants on 32 bit platforms, but still register as flags with ranges. I added comments to the code in question. - Implement missing range/constraints check in "int" and "uint" CommandLineFlagsEx::*AtPut() APIs - Factored out common error printing code - Use "ShouldNotReachHere()" in Flag::flag_error_str() - Consistent constraint error message formating - Consistent placement of "verbose" argument in APIs - Fix other APIs that used to pass value by reference - Merged with Roland Westlin fix for "CICompilerCount=1 when tiered is off is not allowed any more" (JDK-8130858) This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? References: JEP 245: https://bugs.openjdk.java.net/browse/JDK-8122937 bug: https://bugs.openjdk.java.net/browse/JDK-8112746 webrev: http://cr.openjdk.java.net/~gziemski/8112746_rev3/ cheers From sangheon.kim at oracle.com Fri Aug 7 17:30:55 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Fri, 07 Aug 2015 10:30:55 -0700 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55C4DEA3.8090109@oracle.com> References: <55C4DEA3.8090109@oracle.com> Message-ID: <55C4EB4F.1050106@oracle.com> Hi Gerard, Before looking at this new webrev, I found that below are missing. 'apply_int / apply_uint' from CommandLineFlagConstraintList::check_constraints() 'check_int / check_uint' from CommandLineFlagRangeList::check_ranges() If you want to handle these from other RFE, I'm fine. Thanks, Sangheon On 08/07/2015 09:36 AM, gerard ziemski wrote: > hi, > > Please review this webrev 3 of the follow-up fixes including: > > - Passing values by value, not pointer, to constraint functions. It > was thought originally that me way want to ?fix? the values, but it > was decided to be out of scope for the JEP. (requested by Coleen) > > - Add print_error_as_needed() utility function to range/constraint > code to improve code robustness (requested by Coleen) > > - Remove debug code (requested by Kim Barrett) > > - Implement Flag::flag_error_str in .cpp file (requested by Kim Barrett) > > - Only check constraint if range passes (requested by Kim Barrett) > > - Merged with Sangheon Kim fix for "Add additional validation after > heap creation? (JDK-8130459) > > > Changes in webrev3 compared to webrev2: > > - Adding DBL_MAX - decided to let Sangheon handle this as part of his > effort to add missing GC flags ranges/constraints > > - Do not bother checking for NULL in > CommandLineFlagRangesList::check_ranges() and > CommandLineFlagConstraintsList::check_constraints() - we crash on > 32bit platforms if we do this, so can't do it. The problem exists > because there are certain flags (ie. lp64_product) that have ranges > (ie. ObjectAlignmentInBytes) that are defined as constants on 32 bit > platforms, but still register as flags with ranges. I added comments > to the code in question. > > - Implement missing range/constraints check in "int" and "uint" > CommandLineFlagsEx::*AtPut() APIs > > - Factored out common error printing code > > - Use "ShouldNotReachHere()" in Flag::flag_error_str() > > - Consistent constraint error message formating > > - Consistent placement of "verbose" argument in APIs > > - Fix other APIs that used to pass value by reference > > - Merged with Roland Westlin fix for "CICompilerCount=1 when tiered is > off is not allowed any more" (JDK-8130858) > > > This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? > > > References: > > JEP 245: https://bugs.openjdk.java.net/browse/JDK-8122937 > bug: https://bugs.openjdk.java.net/browse/JDK-8112746 > webrev: http://cr.openjdk.java.net/~gziemski/8112746_rev3/ > > > cheers > From gerard.ziemski at oracle.com Fri Aug 7 17:50:28 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Fri, 07 Aug 2015 12:50:28 -0500 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55C4EB4F.1050106@oracle.com> References: <55C4DEA3.8090109@oracle.com> <55C4EB4F.1050106@oracle.com> Message-ID: <55C4EFE4.4020000@oracle.com> On 08/07/2015 12:30 PM, sangheon.kim wrote: > Hi Gerard, > > Before looking at this new webrev, I found that below are missing. > > 'apply_int / apply_uint' from > CommandLineFlagConstraintList::check_constraints() > 'check_int / check_uint' from CommandLineFlagRangeList::check_ranges() > > If you want to handle these from other RFE, I'm fine. Great catch, I would prefer to handle this here now and be done. Fixed. cheers > > Thanks, > Sangheon > > > On 08/07/2015 09:36 AM, gerard ziemski wrote: >> hi, >> >> Please review this webrev 3 of the follow-up fixes including: >> >> - Passing values by value, not pointer, to constraint functions. It >> was thought originally that me way want to ?fix? the values, but it >> was decided to be out of scope for the JEP. (requested by Coleen) >> >> - Add print_error_as_needed() utility function to range/constraint >> code to improve code robustness (requested by Coleen) >> >> - Remove debug code (requested by Kim Barrett) >> >> - Implement Flag::flag_error_str in .cpp file (requested by Kim Barrett) >> >> - Only check constraint if range passes (requested by Kim Barrett) >> >> - Merged with Sangheon Kim fix for "Add additional validation after >> heap creation? (JDK-8130459) >> >> >> Changes in webrev3 compared to webrev2: >> >> - Adding DBL_MAX - decided to let Sangheon handle this as part of his >> effort to add missing GC flags ranges/constraints >> >> - Do not bother checking for NULL in >> CommandLineFlagRangesList::check_ranges() and >> CommandLineFlagConstraintsList::check_constraints() - we crash on >> 32bit platforms if we do this, so can't do it. The problem exists >> because there are certain flags (ie. lp64_product) that have ranges >> (ie. ObjectAlignmentInBytes) that are defined as constants on 32 bit >> platforms, but still register as flags with ranges. I added comments >> to the code in question. >> >> - Implement missing range/constraints check in "int" and "uint" >> CommandLineFlagsEx::*AtPut() APIs >> >> - Factored out common error printing code >> >> - Use "ShouldNotReachHere()" in Flag::flag_error_str() >> >> - Consistent constraint error message formating >> >> - Consistent placement of "verbose" argument in APIs >> >> - Fix other APIs that used to pass value by reference >> >> - Merged with Roland Westlin fix for "CICompilerCount=1 when tiered is >> off is not allowed any more" (JDK-8130858) >> >> >> This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? >> >> >> References: >> >> JEP 245: https://bugs.openjdk.java.net/browse/JDK-8122937 >> bug: https://bugs.openjdk.java.net/browse/JDK-8112746 >> webrev: http://cr.openjdk.java.net/~gziemski/8112746_rev3/ >> >> >> cheers >> > > > From coleen.phillimore at oracle.com Fri Aug 7 23:21:04 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 07 Aug 2015 19:21:04 -0400 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55C4EFE4.4020000@oracle.com> References: <55C4DEA3.8090109@oracle.com> <55C4EB4F.1050106@oracle.com> <55C4EFE4.4020000@oracle.com> Message-ID: <55C53D60.7090508@oracle.com> The improvements look really good to me. Coleen On 8/7/15 1:50 PM, gerard ziemski wrote: > > > On 08/07/2015 12:30 PM, sangheon.kim wrote: >> Hi Gerard, >> >> Before looking at this new webrev, I found that below are missing. >> >> 'apply_int / apply_uint' from >> CommandLineFlagConstraintList::check_constraints() >> 'check_int / check_uint' from CommandLineFlagRangeList::check_ranges() >> >> If you want to handle these from other RFE, I'm fine. > > Great catch, I would prefer to handle this here now and be done. Fixed. > > > cheers > >> >> Thanks, >> Sangheon >> >> >> On 08/07/2015 09:36 AM, gerard ziemski wrote: >>> hi, >>> >>> Please review this webrev 3 of the follow-up fixes including: >>> >>> - Passing values by value, not pointer, to constraint functions. It >>> was thought originally that me way want to ?fix? the values, but it >>> was decided to be out of scope for the JEP. (requested by Coleen) >>> >>> - Add print_error_as_needed() utility function to range/constraint >>> code to improve code robustness (requested by Coleen) >>> >>> - Remove debug code (requested by Kim Barrett) >>> >>> - Implement Flag::flag_error_str in .cpp file (requested by Kim >>> Barrett) >>> >>> - Only check constraint if range passes (requested by Kim Barrett) >>> >>> - Merged with Sangheon Kim fix for "Add additional validation after >>> heap creation? (JDK-8130459) >>> >>> >>> Changes in webrev3 compared to webrev2: >>> >>> - Adding DBL_MAX - decided to let Sangheon handle this as part of his >>> effort to add missing GC flags ranges/constraints >>> >>> - Do not bother checking for NULL in >>> CommandLineFlagRangesList::check_ranges() and >>> CommandLineFlagConstraintsList::check_constraints() - we crash on >>> 32bit platforms if we do this, so can't do it. The problem exists >>> because there are certain flags (ie. lp64_product) that have ranges >>> (ie. ObjectAlignmentInBytes) that are defined as constants on 32 bit >>> platforms, but still register as flags with ranges. I added comments >>> to the code in question. >>> >>> - Implement missing range/constraints check in "int" and "uint" >>> CommandLineFlagsEx::*AtPut() APIs >>> >>> - Factored out common error printing code >>> >>> - Use "ShouldNotReachHere()" in Flag::flag_error_str() >>> >>> - Consistent constraint error message formating >>> >>> - Consistent placement of "verbose" argument in APIs >>> >>> - Fix other APIs that used to pass value by reference >>> >>> - Merged with Roland Westlin fix for "CICompilerCount=1 when tiered is >>> off is not allowed any more" (JDK-8130858) >>> >>> >>> This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? >>> >>> >>> References: >>> >>> JEP 245: https://bugs.openjdk.java.net/browse/JDK-8122937 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8112746 >>> webrev: http://cr.openjdk.java.net/~gziemski/8112746_rev3/ >>> >>> >>> cheers >>> >> >> >> From david.holmes at oracle.com Mon Aug 10 05:53:32 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 10 Aug 2015 15:53:32 +1000 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55C41C20.90208@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> <55B1119D.4030802@oracle.com> <55C41C20.90208@oracle.com> Message-ID: <55C83C5C.60702@oracle.com> Hi Derek, I don't have any further comments. Thanks, David On 7/08/2015 12:46 PM, Derek White wrote: > Another RFR. > > I've updated based on David and Kim's last comments. > > http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/ > https://bugs.openjdk.java.net/browse/JDK-8066821 > > I also have a webrev of webrev.06 vs. webrev.07: > http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/ > > [This webrev is confused about CommandLineOptionTest.java. I > double-checked with a recursive diff and the only differences are in > arguments.cpp and arguments.hpp.] > > Thanks for looking! > > - Derek > > On 7/23/15 12:09 PM, Derek White wrote: >> On 7/20/15 10:03 PM, David Holmes wrote: >>> On 21/07/2015 3:02 AM, Derek White wrote: >>>> Hi David, >>>> >>>> Thanks for looking this over. >>>> >>>> On 7/20/15 5:29 AM, David Holmes wrote: >>>>> Hi Derek, >>>>> >>>>> Sorry but I'm finding this a bit confused and inconsistent. Comments >>>>> below. >>>>> >>>>> On 18/07/2015 3:30 AM, Derek White wrote: >>>>>> Request for review: >>>>>> >>>>>> [This updated webrev is being sent to wider audience, and has been >>>>>> merged with Gerard's option constraints check-in. Also factored out >>>>>> -XX:+AggressiveHeap processing into it's own chapter. I mean function >>>>>> :-)] >>>>>> >>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.06/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>>> >>>>> argument.cpp: >>>>> >>>>> 258 * been not scheduled). >>>>> >>>>> -> not been scheduled >>>> >>>> OK. >>>>> 260 * OBSOLETE: An option may be removed (and deleted from >>>>> globals.hpp), but still be accepted on the command >>>>> 261 * line. A warning is printed to let the user know >>>>> that support may be removed in the future. >>>>> >>>>> >>>>> Isn't this the stronger case that support has already been removed >>>>> (the option does nothing) and it will be removed at the next major >>>>> release. At the start of a major release we should be able to delete >>>>> all entries from the obsolete table - else it wasn't obsolete but >>>>> deprecated. >>>>> >>>>> Not sure "obsolete" is the right term here - obsolete things still >>>>> function. For us an obsolete option does nothing (it exists only in >>>>> the obsolete table). >>>> It's not a great name, but that what the previous code called it. >>>> It's a >>>> "I'll pretend you didn't say that" option, like when a teenager >>>> hears an >>>> adult use out-of-date slang ("groovy!"). How about a "condescending" >>>> option :-) >>> >>> Name aside you didn't comment on my main comment here: an obsolete >>> option has already been removed from globals etc and does nothing. >> >> Ahh, OK. I must have been confusing in tense. I'll rewrite to be more >> direct. >>>>> >>>>> 276 * Tests: Aliases are tested in VMAliasOptions.java. >>>>> 277 * Deprecated options are tested in >>>>> VMDeprecatedOptions.java. >>>>> 278 * Obsolete options are tested in various files. >>>>> >>>>> We don't normally document this kind of thing in the source. >>>> >>>> I'm trying to head off unnecessary one-off test files for each alias >>>> and >>>> deprecated option. For example TestNoParNew.java and >>>> TestDefaultMaxRAMFraction.java. And I think that there should be one >>>> test file for obsolete options also (perhaps expanding >>>> ObsoleteFlagErrorMessage.java), instead of a bunch of separate test >>>> files, but that is not in this webrev. >>> >>> Sounds fine but again we don't normally document test strategies in >>> the source code. >> Normally I'd agree but I'm trying to change current practice of tests >> popping up on the corpses of dead or dying options like mushrooms in a >> forest. I'm doubly adamant if I can add that last sentence to the >> comment :-) >>> >>>>> 281 // Obsolete or deprecated -XX flag. >>>>> >>>>> I can tell this is going to get confusing already. >>>>> >>>>> 284 JDK_Version obsoleted_in; // When the warning started (obsolete >>>>> or deprecated). >>>>> >>>>> But there is a difference: deprecated == warn but still process; >>>>> obsolete == warn and ignore. >>>> Yes, but the SpecialFlag type is concerned with the common aspect of >>>> warning. The "ignore" or "process" aspects are handled by the different >>>> functions that look up the obsolete_jvm_flags and deprecated_jvm_flags >>>> arrays. >>> >>> So that variable should really be obsoleted_or_deprecated_in ? >> >> OK, I see now. It was right in front of me. Maybe "warning_started_in" >> is simpler. >>> >>>>> >>>>> 288 // When a flag is eliminated, it can be added to this list in >>>>> order to >>>>> 289 // continue accepting this flag on the command-line, while >>>>> issuing a warning >>>>> 290 // and ignoring the value. Once the JDK version reaches the >>>>> 'accept_until' >>>>> 291 // limit, we flatly refuse to admit the existence of the flag. >>>>> 292 static SpecialFlag const obsolete_jvm_flags[] = { >>>>> >>>>> When a flag is eliminated it is gone from this table. As soon as the >>>>> accept_until version is the current version we wipe the table of all >>>>> such entries. This should be one of the first things done in a new >>>>> release. >>>> >>>> I completely agree that this is a great plan. But until this April we >>>> still had obsolete flags listed for JDK 5! The obsolete_jvm_flags table >>>> did the right thing until the process caught up. In any case, this >>>> webrev doesn't really change the behavior of the obsolete_jvm_flags >>>> table. >>> >>> But what you are seeing before April is the result of hotspot express >>> (at least in a large part). Now that we don't have to support that we >>> don't have legacy lists to maintain. The code could even be changed >>> upon detecting that current JDK version == "until" version to report >>> "Hey you forgot to update the table!" ;-) >> OK, that history makes more sense. >>> My point is that the comments should reflect how we intend to use >>> these, not give the impression that keeping eliminated options in the >>> table is the expected thing to do. >> >> OK, I'll update the comments both here and up above to describe the >> presumably common "deprecated"->"obsolete" lifecycle. >>>>> >>>>> 320 // When a flag is deprecated, it can be added to this list in >>>>> order to issuing a warning when the flag is used. >>>>> 321 // Once the JDK version reaches the 'accept_until' limit, we >>>>> flatly refuse to admit the existence of the flag. >>>>> 322 static SpecialFlag const deprecated_jvm_flags[] = { >>>>> >>>>> A deprecated flag should be obsoleted before it reaches the >>>>> accept_until limit. >>>> That's a policy that's under discussion on hotspot-runtime-dev. There >>>> are certainly option lifecycles that have been approved by our internal >>>> process that don't follow this proposed policy. The mechanism in this >>>> webrev was concerned about supporting the plethora of current >>>> lifecycles, for better or worse. >>> >>> But again comments should reflect expected usage - if we reach the >>> "until" version of a deprecated option that wasn't obsoleted then >>> something has probably gone wrong. >> >> OK. >>>>> Which suggests that when we start a new version we wipe the obsoleted >>>>> table and move the deprecated options into it. >>>> I can add documentation to describe this case. >>>> >>>> If we decide that we'll always treat a deprecated or aliased option as >>>> obsolete for one extra release, then it might make sense to have a >>>> combined option lifecycle table. But for now I like the fact that >>>> options in deprecated_jvm_flags should always have a real variable >>>> defined in globals.hpp (etc), and options in obsolete_jvm_flags should >>>> never have a global variable. >>> >>> Yes I like that too. >>>> >>>>> 776 case 1: { >>>>> 777 if (warn) { >>>>> 778 char version[256]; >>>>> 779 since.to_string(version, sizeof(version)); >>>>> 780 if (real_name != arg) { >>>>> 781 warning("Option %s was deprecated in version %s and >>>>> will likely be removed in a future release. Use option %s instead.", >>>>> 782 arg, version, real_name); >>>>> 783 } else { >>>>> 784 warning("Option %s was deprecated in version %s and >>>>> will likely be removed in a future release.", >>>>> 785 arg, version); >>>>> 786 } >>>>> >>>>> This isn't distinguishing between deprecated and obsoleted ??? >>>> >>>> Yes, handle_aliases_and_deprecation() doesn't handle obsolete options >>>> (or it would have had a longer name :-) Maybe it should handle that >>>> case, but it would have complicated the control flow in the caller. I >>>> have another proposed change in the works that simplifies the caller >>>> quite a bit that would make the refactoring simpler. >>> >>> I need to think more on that. It is hard to see the overall control >>> flow for argument processing. >> >> Yes it is hard to see. Currently options are parsed into tokens in a >> couple of places. It's roughly either: >> [+][-]arg >> or: >> arg[:]=[value] >> >> But not all of the code handles ":=". Furthermore option processing >> figures out the type of the argument by repeatedly trying to scanf >> "value" to see if it looks like floating point, or an integer, or >> maybe just text. I think we should first parsing out the arg name, get >> the Flag, and ask the Flag what type it is. This would make it much >> easier to handle aliases, deprecation, and obsoleting options in one >> place. >> >> I have a workspace that does this but I suspect there could be slight >> differences in how errors would be reported. >>> >>> Thanks, >>> David >> Thanks for looking at this again. It's heading in the right direction! >> - Derek >> > From dmitry.dmitriev at oracle.com Mon Aug 10 09:52:27 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Mon, 10 Aug 2015 12:52:27 +0300 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55C4DEA3.8090109@oracle.com> References: <55C4DEA3.8090109@oracle.com> Message-ID: <55C8745B.6030507@oracle.com> Hello Gerard, Changes looks good, but I noticed problem in old code. It seems that "is_int()" and "is_uint()" cases are missed in the following places: In CommandLineFlagConstraintList::check_constraints() function on lines 323-343 in src/share/vm/runtime/commandLineFlagConstraintList.cpp module In CommandLineFlagRangeList::check_ranges() function on lines 381-398 in src/share/vm/runtime/commandLineFlagRangeList.cpp Thanks, Dmitry On 07.08.2015 19:36, gerard ziemski wrote: > hi, > > Please review this webrev 3 of the follow-up fixes including: > > - Passing values by value, not pointer, to constraint functions. It was thought originally that me way want to ?fix? the values, but it was decided to be out of scope for the JEP. (requested by Coleen) > > - Add print_error_as_needed() utility function to range/constraint code to improve code robustness (requested by Coleen) > > - Remove debug code (requested by Kim Barrett) > > - Implement Flag::flag_error_str in .cpp file (requested by Kim Barrett) > > - Only check constraint if range passes (requested by Kim Barrett) > > - Merged with Sangheon Kim fix for "Add additional validation after heap creation? (JDK-8130459) > > > Changes in webrev3 compared to webrev2: > > - Adding DBL_MAX - decided to let Sangheon handle this as part of his effort to add missing GC flags ranges/constraints > > - Do not bother checking for NULL in CommandLineFlagRangesList::check_ranges() and CommandLineFlagConstraintsList::check_constraints() - we crash on 32bit platforms if we do this, so can't do it. The problem exists because there are certain flags (ie. lp64_product) that have ranges (ie. ObjectAlignmentInBytes) that are defined as constants on 32 bit platforms, but still register as flags with ranges. I added comments to the code in question. > > - Implement missing range/constraints check in "int" and "uint" CommandLineFlagsEx::*AtPut() APIs > > - Factored out common error printing code > > - Use "ShouldNotReachHere()" in Flag::flag_error_str() > > - Consistent constraint error message formating > > - Consistent placement of "verbose" argument in APIs > > - Fix other APIs that used to pass value by reference > > - Merged with Roland Westlin fix for "CICompilerCount=1 when tiered is off is not allowed any more" (JDK-8130858) > > > This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? > > > References: > > JEP 245:https://bugs.openjdk.java.net/browse/JDK-8122937 > bug:https://bugs.openjdk.java.net/browse/JDK-8112746 > webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev3/ > > > cheers > From gerard.ziemski at oracle.com Mon Aug 10 13:51:06 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Mon, 10 Aug 2015 08:51:06 -0500 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55C8745B.6030507@oracle.com> References: <55C4DEA3.8090109@oracle.com> <55C8745B.6030507@oracle.com> Message-ID: <55C8AC4A.6080906@oracle.com> Yep, already fixed - Sangheon pointed that as well couple of days ago. cheers On 08/10/2015 04:52 AM, Dmitry Dmitriev wrote: > Hello Gerard, > > Changes looks good, but I noticed problem in old code. It seems that > "is_int()" and "is_uint()" cases are missed in the following places: > In CommandLineFlagConstraintList::check_constraints() function on lines > 323-343 in src/share/vm/runtime/commandLineFlagConstraintList.cpp module > In CommandLineFlagRangeList::check_ranges() function on lines 381-398 in > src/share/vm/runtime/commandLineFlagRangeList.cpp > > Thanks, > Dmitry > > On 07.08.2015 19:36, gerard ziemski wrote: >> hi, >> >> Please review this webrev 3 of the follow-up fixes including: >> >> - Passing values by value, not pointer, to constraint functions. It was thought originally that me way want to ?fix? the values, but it was decided to be out of scope for the JEP. (requested by Coleen) >> >> - Add print_error_as_needed() utility function to range/constraint code to improve code robustness (requested by Coleen) >> >> - Remove debug code (requested by Kim Barrett) >> >> - Implement Flag::flag_error_str in .cpp file (requested by Kim Barrett) >> >> - Only check constraint if range passes (requested by Kim Barrett) >> >> - Merged with Sangheon Kim fix for "Add additional validation after heap creation? (JDK-8130459) >> >> >> Changes in webrev3 compared to webrev2: >> >> - Adding DBL_MAX - decided to let Sangheon handle this as part of his effort to add missing GC flags ranges/constraints >> >> - Do not bother checking for NULL in CommandLineFlagRangesList::check_ranges() and CommandLineFlagConstraintsList::check_constraints() - we crash on 32bit platforms if we do this, so can't do it. The problem exists because there are certain flags (ie. lp64_product) that have ranges (ie. ObjectAlignmentInBytes) that are defined as constants on 32 bit platforms, but still register as flags with ranges. I added comments to the code in question. >> >> - Implement missing range/constraints check in "int" and "uint" CommandLineFlagsEx::*AtPut() APIs >> >> - Factored out common error printing code >> >> - Use "ShouldNotReachHere()" in Flag::flag_error_str() >> >> - Consistent constraint error message formating >> >> - Consistent placement of "verbose" argument in APIs >> >> - Fix other APIs that used to pass value by reference >> >> - Merged with Roland Westlin fix for "CICompilerCount=1 when tiered is off is not allowed any more" (JDK-8130858) >> >> >> This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? >> >> >> References: >> >> JEP 245:https://bugs.openjdk.java.net/browse/JDK-8122937 >> bug:https://bugs.openjdk.java.net/browse/JDK-8112746 >> webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev3/ >> >> >> cheers >> From derek.white at oracle.com Mon Aug 10 16:41:58 2015 From: derek.white at oracle.com (Derek White) Date: Mon, 10 Aug 2015 12:41:58 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55C83C5C.60702@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> <55B1119D.4030802@oracle.com> <55C41C20.90208@oracle.com> <55C83C5C.60702@oracle.com> Message-ID: <55C8D456.9030006@oracle.com> Thanks David! - Derek On 8/10/15 1:53 AM, David Holmes wrote: > Hi Derek, > > I don't have any further comments. > > Thanks, > David > > On 7/08/2015 12:46 PM, Derek White wrote: >> Another RFR. >> >> I've updated based on David and Kim's last comments. >> >> http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/ >> https://bugs.openjdk.java.net/browse/JDK-8066821 >> >> I also have a webrev of webrev.06 vs. webrev.07: >> http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/ >> >> [This webrev is confused about CommandLineOptionTest.java. I >> double-checked with a recursive diff and the only differences are in >> arguments.cpp and arguments.hpp.] >> >> Thanks for looking! >> >> - Derek >> .... From gerard.ziemski at oracle.com Mon Aug 10 17:13:41 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Mon, 10 Aug 2015 12:13:41 -0500 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55C4DEA3.8090109@oracle.com> References: <55C4DEA3.8090109@oracle.com> Message-ID: <55C8DBC5.1090103@oracle.com> Here is a rev2 to rev3 diff that Kim requested: http://cr.openjdk.java.net/~gziemski/8112746_rev2_to_rev3/ cheers On 08/07/2015 11:36 AM, gerard ziemski wrote: > hi, > > Please review this webrev 3 of the follow-up fixes including: > > - Passing values by value, not pointer, to constraint functions. It was > thought originally that me way want to ?fix? the values, but it was > decided to be out of scope for the JEP. (requested by Coleen) > > - Add print_error_as_needed() utility function to range/constraint code > to improve code robustness (requested by Coleen) > > - Remove debug code (requested by Kim Barrett) > > - Implement Flag::flag_error_str in .cpp file (requested by Kim Barrett) > > - Only check constraint if range passes (requested by Kim Barrett) > > - Merged with Sangheon Kim fix for "Add additional validation after heap > creation? (JDK-8130459) > > > Changes in webrev3 compared to webrev2: > > - Adding DBL_MAX - decided to let Sangheon handle this as part of his > effort to add missing GC flags ranges/constraints > > - Do not bother checking for NULL in > CommandLineFlagRangesList::check_ranges() and > CommandLineFlagConstraintsList::check_constraints() - we crash on 32bit > platforms if we do this, so can't do it. The problem exists because > there are certain flags (ie. lp64_product) that have ranges (ie. > ObjectAlignmentInBytes) that are defined as constants on 32 bit > platforms, but still register as flags with ranges. I added comments to > the code in question. > > - Implement missing range/constraints check in "int" and "uint" > CommandLineFlagsEx::*AtPut() APIs > > - Factored out common error printing code > > - Use "ShouldNotReachHere()" in Flag::flag_error_str() > > - Consistent constraint error message formating > > - Consistent placement of "verbose" argument in APIs > > - Fix other APIs that used to pass value by reference > > - Merged with Roland Westlin fix for "CICompilerCount=1 when tiered is > off is not allowed any more" (JDK-8130858) > > > This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? > > > References: > > JEP 245: https://bugs.openjdk.java.net/browse/JDK-8122937 > bug: https://bugs.openjdk.java.net/browse/JDK-8112746 > webrev: http://cr.openjdk.java.net/~gziemski/8112746_rev3/ > > > cheers > > > From gerard.ziemski at oracle.com Mon Aug 10 17:14:28 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Mon, 10 Aug 2015 12:14:28 -0500 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55C53D60.7090508@oracle.com> References: <55C4DEA3.8090109@oracle.com> <55C4EB4F.1050106@oracle.com> <55C4EFE4.4020000@oracle.com> <55C53D60.7090508@oracle.com> Message-ID: <55C8DBF4.5080505@oracle.com> Thank you Coleen! On 08/07/2015 06:21 PM, Coleen Phillimore wrote: > > The improvements look really good to me. > > Coleen > > On 8/7/15 1:50 PM, gerard ziemski wrote: >> >> >> On 08/07/2015 12:30 PM, sangheon.kim wrote: >>> Hi Gerard, >>> >>> Before looking at this new webrev, I found that below are missing. >>> >>> 'apply_int / apply_uint' from >>> CommandLineFlagConstraintList::check_constraints() >>> 'check_int / check_uint' from CommandLineFlagRangeList::check_ranges() >>> >>> If you want to handle these from other RFE, I'm fine. >> >> Great catch, I would prefer to handle this here now and be done. Fixed. >> >> >> cheers >> >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 08/07/2015 09:36 AM, gerard ziemski wrote: >>>> hi, >>>> >>>> Please review this webrev 3 of the follow-up fixes including: >>>> >>>> - Passing values by value, not pointer, to constraint functions. It >>>> was thought originally that me way want to ?fix? the values, but it >>>> was decided to be out of scope for the JEP. (requested by Coleen) >>>> >>>> - Add print_error_as_needed() utility function to range/constraint >>>> code to improve code robustness (requested by Coleen) >>>> >>>> - Remove debug code (requested by Kim Barrett) >>>> >>>> - Implement Flag::flag_error_str in .cpp file (requested by Kim >>>> Barrett) >>>> >>>> - Only check constraint if range passes (requested by Kim Barrett) >>>> >>>> - Merged with Sangheon Kim fix for "Add additional validation after >>>> heap creation? (JDK-8130459) >>>> >>>> >>>> Changes in webrev3 compared to webrev2: >>>> >>>> - Adding DBL_MAX - decided to let Sangheon handle this as part of his >>>> effort to add missing GC flags ranges/constraints >>>> >>>> - Do not bother checking for NULL in >>>> CommandLineFlagRangesList::check_ranges() and >>>> CommandLineFlagConstraintsList::check_constraints() - we crash on >>>> 32bit platforms if we do this, so can't do it. The problem exists >>>> because there are certain flags (ie. lp64_product) that have ranges >>>> (ie. ObjectAlignmentInBytes) that are defined as constants on 32 bit >>>> platforms, but still register as flags with ranges. I added comments >>>> to the code in question. >>>> >>>> - Implement missing range/constraints check in "int" and "uint" >>>> CommandLineFlagsEx::*AtPut() APIs >>>> >>>> - Factored out common error printing code >>>> >>>> - Use "ShouldNotReachHere()" in Flag::flag_error_str() >>>> >>>> - Consistent constraint error message formating >>>> >>>> - Consistent placement of "verbose" argument in APIs >>>> >>>> - Fix other APIs that used to pass value by reference >>>> >>>> - Merged with Roland Westlin fix for "CICompilerCount=1 when tiered is >>>> off is not allowed any more" (JDK-8130858) >>>> >>>> >>>> This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? >>>> >>>> >>>> References: >>>> >>>> JEP 245: https://bugs.openjdk.java.net/browse/JDK-8122937 >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8112746 >>>> webrev: http://cr.openjdk.java.net/~gziemski/8112746_rev3/ >>>> >>>> >>>> cheers >>>> >>> >>> >>> > > > From karen.kinnear at oracle.com Mon Aug 10 22:07:34 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 10 Aug 2015 18:07:34 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55C8D456.9030006@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> <55B1119D.4030802@oracle.com> <55C41C20.90208@oracle.com> <55C83C5C.60702@oracle.com> <55C8D456.9030006@oracle.com> Message-ID: <5A08C1CB-58F9-4193-802F-767EE11F4D2B@oracle.com> Derek, Thank you for all of your work on this and responses to suggestions. I had a couple of questions/comments: I appreciate that you have created mechanisms to allow: 1. 2 step obsolete: obsolete_jvm_flags - step 1: obsolete: warn and ignore - step 2: expire - and I expect we will use this for most -XX flags, especially develop flags 2. 2 step deprecate: deprecated_jvm_flags - step 1: deprecate: warn and handle - step 2: expire I see this approach as useful for aliasing and for a few other flags, but not the common path. My concerns: With my understanding of how this is set up today, for the flags that are most exposed to customers, which would want the 3 step deprecation, it would be too easy for an engineer to add the flag to the deprecated_jvm_flags and forget to add it to the obsolete_jvm_flags, as the comments under deprecated_jvm_flags suggest. And we don't want folks to have to go back and do a second step later for flags if they could do it all at once. I think it would be confusing to add a flag to both deprecated_jvm_flags and obsolete_jvm_flags at the same time, since then the expiration release is not clear. 3. For product non-XX, commercial and common -XX flags what I would like to see is a three-step table which I would have called deprecated_jvm_flags, which did - step 1: deprecate: warn and handle - step 2: obsolete: warn and ignore - step 3: expire: unrecognized error Would you be willing to add a table like that which is the recommended approach for external supported flags? So one way to do this would be to change the current deprecated_jvm_flags to have three fields, so that the usual path would be to have three releases listed, and for aliased flags leave the middle field with the undefined version. Another approach would be to have the three fields and have it used by all three approaches, just fill in the steps that are appropriate. minor comment: 1. arguments.hpp Could you possibly change the comments from "and has expired (should be ignored)" to "and has expired (unrecognized error)" unless what you mean really is should be ignored, which is not the same expired. thanks, Karen On Aug 10, 2015, at 12:41 PM, Derek White wrote: > Thanks David! > > - Derek > > On 8/10/15 1:53 AM, David Holmes wrote: >> Hi Derek, >> >> I don't have any further comments. >> >> Thanks, >> David >> >> On 7/08/2015 12:46 PM, Derek White wrote: >>> Another RFR. >>> >>> I've updated based on David and Kim's last comments. >>> >>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/ >>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>> >>> I also have a webrev of webrev.06 vs. webrev.07: >>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/ >>> >>> [This webrev is confused about CommandLineOptionTest.java. I >>> double-checked with a recursive diff and the only differences are in >>> arguments.cpp and arguments.hpp.] >>> >>> Thanks for looking! >>> >>> - Derek >>> .... > From manasthakur17 at gmail.com Tue Aug 11 13:23:27 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Tue, 11 Aug 2015 18:53:27 +0530 Subject: Understanding templateInterpreter Message-ID: Hello all, I am trying to understand the working of HotSpot, and I am stuck with the template interpreter. I was wondering if there a document available on the detailed working of template interpreter. The main thing I want to find out is that once the templates for different byte codes are generated during startup, where is the code that is responsible to select the templates by scanning over the bytecode? Regards, Manas Thakur From aph at redhat.com Tue Aug 11 13:43:00 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 11 Aug 2015 14:43:00 +0100 Subject: Understanding templateInterpreter In-Reply-To: References: Message-ID: <55C9FBE4.3080406@redhat.com> On 08/11/2015 02:23 PM, Manas Thakur wrote: > I am trying to understand the working of HotSpot, and I am stuck > with the template interpreter. > > I was wondering if there a document available on the detailed > working of template interpreter. The main thing I want to find out > is that once the templates for different byte codes are generated > during startup, where is the code that is responsible to select the > templates by scanning over the bytecode? You're probably looking in the wrong place. The group of functions that dispatch to the code for the next bytecode is InterpreterMacroAssembler::dispatch_*. I suggest you print the interpreter and then step through some very simple methods. It should become clear soon enough once you do that. Andrew. From manasthakur17 at gmail.com Tue Aug 11 14:08:05 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Tue, 11 Aug 2015 19:38:05 +0530 Subject: Understanding templateInterpreter In-Reply-To: <55C9FBE4.3080406@redhat.com> References: <55C9FBE4.3080406@redhat.com> Message-ID: <0ADF11A9-E303-4B1B-B7C6-2D4A4A4823AF@gmail.com> Thanks Andrew. I would try it and get back, if needed. Regards, Manas > On 11-Aug-2015, at 7:13 pm, Andrew Haley wrote: > > On 08/11/2015 02:23 PM, Manas Thakur wrote: > >> I am trying to understand the working of HotSpot, and I am stuck >> with the template interpreter. >> >> I was wondering if there a document available on the detailed >> working of template interpreter. The main thing I want to find out >> is that once the templates for different byte codes are generated >> during startup, where is the code that is responsible to select the >> templates by scanning over the bytecode? > > You're probably looking in the wrong place. The group of functions > that dispatch to the code for the next bytecode is > InterpreterMacroAssembler::dispatch_*. > > I suggest you print the interpreter and then step through some very > simple methods. It should become clear soon enough once you do that. > > Andrew. From coleen.phillimore at oracle.com Tue Aug 11 14:23:53 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Aug 2015 10:23:53 -0400 Subject: Understanding templateInterpreter In-Reply-To: <0ADF11A9-E303-4B1B-B7C6-2D4A4A4823AF@gmail.com> References: <55C9FBE4.3080406@redhat.com> <0ADF11A9-E303-4B1B-B7C6-2D4A4A4823AF@gmail.com> Message-ID: <55CA0579.3050900@oracle.com> Manas, Start with the C++ code in src/share/vm/interpreter/templateInterpreter.hpp/cpp which generates the dispatch table. Then look at src/share/vm/interpreter/templateTable.hpp/cpp which has the TemplateTable:: function mappings for each bytecode. Then look at the assembly code in templateTable_x86.cpp, interp_masm_x86.cpp and templateInterpreter_x86_32/64.cpp (or whichever platform you are interested in). Each bytecode has multiple entry points for each type that can be on the top of the stack (the tos optimization caches the result of some bytecodes in register, rather than storing them in the expression stack). This sort of complicates the code. The files src/share/vm/interpreter/bytecodeInterpreter* are for the Zero interpreter and now broken/unused "C++" interpreter, but they give you a good idea of how each bytecode are interpreted. The dispatch there of course is the C++ case statement (or goto/label optimization). As Andrew suggested, there's a PrintInterpreter option which will show the generated code for each bytecode. Hope this helps. Coleen On 8/11/15 10:08 AM, Manas Thakur wrote: > Thanks Andrew. I would try it and get back, if needed. > > Regards, > Manas > > >> On 11-Aug-2015, at 7:13 pm, Andrew Haley wrote: >> >> On 08/11/2015 02:23 PM, Manas Thakur wrote: >> >>> I am trying to understand the working of HotSpot, and I am stuck >>> with the template interpreter. >>> >>> I was wondering if there a document available on the detailed >>> working of template interpreter. The main thing I want to find out >>> is that once the templates for different byte codes are generated >>> during startup, where is the code that is responsible to select the >>> templates by scanning over the bytecode? >> You're probably looking in the wrong place. The group of functions >> that dispatch to the code for the next bytecode is >> InterpreterMacroAssembler::dispatch_*. >> >> I suggest you print the interpreter and then step through some very >> simple methods. It should become clear soon enough once you do that. >> >> Andrew. From richard.reingruber at sap.com Tue Aug 11 15:06:13 2015 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 11 Aug 2015 15:06:13 +0000 Subject: assert(_exception_caught == false) failed: _exception_caught is out of phase Message-ID: <7F953F1E7B01F54E9F0B51450984507D3993D390@DEWDFEMB19B.global.corp.sap> Hi, I would like to report that the assertion assert(_exception_caught == false) failed: _exception_caught is out of phase at jvmtiThreadState.hpp:170 fires when running the command ./images/jdk/bin/java -agentlib:jdwp=transport=dt_socket,address=9000,server=y,suspend=n -Xbatch ExceptionCaughtOutOfPhaseAssertion (when analyzing you might want to add -XX:-TieredCompilation -XX:-Inline '-XX:CompileCommand=compileonly *::run') Source Code: import java.security.AccessController; import java.security.PrivilegedAction; public class ExceptionCaughtOutOfPhaseAssertion { public static void main(String[] args) { PrivilegedAction action = new HotThrowingAction(); System.out.println("### Warm-up"); for(int i=0; i<11000; i++) { try { action.run(); // call run() to get it compiled } catch(Throwable t) { /* ignored */ } } System.out.println("### Warm-up done"); System.out.println("### Executing privileged action"); AccessController.doPrivileged(action); } public static class HotThrowingAction implements PrivilegedAction { public Object run() { throw new Error(); } } } My Analysis: * Error is thrown in interpreted activation of run() - JvmtiThreadState::_exception_detected is set to true - JvmtiThreadState::_exception_caught is set to false * Error is caught in main() method - JvmtiThreadState::_exception_detected is set to false - JvmtiThreadState::_exception_caught is set to true * run() method is compiled * PrivilegedAction is executed * compiled activation of run() method - Error object is allocated and initialized - JavaThread::_should_post_on_exceptions_flag is checked and found to be false -> *no* uncommon trap - compiled frame is popped, rethrow stub calls OptoRuntime::rethrow_C() - _exception_detected is *not* set, remains false - _exception_caught is still true * Java call in JVM_DoPrivileged() returns with pending exception * CLEAR_PENDING_EXCEPTION triggers the assertion How to Fix? I'm not really an expert in this area, but here are my two cent: (a) Improve the assertion ...but how?! Toggling JVMTI exception notifications does not seem to be synchronized with java execution. (b) Calling JvmtiExport::post_exception_throw() in OptoRuntime::rethrow_C() is probably not possible, because of the JRT_LEAF comment for rethrow_C(), but _exception_detected = true could be set. (c) Remove the assertion. I guess (b) could be acceptable. What do you think? Best regards, Richard. From daniel.daugherty at oracle.com Tue Aug 11 18:38:26 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 11 Aug 2015 12:38:26 -0600 Subject: assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <7F953F1E7B01F54E9F0B51450984507D3993D390@DEWDFEMB19B.global.corp.sap> References: <7F953F1E7B01F54E9F0B51450984507D3993D390@DEWDFEMB19B.global.corp.sap> Message-ID: <55CA4122.3080504@oracle.com> Adding serviceability-dev at ... since this JVM/TI... Dan On 8/11/15 9:06 AM, Reingruber, Richard wrote: > Hi, > > I would like to report that the assertion > > assert(_exception_caught == false) failed: _exception_caught is out of phase > > at jvmtiThreadState.hpp:170 fires when running the command > > ./images/jdk/bin/java -agentlib:jdwp=transport=dt_socket,address=9000,server=y,suspend=n -Xbatch ExceptionCaughtOutOfPhaseAssertion > > (when analyzing you might want to add -XX:-TieredCompilation -XX:-Inline '-XX:CompileCommand=compileonly *::run') > > Source Code: > > import java.security.AccessController; > import java.security.PrivilegedAction; > > public class ExceptionCaughtOutOfPhaseAssertion { > > public static void main(String[] args) { > PrivilegedAction action = new HotThrowingAction(); > System.out.println("### Warm-up"); > for(int i=0; i<11000; i++) { > try { > action.run(); // call run() to get it compiled > } catch(Throwable t) { /* ignored */ } > } > System.out.println("### Warm-up done"); > System.out.println("### Executing privileged action"); > AccessController.doPrivileged(action); > } > > public static class HotThrowingAction implements PrivilegedAction { > public Object run() { > throw new Error(); > } > } > } > > My Analysis: > > * Error is thrown in interpreted activation of run() > - JvmtiThreadState::_exception_detected is set to true > - JvmtiThreadState::_exception_caught is set to false > * Error is caught in main() method > - JvmtiThreadState::_exception_detected is set to false > - JvmtiThreadState::_exception_caught is set to true > * run() method is compiled > * PrivilegedAction is executed > * compiled activation of run() method > - Error object is allocated and initialized > - JavaThread::_should_post_on_exceptions_flag is checked and found to be false > -> *no* uncommon trap > - compiled frame is popped, rethrow stub calls OptoRuntime::rethrow_C() > - _exception_detected is *not* set, remains false > - _exception_caught is still true > * Java call in JVM_DoPrivileged() returns with pending exception > * CLEAR_PENDING_EXCEPTION triggers the assertion > > How to Fix? I'm not really an expert in this area, but here are my two cent: > > (a) Improve the assertion ...but how?! Toggling JVMTI exception notifications does not seem > to be synchronized with java execution. > > (b) Calling JvmtiExport::post_exception_throw() in OptoRuntime::rethrow_C() is probably not possible, > because of the JRT_LEAF comment for rethrow_C(), but _exception_detected = true could be set. > > (c) Remove the assertion. > > I guess (b) could be acceptable. > > What do you think? > > Best regards, > Richard. From kim.barrett at oracle.com Tue Aug 11 18:57:19 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 11 Aug 2015 14:57:19 -0400 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <55C8DBC5.1090103@oracle.com> References: <55C4DEA3.8090109@oracle.com> <55C8DBC5.1090103@oracle.com> Message-ID: <27C84ABE-8853-4805-AD73-101B7F9A9A1F@oracle.com> On Aug 10, 2015, at 1:13 PM, gerard ziemski wrote: > > Here is a rev2 to rev3 diff that Kim requested: http://cr.openjdk.java.net/~gziemski/8112746_rev2_to_rev3/ > > On 08/07/2015 11:36 AM, gerard ziemski wrote: >> References: >> >> JEP 245: https://bugs.openjdk.java.net/browse/JDK-8122937 >> bug: https://bugs.openjdk.java.net/browse/JDK-8112746 >> webrev: http://cr.openjdk.java.net/~gziemski/8112746_rev3/ Thanks for the incremental webrev. Generally looks good. I have a few changes to suggest, but I don't see any show-stoppers. I would be ok with deferring some or all of these suggestions, so that we can be done with this change set and unblock Sangheon's dependent work. *** Could be fixed now or later: ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagRangeList.hpp src/share/vm/runtime/commandLineFlagRangeList.cpp class CommandLineError ... I think this isn't the right place for this class. I think a better place would be globals.[ch]pp, following class CommandLineFlags. I think such a change would eliminate the need for new #include of "runtime/commandLineFlagRangeList.hpp" in commandLineFlagConstraints{Compiler,GC,Runtime}.cpp, introduced in this latest revision. And of course, the definition of the print function should be moved to a corresponding location in globals.cpp. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 58 static Flag::Error MaxPLABSizeBounds(const char* name, size_t value, bool verbose) { 59 #if INCLUDE_ALL_GCS 60 if ((UseConcMarkSweepGC || UseG1GC) && (value > PLAB::max_size())) { 61 CommandLineError::print(verbose, 62 "%s (" SIZE_FORMAT ") must be " 63 "less than ergonomic PLAB maximum size (" SIZE_FORMAT ")\n", 64 name, value, PLAB::min_size()); "less than" => "less than or equal to" to be consistent with test. ------------------------------------------------------------------------------ commandLineFlagConstraints{Compiler,GC,Runtime}.cpp With the refactoring for CommandLineError, I think these files no longer need to #include "utilities/defaultStream.hpp". ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintList.cpp 307 bool CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::ConstraintType type) { ... 327 } else if (flag->is_int()) { 328 int value = flag->get_int(); 329 if (constraint->apply_int(value, true) != Flag::SUCCESS) status = false; 330 } else if (flag->is_uint()) { 331 uint value = flag->get_uint(); 332 if (constraint->apply_uint(value, true) != Flag::SUCCESS) status = false; ... [Latest version added missing cases.] Suggest adding a final else clause to the flag type dispatch that is a ShouldNotReachHere or some such. Similary in CommandLineFlagRangeList::check_ranges(). ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 71 static Flag::Error MinMaxPLABSizeBounds(const char* name, size_t value, bool verbose) { 72 if (MinPLABSizeBounds(name, value, verbose) == Flag::SUCCESS) { 73 return MaxPLABSizeBounds(name, value, verbose); 74 } 75 return Flag::VIOLATES_CONSTRAINT; 76 } I'd prefer this returned the result of MinPLABSizeBounds when that isn't SUCCESS, rather than discarding that result and returning VIOLATES_CONSTRAINT. I think there isn't presently a difference, but every time I look at this I need to verify that belief. ------------------------------------------------------------------------------ *** Should be fixed later: ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintList.cpp 307 bool CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::ConstraintType type) { ... 319 Flag* flag = Flag::find_flag(name, strlen(name), true, true); 320 // We must check for NULL here as lp64_product flags on 32 bit architecture 321 // can generate constraint check (despite that they are declared as constants), 322 // but they will not be returned by Flag::find_flag() 323 if (flag != NULL) { This comment suggests to me that there is a bug in the underlying constraint registration infrastructure; why are we registering constraints for options that don't exist? Similary in CommandLineFlagRangeList::check_ranges(). I think this should be addressed as a followup RFE, rather than as further work on this change set. It's a pre-existing problem, not something introduced by this change set. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 218 Flag::Error CMSPrecleanNumeratorConstraintFunc(uintx value, bool verbose) { 219 if (value > (CMSPrecleanDenominator - 1)) { 220 CommandLineError::print(verbose, 221 "CMSPrecleanNumerator (" UINTX_FORMAT ") must be " 222 "less than or equal to CMSPrecleanDenominator - 1 (" UINTX_FORMAT ")\n", 223 value, CMSPrecleanDenominator - 1); [pre-existing] Wouldn't this be simpler with (value >= CMSPrecleanDenominator) and just "less than" (or "strictly less than" for consistency with wording elsewhere; same wording should be used in all such places, but I don't care which). This can be handled as a separate (small) cleanup; maybe give it to Sangheon to deal with among the other GC-related option processing improvements. ------------------------------------------------------------------------------ From derek.white at oracle.com Tue Aug 11 19:33:34 2015 From: derek.white at oracle.com (Derek White) Date: Tue, 11 Aug 2015 15:33:34 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <5A08C1CB-58F9-4193-802F-767EE11F4D2B@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> <55B1119D.4030802@oracle.com> <55C41C20.90208@oracle.com> <55C83C5C.60702@oracle.com> <55C8D456.9030006@oracle.com> <5A08C1CB-58F9-4193-802F-767EE11F4D2B@oracle.com> Message-ID: <55CA4E0E.2070503@oracle.com> Hi Karen, As much as I want to get this RFE over and out, I see your and David H's point :-) I'll spin another rev... - Derek On 8/10/15 6:07 PM, Karen Kinnear wrote: > Derek, > > Thank you for all of your work on this and responses to suggestions. > > I had a couple of questions/comments: > > I appreciate that you have created mechanisms to allow: > 1. 2 step obsolete: obsolete_jvm_flags > - step 1: obsolete: warn and ignore > - step 2: expire > - and I expect we will use this for most -XX flags, especially develop flags > > 2. 2 step deprecate: deprecated_jvm_flags > - step 1: deprecate: warn and handle > - step 2: expire > > I see this approach as useful for aliasing and for a few other flags, but not > the common path. > > My concerns: > > With my understanding of how this is set up today, for the flags that are most exposed to > customers, which would want the 3 step deprecation, it would be too easy for an engineer > to add the flag to the deprecated_jvm_flags and forget to add it to the obsolete_jvm_flags, > as the comments under deprecated_jvm_flags suggest. And we don't want folks to have > to go back and do a second step later for flags if they could do it all at once. > > I think it would be confusing to add a flag to both deprecated_jvm_flags and obsolete_jvm_flags > at the same time, since then the expiration release is not clear. > > 3. For product non-XX, commercial and common -XX flags what I would like to see is > a three-step table which I would have called deprecated_jvm_flags, which did > - step 1: deprecate: warn and handle > - step 2: obsolete: warn and ignore > - step 3: expire: unrecognized error > > Would you be willing to add a table like that which is the recommended approach > for external supported flags? > > So one way to do this would be to change the current deprecated_jvm_flags to have > three fields, so that the usual path would be to have three releases listed, and > for aliased flags leave the middle field with the undefined version. > > Another approach would be to have the three fields and have it used by > all three approaches, just fill in the steps that are appropriate. > > minor comment: > > > 1. arguments.hpp > Could you possibly change the comments from "and has expired (should be ignored)" to > "and has expired (unrecognized error)" > > unless what you mean really is should be ignored, which is not the same expired. > > thanks, > Karen > > > > On Aug 10, 2015, at 12:41 PM, Derek White wrote: > >> Thanks David! >> >> - Derek >> >> On 8/10/15 1:53 AM, David Holmes wrote: >>> Hi Derek, >>> >>> I don't have any further comments. >>> >>> Thanks, >>> David >>> >>> On 7/08/2015 12:46 PM, Derek White wrote: >>>> Another RFR. >>>> >>>> I've updated based on David and Kim's last comments. >>>> >>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/ >>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>> >>>> I also have a webrev of webrev.06 vs. webrev.07: >>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/ >>>> >>>> [This webrev is confused about CommandLineOptionTest.java. I >>>> double-checked with a recursive diff and the only differences are in >>>> arguments.cpp and arguments.hpp.] >>>> >>>> Thanks for looking! >>>> >>>> - Derek >>>> .... From ivan at azulsystems.com Tue Aug 11 21:20:53 2015 From: ivan at azulsystems.com (Ivan Krylov) Date: Wed, 12 Aug 2015 00:20:53 +0300 Subject: Understanding templateInterpreter In-Reply-To: References: Message-ID: <55CA6735.20709@azulsystems.com> On 11/08/2015 16:23, Manas Thakur wrote: > Hello all, > > I am trying to understand the working of HotSpot, and I am stuck with the template interpreter. > > I was wondering if there a document available on the detailed working of template interpreter. The main thing I want to find out is that once the templates for different byte codes are generated during startup, where is the code that is responsible to select the templates by scanning over the bytecode? > > Regards, > Manas Thakur > > You can print the assembly code for each bytecode using -XX:+PrintAssembly. You need to (build and) add the hotspot disassembler hsdis-.so/.dll/.dylib to your LD_LIBRARY_PATH/PATH. Once you see the assembly you will notice the same pattern for the most bytecodes: 0x000000010a59a8b0: movzbl 0x1(%r13),%ebx 0x000000010a59a8b5: inc %r13 0x000000010a59a8b8: movabs $0x10a0f5e00,%r10 0x000000010a59a8c2: jmpq *(%r10,%rbx,8) That's AT&T syntax. That code is reading the next bytecode and jumping to right place in the table for executing that next bytecode. Hope this helps, Ivan From aph at redhat.com Wed Aug 12 08:30:11 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 12 Aug 2015 09:30:11 +0100 Subject: Understanding templateInterpreter In-Reply-To: <55CA6735.20709@azulsystems.com> References: <55CA6735.20709@azulsystems.com> Message-ID: <55CB0413.7040508@redhat.com> On 11/08/15 22:20, Ivan Krylov wrote: > On 11/08/2015 16:23, Manas Thakur wrote: >> Hello all, >> >> I am trying to understand the working of HotSpot, and I am stuck with the template interpreter. >> >> I was wondering if there a document available on the detailed working of template interpreter. The main thing I want to find out is that once the templates for different byte codes are generated during startup, where is the code that is responsible to select the templates by scanning over the bytecode? >> >> Regards, >> Manas Thakur >> >> > You can print the assembly code for each bytecode using > -XX:+PrintAssembly. -XX:+PrintInterpreter And it should be a debug VM. Andrew. From richard.reingruber at sap.com Wed Aug 12 08:30:43 2015 From: richard.reingruber at sap.com (Richard Reingruber) Date: Wed, 12 Aug 2015 10:30:43 +0200 Subject: assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <55CA4122.3080504@oracle.com> References: <7F953F1E7B01F54E9F0B51450984507D3993D390@DEWDFEMB19B.global.corp.sap> <55CA4122.3080504@oracle.com> Message-ID: <55CB0433.3080505@sap.com> Sorry, forgot to add a stack trace. This is amd64: Stack: [0x00007fe6cdacc000,0x00007fe6cdbcd000], sp=0x00007fe6cdbc9d30, free space=1015k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xfce6f1] VMError::report(outputStream*)+0x12fd V [libjvm.so+0xfcfbed] VMError::report_and_die()+0x3fd V [libjvm.so+0x86b82d] report_vm_error(char const*, int, char const*, char const*)+0xb4 V [libjvm.so+0xbe44ba] JvmtiThreadState::clear_exception_detected()+0x4e V [libjvm.so+0xbe3046] JvmtiExport::clear_detected_exception(JavaThread*)+0x72 V [libjvm.so+0xb50627] JVM_DoPrivileged+0x7e4 C [libjava.so+0xd04e] Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x42 j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+0 j ExceptionCaughtOutOfPhaseAssertion.main([Ljava/lang/String;)V+59 v ~StubRoutines::call_stub [...] I can reproduce this on amd64, sparcv9 and ppc64 with dbg builds of the current openjdk9. Richard. On 08/11/2015 08:38 PM, Daniel D. Daugherty wrote: > Adding serviceability-dev at ... since this JVM/TI... > > Dan > > > On 8/11/15 9:06 AM, Reingruber, Richard wrote: >> Hi, >> >> I would like to report that the assertion >> >> assert(_exception_caught == false) failed: _exception_caught is out of phase >> >> at jvmtiThreadState.hpp:170 fires when running the command >> >> ./images/jdk/bin/java -agentlib:jdwp=transport=dt_socket,address=9000,server=y,suspend=n -Xbatch ExceptionCaughtOutOfPhaseAssertion >> >> (when analyzing you might want to add -XX:-TieredCompilation -XX:-Inline '-XX:CompileCommand=compileonly *::run') >> >> Source Code: >> >> import java.security.AccessController; >> import java.security.PrivilegedAction; >> public class ExceptionCaughtOutOfPhaseAssertion { >> public static void main(String[] args) { >> PrivilegedAction action = new HotThrowingAction(); >> System.out.println("### Warm-up"); >> for(int i=0; i<11000; i++) { >> try { >> action.run(); // call run() to get it compiled >> } catch(Throwable t) { /* ignored */ } >> } >> System.out.println("### Warm-up done"); >> System.out.println("### Executing privileged action"); >> AccessController.doPrivileged(action); >> } >> public static class HotThrowingAction implements PrivilegedAction { >> public Object run() { >> throw new Error(); >> } >> } >> } >> My Analysis: >> >> * Error is thrown in interpreted activation of run() >> - JvmtiThreadState::_exception_detected is set to true >> - JvmtiThreadState::_exception_caught is set to false >> * Error is caught in main() method >> - JvmtiThreadState::_exception_detected is set to false >> - JvmtiThreadState::_exception_caught is set to true >> * run() method is compiled >> * PrivilegedAction is executed >> * compiled activation of run() method >> - Error object is allocated and initialized >> - JavaThread::_should_post_on_exceptions_flag is checked and found to be false >> -> *no* uncommon trap >> - compiled frame is popped, rethrow stub calls OptoRuntime::rethrow_C() >> - _exception_detected is *not* set, remains false >> - _exception_caught is still true >> * Java call in JVM_DoPrivileged() returns with pending exception >> * CLEAR_PENDING_EXCEPTION triggers the assertion >> >> How to Fix? I'm not really an expert in this area, but here are my two cent: >> >> (a) Improve the assertion ...but how?! Toggling JVMTI exception notifications does not seem >> to be synchronized with java execution. >> >> (b) Calling JvmtiExport::post_exception_throw() in OptoRuntime::rethrow_C() is probably not possible, >> because of the JRT_LEAF comment for rethrow_C(), but _exception_detected = true could be set. >> >> (c) Remove the assertion. >> >> I guess (b) could be acceptable. >> >> What do you think? >> >> Best regards, >> Richard. > From richard.reingruber at sap.com Wed Aug 12 08:36:54 2015 From: richard.reingruber at sap.com (Richard Reingruber) Date: Wed, 12 Aug 2015 10:36:54 +0200 Subject: assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <55CA4122.3080504@oracle.com> References: <7F953F1E7B01F54E9F0B51450984507D3993D390@DEWDFEMB19B.global.corp.sap> <55CA4122.3080504@oracle.com> Message-ID: <55CB05A6.1010503@sap.com> > Adding serviceability-dev at ... since this JVM/TI... Thanks Dan. Sorry, forgot to add a stack trace. This is from amd64: Stack: [0x00007fe6cdacc000,0x00007fe6cdbcd000], sp=0x00007fe6cdbc9d30, free space=1015k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xfce6f1] VMError::report(outputStream*)+0x12fd V [libjvm.so+0xfcfbed] VMError::report_and_die()+0x3fd V [libjvm.so+0x86b82d] report_vm_error(char const*, int, char const*, char const*)+0xb4 V [libjvm.so+0xbe44ba] JvmtiThreadState::clear_exception_detected()+0x4e V [libjvm.so+0xbe3046] JvmtiExport::clear_detected_exception(JavaThread*)+0x72 V [libjvm.so+0xb50627] JVM_DoPrivileged+0x7e4 C [libjava.so+0xd04e] Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x42 j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+0 j ExceptionCaughtOutOfPhaseAssertion.main([Ljava/lang/String;)V+59 v ~StubRoutines::call_stub [...] I can reproduce this on amd64, sparcv9 and ppc64 with dbg builds of the current openjdk9. Richard. On 08/11/2015 08:38 PM, Daniel D. Daugherty wrote: > Adding serviceability-dev at ... since this JVM/TI... > > Dan > > > On 8/11/15 9:06 AM, Reingruber, Richard wrote: >> Hi, >> >> I would like to report that the assertion >> >> assert(_exception_caught == false) failed: _exception_caught is out of phase >> >> at jvmtiThreadState.hpp:170 fires when running the command >> >> ./images/jdk/bin/java -agentlib:jdwp=transport=dt_socket,address=9000,server=y,suspend=n -Xbatch ExceptionCaughtOutOfPhaseAssertion >> >> (when analyzing you might want to add -XX:-TieredCompilation -XX:-Inline '-XX:CompileCommand=compileonly *::run') >> >> Source Code: >> >> import java.security.AccessController; >> import java.security.PrivilegedAction; >> public class ExceptionCaughtOutOfPhaseAssertion { >> public static void main(String[] args) { >> PrivilegedAction action = new HotThrowingAction(); >> System.out.println("### Warm-up"); >> for(int i=0; i<11000; i++) { >> try { >> action.run(); // call run() to get it compiled >> } catch(Throwable t) { /* ignored */ } >> } >> System.out.println("### Warm-up done"); >> System.out.println("### Executing privileged action"); >> AccessController.doPrivileged(action); >> } >> public static class HotThrowingAction implements PrivilegedAction { >> public Object run() { >> throw new Error(); >> } >> } >> } >> My Analysis: >> >> * Error is thrown in interpreted activation of run() >> - JvmtiThreadState::_exception_detected is set to true >> - JvmtiThreadState::_exception_caught is set to false >> * Error is caught in main() method >> - JvmtiThreadState::_exception_detected is set to false >> - JvmtiThreadState::_exception_caught is set to true >> * run() method is compiled >> * PrivilegedAction is executed >> * compiled activation of run() method >> - Error object is allocated and initialized >> - JavaThread::_should_post_on_exceptions_flag is checked and found to be false >> -> *no* uncommon trap >> - compiled frame is popped, rethrow stub calls OptoRuntime::rethrow_C() >> - _exception_detected is *not* set, remains false >> - _exception_caught is still true >> * Java call in JVM_DoPrivileged() returns with pending exception >> * CLEAR_PENDING_EXCEPTION triggers the assertion >> >> How to Fix? I'm not really an expert in this area, but here are my two cent: >> >> (a) Improve the assertion ...but how?! Toggling JVMTI exception notifications does not seem >> to be synchronized with java execution. >> >> (b) Calling JvmtiExport::post_exception_throw() in OptoRuntime::rethrow_C() is probably not possible, >> because of the JRT_LEAF comment for rethrow_C(), but _exception_detected = true could be set. >> >> (c) Remove the assertion. >> >> I guess (b) could be acceptable. >> >> What do you think? >> >> Best regards, >> Richard. > From thomas.schatzl at oracle.com Wed Aug 12 11:43:32 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 12 Aug 2015 13:43:32 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <20150730115611.585280@eggemoggin.niobe.net> References: <20150428220211.4355960845@eggemoggin.niobe.net> , , , , , , <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> , , , , , , <20150604150835.278728@eggemoggin.niobe.net> , , <55B9E! 78B.5060706@redhat.com>, <55BA611A.5060900@redhat.com> , <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> <20150730115611.585280@eggemoggin.niobe.net> Message-ID: <1439379812.2324.46.camel@oracle.com> Hi all, On Thu, 2015-07-30 at 11:56 -0700, mark.reinhold at oracle.com wrote: > 2015/7/30 11:04 -0700, charlie.hunt at oracle.com: > > ... > > > > On javac, my observation is that it tends to have a very high object > > allocation rate, and the object lifetimes are somewhat short. And, I > > suppose if we think about what javac does, I suppose we can come to > > terms as to why that?s the case. I imagine if one put forth a > > concerted effort, javac could be improved (probably true for many apps > > too). > > If you mean to imply that high allocation rates and short lifetimes are, > necessarily, signs of a poorly-written application then I'll have to > disagree. Sure, these things can be done to extremes, but I don't think > javac does that and I'd hate to see it re-engineered to "improve" these > particular metrics. It might be better just to change javac's launcher > to specify the Parallel GC, since this is most definitely an application > for which pause times are irrelevant. > > > Performance of javac is certainly one we want to pay close > > attention due to its impact to the developer use case. > > No argument there! Observations seem to point to that part of the problem is the high rate of exceptions javac throws, around 60k exceptions per second (with -XX: +TraceExceptions). Not sure why javac needs to throw so many Exceptions, but it does not seem to treat Exceptions as something exceptional... this is a known performance issue with G1, see https://bugs.openjdk.java.net/browse/JDK-8028337 . Parallel GC and others have special inlined code for this case, G1 does not at this time. One workaround is to specify -XX:-StackTraceInThrowable for now. At least it seems to improve G1 performance here in a few cursory runs. The javac code may hit other special cases; it does not seem to be really GC _pause_ related, as the same issue exists when running with heap sizes that cause almost no GCs. There is https://bugs.openjdk.java.net/browse/JDK-8132937 to track this issue. Thanks, Thomas From gerard.ziemski at oracle.com Thu Aug 13 16:13:06 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Thu, 13 Aug 2015 11:13:06 -0500 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) In-Reply-To: <27C84ABE-8853-4805-AD73-101B7F9A9A1F@oracle.com> References: <55C4DEA3.8090109@oracle.com> <55C8DBC5.1090103@oracle.com> <27C84ABE-8853-4805-AD73-101B7F9A9A1F@oracle.com> Message-ID: <55CCC212.4030806@oracle.com> Thank you for the review. Comments in-line: On 08/11/2015 01:57 PM, Kim Barrett wrote: > On Aug 10, 2015, at 1:13 PM, gerard ziemski wrote: >> >> Here is a rev2 to rev3 diff that Kim requested: http://cr.openjdk.java.net/~gziemski/8112746_rev2_to_rev3/ >> >> On 08/07/2015 11:36 AM, gerard ziemski wrote: >>> References: >>> >>> JEP 245: https://bugs.openjdk.java.net/browse/JDK-8122937 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8112746 >>> webrev: http://cr.openjdk.java.net/~gziemski/8112746_rev3/ > > Thanks for the incremental webrev. > > Generally looks good. I have a few changes to suggest, but I don't > see any show-stoppers. I would be ok with deferring some or all of > these suggestions, so that we can be done with this change set and > unblock Sangheon's dependent work. > > *** Could be fixed now or later: > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagRangeList.hpp > src/share/vm/runtime/commandLineFlagRangeList.cpp > class CommandLineError ... > > I think this isn't the right place for this class. I think a better > place would be globals.[ch]pp, following class CommandLineFlags. > > I think such a change would eliminate the need for new #include of > "runtime/commandLineFlagRangeList.hpp" in > commandLineFlagConstraints{Compiler,GC,Runtime}.cpp, introduced in > this latest revision. > > And of course, the definition of the print function should be moved to a > corresponding location in globals.cpp. Even better - I would propose that we factor out the flag manipulation code out of globals.hpp/.cpp and leave those files to deal only with macros, and move the rest of the code into its own CommandLineFlags.hpp/.cpp file. Filed JDK-8133564 (runtime) to track this and the other issues from below. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 58 static Flag::Error MaxPLABSizeBounds(const char* name, size_t value, bool verbose) { > 59 #if INCLUDE_ALL_GCS > 60 if ((UseConcMarkSweepGC || UseG1GC) && (value > PLAB::max_size())) { > 61 CommandLineError::print(verbose, > 62 "%s (" SIZE_FORMAT ") must be " > 63 "less than ergonomic PLAB maximum size (" SIZE_FORMAT ")\n", > 64 name, value, PLAB::min_size()); > > "less than" => "less than or equal to" to be consistent with test. I filed "GC" version of the follow-up issue as JDK-8133565 (gc), for the GC team to own this. > > ------------------------------------------------------------------------------ > commandLineFlagConstraints{Compiler,GC,Runtime}.cpp > > With the refactoring for CommandLineError, I think these files no > longer need to #include "utilities/defaultStream.hpp". Will add to JDK-8133564 (runtime). > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintList.cpp > 307 bool CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::ConstraintType type) { > ... > 327 } else if (flag->is_int()) { > 328 int value = flag->get_int(); > 329 if (constraint->apply_int(value, true) != Flag::SUCCESS) status = false; > 330 } else if (flag->is_uint()) { > 331 uint value = flag->get_uint(); > 332 if (constraint->apply_uint(value, true) != Flag::SUCCESS) status = false; > ... > > [Latest version added missing cases.] > > Suggest adding a final else clause to the flag type dispatch that is a > ShouldNotReachHere or some such. > > Similary in CommandLineFlagRangeList::check_ranges(). Will add to JDK-8133564 (runtime). > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 71 static Flag::Error MinMaxPLABSizeBounds(const char* name, size_t value, bool verbose) { > 72 if (MinPLABSizeBounds(name, value, verbose) == Flag::SUCCESS) { > 73 return MaxPLABSizeBounds(name, value, verbose); > 74 } > 75 return Flag::VIOLATES_CONSTRAINT; > 76 } > > I'd prefer this returned the result of MinPLABSizeBounds when that > isn't SUCCESS, rather than discarding that result and returning > VIOLATES_CONSTRAINT. I think there isn't presently a difference, but > every time I look at this I need to verify that belief. Will add to JDK-8133565 (gc). > > ------------------------------------------------------------------------------ > > *** Should be fixed later: > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintList.cpp > 307 bool CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::ConstraintType type) { > ... > 319 Flag* flag = Flag::find_flag(name, strlen(name), true, true); > 320 // We must check for NULL here as lp64_product flags on 32 bit architecture > 321 // can generate constraint check (despite that they are declared as constants), > 322 // but they will not be returned by Flag::find_flag() > 323 if (flag != NULL) { > > This comment suggests to me that there is a bug in the underlying > constraint registration infrastructure; why are we registering > constraints for options that don't exist? > > Similary in CommandLineFlagRangeList::check_ranges(). > > I think this should be addressed as a followup RFE, rather than as > further work on this change set. It's a pre-existing problem, not > something introduced by this change set. > Will add to JDK-8133564 (runtime). > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 218 Flag::Error CMSPrecleanNumeratorConstraintFunc(uintx value, bool verbose) { > 219 if (value > (CMSPrecleanDenominator - 1)) { > 220 CommandLineError::print(verbose, > 221 "CMSPrecleanNumerator (" UINTX_FORMAT ") must be " > 222 "less than or equal to CMSPrecleanDenominator - 1 (" UINTX_FORMAT ")\n", > 223 value, CMSPrecleanDenominator - 1); > > [pre-existing] > > Wouldn't this be simpler with (value >= CMSPrecleanDenominator) and > just "less than" (or "strictly less than" for consistency with wording > elsewhere; same wording should be used in all such places, but I don't > care which). > > This can be handled as a separate (small) cleanup; maybe give it to > Sangheon to deal with among the other GC-related option processing > improvements. Will add to JDK-8133565 (gc). Coleen, Kim, would one of you kindly sponsor this code for checking-in? I will prepare an hg diff that passes "hg jcheck". Thank you. cheers From richard.reingruber at sap.com Fri Aug 14 15:01:39 2015 From: richard.reingruber at sap.com (Richard Reingruber) Date: Fri, 14 Aug 2015 17:01:39 +0200 Subject: RFR (XS): 8133557: Missing test before a branch when checking for MethodCounters in TemplateTable::branch() on x86 Message-ID: <55CE02D3.5010503@sap.com> Hi, this is a request for review of the following fix for bug 8133557 (https://bugs.openjdk.java.net/browse/JDK-8133557). diff -r af60f1cb36f2 src/cpu/x86/vm/templateTable_x86.cpp --- a/src/cpu/x86/vm/templateTable_x86.cpp Mon Aug 10 10:39:19 2015 -0700 +++ b/src/cpu/x86/vm/templateTable_x86.cpp Fri Aug 14 10:46:47 2015 +0200 @@ -2014,6 +2014,7 @@ __ pop(rcx); __ pop(rdx); __ movptr(rax, Address(rcx, Method::method_counters_offset())); + __ testptr(rax, rax); __ jcc(Assembler::zero, dispatch); __ bind(has_counters); Thanks, Richard. From jesper.wilhelmsson at oracle.com Fri Aug 14 17:12:16 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 14 Aug 2015 19:12:16 +0200 Subject: RFR: JDK-8133669 - Remove unused code in Arguments Message-ID: <55CE2170.4020100@oracle.com> Hi, Please review this small removal of unused code in the argument parser. The variables Arguments::_min_heap_free_ratio and Arguments::_max_heap_free_ratio have no use after the flag verification changes. They can be removed together with Arguments::post_after_ergo_constraint_check() that is used to update them. Bug: https://bugs.openjdk.java.net/browse/JDK-8133669 Webrev: http://cr.openjdk.java.net/~jwilhelm/8133669/webrev.00/ Thanks, /Jesper From vladimir.kozlov at oracle.com Fri Aug 14 18:49:10 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Aug 2015 11:49:10 -0700 Subject: RFR (XS): 8133557: Missing test before a branch when checking for MethodCounters in TemplateTable::branch() on x86 In-Reply-To: <55CE02D3.5010503@sap.com> References: <55CE02D3.5010503@sap.com> Message-ID: <55CE3826.6070703@oracle.com> Fix looks correct. I looked on original 8010862 changes and templateTable_x86_32.cpp had the test instructions while templateTable_x86_64.cpp missed it. Someone, please, sponsor this fix. Thanks, Vladimir On 8/14/15 8:01 AM, Richard Reingruber wrote: > Hi, > > this is a request for review of the following fix for bug 8133557 > (https://bugs.openjdk.java.net/browse/JDK-8133557). > > diff -r af60f1cb36f2 src/cpu/x86/vm/templateTable_x86.cpp > --- a/src/cpu/x86/vm/templateTable_x86.cpp Mon Aug 10 10:39:19 2015 > -0700 > +++ b/src/cpu/x86/vm/templateTable_x86.cpp Fri Aug 14 10:46:47 2015 > +0200 > @@ -2014,6 +2014,7 @@ > __ pop(rcx); > __ pop(rdx); > __ movptr(rax, Address(rcx, Method::method_counters_offset())); > + __ testptr(rax, rax); > __ jcc(Assembler::zero, dispatch); > __ bind(has_counters); > > Thanks, > Richard. From coleen.phillimore at oracle.com Fri Aug 14 19:14:39 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 14 Aug 2015 15:14:39 -0400 Subject: RFR (XS): 8133557: Missing test before a branch when checking for MethodCounters in TemplateTable::branch() on x86 In-Reply-To: <55CE3826.6070703@oracle.com> References: <55CE02D3.5010503@sap.com> <55CE3826.6070703@oracle.com> Message-ID: <55CE3E1F.2070602@oracle.com> I'll sponsor it. It looks good to me also. Thank you for finding this, and thank you Vladimir for checking the old sources. Coleen On 8/14/15 2:49 PM, Vladimir Kozlov wrote: > Fix looks correct. I looked on original 8010862 changes and > templateTable_x86_32.cpp had the test instructions while > templateTable_x86_64.cpp missed it. > > Someone, please, sponsor this fix. > > Thanks, > Vladimir > > On 8/14/15 8:01 AM, Richard Reingruber wrote: >> Hi, >> >> this is a request for review of the following fix for bug 8133557 >> (https://bugs.openjdk.java.net/browse/JDK-8133557). >> >> diff -r af60f1cb36f2 src/cpu/x86/vm/templateTable_x86.cpp >> --- a/src/cpu/x86/vm/templateTable_x86.cpp Mon Aug 10 10:39:19 2015 >> -0700 >> +++ b/src/cpu/x86/vm/templateTable_x86.cpp Fri Aug 14 10:46:47 2015 >> +0200 >> @@ -2014,6 +2014,7 @@ >> __ pop(rcx); >> __ pop(rdx); >> __ movptr(rax, Address(rcx, Method::method_counters_offset())); >> + __ testptr(rax, rax); >> __ jcc(Assembler::zero, dispatch); >> __ bind(has_counters); >> >> Thanks, >> Richard. From gerard.ziemski at oracle.com Sat Aug 15 14:44:49 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Sat, 15 Aug 2015 09:44:49 -0500 Subject: RFR (XS): 8133678: test fails due to 'CICompilerCount=0 must be at least 1' missing from stdout/stderr In-Reply-To: <55CE02D3.5010503@sap.com> References: <55CE02D3.5010503@sap.com> Message-ID: <55CF5061.6070509@oracle.com> hi, Can I please have a review for this very simple test fix, which broke due to my recent fix for JDK-8112746 that changed CICompilerCount constraint error message formatting, but did not change the corresponding test. The change passes "JPRT -testset hotspot", and "RBT vm.quick testlist" References: webrev: http://cr.openjdk.java.net/~gziemski/8133678_rev0/ bug: https://bugs.openjdk.java.net/browse/JDK-8133678 cheers From kim.barrett at oracle.com Sat Aug 15 19:02:58 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 15 Aug 2015 15:02:58 -0400 Subject: RFR (XS): 8133678: test fails due to 'CICompilerCount=0 must be at least 1' missing from stdout/stderr In-Reply-To: <55CF5061.6070509@oracle.com> References: <55CE02D3.5010503@sap.com> <55CF5061.6070509@oracle.com> Message-ID: On Aug 15, 2015, at 10:44 AM, gerard ziemski wrote: > > > hi, > > Can I please have a review for this very simple test fix, which broke due to my recent fix for JDK-8112746 that changed CICompilerCount constraint error message formatting, but did not change the corresponding test. > > The change passes "JPRT -testset hotspot", and "RBT vm.quick testlist" > > References: > webrev: http://cr.openjdk.java.net/~gziemski/8133678_rev0/ > bug: https://bugs.openjdk.java.net/browse/JDK-8133678 Looks good. From daniel.daugherty at oracle.com Sun Aug 16 01:22:48 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 15 Aug 2015 19:22:48 -0600 Subject: RFR (XS): 8133678: test fails due to 'CICompilerCount=0 must be at least 1' missing from stdout/stderr In-Reply-To: <55CF5061.6070509@oracle.com> References: <55CE02D3.5010503@sap.com> <55CF5061.6070509@oracle.com> Message-ID: <55CFE5E8.2000702@oracle.com> test/compiler/arguments/CheckCICompilerCount.java No comments. Thumbs up. Dan On 8/15/15 8:44 AM, gerard ziemski wrote: > > hi, > > Can I please have a review for this very simple test fix, which broke > due to my recent fix for JDK-8112746 that changed CICompilerCount > constraint error message formatting, but did not change the > corresponding test. > > The change passes "JPRT -testset hotspot", and "RBT vm.quick testlist" > > References: > webrev: http://cr.openjdk.java.net/~gziemski/8133678_rev0/ > bug: https://bugs.openjdk.java.net/browse/JDK-8133678 > > > cheers From kim.barrett at oracle.com Sun Aug 16 20:51:46 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 16 Aug 2015 16:51:46 -0400 Subject: RFR: JDK-8133669 - Remove unused code in Arguments In-Reply-To: <55CE2170.4020100@oracle.com> References: <55CE2170.4020100@oracle.com> Message-ID: <34C9B6CE-B600-4E40-8738-4C13A65E889E@oracle.com> On Aug 14, 2015, at 1:12 PM, Jesper Wilhelmsson wrote: > > Hi, > > Please review this small removal of unused code in the argument parser. The variables Arguments::_min_heap_free_ratio and Arguments::_max_heap_free_ratio have no use after the flag verification changes. They can be removed together with Arguments::post_after_ergo_constraint_check() that is used to update them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8133669 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8133669/webrev.00/ Looks good. From david.holmes at oracle.com Mon Aug 17 04:44:15 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Aug 2015 14:44:15 +1000 Subject: RFR: JDK-8133669 - Remove unused code in Arguments In-Reply-To: <55CE2170.4020100@oracle.com> References: <55CE2170.4020100@oracle.com> Message-ID: <55D1669F.3090201@oracle.com> Hi Jesper, On 15/08/2015 3:12 AM, Jesper Wilhelmsson wrote: > Hi, > > Please review this small removal of unused code in the argument parser. > The variables Arguments::_min_heap_free_ratio and > Arguments::_max_heap_free_ratio have no use after the flag verification > changes. They can be removed together with > Arguments::post_after_ergo_constraint_check() that is used to update them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8133669 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8133669/webrev.00/ As Gerard mentioned offlist arguments.hpp also needs to remove: // Set any arguments that need to be set after the 'CommandLineFlagConstraint::AfterErgo' constraint check static void post_after_ergo_constraint_check(bool check_passed); Otherwise the cleanup looks okay. Thanks, David > Thanks, > /Jesper From richard.reingruber at sap.com Mon Aug 17 05:19:08 2015 From: richard.reingruber at sap.com (Richard Reingruber) Date: Mon, 17 Aug 2015 07:19:08 +0200 Subject: RFR (XS): 8133557: Missing test before a branch when checking for MethodCounters in TemplateTable::branch() on x86 In-Reply-To: <55CE3E1F.2070602@oracle.com> References: <55CE02D3.5010503@sap.com> <55CE3826.6070703@oracle.com> <55CE3E1F.2070602@oracle.com> Message-ID: <55D16ECC.1050406@sap.com> Thank you, Coleen and Vladimir, for taking care of this. Richard. On 08/14/2015 09:14 PM, Coleen Phillimore wrote: > > I'll sponsor it. It looks good to me also. Thank you for finding this, and thank you Vladimir for checking the old sources. > Coleen > > On 8/14/15 2:49 PM, Vladimir Kozlov wrote: >> Fix looks correct. I looked on original 8010862 changes and templateTable_x86_32.cpp had the test instructions while templateTable_x86_64.cpp missed it. >> >> Someone, please, sponsor this fix. >> >> Thanks, >> Vladimir >> >> On 8/14/15 8:01 AM, Richard Reingruber wrote: >>> Hi, >>> >>> this is a request for review of the following fix for bug 8133557 >>> (https://bugs.openjdk.java.net/browse/JDK-8133557). >>> >>> diff -r af60f1cb36f2 src/cpu/x86/vm/templateTable_x86.cpp >>> --- a/src/cpu/x86/vm/templateTable_x86.cpp Mon Aug 10 10:39:19 2015 >>> -0700 >>> +++ b/src/cpu/x86/vm/templateTable_x86.cpp Fri Aug 14 10:46:47 2015 >>> +0200 >>> @@ -2014,6 +2014,7 @@ >>> __ pop(rcx); >>> __ pop(rdx); >>> __ movptr(rax, Address(rcx, Method::method_counters_offset())); >>> + __ testptr(rax, rax); >>> __ jcc(Assembler::zero, dispatch); >>> __ bind(has_counters); >>> >>> Thanks, >>> Richard. > From jesper.wilhelmsson at oracle.com Mon Aug 17 13:31:46 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 17 Aug 2015 15:31:46 +0200 Subject: RFR: JDK-8133669 - Remove unused code in Arguments In-Reply-To: <55D1669F.3090201@oracle.com> References: <55CE2170.4020100@oracle.com> <55D1669F.3090201@oracle.com> Message-ID: <55D1E242.2050301@oracle.com> David, Kim, Thanks for the reviews! A new version with the method declaration removed is available here: http://cr.openjdk.java.net/~jwilhelm/8133669/webrev.01/ Thanks, /Jesper David Holmes skrev den 17/8/15 06:44: > Hi Jesper, > > On 15/08/2015 3:12 AM, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this small removal of unused code in the argument parser. >> The variables Arguments::_min_heap_free_ratio and >> Arguments::_max_heap_free_ratio have no use after the flag verification >> changes. They can be removed together with >> Arguments::post_after_ergo_constraint_check() that is used to update them. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8133669 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8133669/webrev.00/ > > As Gerard mentioned offlist arguments.hpp also needs to remove: > > // Set any arguments that need to be set after the > 'CommandLineFlagConstraint::AfterErgo' constraint check > static void post_after_ergo_constraint_check(bool check_passed); > > Otherwise the cleanup looks okay. > > Thanks, > David > >> Thanks, >> /Jesper From kim.barrett at oracle.com Mon Aug 17 16:23:47 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 17 Aug 2015 12:23:47 -0400 Subject: RFR: JDK-8133669 - Remove unused code in Arguments In-Reply-To: <55D1E242.2050301@oracle.com> References: <55CE2170.4020100@oracle.com> <55D1669F.3090201@oracle.com> <55D1E242.2050301@oracle.com> Message-ID: <030D4C29-1339-4887-BC1E-B27E35C5E83B@oracle.com> On Aug 17, 2015, at 9:31 AM, Jesper Wilhelmsson wrote: > > David, Kim, > > Thanks for the reviews! > > A new version with the method declaration removed is available here: > http://cr.openjdk.java.net/~jwilhelm/8133669/webrev.01/ Looks good. From jesper.wilhelmsson at oracle.com Mon Aug 17 19:42:00 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 17 Aug 2015 21:42:00 +0200 Subject: RFR: JDK-8133669 - Remove unused code in Arguments In-Reply-To: <030D4C29-1339-4887-BC1E-B27E35C5E83B@oracle.com> References: <55CE2170.4020100@oracle.com> <55D1669F.3090201@oracle.com> <55D1E242.2050301@oracle.com> <030D4C29-1339-4887-BC1E-B27E35C5E83B@oracle.com> Message-ID: <55D23908.1020504@oracle.com> Thanks! /Jesper Kim Barrett skrev den 17/8/15 18:23: > On Aug 17, 2015, at 9:31 AM, Jesper Wilhelmsson wrote: >> >> David, Kim, >> >> Thanks for the reviews! >> >> A new version with the method declaration removed is available here: >> http://cr.openjdk.java.net/~jwilhelm/8133669/webrev.01/ > > Looks good. > From david.holmes at oracle.com Mon Aug 17 21:00:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Aug 2015 07:00:34 +1000 Subject: RFR: JDK-8133669 - Remove unused code in Arguments In-Reply-To: <55D1E242.2050301@oracle.com> References: <55CE2170.4020100@oracle.com> <55D1669F.3090201@oracle.com> <55D1E242.2050301@oracle.com> Message-ID: <55D24B72.1090902@oracle.com> Looks good! Thanks, David On 17/08/2015 11:31 PM, Jesper Wilhelmsson wrote: > David, Kim, > > Thanks for the reviews! > > A new version with the method declaration removed is available here: > http://cr.openjdk.java.net/~jwilhelm/8133669/webrev.01/ > > Thanks, > /Jesper > > > David Holmes skrev den 17/8/15 06:44: >> Hi Jesper, >> >> On 15/08/2015 3:12 AM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> Please review this small removal of unused code in the argument parser. >>> The variables Arguments::_min_heap_free_ratio and >>> Arguments::_max_heap_free_ratio have no use after the flag verification >>> changes. They can be removed together with >>> Arguments::post_after_ergo_constraint_check() that is used to update >>> them. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8133669 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8133669/webrev.00/ >> >> As Gerard mentioned offlist arguments.hpp also needs to remove: >> >> // Set any arguments that need to be set after the >> 'CommandLineFlagConstraint::AfterErgo' constraint check >> static void post_after_ergo_constraint_check(bool check_passed); >> >> Otherwise the cleanup looks okay. >> >> Thanks, >> David >> >>> Thanks, >>> /Jesper From jesper.wilhelmsson at oracle.com Mon Aug 17 21:05:38 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 17 Aug 2015 23:05:38 +0200 Subject: RFR: JDK-8133669 - Remove unused code in Arguments In-Reply-To: <55D24B72.1090902@oracle.com> References: <55CE2170.4020100@oracle.com> <55D1669F.3090201@oracle.com> <55D1E242.2050301@oracle.com> <55D24B72.1090902@oracle.com> Message-ID: <55D24CA2.3020900@oracle.com> Thanks! /Jesper David Holmes skrev den 17/8/15 23:00: > Looks good! > > Thanks, > David > > On 17/08/2015 11:31 PM, Jesper Wilhelmsson wrote: >> David, Kim, >> >> Thanks for the reviews! >> >> A new version with the method declaration removed is available here: >> http://cr.openjdk.java.net/~jwilhelm/8133669/webrev.01/ >> >> Thanks, >> /Jesper >> >> >> David Holmes skrev den 17/8/15 06:44: >>> Hi Jesper, >>> >>> On 15/08/2015 3:12 AM, Jesper Wilhelmsson wrote: >>>> Hi, >>>> >>>> Please review this small removal of unused code in the argument parser. >>>> The variables Arguments::_min_heap_free_ratio and >>>> Arguments::_max_heap_free_ratio have no use after the flag verification >>>> changes. They can be removed together with >>>> Arguments::post_after_ergo_constraint_check() that is used to update >>>> them. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8133669 >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8133669/webrev.00/ >>> >>> As Gerard mentioned offlist arguments.hpp also needs to remove: >>> >>> // Set any arguments that need to be set after the >>> 'CommandLineFlagConstraint::AfterErgo' constraint check >>> static void post_after_ergo_constraint_check(bool check_passed); >>> >>> Otherwise the cleanup looks okay. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> /Jesper From david.holmes at oracle.com Tue Aug 18 03:05:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Aug 2015 13:05:51 +1000 Subject: Need some help: 8133646: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond Message-ID: <55D2A10F.6010408@oracle.com> Hi Compiler and x86_64 code experts, :) Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 There's a chance this failure is related to my recent changes under 8130212: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10 Given the failing debug code: 367 #ifdef ASSERT 368 // verify that threads correspond 369 { 370 Label L, S; 371 __ cmpptr(r15_thread, thread); 372 __ jcc(Assembler::notEqual, S); 373 __ get_thread(rbx); 374 __ cmpptr(r15_thread, rbx); 375 __ jcc(Assembler::equal, L); 376 __ bind(S); 377 __ jcc(Assembler::equal, L); 378 __ stop("StubRoutines::call_stub: threads must correspond"); 379 __ bind(L); 380 } 381 #endif and given the definition of get_thread: // This is simply a call to ThreadLocalStorage::thread() void MacroAssembler::get_thread(Register thread) { if (thread != rax) { push(rax); } push(rdi); push(rsi); push(rdx); push(rcx); push(r8); push(r9); push(r10); push(r11); call(RuntimeAddress(CAST_FROM_FN_PTR(address, ThreadLocalStorage::thread))); pop(r11); pop(r10); pop(r9); pop(r8); pop(rcx); pop(rdx); pop(rsi); pop(rdi); if (thread != rax) { movl(thread, rax); pop(rax); } } where ThreadLocalStorage::thread() is simply: inline Thread* ThreadLocalStorage::thread() { return _thr_current; } and _thr_current is a compiler-defined thread-local variable: static __thread Thread * _thr_current; Can anyone see anything that might cause an issue? I was wondering whether I have to verify that r15 is preserved by the actual thread-local access? IIUC normally the get_thread slow-path would be used to set r15_thread and so we wouldn't notice if it got trashed under some circumstances. It obviously doesn't always get trashed because the bug has only been seen to occur once. And of course the failure could be completely incidental to my changes. :) Thanks, David From kirk at kodewerk.com Tue Aug 18 10:31:15 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 18 Aug 2015 06:31:15 -0400 Subject: race condition in GC logs Message-ID: <9E79C717-7C53-49F5-AD0F-C003A03F11E5@kodewerk.com> Hi all, I found this.. in a few logs. Before I started trolling the source trying to sort out what the second PhantomReferences count was, I pinged Charlie and asked him. He suggested it was a (concurrency??) bug witnessed only once by someone else. I?ve now seen it in several logs where the numbers reported are different. Sorry for being lazy for not trolling the code before asking but is this a bug? Regards, Kirk Java HotSpot(TM) 64-Bit Server VM (25.51-b03) for linux-amd64 JRE (1.8.0_51-b16), built on Jun 8 2015 19:28:07 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8) Memory: 4k page, physical 9570132k(9340292k free), swap 4095996k(4095996k free) CommandLine flags: -XX:+AggressiveOpts -XX:G1HeapRegionSize=16777216 -XX:InitialHeapSize=3221225472 -XX:InitiatingHeapOccupancyPercent=75 -XX:+ManagementServer -XX:MaxGCPauseMillis=250 -XX:MaxHeapSize=3221225472 -XX:+ParallelRefProcEnabled -XX:+PerfDisableSharedMem -XX:+PrintAdaptiveSizePolicy -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC -XX:+UseLargePages 0.198: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion amount: 3221225472 bytes, attempted expansion amount: 3221225472 bytes] 2015-08-11T08:23:02.219+0200: 7.630: [GC pause (G1 Evacuation Pause) (young) Desired survivor size 16777216 bytes, new threshold 15 (max 15) 7.631: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 0, predicted base time: 10.00 ms, remaining time: 240.00 ms, target pause time: 250.00 ms] 7.631: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 9 regions, survivors: 0 regions, predicted young region time: 3626.58 ms] 7.631: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 9 regions, survivors: 0 regions, old: 0 regions, predicted pause time: 3636.58 ms, target pause time: 250.00 ms] 7.642: [SoftReference, 0 refs, 0.0006965 secs]7.643: [WeakReference, 40 refs, 0.0003039 secs]7.643: [FinalReference, 3477 refs, 0.0036191 secs]7.647: [PhantomReference, 0 refs, 0 refs, 0.0006649 secs]7.647: [JNI Weak Reference, 0.0000119 secs], 0.0173298 secs] From bengt.rutisson at oracle.com Tue Aug 18 10:47:44 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 18 Aug 2015 12:47:44 +0200 Subject: race condition in GC logs In-Reply-To: <9E79C717-7C53-49F5-AD0F-C003A03F11E5@kodewerk.com> References: <9E79C717-7C53-49F5-AD0F-C003A03F11E5@kodewerk.com> Message-ID: <55D30D50.8060302@oracle.com> Hi Kirk, On 2015-08-18 12:31, Kirk Pepperdine wrote: > Hi all, > > I found this.. in a few logs. Before I started trolling the source trying to sort out what the second PhantomReferences count was, I pinged Charlie and asked him. He suggested it was a (concurrency??) bug witnessed only once by someone else. I?ve now seen it in several logs where the numbers reported are different. Sorry for being lazy for not trolling the code before asking but is this a bug? The second ref count is for cleaner references. They used to be treated the same way as phantom references, but a recent improvement was to separate the handling of the cleaners to after all phantom references have been handled. So, the first count is the "real" phantom references and the second count is the cleaner references. It's confusing logging, I agree. This came in with this fix: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2194fdf3fbd9 since this adds one more call to preclean_discovered_reflist(), which is the method that prints the refs count. Thanks, Bengt > > Regards, > Kirk > > Java HotSpot(TM) 64-Bit Server VM (25.51-b03) for linux-amd64 JRE (1.8.0_51-b16), built on Jun 8 2015 19:28:07 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8) > Memory: 4k page, physical 9570132k(9340292k free), swap 4095996k(4095996k free) > CommandLine flags: -XX:+AggressiveOpts -XX:G1HeapRegionSize=16777216 -XX:InitialHeapSize=3221225472 -XX:InitiatingHeapOccupancyPercent=75 -XX:+ManagementServer -XX:MaxGCPauseMillis=250 -XX:MaxHeapSize=3221225472 -XX:+ParallelRefProcEnabled -XX:+PerfDisableSharedMem -XX:+PrintAdaptiveSizePolicy -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC -XX:+UseLargePages > 0.198: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion amount: 3221225472 bytes, attempted expansion amount: 3221225472 bytes] > 2015-08-11T08:23:02.219+0200: 7.630: [GC pause (G1 Evacuation Pause) (young) > Desired survivor size 16777216 bytes, new threshold 15 (max 15) > 7.631: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 0, predicted base time: 10.00 ms, remaining time: 240.00 ms, target pause time: 250.00 ms] > 7.631: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 9 regions, survivors: 0 regions, predicted young region time: 3626.58 ms] > 7.631: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 9 regions, survivors: 0 regions, old: 0 regions, predicted pause time: 3636.58 ms, target pause time: 250.00 ms] > 7.642: [SoftReference, 0 refs, 0.0006965 secs]7.643: [WeakReference, 40 refs, 0.0003039 secs]7.643: [FinalReference, 3477 refs, 0.0036191 secs]7.647: [PhantomReference, 0 refs, 0 refs, 0.0006649 secs]7.647: [JNI Weak Reference, 0.0000119 secs], 0.0173298 secs] From bengt.rutisson at oracle.com Tue Aug 18 12:39:16 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 18 Aug 2015 14:39:16 +0200 Subject: race condition in GC logs In-Reply-To: <55D30D50.8060302@oracle.com> References: <9E79C717-7C53-49F5-AD0F-C003A03F11E5@kodewerk.com> <55D30D50.8060302@oracle.com> Message-ID: <55D32774.2090903@oracle.com> On 2015-08-18 12:47, Bengt Rutisson wrote: > > Hi Kirk, > > On 2015-08-18 12:31, Kirk Pepperdine wrote: >> Hi all, >> >> I found this.. in a few logs. Before I started trolling the source >> trying to sort out what the second PhantomReferences count was, I >> pinged Charlie and asked him. He suggested it was a (concurrency??) >> bug witnessed only once by someone else. I?ve now seen it in several >> logs where the numbers reported are different. Sorry for being lazy >> for not trolling the code before asking but is this a bug? > > The second ref count is for cleaner references. They used to be > treated the same way as phantom references, but a recent improvement > was to separate the handling of the cleaners to after all phantom > references have been handled. So, the first count is the "real" > phantom references and the second count is the cleaner references. > > It's confusing logging, I agree. > > This came in with this fix: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2194fdf3fbd9 > > since this adds one more call to preclean_discovered_reflist(), which > is the method that prints the refs count. Thomas was nice and created a bug report for this :) Additional number of processed references printed with -XX:+PrintReferenceGC after JDK-8047125 https://bugs.openjdk.java.net/browse/JDK-8133818 Bengt > > Thanks, > Bengt > >> >> Regards, >> Kirk >> >> Java HotSpot(TM) 64-Bit Server VM (25.51-b03) for linux-amd64 JRE >> (1.8.0_51-b16), built on Jun 8 2015 19:28:07 by "java_re" with gcc >> 4.3.0 20080428 (Red Hat 4.3.0-8) >> Memory: 4k page, physical 9570132k(9340292k free), swap >> 4095996k(4095996k free) >> CommandLine flags: -XX:+AggressiveOpts -XX:G1HeapRegionSize=16777216 >> -XX:InitialHeapSize=3221225472 -XX:InitiatingHeapOccupancyPercent=75 >> -XX:+ManagementServer -XX:MaxGCPauseMillis=250 >> -XX:MaxHeapSize=3221225472 -XX:+ParallelRefProcEnabled >> -XX:+PerfDisableSharedMem -XX:+PrintAdaptiveSizePolicy -XX:+PrintGC >> -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps >> -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC >> -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers >> -XX:+UseCompressedOops -XX:+UseG1GC -XX:+UseLargePages >> 0.198: [G1Ergonomics (Heap Sizing) expand the heap, requested >> expansion amount: 3221225472 bytes, attempted expansion amount: >> 3221225472 bytes] >> 2015-08-11T08:23:02.219+0200: 7.630: [GC pause (G1 Evacuation Pause) >> (young) >> Desired survivor size 16777216 bytes, new threshold 15 (max 15) >> 7.631: [G1Ergonomics (CSet Construction) start choosing CSet, >> _pending_cards: 0, predicted base time: 10.00 ms, remaining time: >> 240.00 ms, target pause time: 250.00 ms] >> 7.631: [G1Ergonomics (CSet Construction) add young regions to CSet, >> eden: 9 regions, survivors: 0 regions, predicted young region time: >> 3626.58 ms] >> 7.631: [G1Ergonomics (CSet Construction) finish choosing CSet, >> eden: 9 regions, survivors: 0 regions, old: 0 regions, predicted >> pause time: 3636.58 ms, target pause time: 250.00 ms] >> 7.642: [SoftReference, 0 refs, 0.0006965 secs]7.643: [WeakReference, >> 40 refs, 0.0003039 secs]7.643: [FinalReference, 3477 refs, 0.0036191 >> secs]7.647: [PhantomReference, 0 refs, 0 refs, 0.0006649 secs]7.647: >> [JNI Weak Reference, 0.0000119 secs], 0.0173298 secs] > From christoph.langer at sap.com Tue Aug 18 13:28:40 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 18 Aug 2015 13:28:40 +0000 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: <55C4BDD6.5010409@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> <55AD0339.2060606@oracle.com> <55C4BDD6.5010409@oracle.com> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338EEF66C@DEWDFEMB12B.global.corp.sap> Hi Dan, did you find some time to look at this issue in the meanwhile? Is there anything speaking against my proposal for a short term fix? Thanks Christoph -----Original Message----- From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Freitag, 7. August 2015 16:17 To: Volker Simonis Cc: Langer, Christoph; hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions Volker, Sorry I didn't get back to this thread before I went on vacation. I'll try to refresh the thread in my brain and get back to you guys shortly... Dan On 8/7/15 6:39 AM, Volker Simonis wrote: > On Mon, Jul 20, 2015 at 4:18 PM, Daniel D. Daugherty > wrote: >> On 7/17/15 4:58 PM, Volker Simonis wrote: >> >> >> >> On Saturday, July 18, 2015, Daniel D. Daugherty >> wrote: >>> On 7/16/15 9:18 AM, Langer, Christoph wrote: >>>> Hi all, >>>> >>>> >>>> >>>> I don't know if this mailing list is the right one for this issue. Let me >>>> know if I should post it elsewhere. >>>> >>>> >>>> >>>> I have prepared a fix for an issue with /tmp/hsperfdata files. >>>> >>>> >>>> >>>> Please review this change. I also need a sponsor. >>>> >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8130910 >>>> >>>> Change: http://cr.openjdk.java.net/~simonis/webrevs/2015/8130910/ >>> >>> src/os/aix/vm/perfMemory_aix.cpp >>> No comments. >>> >>> src/os/bsd/vm/perfMemory_bsd.cpp >>> No comments. >>> >>> src/os/linux/vm/perfMemory_linux.cpp >>> No comments. >>> >>> src/os/solaris/vm/perfMemory_solaris.cpp >>> No comments. >>> >>> >>> I think I'm OK with the code changes above, but I need more >>> time to mull on them. I also need time to mull on the stuff >>> down below. >>> >> Hi Dan, >> >> thanks for looking at this change. >> >> Maybe I can add some more context here. Christoph detected this issue when >> somebody who ran the VM in a security context with a umask which masked out >> all the executable bits of newly created files complained about the stale >> files in the current working directory. >> >> >> Thanks for the context. >> >> >> >> I think that Chritoph's change is good >> >> >> I concur that the change is good. I'm simply mulling on potential >> side effects. >> > Hi Dan, > > have you come to a conclusion? > > Regards, > Volker > >> and I also share his doubts about changing the current working directory. I >> think this is questionable because it can have non-local side effects but I >> think this should be fixed in a follow up change. >> >> >> Changing the working directory can definitely have non-local side >> effects, but the change of directory is a necessary part of the >> secure file system object creation protocol. Jerry has a good >> comment that explains what APIs we would rather use than changing >> the current working directory, but those APIs don't exist on all >> platforms (yet). >> >> 348 // NOTE: The code below uses fchdir(), open() and unlink() because >> 349 // fdopendir(), openat() and unlinkat() are not supported on all >> 350 // versions. Once the support for fdopendir(), openat() and unlinkat() >> 351 // is available on all supported versions the code can be changed >> 352 // to use these functions. >> 353 >> 354 // Open the directory of the given path, validate it and set the >> 355 // current working directory to it. >> 356 // Return a DIR * of the open directory and the saved cwd fd. >> 357 // >> 358 static DIR *open_directory_secure_cwd(const char* dirname, int >> *saved_cwd_fd) { >> >> The protocol is basically: >> >> open_directory_secure_cwd() >> do operations to files in the directory using relative paths >> close_directory_secure_cwd() >> >> The alternative of using full paths is difficult to do safely without >> exposure to attacks along exposed path elements. >> >> Dan >> >> >> >> Thanks, >> Volker >> >>> Will get back to this next week. >>> >>> Dan >>> >>> >>>> >>>> >>>> The problem is that for creating a file in /tmp/hsperfdata_, an >>>> fchdir to this directory is attempted. In case there's no execute permission >>>> on /tmp/hsperfdata_, the fchdir fails. As its return code is not >>>> checked up to now, the process would stay in its current working directory >>>> and create the file in there. The location stored for cleaning up at the end >>>> of the VM is also remembered as /tmp/hsperfdata... so the file would remain >>>> left over eventually. There are several checks for the hsperfdata location >>>> in place but nothing would hit and prevent the fchdir attempt beforehand in >>>> this case. >>>> >>>> >>>> >>>> I fixed it by handling fchdir return code and in case of failure closing >>>> the handles and returning NULL. In that case we wouldn't have shared >>>> PerfMemory but I think that is ok then. >>>> >>>> >>>> >>>> I thought about a testcase but it would involve messing around with >>>> /tmp/hsperfdata permissions which can have effects on other running JVMs, >>>> too, which I consider a bit dangerous. >>>> >>>> >>>> >>>> Generally I don't know if it is a good idea to do an fchdir at all but I >>>> don't know so much about the backgrounds of it... maybe someone wants to >>>> comment on that as well. >>>> >>>> >>>> >>>> Thanks and best regards, >>>> >>>> Christoph >>>> >>>> >>>> From charlie.hunt at oracle.com Tue Aug 18 13:34:56 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Tue, 18 Aug 2015 08:34:56 -0500 Subject: race condition in GC logs In-Reply-To: <55D32774.2090903@oracle.com> References: <9E79C717-7C53-49F5-AD0F-C003A03F11E5@kodewerk.com> <55D30D50.8060302@oracle.com> <55D32774.2090903@oracle.com> Message-ID: <3F310328-DB06-4BC1-AF7C-E37D6169A09B@oracle.com> Hi Bengt, Do you know if this change back ported to JDK 8 ? I see Kirk?s example shows a version string of: Java HotSpot(TM) 64-Bit Server VM (25.51-b03) for linux-amd64 JRE (1.8.0_51-b16) Also, as Eric (Caspole) observed, there is no # of processed JNI Weak References reported too. That observation is what led us to believe it may be a printing race condition. thanks, charlie > On Aug 18, 2015, at 7:39 AM, Bengt Rutisson wrote: > > > > On 2015-08-18 12:47, Bengt Rutisson wrote: >> >> Hi Kirk, >> >> On 2015-08-18 12:31, Kirk Pepperdine wrote: >>> Hi all, >>> >>> I found this.. in a few logs. Before I started trolling the source trying to sort out what the second PhantomReferences count was, I pinged Charlie and asked him. He suggested it was a (concurrency??) bug witnessed only once by someone else. I?ve now seen it in several logs where the numbers reported are different. Sorry for being lazy for not trolling the code before asking but is this a bug? >> >> The second ref count is for cleaner references. They used to be treated the same way as phantom references, but a recent improvement was to separate the handling of the cleaners to after all phantom references have been handled. So, the first count is the "real" phantom references and the second count is the cleaner references. >> >> It's confusing logging, I agree. >> >> This came in with this fix: >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2194fdf3fbd9 >> >> since this adds one more call to preclean_discovered_reflist(), which is the method that prints the refs count. > > Thomas was nice and created a bug report for this :) > > Additional number of processed references printed with -XX:+PrintReferenceGC after JDK-8047125 > https://bugs.openjdk.java.net/browse/JDK-8133818 > > Bengt > >> >> Thanks, >> Bengt >> >>> >>> Regards, >>> Kirk >>> >>> Java HotSpot(TM) 64-Bit Server VM (25.51-b03) for linux-amd64 JRE (1.8.0_51-b16), built on Jun 8 2015 19:28:07 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8) >>> Memory: 4k page, physical 9570132k(9340292k free), swap 4095996k(4095996k free) >>> CommandLine flags: -XX:+AggressiveOpts -XX:G1HeapRegionSize=16777216 -XX:InitialHeapSize=3221225472 -XX:InitiatingHeapOccupancyPercent=75 -XX:+ManagementServer -XX:MaxGCPauseMillis=250 -XX:MaxHeapSize=3221225472 -XX:+ParallelRefProcEnabled -XX:+PerfDisableSharedMem -XX:+PrintAdaptiveSizePolicy -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC -XX:+UseLargePages >>> 0.198: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion amount: 3221225472 bytes, attempted expansion amount: 3221225472 bytes] >>> 2015-08-11T08:23:02.219+0200: 7.630: [GC pause (G1 Evacuation Pause) (young) >>> Desired survivor size 16777216 bytes, new threshold 15 (max 15) >>> 7.631: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 0, predicted base time: 10.00 ms, remaining time: 240.00 ms, target pause time: 250.00 ms] >>> 7.631: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 9 regions, survivors: 0 regions, predicted young region time: 3626.58 ms] >>> 7.631: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 9 regions, survivors: 0 regions, old: 0 regions, predicted pause time: 3636.58 ms, target pause time: 250.00 ms] >>> 7.642: [SoftReference, 0 refs, 0.0006965 secs]7.643: [WeakReference, 40 refs, 0.0003039 secs]7.643: [FinalReference, 3477 refs, 0.0036191 secs]7.647: [PhantomReference, 0 refs, 0 refs, 0.0006649 secs]7.647: [JNI Weak Reference, 0.0000119 secs], 0.0173298 secs] >> > From thomas.schatzl at oracle.com Tue Aug 18 13:44:19 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 18 Aug 2015 15:44:19 +0200 Subject: race condition in GC logs In-Reply-To: <3F310328-DB06-4BC1-AF7C-E37D6169A09B@oracle.com> References: <9E79C717-7C53-49F5-AD0F-C003A03F11E5@kodewerk.com> <55D30D50.8060302@oracle.com> <55D32774.2090903@oracle.com> <3F310328-DB06-4BC1-AF7C-E37D6169A09B@oracle.com> Message-ID: <1439905459.2316.13.camel@oracle.com> Hi, On Tue, 2015-08-18 at 08:34 -0500, charlie hunt wrote: > Hi Bengt, > > Do you know if this change back ported to JDK 8 ? > > I see Kirk?s example shows a version string of: > Java HotSpot(TM) 64-Bit Server VM (25.51-b03) for linux-amd64 JRE (1.8.0_51-b16) > > Also, as Eric (Caspole) observed, there is no # of processed JNI Weak References reported too. That observation is what led us to believe it may be a printing race condition. Not sure about the JNI weak reference. But I think the change is in 8u51 b16, see http://hg.openjdk.java.net/jdk8u/jdk8u60/hotspot/file/4894e24d2edc/src/share/vm/memory/referenceProcessor.cpp which has the 8u51-b16 tag: http://hg.openjdk.java.net/jdk8u/jdk8u60/hotspot/rev/4894e24d2edc (That is, if I understood the repo tagging mechanism) Thanks, Thomas From charlie.hunt at oracle.com Tue Aug 18 14:08:02 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Tue, 18 Aug 2015 09:08:02 -0500 Subject: race condition in GC logs In-Reply-To: <1439905459.2316.13.camel@oracle.com> References: <9E79C717-7C53-49F5-AD0F-C003A03F11E5@kodewerk.com> <55D30D50.8060302@oracle.com> <55D32774.2090903@oracle.com> <3F310328-DB06-4BC1-AF7C-E37D6169A09B@oracle.com> <1439905459.2316.13.camel@oracle.com> Message-ID: <3BA271E2-A619-4ADD-AE8F-4781F8283B46@oracle.com> > On Aug 18, 2015, at 8:44 AM, Thomas Schatzl wrote: > > Hi, > > On Tue, 2015-08-18 at 08:34 -0500, charlie hunt wrote: >> Hi Bengt, >> >> Do you know if this change back ported to JDK 8 ? >> >> I see Kirk?s example shows a version string of: >> Java HotSpot(TM) 64-Bit Server VM (25.51-b03) for linux-amd64 JRE (1.8.0_51-b16) >> >> Also, as Eric (Caspole) observed, there is no # of processed JNI Weak References reported too. That observation is what led us to believe it may be a printing race condition. > > > Not sure about the JNI weak reference. > > But I think the change is in 8u51 b16, see > > http://hg.openjdk.java.net/jdk8u/jdk8u60/hotspot/file/4894e24d2edc/src/share/vm/memory/referenceProcessor.cpp > > which has the 8u51-b16 tag: > > http://hg.openjdk.java.net/jdk8u/jdk8u60/hotspot/rev/4894e24d2edc > > (That is, if I understood the repo tagging mechanism) > > Thanks, > Thomas Thanks Thomas! After looking at the source from the link you mentioned, it does indeed look like this change was back ported to JDK 8, and it also looks like it is indeed in 8u51. Also, if I am looking at the code correctly, it doesn?t look like we print the number of refs processed on JNI Weak References. To summarize, in Kirk?s example output, it looks the additional ?refs? count in PhantomReferences output is indeed as Bengt described, i.e. ? first count is the ?real? phantom references and the second count is the cleaner references?. charlie From kirk at kodewerk.com Tue Aug 18 17:31:26 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 18 Aug 2015 13:31:26 -0400 Subject: race condition in GC logs In-Reply-To: <55D30D50.8060302@oracle.com> References: <9E79C717-7C53-49F5-AD0F-C003A03F11E5@kodewerk.com> <55D30D50.8060302@oracle.com> Message-ID: <88F687EE-0386-4F34-B803-870F78F3EC19@kodewerk.com> Hi Bengt, Thanks for the information. I try to read the patches but I don?t get to them all. Indeed the log is confusing but nothing tooling can?t deal with. Regards, Kirk > On Aug 18, 2015, at 6:47 AM, Bengt Rutisson wrote: > > > Hi Kirk, > > On 2015-08-18 12:31, Kirk Pepperdine wrote: >> Hi all, >> >> I found this.. in a few logs. Before I started trolling the source trying to sort out what the second PhantomReferences count was, I pinged Charlie and asked him. He suggested it was a (concurrency??) bug witnessed only once by someone else. I?ve now seen it in several logs where the numbers reported are different. Sorry for being lazy for not trolling the code before asking but is this a bug? > > The second ref count is for cleaner references. They used to be treated the same way as phantom references, but a recent improvement was to separate the handling of the cleaners to after all phantom references have been handled. So, the first count is the "real" phantom references and the second count is the cleaner references. > > It's confusing logging, I agree. > > This came in with this fix: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2194fdf3fbd9 > > since this adds one more call to preclean_discovered_reflist(), which is the method that prints the refs count. > > Thanks, > Bengt > >> >> Regards, >> Kirk >> >> Java HotSpot(TM) 64-Bit Server VM (25.51-b03) for linux-amd64 JRE (1.8.0_51-b16), built on Jun 8 2015 19:28:07 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8) >> Memory: 4k page, physical 9570132k(9340292k free), swap 4095996k(4095996k free) >> CommandLine flags: -XX:+AggressiveOpts -XX:G1HeapRegionSize=16777216 -XX:InitialHeapSize=3221225472 -XX:InitiatingHeapOccupancyPercent=75 -XX:+ManagementServer -XX:MaxGCPauseMillis=250 -XX:MaxHeapSize=3221225472 -XX:+ParallelRefProcEnabled -XX:+PerfDisableSharedMem -XX:+PrintAdaptiveSizePolicy -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC -XX:+UseLargePages >> 0.198: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion amount: 3221225472 bytes, attempted expansion amount: 3221225472 bytes] >> 2015-08-11T08:23:02.219+0200: 7.630: [GC pause (G1 Evacuation Pause) (young) >> Desired survivor size 16777216 bytes, new threshold 15 (max 15) >> 7.631: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 0, predicted base time: 10.00 ms, remaining time: 240.00 ms, target pause time: 250.00 ms] >> 7.631: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 9 regions, survivors: 0 regions, predicted young region time: 3626.58 ms] >> 7.631: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 9 regions, survivors: 0 regions, old: 0 regions, predicted pause time: 3636.58 ms, target pause time: 250.00 ms] >> 7.642: [SoftReference, 0 refs, 0.0006965 secs]7.643: [WeakReference, 40 refs, 0.0003039 secs]7.643: [FinalReference, 3477 refs, 0.0036191 secs]7.647: [PhantomReference, 0 refs, 0 refs, 0.0006649 secs]7.647: [JNI Weak Reference, 0.0000119 secs], 0.0173298 secs] > From sangheon.kim at oracle.com Wed Aug 19 04:25:42 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Tue, 18 Aug 2015 21:25:42 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing Message-ID: <55D40546.2060907@oracle.com> Hi all, Please review this patch for command-line validation for GC flags. This includes adding ranges and implementing constraint functions for GC flags. Here are several things to note. 1. Exponential notation for 'double' type variable parse: Previously there were some discussion for maximum value for double type flags from code review of JDK-8059557 and JDK-8112746. And Kim and I decided not to add upper limit unless there are problems with DBL_MAX. And as 255 is the maximum length that can be passed via command-line, we introduced exponential notation to avoid this limit. ( arguments.cpp ) 2. These GC flags ranges are not ideal ranges but ranges which don't make problem with current source code. If one flag makes some problem but hard to find good range, I added some ranges. 3. There are some constraint functions to avoid overflow. 4. Test applications are changed: as some of them assumed to be ParallelGC or to check it's output messages. 5. Includes cleanup of JDK-8133565: GC -2nd followup to JDK-8059557. CR: https://bugs.openjdk.java.net/browse/JDK-8078555 Webrev: http://cr.openjdk.java.net/~sangheki/8078555/webrev.00/ Testing: JPRT, UTE(vm.quick-pcl), tests at test/runtime/CommandLine and local tests[1]. [1]: Running GCOld for non bool GC flags with its variable type's min/max/median. Needed real GCs to verify whether flags are making problems or not. (e.g. java -XX:YoungPLABSize={min_uintx, max_uintx, max_uintx/2} GCOld 10 200 100 20 5000 Thanks, Sangheon From edward.nevill at gmail.com Wed Aug 19 12:10:06 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 19 Aug 2015 13:10:06 +0100 Subject: RFR: 8133935: aarch64: fails to build from source Message-ID: <1439986206.23660.11.camel@mint> Hi, http://cr.openjdk.java.net/~enevill/8133935/webrev/ fixes the following error in the build macroAssembler_aarch64.o: In function `MacroAssembler::patch_oop(unsigned char*, unsigned char*)': $HOME/openjdk/jdk9/dev/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:168: undefined reference to `oopDesc::encode_heap_oop(oopDesc*)' collect2: error: ld returned 1 exit status make[8]: *** [libjvm.so] Error 1 Please review, Thanks, Ed. PS: Both hs-comp and dev are broken, should I push to both? or just to hs-comp? From coleen.phillimore at oracle.com Wed Aug 19 12:41:07 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 19 Aug 2015 08:41:07 -0400 Subject: RFR: 8133935: aarch64: fails to build from source In-Reply-To: <1439986206.23660.11.camel@mint> References: <1439986206.23660.11.camel@mint> Message-ID: <55D47963.3050100@oracle.com> Looks good. Just push to hs-comp. Coleen On 8/19/15 8:10 AM, Edward Nevill wrote: > Hi, > > http://cr.openjdk.java.net/~enevill/8133935/webrev/ > > fixes the following error in the build > > macroAssembler_aarch64.o: In function `MacroAssembler::patch_oop(unsigned char*, unsigned char*)': > $HOME/openjdk/jdk9/dev/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:168: undefined reference to `oopDesc::encode_heap_oop(oopDesc*)' > collect2: error: ld returned 1 exit status > make[8]: *** [libjvm.so] Error 1 > > Please review, > Thanks, > Ed. > > PS: Both hs-comp and dev are broken, should I push to both? or just to hs-comp? > > From coleen.phillimore at oracle.com Wed Aug 19 12:49:54 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 19 Aug 2015 08:49:54 -0400 Subject: RFR: 8133935: aarch64: fails to build from source In-Reply-To: <1439986206.23660.11.camel@mint> References: <1439986206.23660.11.camel@mint> Message-ID: <55D47B72.40509@oracle.com> Sorry, I should spend more time on stuff like this. The #include list should be alphabetized. Coleen On 8/19/15 8:10 AM, Edward Nevill wrote: > Hi, > > http://cr.openjdk.java.net/~enevill/8133935/webrev/ > > fixes the following error in the build > > macroAssembler_aarch64.o: In function `MacroAssembler::patch_oop(unsigned char*, unsigned char*)': > $HOME/openjdk/jdk9/dev/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:168: undefined reference to `oopDesc::encode_heap_oop(oopDesc*)' > collect2: error: ld returned 1 exit status > make[8]: *** [libjvm.so] Error 1 > > Please review, > Thanks, > Ed. > > PS: Both hs-comp and dev are broken, should I push to both? or just to hs-comp? > > From edward.nevill at gmail.com Wed Aug 19 13:24:05 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 19 Aug 2015 14:24:05 +0100 Subject: RFR: 8133935: aarch64: fails to build from source In-Reply-To: <55D47B72.40509@oracle.com> References: <1439986206.23660.11.camel@mint> <55D47B72.40509@oracle.com> Message-ID: <1439990645.23660.64.camel@mint> Sorry. I wasn't aware of that. New webrev. http://cr.openjdk.java.net/~enevill/8133935/webrev.01/ Thanks, Ed. On Wed, 2015-08-19 at 08:49 -0400, Coleen Phillimore wrote: > Sorry, I should spend more time on stuff like this. The #include list > should be alphabetized. > Coleen > > On 8/19/15 8:10 AM, Edward Nevill wrote: > > Hi, > > > > http://cr.openjdk.java.net/~enevill/8133935/webrev/ > > > > fixes the following error in the build > > > > macroAssembler_aarch64.o: In function `MacroAssembler::patch_oop(unsigned char*, unsigned char*)': > > $HOME/openjdk/jdk9/dev/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:168: undefined reference to `oopDesc::encode_heap_oop(oopDesc*)' > > collect2: error: ld returned 1 exit status > > make[8]: *** [libjvm.so] Error 1 > > > > Please review, > > Thanks, > > Ed. > > > > PS: Both hs-comp and dev are broken, should I push to both? or just to hs-comp? > > > > > From coleen.phillimore at oracle.com Wed Aug 19 14:10:31 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 19 Aug 2015 10:10:31 -0400 Subject: RFR: 8133935: aarch64: fails to build from source In-Reply-To: <1439990645.23660.64.camel@mint> References: <1439986206.23660.11.camel@mint> <55D47B72.40509@oracle.com> <1439990645.23660.64.camel@mint> Message-ID: <55D48E57.8040805@oracle.com> yes, this looks good. Coleen On 8/19/15 9:24 AM, Edward Nevill wrote: > Sorry. I wasn't aware of that. New webrev. > > http://cr.openjdk.java.net/~enevill/8133935/webrev.01/ > > Thanks, > Ed. > > On Wed, 2015-08-19 at 08:49 -0400, Coleen Phillimore wrote: >> Sorry, I should spend more time on stuff like this. The #include list >> should be alphabetized. >> Coleen >> >> On 8/19/15 8:10 AM, Edward Nevill wrote: >>> Hi, >>> >>> http://cr.openjdk.java.net/~enevill/8133935/webrev/ >>> >>> fixes the following error in the build >>> >>> macroAssembler_aarch64.o: In function `MacroAssembler::patch_oop(unsigned char*, unsigned char*)': >>> $HOME/openjdk/jdk9/dev/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:168: undefined reference to `oopDesc::encode_heap_oop(oopDesc*)' >>> collect2: error: ld returned 1 exit status >>> make[8]: *** [libjvm.so] Error 1 >>> >>> Please review, >>> Thanks, >>> Ed. >>> >>> PS: Both hs-comp and dev are broken, should I push to both? or just to hs-comp? >>> >>> > From dmitry.dmitriev at oracle.com Wed Aug 19 14:18:25 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 19 Aug 2015 17:18:25 +0300 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55D40546.2060907@oracle.com> References: <55D40546.2060907@oracle.com> Message-ID: <55D49031.4010405@oracle.com> Hello Sangheon, I have one comment about changed set_fp_numeric_flag function in src/share/vm/runtime/arguments.cpp: 583 static bool set_fp_numeric_flag(char* name, char* value, Flag::Flags origin) { 584 errno = 0; 585 double v = strtod(value, NULL); 586 if (errno == ERANGE) { 587 return false; 588 } I think that second parameter for strtod also should be checked to ensure that valid exponential notation is passed. For example, currently it is possible to pass following notation: "1.5ee10" or "1.5e++10" and value will be set to 1.5 Also, I still have opinion that DBL_MAX is a not great upper range for double options, but I agree that we can leave it not and probably find more appropriate value in the future enhancement. For example, CMSSmallCoalSurplusPercent(and similar) have upper range equal to DBL_MAX. I looked at this flag and it used in multiplication and then result is converted to ssize_t(line 2129 in src/share/vm/gc/cms/compactibleFreeListSpace.cpp module) and these can lead to some overflow problems. So, it one of the reason why I think that we need to find more precise upper range. This can be considered as future enhancement. Thank you, Dmitry On 19.08.2015 7:25, sangheon.kim wrote: > Hi all, > > Please review this patch for command-line validation for GC flags. > This includes adding ranges and implementing constraint functions for > GC flags. > > Here are several things to note. > 1. Exponential notation for 'double' type variable parse: Previously > there were some discussion for maximum value for double type flags > from code review of JDK-8059557 and JDK-8112746. And Kim and I decided > not to add upper limit unless there are problems with DBL_MAX. And as > 255 is the maximum length that can be passed via command-line, we > introduced exponential notation to avoid this limit. ( arguments.cpp ) > 2. These GC flags ranges are not ideal ranges but ranges which don't > make problem with current source code. > If one flag makes some problem but hard to find good range, I > added some ranges. > 3. There are some constraint functions to avoid overflow. > 4. Test applications are changed: as some of them assumed to be > ParallelGC or to check it's output messages. > 5. Includes cleanup of JDK-8133565: GC -2nd followup to JDK-8059557. > > CR: https://bugs.openjdk.java.net/browse/JDK-8078555 > Webrev: http://cr.openjdk.java.net/~sangheki/8078555/webrev.00/ > Testing: JPRT, UTE(vm.quick-pcl), tests at test/runtime/CommandLine > and local tests[1]. > > [1]: Running GCOld for non bool GC flags with its variable type's > min/max/median. Needed real GCs to verify whether flags are making > problems or not. > (e.g. java -XX:YoungPLABSize={min_uintx, max_uintx, max_uintx/2} GCOld > 10 200 100 20 5000 > > Thanks, > Sangheon From daniel.daugherty at oracle.com Wed Aug 19 14:37:19 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 19 Aug 2015 08:37:19 -0600 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: <55A983CF.20600@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> Message-ID: <55D4949F.8010304@oracle.com> > I also need time to mull on the stuff down below. Closing the loop on this part. On 7/17/15 4:38 PM, Daniel D. Daugherty wrote: > On 7/16/15 9:18 AM, Langer, Christoph wrote: >> Hi all, >> >> >> >> I don't know if this mailing list is the right one for this issue. >> Let me know if I should post it elsewhere. >> >> >> >> I have prepared a fix for an issue with /tmp/hsperfdata files. >> >> >> >> Please review this change. I also need a sponsor. >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8130910 >> >> Change: http://cr.openjdk.java.net/~simonis/webrevs/2015/8130910/ > > src/os/aix/vm/perfMemory_aix.cpp > No comments. > > src/os/bsd/vm/perfMemory_bsd.cpp > No comments. > > src/os/linux/vm/perfMemory_linux.cpp > No comments. > > src/os/solaris/vm/perfMemory_solaris.cpp > No comments. > > > I think I'm OK with the code changes above, but I need more > time to mull on them. I also need time to mull on the stuff > down below. > > Will get back to this next week. > > Dan > > >> >> >> >> The problem is that for creating a file in >> /tmp/hsperfdata_, an fchdir to this directory is attempted. >> In case there's no execute permission on /tmp/hsperfdata_, >> the fchdir fails. As its return code is not checked up to now, the >> process would stay in its current working directory and create the >> file in there. The location stored for cleaning up at the end of the >> VM is also remembered as /tmp/hsperfdata... so the file would remain >> left over eventually. There are several checks for the hsperfdata >> location in place but nothing would hit and prevent the fchdir >> attempt beforehand in this case. I concur that the fchdir() error check is a good idea. >> I fixed it by handling fchdir return code and in case of failure >> closing the handles and returning NULL. In that case we wouldn't have >> shared PerfMemory but I think that is ok then. Since it's not necessarily safe to do the PerfMemory stuff if the fchdir() fails, this is a good solution. >> I thought about a testcase but it would involve messing around with >> /tmp/hsperfdata permissions which can have effects on other running >> JVMs, too, which I consider a bit dangerous. Yes, Jerry ran into lots of landmines with trying to create a test for the original failure mode. I can easily see how tweaking permissions in a test can mess up other Java processes running on the system. >> Generally I don't know if it is a good idea to do an fchdir at all >> but I don't know so much about the backgrounds of it... maybe someone >> wants to comment on that as well. This one is covered in a follow up email on 2015.07.17 to the original review request. Dan >> >> >> >> Thanks and best regards, >> >> Christoph >> >> >> > > From daniel.daugherty at oracle.com Wed Aug 19 14:37:29 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 19 Aug 2015 08:37:29 -0600 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338ED1655@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> <55AD0339.2060606@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338ED1655@DEWDFEMB12B.global.corp.sap> Message-ID: <55D494A9.8060804@oracle.com> Finally got the cycles to look at this again. Sorry for the very long delay. More embedded below... On 7/21/15 1:36 AM, Langer, Christoph wrote: > Hi Dan, > > thanks for looking into that matter. No problem. I was one of the original reviewers of Jerry's change so it only makes sense that I try to help out here. :-) Jerry should also be chiming in on this thread since this his code. > What about implementing the ?fdopendir(), openat() and unlinkat()? way of the secure file system object creation protocol already for the platforms where those APIs are supported? And use fchdir() only as fallback on platforms where the other APIs aren?t available yet? But this is probably a bigger topic and should be handled in a different change. That would definitely have to be examined in a different bug. We're trying to keep all the UNIX-like code as similar as possible so there would need to be a well defined breakage to justify doing something platform specific here. > Should you come to the final conclusion that the changes are good, it would be great if you could sponsor it. Yes, I will sponsor the change. I'll also run it through our internal testing infrastructure prior to committing. Dan > > Best regards > Christoph > > > > > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Montag, 20. Juli 2015 16:19 > > ... > > On 7/17/15 4:58 PM, Volker Simonis wrote: > > and I also share his doubts about changing the current working directory. > > I think this is questionable because it can have non-local side effects > > but I think this should be fixed in a follow up change. > > Changing the working directory can definitely have non-local side > effects, but the change of directory is a necessary part of the > secure file system object creation protocol. Jerry has a good > comment that explains what APIs we would rather use than changing > the current working directory, but those APIs don't exist on all > platforms (yet). > > 348 // NOTE: The code below uses fchdir(), open() and unlink() because > 349 // fdopendir(), openat() and unlinkat() are not supported on all > 350 // versions. Once the support for fdopendir(), openat() and unlinkat() > 351 // is available on all supported versions the code can be changed > 352 // to use these functions. > 353 > 354 // Open the directory of the given path, validate it and set the > 355 // current working directory to it. > 356 // Return a DIR * of the open directory and the saved cwd fd. > 357 // > 358 static DIR *open_directory_secure_cwd(const char* dirname, int *saved_cwd_fd) { > > The protocol is basically: > > open_directory_secure_cwd() > do operations to files in the directory using relative paths > close_directory_secure_cwd() > > The alternative of using full paths is difficult to do safely without > exposure to attacks along exposed path elements. > > From gerald.thornbrugh at oracle.com Wed Aug 19 14:42:56 2015 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Wed, 19 Aug 2015 08:42:56 -0600 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: <55D494A9.8060804@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> <55AD0339.2060606@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338ED1655@DEWDFEMB12B.global.corp.sap> <55D494A9.8060804@oracle.com> Message-ID: <55D495F0.9020503@oracle.com> Hi Langer, As Dan mentioned below I did the original change. > Finally got the cycles to look at this again. Sorry for the very > long delay. > > More embedded below... > > > On 7/21/15 1:36 AM, Langer, Christoph wrote: >> Hi Dan, >> >> thanks for looking into that matter. > > No problem. I was one of the original reviewers of Jerry's change > so it only makes sense that I try to help out here. :-) Jerry > should also be chiming in on this thread since this his code. I will also review your change although I am not a "Reviewer". > > >> What about implementing the ?fdopendir(), openat() and unlinkat()? >> way of the secure file system object creation protocol already for >> the platforms where those APIs are supported? And use fchdir() only >> as fallback on platforms where the other APIs aren?t available yet? >> But this is probably a bigger topic and should be handled in a >> different change. > > That would definitely have to be examined in a different bug. > We're trying to keep all the UNIX-like code as similar as > possible so there would need to be a well defined breakage > to justify doing something platform specific here. I agree with Dan, we did this sot he UNIX-like code would be similar. > > >> Should you come to the final conclusion that the changes are good, it >> would be great if you could sponsor it. > > Yes, I will sponsor the change. I'll also run it through our > internal testing infrastructure prior to committing. > > Dan I will answer any other questions you may have about the fix. Thanks, Jerry > > > >> >> Best regards >> Christoph >> >> >> >> >> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] >> Sent: Montag, 20. Juli 2015 16:19 >> >> ... >> >> On 7/17/15 4:58 PM, Volker Simonis wrote: >> > and I also share his doubts about changing the current working >> directory. >> > I think this is questionable because it can have non-local side >> effects >> > but I think this should be fixed in a follow up change. >> >> Changing the working directory can definitely have non-local side >> effects, but the change of directory is a necessary part of the >> secure file system object creation protocol. Jerry has a good >> comment that explains what APIs we would rather use than changing >> the current working directory, but those APIs don't exist on all >> platforms (yet). >> 348 // NOTE: The code below uses fchdir(), open() and unlink() >> because >> 349 // fdopendir(), openat() and unlinkat() are not supported on all >> 350 // versions. Once the support for fdopendir(), openat() and >> unlinkat() >> 351 // is available on all supported versions the code can be changed >> 352 // to use these functions. >> 353 >> 354 // Open the directory of the given path, validate it and set the >> 355 // current working directory to it. >> 356 // Return a DIR * of the open directory and the saved cwd fd. >> 357 // >> 358 static DIR *open_directory_secure_cwd(const char* dirname, int >> *saved_cwd_fd) { >> >> The protocol is basically: >> >> open_directory_secure_cwd() >> do operations to files in the directory using relative paths >> close_directory_secure_cwd() >> >> The alternative of using full paths is difficult to do safely without >> exposure to attacks along exposed path elements. >> >> > From sangheon.kim at oracle.com Wed Aug 19 16:25:43 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 19 Aug 2015 09:25:43 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55D49031.4010405@oracle.com> References: <55D40546.2060907@oracle.com> <55D49031.4010405@oracle.com> Message-ID: <55D4AE07.10907@oracle.com> Hi Dmitry, Thank you for looking at this! On 08/19/2015 07:18 AM, Dmitry Dmitriev wrote: > Hello Sangheon, > > I have one comment about changed set_fp_numeric_flag function in > src/share/vm/runtime/arguments.cpp: > 583 static bool set_fp_numeric_flag(char* name, char* value, > Flag::Flags origin) { > 584 errno = 0; > 585 double v = strtod(value, NULL); > 586 if (errno == ERANGE) { > 587 return false; > 588 } > > I think that second parameter for strtod also should be checked to > ensure that valid exponential notation is passed. For example, > currently it is possible to pass following notation: "1.5ee10" or > "1.5e++10" and value will be set to 1.5 Yes, right. When I changed this routine I knew them but I thought it is okay. You are pointing these values should not parsed, right? Let me change this at next version. :) > > Also, I still have opinion that DBL_MAX is a not great upper range for > double options, but I agree that we can leave it not and probably find > more appropriate value in the future enhancement. For example, > CMSSmallCoalSurplusPercent(and similar) have upper range equal to > DBL_MAX. I looked at this flag and it used in multiplication and then > result is converted to ssize_t(line 2129 in > src/share/vm/gc/cms/compactibleFreeListSpace.cpp module) and these can > lead to some overflow problems. So, it one of the reason why I think > that we need to find more precise upper range. This can be considered > as future enhancement. Yes, there would happen overflow. CMSSmallCoalSurplusPercent and its friends have same behavior. (ssize_t type) * (double type) is saved at (ssize_t type) Fortunately, these flags with DBL_MAX doesn't hit assert or crash during running GCOld. As you mentioned, we can leave them for future enhancement. Thanks, Sangheon > > Thank you, > Dmitry > > On 19.08.2015 7:25, sangheon.kim wrote: >> Hi all, >> >> Please review this patch for command-line validation for GC flags. >> This includes adding ranges and implementing constraint functions for >> GC flags. >> >> Here are several things to note. >> 1. Exponential notation for 'double' type variable parse: Previously >> there were some discussion for maximum value for double type flags >> from code review of JDK-8059557 and JDK-8112746. And Kim and I >> decided not to add upper limit unless there are problems with >> DBL_MAX. And as 255 is the maximum length that can be passed via >> command-line, we introduced exponential notation to avoid this limit. >> ( arguments.cpp ) >> 2. These GC flags ranges are not ideal ranges but ranges which don't >> make problem with current source code. >> If one flag makes some problem but hard to find good range, I >> added some ranges. >> 3. There are some constraint functions to avoid overflow. >> 4. Test applications are changed: as some of them assumed to be >> ParallelGC or to check it's output messages. >> 5. Includes cleanup of JDK-8133565: GC -2nd followup to JDK-8059557. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8078555 >> Webrev: http://cr.openjdk.java.net/~sangheki/8078555/webrev.00/ >> Testing: JPRT, UTE(vm.quick-pcl), tests at test/runtime/CommandLine >> and local tests[1]. >> >> [1]: Running GCOld for non bool GC flags with its variable type's >> min/max/median. Needed real GCs to verify whether flags are making >> problems or not. >> (e.g. java -XX:YoungPLABSize={min_uintx, max_uintx, max_uintx/2} >> GCOld 10 200 100 20 5000 >> >> Thanks, >> Sangheon > From dmitry.dmitriev at oracle.com Wed Aug 19 17:34:27 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 19 Aug 2015 20:34:27 +0300 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55D4AE07.10907@oracle.com> References: <55D40546.2060907@oracle.com> <55D49031.4010405@oracle.com> <55D4AE07.10907@oracle.com> Message-ID: <55D4BE23.7020101@oracle.com> Sangheon, Few comments inline. On 19.08.2015 19:25, sangheon.kim wrote: > Hi Dmitry, > > Thank you for looking at this! > > On 08/19/2015 07:18 AM, Dmitry Dmitriev wrote: >> Hello Sangheon, >> >> I have one comment about changed set_fp_numeric_flag function in >> src/share/vm/runtime/arguments.cpp: >> 583 static bool set_fp_numeric_flag(char* name, char* value, >> Flag::Flags origin) { >> 584 errno = 0; >> 585 double v = strtod(value, NULL); >> 586 if (errno == ERANGE) { >> 587 return false; >> 588 } >> >> I think that second parameter for strtod also should be checked to >> ensure that valid exponential notation is passed. For example, >> currently it is possible to pass following notation: "1.5ee10" or >> "1.5e++10" and value will be set to 1.5 > Yes, right. > When I changed this routine I knew them but I thought it is okay. > You are pointing these values should not parsed, right? Yes, I think that these values should not be parsed and JVM should report error. For example if I put two "ee", then I should get an error. Currently "1.5ee10" value is parsed and double flag is equal to "1.5" isntead of "1.5e10". > Let me change this at next version. :) Thank you! > >> >> Also, I still have opinion that DBL_MAX is a not great upper range >> for double options, but I agree that we can leave it not and probably >> find more appropriate value in the future enhancement. For example, >> CMSSmallCoalSurplusPercent(and similar) have upper range equal to >> DBL_MAX. I looked at this flag and it used in multiplication and then >> result is converted to ssize_t(line 2129 in >> src/share/vm/gc/cms/compactibleFreeListSpace.cpp module) and these >> can lead to some overflow problems. So, it one of the reason why I >> think that we need to find more precise upper range. This can be >> considered as future enhancement. > Yes, there would happen overflow. > CMSSmallCoalSurplusPercent and its friends have same behavior. > (ssize_t type) * (double type) is saved at (ssize_t type) > Fortunately, these flags with DBL_MAX doesn't hit assert or crash > during running GCOld. > As you mentioned, we can leave them for future enhancement. Yes, sure! Thanks, Dmitry > > Thanks, > Sangheon > > >> >> Thank you, >> Dmitry >> >> On 19.08.2015 7:25, sangheon.kim wrote: >>> Hi all, >>> >>> Please review this patch for command-line validation for GC flags. >>> This includes adding ranges and implementing constraint functions >>> for GC flags. >>> >>> Here are several things to note. >>> 1. Exponential notation for 'double' type variable parse: Previously >>> there were some discussion for maximum value for double type flags >>> from code review of JDK-8059557 and JDK-8112746. And Kim and I >>> decided not to add upper limit unless there are problems with >>> DBL_MAX. And as 255 is the maximum length that can be passed via >>> command-line, we introduced exponential notation to avoid this >>> limit. ( arguments.cpp ) >>> 2. These GC flags ranges are not ideal ranges but ranges which don't >>> make problem with current source code. >>> If one flag makes some problem but hard to find good range, I >>> added some ranges. >>> 3. There are some constraint functions to avoid overflow. >>> 4. Test applications are changed: as some of them assumed to be >>> ParallelGC or to check it's output messages. >>> 5. Includes cleanup of JDK-8133565: GC -2nd followup to JDK-8059557. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8078555 >>> Webrev: http://cr.openjdk.java.net/~sangheki/8078555/webrev.00/ >>> Testing: JPRT, UTE(vm.quick-pcl), tests at test/runtime/CommandLine >>> and local tests[1]. >>> >>> [1]: Running GCOld for non bool GC flags with its variable type's >>> min/max/median. Needed real GCs to verify whether flags are making >>> problems or not. >>> (e.g. java -XX:YoungPLABSize={min_uintx, max_uintx, max_uintx/2} >>> GCOld 10 200 100 20 5000 >>> >>> Thanks, >>> Sangheon >> > From coleen.phillimore at oracle.com Wed Aug 19 17:45:37 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 19 Aug 2015 13:45:37 -0400 Subject: RFR: 8133951: Zero interpreter asserts in stubRoutines.cpp Message-ID: <55D4C0C1.8090104@oracle.com> Summary: Allow zero sized code buffer when checking if there's enough remaining size open webrev at http://cr.openjdk.java.net/~coleenp/8133951/ bug link https://bugs.openjdk.java.net/browse/JDK-8133951 Tested with java -version of zero and runThese -jck tests. Thanks, Coleen From vladimir.kozlov at oracle.com Wed Aug 19 17:57:25 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Aug 2015 10:57:25 -0700 Subject: RFR: 8133951: Zero interpreter asserts in stubRoutines.cpp In-Reply-To: <55D4C0C1.8090104@oracle.com> References: <55D4C0C1.8090104@oracle.com> Message-ID: <55D4C385.3030407@oracle.com> Insts sizes are set by CodeBuffer constructor which is called before StubGenerator_generate: CodeBuffer buffer(_code1); StubGenerator_generate(&buffer, false); See CodeBuffer::initialize() and CodeSection::initialize(). So if nothing generated insts_remaining() should be code_size1 value. Why it is not? Thanks, Vladimir On 8/19/15 10:45 AM, Coleen Phillimore wrote: > Summary: Allow zero sized code buffer when checking if there's enough > remaining size > > open webrev at http://cr.openjdk.java.net/~coleenp/8133951/ > bug link https://bugs.openjdk.java.net/browse/JDK-8133951 > > Tested with java -version of zero and runThese -jck tests. > > Thanks, > Coleen From vladimir.kozlov at oracle.com Wed Aug 19 18:15:33 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Aug 2015 11:15:33 -0700 Subject: RFR: 8133951: Zero interpreter asserts in stubRoutines.cpp In-Reply-To: <55D4C385.3030407@oracle.com> References: <55D4C0C1.8090104@oracle.com> <55D4C385.3030407@oracle.com> Message-ID: <55D4C7C5.5020707@oracle.com> I found it in stubRoutines_zero.hpp: enum platform_dependent_constants { code_size1 = 0, // The assembler will fail with a guarantee code_size2 = 0 // if these are too small. Simply increase }; // them if that happens. That is why zero hits assert. I think asserts should be relaxed as: assert(code_size1 == 0 || buffer.insts_remaining() > 200, "increase code_size1"); assert(code_size2 == 0 || buffer.insts_remaining() > 200, "increase code_size2"); Thanks, Vladimir On 8/19/15 10:57 AM, Vladimir Kozlov wrote: > Insts sizes are set by CodeBuffer constructor which is called before > StubGenerator_generate: > > CodeBuffer buffer(_code1); > StubGenerator_generate(&buffer, false); > > See CodeBuffer::initialize() and CodeSection::initialize(). So if > nothing generated insts_remaining() should be code_size1 value. Why it > is not? > > Thanks, > Vladimir > > On 8/19/15 10:45 AM, Coleen Phillimore wrote: >> Summary: Allow zero sized code buffer when checking if there's enough >> remaining size >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8133951/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8133951 >> >> Tested with java -version of zero and runThese -jck tests. >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Wed Aug 19 18:21:23 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 19 Aug 2015 14:21:23 -0400 Subject: RFR: 8133951: Zero interpreter asserts in stubRoutines.cpp In-Reply-To: <55D4C7C5.5020707@oracle.com> References: <55D4C0C1.8090104@oracle.com> <55D4C385.3030407@oracle.com> <55D4C7C5.5020707@oracle.com> Message-ID: <55D4C923.8060703@oracle.com> I can make the change like this. Thank you for finding where the 0 size comes from! I didn't notice initially that code_size1 and 2 were constants. Coleen On 8/19/15 2:15 PM, Vladimir Kozlov wrote: > I found it in stubRoutines_zero.hpp: > > enum platform_dependent_constants { > code_size1 = 0, // The assembler will fail with a guarantee > code_size2 = 0 // if these are too small. Simply increase > }; // them if that happens. > > That is why zero hits assert. > > I think asserts should be relaxed as: > > assert(code_size1 == 0 || buffer.insts_remaining() > 200, "increase > code_size1"); > > assert(code_size2 == 0 || buffer.insts_remaining() > 200, "increase > code_size2"); > > Thanks, > Vladimir > > On 8/19/15 10:57 AM, Vladimir Kozlov wrote: >> Insts sizes are set by CodeBuffer constructor which is called before >> StubGenerator_generate: >> >> CodeBuffer buffer(_code1); >> StubGenerator_generate(&buffer, false); >> >> See CodeBuffer::initialize() and CodeSection::initialize(). So if >> nothing generated insts_remaining() should be code_size1 value. Why it >> is not? >> >> Thanks, >> Vladimir >> >> On 8/19/15 10:45 AM, Coleen Phillimore wrote: >>> Summary: Allow zero sized code buffer when checking if there's enough >>> remaining size >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8133951/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8133951 >>> >>> Tested with java -version of zero and runThese -jck tests. >>> >>> Thanks, >>> Coleen From coleen.phillimore at oracle.com Wed Aug 19 18:27:23 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 19 Aug 2015 14:27:23 -0400 Subject: RFR: 8133951: Zero interpreter asserts in stubRoutines.cpp In-Reply-To: <55D4C7C5.5020707@oracle.com> References: <55D4C0C1.8090104@oracle.com> <55D4C385.3030407@oracle.com> <55D4C7C5.5020707@oracle.com> Message-ID: <55D4CA8B.2070100@oracle.com> Yes, this works also and is more minimal. Thanks! http://cr.openjdk.java.net/~coleenp/8133951.02/ Coleen On 8/19/15 2:15 PM, Vladimir Kozlov wrote: > I found it in stubRoutines_zero.hpp: > > enum platform_dependent_constants { > code_size1 = 0, // The assembler will fail with a guarantee > code_size2 = 0 // if these are too small. Simply increase > }; // them if that happens. > > That is why zero hits assert. > > I think asserts should be relaxed as: > > assert(code_size1 == 0 || buffer.insts_remaining() > 200, "increase > code_size1"); > > assert(code_size2 == 0 || buffer.insts_remaining() > 200, "increase > code_size2"); > > Thanks, > Vladimir > > On 8/19/15 10:57 AM, Vladimir Kozlov wrote: >> Insts sizes are set by CodeBuffer constructor which is called before >> StubGenerator_generate: >> >> CodeBuffer buffer(_code1); >> StubGenerator_generate(&buffer, false); >> >> See CodeBuffer::initialize() and CodeSection::initialize(). So if >> nothing generated insts_remaining() should be code_size1 value. Why it >> is not? >> >> Thanks, >> Vladimir >> >> On 8/19/15 10:45 AM, Coleen Phillimore wrote: >>> Summary: Allow zero sized code buffer when checking if there's enough >>> remaining size >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8133951/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8133951 >>> >>> Tested with java -version of zero and runThese -jck tests. >>> >>> Thanks, >>> Coleen From vladimir.kozlov at oracle.com Wed Aug 19 18:49:23 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Aug 2015 11:49:23 -0700 Subject: Need some help: 8133646: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <55D2A10F.6010408@oracle.com> References: <55D2A10F.6010408@oracle.com> Message-ID: <55D4CFB3.7040701@oracle.com> First, there copy-paste problem in verification code, jcc after bind is not needed: > 375 __ jcc(Assembler::equal, L); > 376 __ bind(S); > 377 __ jcc(Assembler::equal, L); Yes, the code assumes that get_thread(rbx); returns correct value and will not modify r15. r15 is save-on-entry so the C code should save it. Is it possible that Sun's C++ compiler has a bug? So that _thr_current has wrong value? Or does not save r15? To make sure that it is the cause of problem I would suggest to modify verification code as next: Label L1, L2; __ cmpptr(r15_thread, thread); __ jcc(Assembler::equal, L1); __ stop("StubRoutines::call_stub: r15_thread is corrupted"); __ bind(L1); __ get_thread(rbx); __ cmpptr(r15_thread, rbx); __ jcc(Assembler::equal, L2); __ stop("StubRoutines::call_stub: threads must correspond"); __ bind(L2); Thanks, Vladimir On 8/17/15 8:05 PM, David Holmes wrote: > Hi Compiler and x86_64 code experts, :) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 > > There's a chance this failure is related to my recent changes under > 8130212: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10 > > Given the failing debug code: > > 367 #ifdef ASSERT > 368 // verify that threads correspond > 369 { > 370 Label L, S; > 371 __ cmpptr(r15_thread, thread); > 372 __ jcc(Assembler::notEqual, S); > 373 __ get_thread(rbx); > 374 __ cmpptr(r15_thread, rbx); > 375 __ jcc(Assembler::equal, L); > 376 __ bind(S); > 377 __ jcc(Assembler::equal, L); > 378 __ stop("StubRoutines::call_stub: threads must correspond"); > 379 __ bind(L); > 380 } > 381 #endif > > and given the definition of get_thread: > > // This is simply a call to ThreadLocalStorage::thread() > void MacroAssembler::get_thread(Register thread) { > if (thread != rax) { > push(rax); > } > push(rdi); > push(rsi); > push(rdx); > push(rcx); > push(r8); > push(r9); > push(r10); > push(r11); > > call(RuntimeAddress(CAST_FROM_FN_PTR(address, > ThreadLocalStorage::thread))); > > pop(r11); > pop(r10); > pop(r9); > pop(r8); > pop(rcx); > pop(rdx); > pop(rsi); > pop(rdi); > > if (thread != rax) { > movl(thread, rax); > pop(rax); > } > } > > where ThreadLocalStorage::thread() is simply: > > inline Thread* ThreadLocalStorage::thread() { > return _thr_current; > } > > and _thr_current is a compiler-defined thread-local variable: > > static __thread Thread * _thr_current; > > Can anyone see anything that might cause an issue? I was wondering > whether I have to verify that r15 is preserved by the actual > thread-local access? IIUC normally the get_thread slow-path would be > used to set r15_thread and so we wouldn't notice if it got trashed under > some circumstances. It obviously doesn't always get trashed because the > bug has only been seen to occur once. And of course the failure could be > completely incidental to my changes. :) > > Thanks, > David From vladimir.kozlov at oracle.com Wed Aug 19 18:50:36 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Aug 2015 11:50:36 -0700 Subject: RFR: 8133951: Zero interpreter asserts in stubRoutines.cpp In-Reply-To: <55D4CA8B.2070100@oracle.com> References: <55D4C0C1.8090104@oracle.com> <55D4C385.3030407@oracle.com> <55D4C7C5.5020707@oracle.com> <55D4CA8B.2070100@oracle.com> Message-ID: <55D4CFFC.6040107@oracle.com> Looks good. Thanks, Vladimir On 8/19/15 11:27 AM, Coleen Phillimore wrote: > Yes, this works also and is more minimal. Thanks! > > http://cr.openjdk.java.net/~coleenp/8133951.02/ > > Coleen > > On 8/19/15 2:15 PM, Vladimir Kozlov wrote: >> I found it in stubRoutines_zero.hpp: >> >> enum platform_dependent_constants { >> code_size1 = 0, // The assembler will fail with a guarantee >> code_size2 = 0 // if these are too small. Simply increase >> }; // them if that happens. >> >> That is why zero hits assert. >> >> I think asserts should be relaxed as: >> >> assert(code_size1 == 0 || buffer.insts_remaining() > 200, "increase >> code_size1"); >> >> assert(code_size2 == 0 || buffer.insts_remaining() > 200, "increase >> code_size2"); >> >> Thanks, >> Vladimir >> >> On 8/19/15 10:57 AM, Vladimir Kozlov wrote: >>> Insts sizes are set by CodeBuffer constructor which is called before >>> StubGenerator_generate: >>> >>> CodeBuffer buffer(_code1); >>> StubGenerator_generate(&buffer, false); >>> >>> See CodeBuffer::initialize() and CodeSection::initialize(). So if >>> nothing generated insts_remaining() should be code_size1 value. Why it >>> is not? >>> >>> Thanks, >>> Vladimir >>> >>> On 8/19/15 10:45 AM, Coleen Phillimore wrote: >>>> Summary: Allow zero sized code buffer when checking if there's enough >>>> remaining size >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8133951/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8133951 >>>> >>>> Tested with java -version of zero and runThese -jck tests. >>>> >>>> Thanks, >>>> Coleen > From coleen.phillimore at oracle.com Wed Aug 19 18:52:32 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 19 Aug 2015 14:52:32 -0400 Subject: RFR: 8133951: Zero interpreter asserts in stubRoutines.cpp In-Reply-To: <55D4CFFC.6040107@oracle.com> References: <55D4C0C1.8090104@oracle.com> <55D4C385.3030407@oracle.com> <55D4C7C5.5020707@oracle.com> <55D4CA8B.2070100@oracle.com> <55D4CFFC.6040107@oracle.com> Message-ID: <55D4D070.7000803@oracle.com> Thanks! Coleen On 8/19/15 2:50 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 8/19/15 11:27 AM, Coleen Phillimore wrote: >> Yes, this works also and is more minimal. Thanks! >> >> http://cr.openjdk.java.net/~coleenp/8133951.02/ >> >> Coleen >> >> On 8/19/15 2:15 PM, Vladimir Kozlov wrote: >>> I found it in stubRoutines_zero.hpp: >>> >>> enum platform_dependent_constants { >>> code_size1 = 0, // The assembler will fail with a guarantee >>> code_size2 = 0 // if these are too small. Simply increase >>> }; // them if that happens. >>> >>> That is why zero hits assert. >>> >>> I think asserts should be relaxed as: >>> >>> assert(code_size1 == 0 || buffer.insts_remaining() > 200, "increase >>> code_size1"); >>> >>> assert(code_size2 == 0 || buffer.insts_remaining() > 200, "increase >>> code_size2"); >>> >>> Thanks, >>> Vladimir >>> >>> On 8/19/15 10:57 AM, Vladimir Kozlov wrote: >>>> Insts sizes are set by CodeBuffer constructor which is called before >>>> StubGenerator_generate: >>>> >>>> CodeBuffer buffer(_code1); >>>> StubGenerator_generate(&buffer, false); >>>> >>>> See CodeBuffer::initialize() and CodeSection::initialize(). So if >>>> nothing generated insts_remaining() should be code_size1 value. Why it >>>> is not? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/19/15 10:45 AM, Coleen Phillimore wrote: >>>>> Summary: Allow zero sized code buffer when checking if there's enough >>>>> remaining size >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8133951/ >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8133951 >>>>> >>>>> Tested with java -version of zero and runThese -jck tests. >>>>> >>>>> Thanks, >>>>> Coleen >> From vladimir.kozlov at oracle.com Wed Aug 19 18:54:55 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Aug 2015 11:54:55 -0700 Subject: Need some help: 8133646: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <55D4CFB3.7040701@oracle.com> References: <55D2A10F.6010408@oracle.com> <55D4CFB3.7040701@oracle.com> Message-ID: <55D4D0FF.6000806@oracle.com> Additional check: Label L1, L2, L3; __ cmpptr(r15_thread, thread); __ jcc(Assembler::equal, L1); __ stop("StubRoutines::call_stub: r15_thread is corrupted"); __ bind(L1); __ get_thread(rbx); __ cmpptr(r15_thread, thread); __ jcc(Assembler::equal, L2); __ stop("StubRoutines::call_stub: r15_thread is modified by call"); __ bind(L2); __ cmpptr(r15_thread, rbx); __ jcc(Assembler::equal, L3); __ stop("StubRoutines::call_stub: threads must correspond"); __ bind(L3); Vladimir On 8/19/15 11:49 AM, Vladimir Kozlov wrote: > First, there copy-paste problem in verification code, jcc after bind is > not needed: > > > 375 __ jcc(Assembler::equal, L); > > 376 __ bind(S); > > 377 __ jcc(Assembler::equal, L); > > Yes, the code assumes that get_thread(rbx); returns correct value and > will not modify r15. r15 is save-on-entry so the C code should save it. > > Is it possible that Sun's C++ compiler has a bug? So that _thr_current > has wrong value? Or does not save r15? > > To make sure that it is the cause of problem I would suggest to modify > verification code as next: > > Label L1, L2; > __ cmpptr(r15_thread, thread); > __ jcc(Assembler::equal, L1); > __ stop("StubRoutines::call_stub: r15_thread is corrupted"); > __ bind(L1); > __ get_thread(rbx); > __ cmpptr(r15_thread, rbx); > __ jcc(Assembler::equal, L2); > __ stop("StubRoutines::call_stub: threads must correspond"); > __ bind(L2); > > > Thanks, > Vladimir > > On 8/17/15 8:05 PM, David Holmes wrote: >> Hi Compiler and x86_64 code experts, :) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 >> >> There's a chance this failure is related to my recent changes under >> 8130212: >> >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10 >> >> Given the failing debug code: >> >> 367 #ifdef ASSERT >> 368 // verify that threads correspond >> 369 { >> 370 Label L, S; >> 371 __ cmpptr(r15_thread, thread); >> 372 __ jcc(Assembler::notEqual, S); >> 373 __ get_thread(rbx); >> 374 __ cmpptr(r15_thread, rbx); >> 375 __ jcc(Assembler::equal, L); >> 376 __ bind(S); >> 377 __ jcc(Assembler::equal, L); >> 378 __ stop("StubRoutines::call_stub: threads must correspond"); >> 379 __ bind(L); >> 380 } >> 381 #endif >> >> and given the definition of get_thread: >> >> // This is simply a call to ThreadLocalStorage::thread() >> void MacroAssembler::get_thread(Register thread) { >> if (thread != rax) { >> push(rax); >> } >> push(rdi); >> push(rsi); >> push(rdx); >> push(rcx); >> push(r8); >> push(r9); >> push(r10); >> push(r11); >> >> call(RuntimeAddress(CAST_FROM_FN_PTR(address, >> ThreadLocalStorage::thread))); >> >> pop(r11); >> pop(r10); >> pop(r9); >> pop(r8); >> pop(rcx); >> pop(rdx); >> pop(rsi); >> pop(rdi); >> >> if (thread != rax) { >> movl(thread, rax); >> pop(rax); >> } >> } >> >> where ThreadLocalStorage::thread() is simply: >> >> inline Thread* ThreadLocalStorage::thread() { >> return _thr_current; >> } >> >> and _thr_current is a compiler-defined thread-local variable: >> >> static __thread Thread * _thr_current; >> >> Can anyone see anything that might cause an issue? I was wondering >> whether I have to verify that r15 is preserved by the actual >> thread-local access? IIUC normally the get_thread slow-path would be >> used to set r15_thread and so we wouldn't notice if it got trashed under >> some circumstances. It obviously doesn't always get trashed because the >> bug has only been seen to occur once. And of course the failure could be >> completely incidental to my changes. :) >> >> Thanks, >> David From daniel.daugherty at oracle.com Wed Aug 19 21:31:07 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 19 Aug 2015 15:31:07 -0600 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: <55D494A9.8060804@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> <55AD0339.2060606@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338ED1655@DEWDFEMB12B.global.corp.sap> <55D494A9.8060804@oracle.com> Message-ID: <55D4F59B.6020807@oracle.com> > Yes, I will sponsor the change. I'll also run it through our > internal testing infrastructure prior to committing. My "JPRT -testset hotspot" job went just fine and now I've submitted the bits for an Aurora Adhoc "RT-SVC Nightly tests" run. I'll keep an eye on the testing and let folks know the results. Here's my current commit message: 8130910: hsperfdata file is created in wrong directory and not cleaned up if /tmp/hsperfdata_ has wrong permissions Summary: Add check for fchir() failure and disable shared PerfMemory in that case. Reviewed-by: dcubed, simonis, gthornbr Contributed-by: christoph.langer at sap.com Everybody good with it (modulo any new reviewers)? Dan On 8/19/15 8:37 AM, Daniel D. Daugherty wrote: > Finally got the cycles to look at this again. Sorry for the very > long delay. > > More embedded below... > > > On 7/21/15 1:36 AM, Langer, Christoph wrote: >> Hi Dan, >> >> thanks for looking into that matter. > > No problem. I was one of the original reviewers of Jerry's change > so it only makes sense that I try to help out here. :-) Jerry > should also be chiming in on this thread since this his code. > > >> What about implementing the ?fdopendir(), openat() and unlinkat()? >> way of the secure file system object creation protocol already for >> the platforms where those APIs are supported? And use fchdir() only >> as fallback on platforms where the other APIs aren?t available yet? >> But this is probably a bigger topic and should be handled in a >> different change. > > That would definitely have to be examined in a different bug. > We're trying to keep all the UNIX-like code as similar as > possible so there would need to be a well defined breakage > to justify doing something platform specific here. > > >> Should you come to the final conclusion that the changes are good, it >> would be great if you could sponsor it. > > Yes, I will sponsor the change. I'll also run it through our > internal testing infrastructure prior to committing. > > Dan > > > >> >> Best regards >> Christoph >> >> >> >> >> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] >> Sent: Montag, 20. Juli 2015 16:19 >> >> ... >> >> On 7/17/15 4:58 PM, Volker Simonis wrote: >> > and I also share his doubts about changing the current working >> directory. >> > I think this is questionable because it can have non-local side >> effects >> > but I think this should be fixed in a follow up change. >> >> Changing the working directory can definitely have non-local side >> effects, but the change of directory is a necessary part of the >> secure file system object creation protocol. Jerry has a good >> comment that explains what APIs we would rather use than changing >> the current working directory, but those APIs don't exist on all >> platforms (yet). >> 348 // NOTE: The code below uses fchdir(), open() and unlink() >> because >> 349 // fdopendir(), openat() and unlinkat() are not supported on all >> 350 // versions. Once the support for fdopendir(), openat() and >> unlinkat() >> 351 // is available on all supported versions the code can be changed >> 352 // to use these functions. >> 353 >> 354 // Open the directory of the given path, validate it and set the >> 355 // current working directory to it. >> 356 // Return a DIR * of the open directory and the saved cwd fd. >> 357 // >> 358 static DIR *open_directory_secure_cwd(const char* dirname, int >> *saved_cwd_fd) { >> >> The protocol is basically: >> >> open_directory_secure_cwd() >> do operations to files in the directory using relative paths >> close_directory_secure_cwd() >> >> The alternative of using full paths is difficult to do safely without >> exposure to attacks along exposed path elements. >> >> > > From gerald.thornbrugh at oracle.com Wed Aug 19 21:34:12 2015 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Wed, 19 Aug 2015 15:34:12 -0600 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: <55D4F59B.6020807@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> <55AD0339.2060606@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338ED1655@DEWDFEMB12B.global.corp.sap> <55D494A9.8060804@oracle.com> <55D4F59B.6020807@oracle.com> Message-ID: <55D4F654.3080007@oracle.com> Hi Dan, > > Yes, I will sponsor the change. I'll also run it through our > > internal testing infrastructure prior to committing. > > My "JPRT -testset hotspot" job went just fine and now I've submitted > the bits for an Aurora Adhoc "RT-SVC Nightly tests" run. I'll keep > an eye on the testing and let folks know the results. > > Here's my current commit message: > > 8130910: hsperfdata file is created in wrong directory and not cleaned > up if /tmp/hsperfdata_ has wrong permissions > Summary: Add check for fchir() failure and disable shared PerfMemory > in that case. > Reviewed-by: dcubed, simonis, gthornbr > Contributed-by: christoph.langer at sap.com > > Everybody good with it (modulo any new reviewers)? I am good with it. Jerry > > Dan > > > On 8/19/15 8:37 AM, Daniel D. Daugherty wrote: >> Finally got the cycles to look at this again. Sorry for the very >> long delay. >> >> More embedded below... >> >> >> On 7/21/15 1:36 AM, Langer, Christoph wrote: >>> Hi Dan, >>> >>> thanks for looking into that matter. >> >> No problem. I was one of the original reviewers of Jerry's change >> so it only makes sense that I try to help out here. :-) Jerry >> should also be chiming in on this thread since this his code. >> >> >>> What about implementing the ?fdopendir(), openat() and unlinkat()? >>> way of the secure file system object creation protocol already for >>> the platforms where those APIs are supported? And use fchdir() only >>> as fallback on platforms where the other APIs aren?t available yet? >>> But this is probably a bigger topic and should be handled in a >>> different change. >> >> That would definitely have to be examined in a different bug. >> We're trying to keep all the UNIX-like code as similar as >> possible so there would need to be a well defined breakage >> to justify doing something platform specific here. >> >> >>> Should you come to the final conclusion that the changes are good, >>> it would be great if you could sponsor it. >> >> Yes, I will sponsor the change. I'll also run it through our >> internal testing infrastructure prior to committing. >> >> Dan >> >> >> >>> >>> Best regards >>> Christoph >>> >>> >>> >>> >>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] >>> Sent: Montag, 20. Juli 2015 16:19 >>> >>> ... >>> >>> On 7/17/15 4:58 PM, Volker Simonis wrote: >>> > and I also share his doubts about changing the current working >>> directory. >>> > I think this is questionable because it can have non-local side >>> effects >>> > but I think this should be fixed in a follow up change. >>> >>> Changing the working directory can definitely have non-local side >>> effects, but the change of directory is a necessary part of the >>> secure file system object creation protocol. Jerry has a good >>> comment that explains what APIs we would rather use than changing >>> the current working directory, but those APIs don't exist on all >>> platforms (yet). >>> 348 // NOTE: The code below uses fchdir(), open() and unlink() >>> because >>> 349 // fdopendir(), openat() and unlinkat() are not supported on all >>> 350 // versions. Once the support for fdopendir(), openat() and >>> unlinkat() >>> 351 // is available on all supported versions the code can be changed >>> 352 // to use these functions. >>> 353 >>> 354 // Open the directory of the given path, validate it and set the >>> 355 // current working directory to it. >>> 356 // Return a DIR * of the open directory and the saved cwd fd. >>> 357 // >>> 358 static DIR *open_directory_secure_cwd(const char* dirname, int >>> *saved_cwd_fd) { >>> >>> The protocol is basically: >>> >>> open_directory_secure_cwd() >>> do operations to files in the directory using relative paths >>> close_directory_secure_cwd() >>> >>> The alternative of using full paths is difficult to do safely without >>> exposure to attacks along exposed path elements. >>> >>> >> >> > From kim.barrett at oracle.com Wed Aug 19 21:59:29 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 19 Aug 2015 17:59:29 -0400 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55D40546.2060907@oracle.com> References: <55D40546.2060907@oracle.com> Message-ID: <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> On Aug 19, 2015, at 12:25 AM, sangheon.kim wrote: > > Hi all, > > Please review this patch for command-line validation for GC flags. > This includes adding ranges and implementing constraint functions for GC flags. > > [?] > CR: https://bugs.openjdk.java.net/browse/JDK-8078555 > Webrev: http://cr.openjdk.java.net/~sangheki/8078555/webrev.00/ > Testing: JPRT, UTE(vm.quick-pcl), tests at test/runtime/CommandLine and local tests[1]. ------------------------------------------------------------------------------ src/share/vm/gc/g1/g1_globals.hpp 87 product(size_t, G1SATBBufferSize, 1*K, \ 88 "Number of entries in an SATB log buffer.") \ 89 range(1, max_uintx) \ Shouldn't that be max_size_t? Oh, wait; we don't have that. Maybe we should. ------------------------------------------------------------------------------ src/share/vm/runtime/arguments.cpp 583 static bool set_fp_numeric_flag(char* name, char* value, Flag::Flags origin) { 584 errno = 0; 585 double v = strtod(value, NULL); 586 if (errno == ERANGE) { 587 return false; 588 } You and Dmitry already discussed checking the endptr. Good catch, Dmitry. I suggest returning false for any non-zero errno value. ------------------------------------------------------------------------------ src/share/vm/runtime/arguments.cpp 722 #define NUMBER_RANGE "[0123456789eE+]" Missing "-" for negative exponents. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 48 static Flag::Error ParallelGCThreadsAndCMSWorkQueueDrainThreshold(bool verbose) { 61 Flag::Error ParallelGCThreadsConstraintFunc(uint value, bool verbose) { 90 Flag::Error ConcGCThreadsConstraintFunc(uint value, bool verbose) { These are associated with collectors that are excluded when INCLUDE_ALL_GCS is false. The bodies of these should be conditionally included based on that macro, and they should just return Flag::SUCCESS when the macro is false. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 142 Flag::Error OldPLABSizeConstraintFunc(size_t value, bool verbose) { 143 if (UseConcMarkSweepGC) { The UseConcMarkSweepGC clause should be conditionalized out if INCLUDE_ALL_GCS is false. Peeking ahead, it looks like there are quite a few constraint functions that should be similarly conditionalized. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 183 static Flag::Error CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(bool verbose) { ... 196 Flag::Error SoftRefLRUPolicyMSPerMBConstraintFunc(intx value, bool verbose) { 197 return CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(verbose); 198 } This doesn't look right. The Check helper function is using the current value of SoftRefLRUPolicyMSPerMB, and doesn't have access to the prospective new value, since the constraint function isn't passing it. I see that the Check helper is being used both here and for MaxHeapSize constraint function. I think the helper needs to be called with *both* values, and not refer to the current values at all. The SoftRefXXX checker would call Check with the argument value and the current value of MaxHeapSize. The MaxHeapSize checker would call Check with the current value of SoftRefXXX and the argument value. Otherwise, updates that validate the value before performing the assignment will be using the old value for validation, rather than checking the new value as intended. This also brings up an interesting limitation of the present mechanism. If two options are related in some way, both need to have constraint checking functions to ensure the relationship remains valid after initial option checking. But this means that the initial option checking will check the relationship twice, and if there is a problem it will be reported twice. I don't have any easy suggestions for how to improve on this situation though. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.hpp 1854 range(0, MarkStackSizeMax) \ Does this actually work? I'm not sure when the range values are evaluated. I suspect this wouldn't work properly in the face of later updates to MarkStackSizeMax. ------------------------------------------------------------------------------ From kirk at kodewerk.com Wed Aug 19 22:20:10 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 19 Aug 2015 18:20:10 -0400 Subject: race condition in GC logs In-Reply-To: <55D32774.2090903@oracle.com> References: <9E79C717-7C53-49F5-AD0F-C003A03F11E5@kodewerk.com> <55D30D50.8060302@oracle.com> <55D32774.2090903@oracle.com> Message-ID: Hi Bengt, Thanks for filing. I really didn?t consider this a bug but it seems reasonable to add clarity in the log. ? Kirk > On Aug 18, 2015, at 8:39 AM, Bengt Rutisson wrote: > > > > On 2015-08-18 12:47, Bengt Rutisson wrote: >> >> Hi Kirk, >> >> On 2015-08-18 12:31, Kirk Pepperdine wrote: >>> Hi all, >>> >>> I found this.. in a few logs. Before I started trolling the source trying to sort out what the second PhantomReferences count was, I pinged Charlie and asked him. He suggested it was a (concurrency??) bug witnessed only once by someone else. I?ve now seen it in several logs where the numbers reported are different. Sorry for being lazy for not trolling the code before asking but is this a bug? >> >> The second ref count is for cleaner references. They used to be treated the same way as phantom references, but a recent improvement was to separate the handling of the cleaners to after all phantom references have been handled. So, the first count is the "real" phantom references and the second count is the cleaner references. >> >> It's confusing logging, I agree. >> >> This came in with this fix: >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2194fdf3fbd9 >> >> since this adds one more call to preclean_discovered_reflist(), which is the method that prints the refs count. > > Thomas was nice and created a bug report for this :) > > Additional number of processed references printed with -XX:+PrintReferenceGC after JDK-8047125 > https://bugs.openjdk.java.net/browse/JDK-8133818 > > Bengt > >> >> Thanks, >> Bengt >> >>> >>> Regards, >>> Kirk >>> >>> Java HotSpot(TM) 64-Bit Server VM (25.51-b03) for linux-amd64 JRE (1.8.0_51-b16), built on Jun 8 2015 19:28:07 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8) >>> Memory: 4k page, physical 9570132k(9340292k free), swap 4095996k(4095996k free) >>> CommandLine flags: -XX:+AggressiveOpts -XX:G1HeapRegionSize=16777216 -XX:InitialHeapSize=3221225472 -XX:InitiatingHeapOccupancyPercent=75 -XX:+ManagementServer -XX:MaxGCPauseMillis=250 -XX:MaxHeapSize=3221225472 -XX:+ParallelRefProcEnabled -XX:+PerfDisableSharedMem -XX:+PrintAdaptiveSizePolicy -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC -XX:+UseLargePages >>> 0.198: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion amount: 3221225472 bytes, attempted expansion amount: 3221225472 bytes] >>> 2015-08-11T08:23:02.219+0200: 7.630: [GC pause (G1 Evacuation Pause) (young) >>> Desired survivor size 16777216 bytes, new threshold 15 (max 15) >>> 7.631: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 0, predicted base time: 10.00 ms, remaining time: 240.00 ms, target pause time: 250.00 ms] >>> 7.631: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 9 regions, survivors: 0 regions, predicted young region time: 3626.58 ms] >>> 7.631: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 9 regions, survivors: 0 regions, old: 0 regions, predicted pause time: 3636.58 ms, target pause time: 250.00 ms] >>> 7.642: [SoftReference, 0 refs, 0.0006965 secs]7.643: [WeakReference, 40 refs, 0.0003039 secs]7.643: [FinalReference, 3477 refs, 0.0036191 secs]7.647: [PhantomReference, 0 refs, 0 refs, 0.0006649 secs]7.647: [JNI Weak Reference, 0.0000119 secs], 0.0173298 secs] >> > From sangheon.kim at oracle.com Wed Aug 19 22:58:04 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 19 Aug 2015 15:58:04 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> Message-ID: <55D509FC.3040307@oracle.com> Hi Kim, Thank you for reviewing this. On 08/19/2015 02:59 PM, Kim Barrett wrote: > On Aug 19, 2015, at 12:25 AM, sangheon.kim wrote: >> Hi all, >> >> Please review this patch for command-line validation for GC flags. >> This includes adding ranges and implementing constraint functions for GC flags. >> >> [?] >> CR: https://bugs.openjdk.java.net/browse/JDK-8078555 >> Webrev: http://cr.openjdk.java.net/~sangheki/8078555/webrev.00/ >> Testing: JPRT, UTE(vm.quick-pcl), tests at test/runtime/CommandLine and local tests[1]. > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/g1_globals.hpp > 87 product(size_t, G1SATBBufferSize, 1*K, \ > 88 "Number of entries in an SATB log buffer.") \ > 89 range(1, max_uintx) \ > > Shouldn't that be max_size_t? Oh, wait; we don't have that. Maybe we > should. It would be nice to have. Let me handle from follow up CR. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 583 static bool set_fp_numeric_flag(char* name, char* value, Flag::Flags origin) { > 584 errno = 0; > 585 double v = strtod(value, NULL); > 586 if (errno == ERANGE) { > 587 return false; > 588 } > > You and Dmitry already discussed checking the endptr. Good catch, > Dmitry. > > I suggest returning false for any non-zero errno value. Okay, I will change to (errno != 0). > > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 722 #define NUMBER_RANGE "[0123456789eE+]" > > Missing "-" for negative exponents. This definition is used for below decimal point. So we don't need '-' here. Currently we can reach strtod function above with '-1.1'. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 48 static Flag::Error ParallelGCThreadsAndCMSWorkQueueDrainThreshold(bool verbose) { > 61 Flag::Error ParallelGCThreadsConstraintFunc(uint value, bool verbose) { > 90 Flag::Error ConcGCThreadsConstraintFunc(uint value, bool verbose) { > > These are associated with collectors that are excluded when > INCLUDE_ALL_GCS is false. The bodies of these should be conditionally > included based on that macro, and they should just return > Flag::SUCCESS when the macro is false. Okay. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 142 Flag::Error OldPLABSizeConstraintFunc(size_t value, bool verbose) { > 143 if (UseConcMarkSweepGC) { > > The UseConcMarkSweepGC clause should be conditionalized out if > INCLUDE_ALL_GCS is false. > > Peeking ahead, it looks like there are quite a few constraint > functions that should be similarly conditionalized. Okay. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 183 static Flag::Error CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(bool verbose) { > ... > 196 Flag::Error SoftRefLRUPolicyMSPerMBConstraintFunc(intx value, bool verbose) { > 197 return CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(verbose); > 198 } > > This doesn't look right. The Check helper function is using the > current value of SoftRefLRUPolicyMSPerMB, and doesn't have access to > the prospective new value, since the constraint function isn't passing > it. > > I see that the Check helper is being used both here and for > MaxHeapSize constraint function. I think the helper needs to be > called with *both* values, and not refer to the current values at > all. The SoftRefXXX checker would call Check with the argument value > and the current value of MaxHeapSize. The MaxHeapSize checker would > call Check with the current value of SoftRefXXX and the argument > value. Oh, right. I will fix this. > > Otherwise, updates that validate the value before performing the > assignment will be using the old value for validation, rather than > checking the new value as intended. > > This also brings up an interesting limitation of the present > mechanism. If two options are related in some way, both need to have > constraint checking functions to ensure the relationship remains valid > after initial option checking. But this means that the initial option > checking will check the relationship twice, and if there is a problem > it will be reported twice. I don't have any easy suggestions for how > to improve on this situation though. Right. This is current limitation. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.hpp > 1854 range(0, MarkStackSizeMax) \ > > Does this actually work? I'm not sure when the range values are > evaluated. I suspect this wouldn't work properly in the face of later > updates to MarkStackSizeMax. Correct. I will change their order to be 'MarkStackSizeMax' first. I will send next version of webrev soon. Thanks, Sangheon > > ------------------------------------------------------------------------------ > From david.holmes at oracle.com Thu Aug 20 04:57:38 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Aug 2015 14:57:38 +1000 Subject: Need some help: 8133646: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <55D4D0FF.6000806@oracle.com> References: <55D2A10F.6010408@oracle.com> <55D4CFB3.7040701@oracle.com> <55D4D0FF.6000806@oracle.com> Message-ID: <55D55E42.7040609@oracle.com> Thanks Vladimir. Once I can reproduce the issue I will add in the diagnostics. David On 20/08/2015 4:54 AM, Vladimir Kozlov wrote: > Additional check: > > Label L1, L2, L3; > __ cmpptr(r15_thread, thread); > __ jcc(Assembler::equal, L1); > __ stop("StubRoutines::call_stub: r15_thread is corrupted"); > __ bind(L1); > __ get_thread(rbx); > __ cmpptr(r15_thread, thread); > __ jcc(Assembler::equal, L2); > __ stop("StubRoutines::call_stub: r15_thread is modified by call"); > __ bind(L2); > __ cmpptr(r15_thread, rbx); > __ jcc(Assembler::equal, L3); > __ stop("StubRoutines::call_stub: threads must correspond"); > __ bind(L3); > > Vladimir > > On 8/19/15 11:49 AM, Vladimir Kozlov wrote: >> First, there copy-paste problem in verification code, jcc after bind is >> not needed: >> >> > 375 __ jcc(Assembler::equal, L); >> > 376 __ bind(S); >> > 377 __ jcc(Assembler::equal, L); >> >> Yes, the code assumes that get_thread(rbx); returns correct value and >> will not modify r15. r15 is save-on-entry so the C code should save it. >> >> Is it possible that Sun's C++ compiler has a bug? So that _thr_current >> has wrong value? Or does not save r15? >> >> To make sure that it is the cause of problem I would suggest to modify >> verification code as next: >> >> Label L1, L2; >> __ cmpptr(r15_thread, thread); >> __ jcc(Assembler::equal, L1); >> __ stop("StubRoutines::call_stub: r15_thread is corrupted"); >> __ bind(L1); >> __ get_thread(rbx); >> __ cmpptr(r15_thread, rbx); >> __ jcc(Assembler::equal, L2); >> __ stop("StubRoutines::call_stub: threads must correspond"); >> __ bind(L2); >> >> >> Thanks, >> Vladimir >> >> On 8/17/15 8:05 PM, David Holmes wrote: >>> Hi Compiler and x86_64 code experts, :) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 >>> >>> There's a chance this failure is related to my recent changes under >>> 8130212: >>> >>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10 >>> >>> Given the failing debug code: >>> >>> 367 #ifdef ASSERT >>> 368 // verify that threads correspond >>> 369 { >>> 370 Label L, S; >>> 371 __ cmpptr(r15_thread, thread); >>> 372 __ jcc(Assembler::notEqual, S); >>> 373 __ get_thread(rbx); >>> 374 __ cmpptr(r15_thread, rbx); >>> 375 __ jcc(Assembler::equal, L); >>> 376 __ bind(S); >>> 377 __ jcc(Assembler::equal, L); >>> 378 __ stop("StubRoutines::call_stub: threads must correspond"); >>> 379 __ bind(L); >>> 380 } >>> 381 #endif >>> >>> and given the definition of get_thread: >>> >>> // This is simply a call to ThreadLocalStorage::thread() >>> void MacroAssembler::get_thread(Register thread) { >>> if (thread != rax) { >>> push(rax); >>> } >>> push(rdi); >>> push(rsi); >>> push(rdx); >>> push(rcx); >>> push(r8); >>> push(r9); >>> push(r10); >>> push(r11); >>> >>> call(RuntimeAddress(CAST_FROM_FN_PTR(address, >>> ThreadLocalStorage::thread))); >>> >>> pop(r11); >>> pop(r10); >>> pop(r9); >>> pop(r8); >>> pop(rcx); >>> pop(rdx); >>> pop(rsi); >>> pop(rdi); >>> >>> if (thread != rax) { >>> movl(thread, rax); >>> pop(rax); >>> } >>> } >>> >>> where ThreadLocalStorage::thread() is simply: >>> >>> inline Thread* ThreadLocalStorage::thread() { >>> return _thr_current; >>> } >>> >>> and _thr_current is a compiler-defined thread-local variable: >>> >>> static __thread Thread * _thr_current; >>> >>> Can anyone see anything that might cause an issue? I was wondering >>> whether I have to verify that r15 is preserved by the actual >>> thread-local access? IIUC normally the get_thread slow-path would be >>> used to set r15_thread and so we wouldn't notice if it got trashed under >>> some circumstances. It obviously doesn't always get trashed because the >>> bug has only been seen to occur once. And of course the failure could be >>> completely incidental to my changes. :) >>> >>> Thanks, >>> David From christoph.langer at sap.com Thu Aug 20 06:19:01 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 20 Aug 2015 06:19:01 +0000 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: <55D4F59B.6020807@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> <55AD0339.2060606@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338ED1655@DEWDFEMB12B.global.corp.sap> <55D494A9.8060804@oracle.com> <55D4F59B.6020807@oracle.com> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338EF0DE6@DEWDFEMB12B.global.corp.sap> Hi Dan, that's great. Thanks for sponsoring. Best regards Christoph -----Original Message----- From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Mittwoch, 19. August 2015 23:31 To: Langer, Christoph; Gerald Thornbrugh; Volker Simonis Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions > Yes, I will sponsor the change. I'll also run it through our > internal testing infrastructure prior to committing. My "JPRT -testset hotspot" job went just fine and now I've submitted the bits for an Aurora Adhoc "RT-SVC Nightly tests" run. I'll keep an eye on the testing and let folks know the results. Here's my current commit message: 8130910: hsperfdata file is created in wrong directory and not cleaned up if /tmp/hsperfdata_ has wrong permissions Summary: Add check for fchir() failure and disable shared PerfMemory in that case. Reviewed-by: dcubed, simonis, gthornbr Contributed-by: christoph.langer at sap.com Everybody good with it (modulo any new reviewers)? Dan From sangheon.kim at oracle.com Thu Aug 20 06:31:17 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 19 Aug 2015 23:31:17 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55D509FC.3040307@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> Message-ID: <55D57435.6050604@oracle.com> Hi Kim and Dmitry, Here's new webrev. http://cr.openjdk.java.net/~sangheki/8078555/webrev.01/ http://cr.openjdk.java.net/~sangheki/8078555/webrev.01_to_00/ And let me correct one of my answers to Kim. >> I see that the Check helper is being used both here and for >> MaxHeapSize constraint function. I think the helper needs to be >> called with **both** values, and not refer to the current values at >> all. The SoftRefXXX checker would call Check with the argument value >> and the current value of MaxHeapSize. The MaxHeapSize checker would >> call Check with the current value of SoftRefXXX and the argument >> value. >> Oh, right. >> I will fix this. > Oh, right. > I will fix this. As you already mentioned, validation check can be done for only one flag at a time. So helper function can't called with BOTH new values. But I think there's no problem with this as eventually these new values will be compared. e.g. flagA = 10(default 5), flagB = 20(default 5) and constraint: flagA * flagB <= 150 constraint functions will be called for their declared order. when constraint function for flagA is called: 10(new flagA) * 5(default flagB) -> PASS when constraint function for flagB is called: 10(new flagA) * 20(new flagB) -> FAIL. Thanks, Sangheon On 08/19/2015 03:58 PM, sangheon.kim wrote: > Hi Kim, > > Thank you for reviewing this. > > On 08/19/2015 02:59 PM, Kim Barrett wrote: >> On Aug 19, 2015, at 12:25 AM, sangheon.kim >> wrote: >>> Hi all, >>> >>> Please review this patch for command-line validation for GC flags. >>> This includes adding ranges and implementing constraint functions >>> for GC flags. >>> >>> [?] >>> CR: https://bugs.openjdk.java.net/browse/JDK-8078555 >>> Webrev: http://cr.openjdk.java.net/~sangheki/8078555/webrev.00/ >>> Testing: JPRT, UTE(vm.quick-pcl), tests at test/runtime/CommandLine >>> and local tests[1]. >> ------------------------------------------------------------------------------ >> >> src/share/vm/gc/g1/g1_globals.hpp >> 87 product(size_t, G1SATBBufferSize, >> 1*K, \ >> 88 "Number of entries in an SATB log >> buffer.") \ >> 89 range(1, >> max_uintx) \ >> >> Shouldn't that be max_size_t? Oh, wait; we don't have that. Maybe we >> should. > It would be nice to have. > Let me handle from follow up CR. > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/runtime/arguments.cpp >> 583 static bool set_fp_numeric_flag(char* name, char* value, >> Flag::Flags origin) { >> 584 errno = 0; >> 585 double v = strtod(value, NULL); >> 586 if (errno == ERANGE) { >> 587 return false; >> 588 } >> >> You and Dmitry already discussed checking the endptr. Good catch, >> Dmitry. >> >> I suggest returning false for any non-zero errno value. > Okay, I will change to (errno != 0). > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/runtime/arguments.cpp >> 722 #define NUMBER_RANGE "[0123456789eE+]" >> >> Missing "-" for negative exponents. > This definition is used for below decimal point. So we don't need '-' > here. > Currently we can reach strtod function above with '-1.1'. > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >> 48 static Flag::Error >> ParallelGCThreadsAndCMSWorkQueueDrainThreshold(bool verbose) { >> 61 Flag::Error ParallelGCThreadsConstraintFunc(uint value, bool >> verbose) { >> 90 Flag::Error ConcGCThreadsConstraintFunc(uint value, bool >> verbose) { >> >> These are associated with collectors that are excluded when >> INCLUDE_ALL_GCS is false. The bodies of these should be conditionally >> included based on that macro, and they should just return >> Flag::SUCCESS when the macro is false. > Okay. > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >> 142 Flag::Error OldPLABSizeConstraintFunc(size_t value, bool >> verbose) { >> 143 if (UseConcMarkSweepGC) { >> >> The UseConcMarkSweepGC clause should be conditionalized out if >> INCLUDE_ALL_GCS is false. >> >> Peeking ahead, it looks like there are quite a few constraint >> functions that should be similarly conditionalized. > Okay. > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >> 183 static Flag::Error >> CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(bool verbose) { >> ... >> 196 Flag::Error SoftRefLRUPolicyMSPerMBConstraintFunc(intx value, >> bool verbose) { >> 197 return CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(verbose); >> 198 } >> >> This doesn't look right. The Check helper function is using the >> current value of SoftRefLRUPolicyMSPerMB, and doesn't have access to >> the prospective new value, since the constraint function isn't passing >> it. >> >> I see that the Check helper is being used both here and for >> MaxHeapSize constraint function. I think the helper needs to be >> called with *both* values, and not refer to the current values at >> all. The SoftRefXXX checker would call Check with the argument value >> and the current value of MaxHeapSize. The MaxHeapSize checker would >> call Check with the current value of SoftRefXXX and the argument >> value. > Oh, right. > I will fix this. > >> >> Otherwise, updates that validate the value before performing the >> assignment will be using the old value for validation, rather than >> checking the new value as intended. >> >> This also brings up an interesting limitation of the present >> mechanism. If two options are related in some way, both need to have >> constraint checking functions to ensure the relationship remains valid >> after initial option checking. But this means that the initial option >> checking will check the relationship twice, and if there is a problem >> it will be reported twice. I don't have any easy suggestions for how >> to improve on this situation though. > Right. > This is current limitation. > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/runtime/globals.hpp >> 1854 range(0, >> MarkStackSizeMax) \ >> >> Does this actually work? I'm not sure when the range values are >> evaluated. I suspect this wouldn't work properly in the face of later >> updates to MarkStackSizeMax. > Correct. > I will change their order to be 'MarkStackSizeMax' first. > > I will send next version of webrev soon. > > Thanks, > Sangheon > >> >> ------------------------------------------------------------------------------ >> >> > From sangheon.kim at oracle.com Thu Aug 20 08:18:02 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 20 Aug 2015 01:18:02 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55D57435.6050604@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> Message-ID: <55D58D3A.8080800@oracle.com> Hi Kim, >> src/share/vm/runtime/arguments.cpp >> 722 #define NUMBER_RANGE "[0123456789eE+]" >> >> Missing "-" for negative exponents. > This definition is used for below decimal point. So we don't need '-' > here. > Currently we can reach strtod function above with '-1.1'. Sorry, I misunderstood your point! You are right to parse negative exponential we need '-' too. e.g. '1.1e_*-*_308'. This is also reflected to webrev.01. Thanks, Sangheon On 08/19/2015 11:31 PM, sangheon.kim wrote: > Hi Kim and Dmitry, > > Here's new webrev. > > http://cr.openjdk.java.net/~sangheki/8078555/webrev.01/ > http://cr.openjdk.java.net/~sangheki/8078555/webrev.01_to_00/ > > And let me correct one of my answers to Kim. >>> I see that the Check helper is being used both here and for >>> MaxHeapSize constraint function. I think the helper needs to be >>> called with **both** values, and not refer to the current values at >>> all. The SoftRefXXX checker would call Check with the argument value >>> and the current value of MaxHeapSize. The MaxHeapSize checker would >>> call Check with the current value of SoftRefXXX and the argument >>> value. >>> Oh, right. >>> I will fix this. >> Oh, right. >> I will fix this. > As you already mentioned, validation check can be done for only one > flag at a time. > So helper function can't called with BOTH new values. > But I think there's no problem with this as eventually these new > values will be compared. > e.g. flagA = 10(default 5), flagB = 20(default 5) and constraint: > flagA * flagB <= 150 > constraint functions will be called for their declared order. > when constraint function for flagA is called: 10(new flagA) * > 5(default flagB) -> PASS > when constraint function for flagB is called: 10(new flagA) * 20(new > flagB) -> FAIL. > > Thanks, > Sangheon > > > On 08/19/2015 03:58 PM, sangheon.kim wrote: >> Hi Kim, >> >> Thank you for reviewing this. >> >> On 08/19/2015 02:59 PM, Kim Barrett wrote: >>> On Aug 19, 2015, at 12:25 AM, sangheon.kim >>> wrote: >>>> Hi all, >>>> >>>> Please review this patch for command-line validation for GC flags. >>>> This includes adding ranges and implementing constraint functions >>>> for GC flags. >>>> >>>> [?] >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8078555 >>>> Webrev: http://cr.openjdk.java.net/~sangheki/8078555/webrev.00/ >>>> Testing: JPRT, UTE(vm.quick-pcl), tests at test/runtime/CommandLine >>>> and local tests[1]. >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/gc/g1/g1_globals.hpp >>> 87 product(size_t, G1SATBBufferSize, >>> 1*K, \ >>> 88 "Number of entries in an SATB log >>> buffer.") \ >>> 89 range(1, >>> max_uintx) \ >>> >>> Shouldn't that be max_size_t? Oh, wait; we don't have that. Maybe we >>> should. >> It would be nice to have. >> Let me handle from follow up CR. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/arguments.cpp >>> 583 static bool set_fp_numeric_flag(char* name, char* value, >>> Flag::Flags origin) { >>> 584 errno = 0; >>> 585 double v = strtod(value, NULL); >>> 586 if (errno == ERANGE) { >>> 587 return false; >>> 588 } >>> >>> You and Dmitry already discussed checking the endptr. Good catch, >>> Dmitry. >>> >>> I suggest returning false for any non-zero errno value. >> Okay, I will change to (errno != 0). >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/arguments.cpp >>> 722 #define NUMBER_RANGE "[0123456789eE+]" >>> >>> Missing "-" for negative exponents. >> This definition is used for below decimal point. So we don't need '-' >> here. >> Currently we can reach strtod function above with '-1.1'. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> 48 static Flag::Error >>> ParallelGCThreadsAndCMSWorkQueueDrainThreshold(bool verbose) { >>> 61 Flag::Error ParallelGCThreadsConstraintFunc(uint value, bool >>> verbose) { >>> 90 Flag::Error ConcGCThreadsConstraintFunc(uint value, bool >>> verbose) { >>> >>> These are associated with collectors that are excluded when >>> INCLUDE_ALL_GCS is false. The bodies of these should be conditionally >>> included based on that macro, and they should just return >>> Flag::SUCCESS when the macro is false. >> Okay. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> 142 Flag::Error OldPLABSizeConstraintFunc(size_t value, bool >>> verbose) { >>> 143 if (UseConcMarkSweepGC) { >>> >>> The UseConcMarkSweepGC clause should be conditionalized out if >>> INCLUDE_ALL_GCS is false. >>> >>> Peeking ahead, it looks like there are quite a few constraint >>> functions that should be similarly conditionalized. >> Okay. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> 183 static Flag::Error >>> CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(bool verbose) { >>> ... >>> 196 Flag::Error SoftRefLRUPolicyMSPerMBConstraintFunc(intx value, >>> bool verbose) { >>> 197 return CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(verbose); >>> 198 } >>> >>> This doesn't look right. The Check helper function is using the >>> current value of SoftRefLRUPolicyMSPerMB, and doesn't have access to >>> the prospective new value, since the constraint function isn't passing >>> it. >>> >>> I see that the Check helper is being used both here and for >>> MaxHeapSize constraint function. I think the helper needs to be >>> called with *both* values, and not refer to the current values at >>> all. The SoftRefXXX checker would call Check with the argument value >>> and the current value of MaxHeapSize. The MaxHeapSize checker would >>> call Check with the current value of SoftRefXXX and the argument >>> value. >> Oh, right. >> I will fix this. >> >>> >>> Otherwise, updates that validate the value before performing the >>> assignment will be using the old value for validation, rather than >>> checking the new value as intended. >>> >>> This also brings up an interesting limitation of the present >>> mechanism. If two options are related in some way, both need to have >>> constraint checking functions to ensure the relationship remains valid >>> after initial option checking. But this means that the initial option >>> checking will check the relationship twice, and if there is a problem >>> it will be reported twice. I don't have any easy suggestions for how >>> to improve on this situation though. >> Right. >> This is current limitation. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/globals.hpp >>> 1854 range(0, >>> MarkStackSizeMax) \ >>> >>> Does this actually work? I'm not sure when the range values are >>> evaluated. I suspect this wouldn't work properly in the face of later >>> updates to MarkStackSizeMax. >> Correct. >> I will change their order to be 'MarkStackSizeMax' first. >> >> I will send next version of webrev soon. >> >> Thanks, >> Sangheon >> >>> >>> ------------------------------------------------------------------------------ >>> >>> >> > From gerard.ziemski at oracle.com Thu Aug 20 16:17:33 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Thu, 20 Aug 2015 11:17:33 -0500 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55D57435.6050604@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> Message-ID: <55D5FD9D.2030307@oracle.com> hi Sangheon, Is it me or is the patch.01 out of sync with the actual webrev.01? I tried applying the patch from your webrev.01, but the resulting code produced does not match that of the webrev itself - the src/share/vm/runtime/commandLineFlagConstraintsGC.cpp in particular does not match. Would you kindly double check that and fix it if it's not just me? cheers On 08/20/2015 01:31 AM, sangheon.kim wrote: > Hi Kim and Dmitry, > > Here's new webrev. > > http://cr.openjdk.java.net/~sangheki/8078555/webrev.01/ > http://cr.openjdk.java.net/~sangheki/8078555/webrev.01_to_00/ > > And let me correct one of my answers to Kim. >>> I see that the Check helper is being used both here and for >>> MaxHeapSize constraint function. I think the helper needs to be >>> called with **both** values, and not refer to the current values at >>> all. The SoftRefXXX checker would call Check with the argument value >>> and the current value of MaxHeapSize. The MaxHeapSize checker would >>> call Check with the current value of SoftRefXXX and the argument >>> value. >>> Oh, right. >>> I will fix this. >> Oh, right. >> I will fix this. > As you already mentioned, validation check can be done for only one flag > at a time. > So helper function can't called with BOTH new values. > But I think there's no problem with this as eventually these new values > will be compared. > e.g. flagA = 10(default 5), flagB = 20(default 5) and constraint: flagA > * flagB <= 150 > constraint functions will be called for their declared order. > when constraint function for flagA is called: 10(new flagA) * 5(default > flagB) -> PASS > when constraint function for flagB is called: 10(new flagA) * 20(new > flagB) -> FAIL. > > Thanks, > Sangheon > > > On 08/19/2015 03:58 PM, sangheon.kim wrote: >> Hi Kim, >> >> Thank you for reviewing this. >> >> On 08/19/2015 02:59 PM, Kim Barrett wrote: >>> On Aug 19, 2015, at 12:25 AM, sangheon.kim >>> wrote: >>>> Hi all, >>>> >>>> Please review this patch for command-line validation for GC flags. >>>> This includes adding ranges and implementing constraint functions >>>> for GC flags. >>>> >>>> [?] >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8078555 >>>> Webrev: http://cr.openjdk.java.net/~sangheki/8078555/webrev.00/ >>>> Testing: JPRT, UTE(vm.quick-pcl), tests at test/runtime/CommandLine >>>> and local tests[1]. >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/gc/g1/g1_globals.hpp >>> 87 product(size_t, G1SATBBufferSize, >>> 1*K, \ >>> 88 "Number of entries in an SATB log >>> buffer.") \ >>> 89 range(1, >>> max_uintx) \ >>> >>> Shouldn't that be max_size_t? Oh, wait; we don't have that. Maybe we >>> should. >> It would be nice to have. >> Let me handle from follow up CR. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/arguments.cpp >>> 583 static bool set_fp_numeric_flag(char* name, char* value, >>> Flag::Flags origin) { >>> 584 errno = 0; >>> 585 double v = strtod(value, NULL); >>> 586 if (errno == ERANGE) { >>> 587 return false; >>> 588 } >>> >>> You and Dmitry already discussed checking the endptr. Good catch, >>> Dmitry. >>> >>> I suggest returning false for any non-zero errno value. >> Okay, I will change to (errno != 0). >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/arguments.cpp >>> 722 #define NUMBER_RANGE "[0123456789eE+]" >>> >>> Missing "-" for negative exponents. >> This definition is used for below decimal point. So we don't need '-' >> here. >> Currently we can reach strtod function above with '-1.1'. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> 48 static Flag::Error >>> ParallelGCThreadsAndCMSWorkQueueDrainThreshold(bool verbose) { >>> 61 Flag::Error ParallelGCThreadsConstraintFunc(uint value, bool >>> verbose) { >>> 90 Flag::Error ConcGCThreadsConstraintFunc(uint value, bool >>> verbose) { >>> >>> These are associated with collectors that are excluded when >>> INCLUDE_ALL_GCS is false. The bodies of these should be conditionally >>> included based on that macro, and they should just return >>> Flag::SUCCESS when the macro is false. >> Okay. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> 142 Flag::Error OldPLABSizeConstraintFunc(size_t value, bool >>> verbose) { >>> 143 if (UseConcMarkSweepGC) { >>> >>> The UseConcMarkSweepGC clause should be conditionalized out if >>> INCLUDE_ALL_GCS is false. >>> >>> Peeking ahead, it looks like there are quite a few constraint >>> functions that should be similarly conditionalized. >> Okay. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> 183 static Flag::Error >>> CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(bool verbose) { >>> ... >>> 196 Flag::Error SoftRefLRUPolicyMSPerMBConstraintFunc(intx value, >>> bool verbose) { >>> 197 return CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(verbose); >>> 198 } >>> >>> This doesn't look right. The Check helper function is using the >>> current value of SoftRefLRUPolicyMSPerMB, and doesn't have access to >>> the prospective new value, since the constraint function isn't passing >>> it. >>> >>> I see that the Check helper is being used both here and for >>> MaxHeapSize constraint function. I think the helper needs to be >>> called with *both* values, and not refer to the current values at >>> all. The SoftRefXXX checker would call Check with the argument value >>> and the current value of MaxHeapSize. The MaxHeapSize checker would >>> call Check with the current value of SoftRefXXX and the argument >>> value. >> Oh, right. >> I will fix this. >> >>> >>> Otherwise, updates that validate the value before performing the >>> assignment will be using the old value for validation, rather than >>> checking the new value as intended. >>> >>> This also brings up an interesting limitation of the present >>> mechanism. If two options are related in some way, both need to have >>> constraint checking functions to ensure the relationship remains valid >>> after initial option checking. But this means that the initial option >>> checking will check the relationship twice, and if there is a problem >>> it will be reported twice. I don't have any easy suggestions for how >>> to improve on this situation though. >> Right. >> This is current limitation. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/globals.hpp >>> 1854 range(0, >>> MarkStackSizeMax) \ >>> >>> Does this actually work? I'm not sure when the range values are >>> evaluated. I suspect this wouldn't work properly in the face of later >>> updates to MarkStackSizeMax. >> Correct. >> I will change their order to be 'MarkStackSizeMax' first. >> >> I will send next version of webrev soon. >> >> Thanks, >> Sangheon >> >>> >>> ------------------------------------------------------------------------------ >>> >>> >> > > > From sangheon.kim at oracle.com Thu Aug 20 16:42:28 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 20 Aug 2015 09:42:28 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55D5FD9D.2030307@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D5FD9D.2030307@oracle.com> Message-ID: <55D60374.90204@oracle.com> Hi Gerard, You are right. Now I fixed both webrev.01 and webrev.01_to_00. Thank you for finding them! Sangheon On 08/20/2015 09:17 AM, gerard ziemski wrote: > hi Sangheon, > > Is it me or is the patch.01 out of sync with the actual webrev.01? > > I tried applying the patch from your webrev.01, but the resulting code > produced does not match that of the webrev itself - the > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp in particular > does not match. > > Would you kindly double check that and fix it if it's not just me? > > > cheers > > On 08/20/2015 01:31 AM, sangheon.kim wrote: >> Hi Kim and Dmitry, >> >> Here's new webrev. >> >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.01/ >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.01_to_00/ >> >> And let me correct one of my answers to Kim. >>>> I see that the Check helper is being used both here and for >>>> MaxHeapSize constraint function. I think the helper needs to be >>>> called with **both** values, and not refer to the current values at >>>> all. The SoftRefXXX checker would call Check with the argument value >>>> and the current value of MaxHeapSize. The MaxHeapSize checker would >>>> call Check with the current value of SoftRefXXX and the argument >>>> value. >>>> Oh, right. >>>> I will fix this. >>> Oh, right. >>> I will fix this. >> As you already mentioned, validation check can be done for only one flag >> at a time. >> So helper function can't called with BOTH new values. >> But I think there's no problem with this as eventually these new values >> will be compared. >> e.g. flagA = 10(default 5), flagB = 20(default 5) and constraint: flagA >> * flagB <= 150 >> constraint functions will be called for their declared order. >> when constraint function for flagA is called: 10(new flagA) * 5(default >> flagB) -> PASS >> when constraint function for flagB is called: 10(new flagA) * 20(new >> flagB) -> FAIL. >> >> Thanks, >> Sangheon >> >> >> On 08/19/2015 03:58 PM, sangheon.kim wrote: >>> Hi Kim, >>> >>> Thank you for reviewing this. >>> >>> On 08/19/2015 02:59 PM, Kim Barrett wrote: >>>> On Aug 19, 2015, at 12:25 AM, sangheon.kim >>>> wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch for command-line validation for GC flags. >>>>> This includes adding ranges and implementing constraint functions >>>>> for GC flags. >>>>> >>>>> [?] >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8078555 >>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8078555/webrev.00/ >>>>> Testing: JPRT, UTE(vm.quick-pcl), tests at test/runtime/CommandLine >>>>> and local tests[1]. >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/gc/g1/g1_globals.hpp >>>> 87 product(size_t, G1SATBBufferSize, >>>> 1*K, \ >>>> 88 "Number of entries in an SATB log >>>> buffer.") \ >>>> 89 range(1, >>>> max_uintx) \ >>>> >>>> Shouldn't that be max_size_t? Oh, wait; we don't have that. Maybe we >>>> should. >>> It would be nice to have. >>> Let me handle from follow up CR. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/arguments.cpp >>>> 583 static bool set_fp_numeric_flag(char* name, char* value, >>>> Flag::Flags origin) { >>>> 584 errno = 0; >>>> 585 double v = strtod(value, NULL); >>>> 586 if (errno == ERANGE) { >>>> 587 return false; >>>> 588 } >>>> >>>> You and Dmitry already discussed checking the endptr. Good catch, >>>> Dmitry. >>>> >>>> I suggest returning false for any non-zero errno value. >>> Okay, I will change to (errno != 0). >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/arguments.cpp >>>> 722 #define NUMBER_RANGE "[0123456789eE+]" >>>> >>>> Missing "-" for negative exponents. >>> This definition is used for below decimal point. So we don't need '-' >>> here. >>> Currently we can reach strtod function above with '-1.1'. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>>> 48 static Flag::Error >>>> ParallelGCThreadsAndCMSWorkQueueDrainThreshold(bool verbose) { >>>> 61 Flag::Error ParallelGCThreadsConstraintFunc(uint value, bool >>>> verbose) { >>>> 90 Flag::Error ConcGCThreadsConstraintFunc(uint value, bool >>>> verbose) { >>>> >>>> These are associated with collectors that are excluded when >>>> INCLUDE_ALL_GCS is false. The bodies of these should be conditionally >>>> included based on that macro, and they should just return >>>> Flag::SUCCESS when the macro is false. >>> Okay. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>>> 142 Flag::Error OldPLABSizeConstraintFunc(size_t value, bool >>>> verbose) { >>>> 143 if (UseConcMarkSweepGC) { >>>> >>>> The UseConcMarkSweepGC clause should be conditionalized out if >>>> INCLUDE_ALL_GCS is false. >>>> >>>> Peeking ahead, it looks like there are quite a few constraint >>>> functions that should be similarly conditionalized. >>> Okay. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>>> 183 static Flag::Error >>>> CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(bool verbose) { >>>> ... >>>> 196 Flag::Error SoftRefLRUPolicyMSPerMBConstraintFunc(intx value, >>>> bool verbose) { >>>> 197 return CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(verbose); >>>> 198 } >>>> >>>> This doesn't look right. The Check helper function is using the >>>> current value of SoftRefLRUPolicyMSPerMB, and doesn't have access to >>>> the prospective new value, since the constraint function isn't passing >>>> it. >>>> >>>> I see that the Check helper is being used both here and for >>>> MaxHeapSize constraint function. I think the helper needs to be >>>> called with *both* values, and not refer to the current values at >>>> all. The SoftRefXXX checker would call Check with the argument value >>>> and the current value of MaxHeapSize. The MaxHeapSize checker would >>>> call Check with the current value of SoftRefXXX and the argument >>>> value. >>> Oh, right. >>> I will fix this. >>> >>>> >>>> Otherwise, updates that validate the value before performing the >>>> assignment will be using the old value for validation, rather than >>>> checking the new value as intended. >>>> >>>> This also brings up an interesting limitation of the present >>>> mechanism. If two options are related in some way, both need to have >>>> constraint checking functions to ensure the relationship remains valid >>>> after initial option checking. But this means that the initial option >>>> checking will check the relationship twice, and if there is a problem >>>> it will be reported twice. I don't have any easy suggestions for how >>>> to improve on this situation though. >>> Right. >>> This is current limitation. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/globals.hpp >>>> 1854 range(0, >>>> MarkStackSizeMax) \ >>>> >>>> Does this actually work? I'm not sure when the range values are >>>> evaluated. I suspect this wouldn't work properly in the face of later >>>> updates to MarkStackSizeMax. >>> Correct. >>> I will change their order to be 'MarkStackSizeMax' first. >>> >>> I will send next version of webrev soon. >>> >>> Thanks, >>> Sangheon >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> >>> >> >> >> From daniel.daugherty at oracle.com Thu Aug 20 18:05:21 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 20 Aug 2015 12:05:21 -0600 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338EF0DE6@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> <55AD0339.2060606@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338ED1655@DEWDFEMB12B.global.corp.sap> <55D494A9.8060804@oracle.com> <55D4F59B.6020807@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338EF0DE6@DEWDFEMB12B.global.corp.sap> Message-ID: <55D616E1.3040305@oracle.com> No regressions in the testing. Submitting the JPRT job now. Should be done in a couple of hours... Dan On 8/20/15 12:19 AM, Langer, Christoph wrote: > Hi Dan, > > that's great. Thanks for sponsoring. > > Best regards > Christoph > > -----Original Message----- > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Mittwoch, 19. August 2015 23:31 > To: Langer, Christoph; Gerald Thornbrugh; Volker Simonis > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions > > > Yes, I will sponsor the change. I'll also run it through our > > internal testing infrastructure prior to committing. > > My "JPRT -testset hotspot" job went just fine and now I've submitted > the bits for an Aurora Adhoc "RT-SVC Nightly tests" run. I'll keep > an eye on the testing and let folks know the results. > > Here's my current commit message: > > 8130910: hsperfdata file is created in wrong directory and not cleaned > up if /tmp/hsperfdata_ has wrong permissions > Summary: Add check for fchir() failure and disable shared PerfMemory in > that case. > Reviewed-by: dcubed, simonis, gthornbr > Contributed-by: christoph.langer at sap.com > > Everybody good with it (modulo any new reviewers)? > > Dan From gerard.ziemski at oracle.com Thu Aug 20 18:57:23 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Thu, 20 Aug 2015 13:57:23 -0500 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55D57435.6050604@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> Message-ID: <55D62313.2090306@oracle.com> hi Sangheon, I won't pretend to understand all the GC flags and their meanings, but I tried my best and it looks good, but I have a few small nitpicks: #1 ---------------------------------- src/share/vm/runtime/arguments.cpp 587 if (errno != 0 || *end != 0) { Would be nice to have extra brackets? 587 if ((errno != 0) || (*end != 0)) { #2 ----------------------------------------------------- src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 77 if (UseConcMarkSweepGC && (value > max_jint / 10)) { Can we perhaps add some extra brackets around math operations, like? 77 if (UseConcMarkSweepGC && (value > (max_jint / 10))) { similarly lines 81, 191, 363, 367, 533, 567, 571, 580 #3 ----------------------------------------------------- src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 442 "MaxGCPauseMillis (" UINTX_FORMAT ") must be less than ? 443 "GCPauseIntervalMillis (" UINTX_FORMAT ")\n?, Technically it should be: 442 "MaxGCPauseMillis (" UINTX_FORMAT ") must be ? 443 "less than GCPauseIntervalMillis (" UINTX_FORMAT ")\n", similarly other messages where "must be? should end the first?s message text line for consistency. #4 ----------------------------------------------------- src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 363 if (UseConcMarkSweepGC && (value > max_jint / ParallelGCThreads)) { Should we perhaps cast up? 363 if (UseConcMarkSweepGC && (value > ((uintx)max_jint / (uintx)ParallelGCThreads))) { And also change: 366 "less than or equal to ergonomic maximum (" INT32_FORMAT ")\n", 367 value, max_jint / ParallelGCThreads); to: 366 "less than or equal to ergonomic maximum (" UINTX_FORMAT ")\n", 367 value, ((uintx)max_jint / (uintx)ParallelGCThreads)); #5 I have noticed that none of the flags used "AtParse" in their constraints and I am again starting to think that "AtParse" is not quite what we want, but I will get into that later with my own check-in ;-) cheers On 08/20/2015 01:31 AM, sangheon.kim wrote: > Hi Kim and Dmitry, > > Here's new webrev. > > http://cr.openjdk.java.net/~sangheki/8078555/webrev.01/ > http://cr.openjdk.java.net/~sangheki/8078555/webrev.01_to_00/ > > And let me correct one of my answers to Kim. >>> I see that the Check helper is being used both here and for >>> MaxHeapSize constraint function. I think the helper needs to be >>> called with **both** values, and not refer to the current values at >>> all. The SoftRefXXX checker would call Check with the argument value >>> and the current value of MaxHeapSize. The MaxHeapSize checker would >>> call Check with the current value of SoftRefXXX and the argument >>> value. >>> Oh, right. >>> I will fix this. >> Oh, right. >> I will fix this. > As you already mentioned, validation check can be done for only one flag > at a time. > So helper function can't called with BOTH new values. > But I think there's no problem with this as eventually these new values > will be compared. > e.g. flagA = 10(default 5), flagB = 20(default 5) and constraint: flagA > * flagB <= 150 > constraint functions will be called for their declared order. > when constraint function for flagA is called: 10(new flagA) * 5(default > flagB) -> PASS > when constraint function for flagB is called: 10(new flagA) * 20(new > flagB) -> FAIL. > > Thanks, > Sangheon > > > On 08/19/2015 03:58 PM, sangheon.kim wrote: >> Hi Kim, >> >> Thank you for reviewing this. >> >> On 08/19/2015 02:59 PM, Kim Barrett wrote: >>> On Aug 19, 2015, at 12:25 AM, sangheon.kim >>> wrote: >>>> Hi all, >>>> >>>> Please review this patch for command-line validation for GC flags. >>>> This includes adding ranges and implementing constraint functions >>>> for GC flags. >>>> >>>> [?] >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8078555 >>>> Webrev: http://cr.openjdk.java.net/~sangheki/8078555/webrev.00/ >>>> Testing: JPRT, UTE(vm.quick-pcl), tests at test/runtime/CommandLine >>>> and local tests[1]. >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/gc/g1/g1_globals.hpp >>> 87 product(size_t, G1SATBBufferSize, >>> 1*K, \ >>> 88 "Number of entries in an SATB log >>> buffer.") \ >>> 89 range(1, >>> max_uintx) \ >>> >>> Shouldn't that be max_size_t? Oh, wait; we don't have that. Maybe we >>> should. >> It would be nice to have. >> Let me handle from follow up CR. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/arguments.cpp >>> 583 static bool set_fp_numeric_flag(char* name, char* value, >>> Flag::Flags origin) { >>> 584 errno = 0; >>> 585 double v = strtod(value, NULL); >>> 586 if (errno == ERANGE) { >>> 587 return false; >>> 588 } >>> >>> You and Dmitry already discussed checking the endptr. Good catch, >>> Dmitry. >>> >>> I suggest returning false for any non-zero errno value. >> Okay, I will change to (errno != 0). >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/arguments.cpp >>> 722 #define NUMBER_RANGE "[0123456789eE+]" >>> >>> Missing "-" for negative exponents. >> This definition is used for below decimal point. So we don't need '-' >> here. >> Currently we can reach strtod function above with '-1.1'. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> 48 static Flag::Error >>> ParallelGCThreadsAndCMSWorkQueueDrainThreshold(bool verbose) { >>> 61 Flag::Error ParallelGCThreadsConstraintFunc(uint value, bool >>> verbose) { >>> 90 Flag::Error ConcGCThreadsConstraintFunc(uint value, bool >>> verbose) { >>> >>> These are associated with collectors that are excluded when >>> INCLUDE_ALL_GCS is false. The bodies of these should be conditionally >>> included based on that macro, and they should just return >>> Flag::SUCCESS when the macro is false. >> Okay. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> 142 Flag::Error OldPLABSizeConstraintFunc(size_t value, bool >>> verbose) { >>> 143 if (UseConcMarkSweepGC) { >>> >>> The UseConcMarkSweepGC clause should be conditionalized out if >>> INCLUDE_ALL_GCS is false. >>> >>> Peeking ahead, it looks like there are quite a few constraint >>> functions that should be similarly conditionalized. >> Okay. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> 183 static Flag::Error >>> CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(bool verbose) { >>> ... >>> 196 Flag::Error SoftRefLRUPolicyMSPerMBConstraintFunc(intx value, >>> bool verbose) { >>> 197 return CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(verbose); >>> 198 } >>> >>> This doesn't look right. The Check helper function is using the >>> current value of SoftRefLRUPolicyMSPerMB, and doesn't have access to >>> the prospective new value, since the constraint function isn't passing >>> it. >>> >>> I see that the Check helper is being used both here and for >>> MaxHeapSize constraint function. I think the helper needs to be >>> called with *both* values, and not refer to the current values at >>> all. The SoftRefXXX checker would call Check with the argument value >>> and the current value of MaxHeapSize. The MaxHeapSize checker would >>> call Check with the current value of SoftRefXXX and the argument >>> value. >> Oh, right. >> I will fix this. >> >>> >>> Otherwise, updates that validate the value before performing the >>> assignment will be using the old value for validation, rather than >>> checking the new value as intended. >>> >>> This also brings up an interesting limitation of the present >>> mechanism. If two options are related in some way, both need to have >>> constraint checking functions to ensure the relationship remains valid >>> after initial option checking. But this means that the initial option >>> checking will check the relationship twice, and if there is a problem >>> it will be reported twice. I don't have any easy suggestions for how >>> to improve on this situation though. >> Right. >> This is current limitation. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/globals.hpp >>> 1854 range(0, >>> MarkStackSizeMax) \ >>> >>> Does this actually work? I'm not sure when the range values are >>> evaluated. I suspect this wouldn't work properly in the face of later >>> updates to MarkStackSizeMax. >> Correct. >> I will change their order to be 'MarkStackSizeMax' first. >> >> I will send next version of webrev soon. >> >> Thanks, >> Sangheon >> >>> >>> ------------------------------------------------------------------------------ >>> >>> >> > > > From sangheon.kim at oracle.com Fri Aug 21 06:32:12 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 20 Aug 2015 23:32:12 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55D62313.2090306@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> Message-ID: <55D6C5EC.9070202@oracle.com> Hi Gerard, Thank you for reviewing this. On 08/20/2015 11:57 AM, gerard ziemski wrote: > hi Sangheon, > > I won't pretend to understand all the GC flags and their meanings, but > I tried my best and it looks good, but I have a few small nitpicks: > > > #1 > ---------------------------------- > src/share/vm/runtime/arguments.cpp > > 587 if (errno != 0 || *end != 0) { > > Would be nice to have extra brackets? > > 587 if ((errno != 0) || (*end != 0)) { Okay, I fixed as you suggested. > > > #2 > ----------------------------------------------------- > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > > 77 if (UseConcMarkSweepGC && (value > max_jint / 10)) { > > Can we perhaps add some extra brackets around math operations, like? > > 77 if (UseConcMarkSweepGC && (value > (max_jint / 10))) { > > similarly lines 81, 191, 363, 367, 533, 567, 571, 580 Done. > > > #3 > ----------------------------------------------------- > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > > 442 "MaxGCPauseMillis (" UINTX_FORMAT ") > must be less than ? > 443 "GCPauseIntervalMillis (" UINTX_FORMAT > ")\n?, > > Technically it should be: > > 442 "MaxGCPauseMillis (" UINTX_FORMAT ") > must be ? > 443 "less than GCPauseIntervalMillis (" > UINTX_FORMAT ")\n", > > similarly other messages where "must be? should end the first?s > message text line for consistency. Yes, this makes better look. Done. > > > #4 > ----------------------------------------------------- > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > > 363 if (UseConcMarkSweepGC && (value > max_jint / ParallelGCThreads)) { > > Should we perhaps cast up? > > 363 if (UseConcMarkSweepGC && (value > ((uintx)max_jint / > (uintx)ParallelGCThreads))) { > > And also change: > > 366 "less than or equal to ergonomic > maximum (" INT32_FORMAT ")\n", > 367 value, max_jint / ParallelGCThreads); > > to: > > 366 "less than or equal to ergonomic > maximum (" UINTX_FORMAT ")\n", > 367 value, ((uintx)max_jint / > (uintx)ParallelGCThreads)); Done. > > > #5 > > I have noticed that none of the flags used "AtParse" in their > constraints and I am again starting to think that "AtParse" is not > quite what we want, but I will get into that later with my own > check-in ;-) Hmm. Okay, let's talk more from your review. :) http://cr.openjdk.java.net/~sangheki/8078555/webrev.02/ http://cr.openjdk.java.net/~sangheki/8078555/webrev.02_to_01 Thanks, Sangheon > > > cheers > > On 08/20/2015 01:31 AM, sangheon.kim wrote: >> Hi Kim and Dmitry, >> >> Here's new webrev. >> >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.01/ >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.01_to_00/ >> >> And let me correct one of my answers to Kim. >>>> I see that the Check helper is being used both here and for >>>> MaxHeapSize constraint function. I think the helper needs to be >>>> called with **both** values, and not refer to the current values at >>>> all. The SoftRefXXX checker would call Check with the argument value >>>> and the current value of MaxHeapSize. The MaxHeapSize checker would >>>> call Check with the current value of SoftRefXXX and the argument >>>> value. >>>> Oh, right. >>>> I will fix this. >>> Oh, right. >>> I will fix this. >> As you already mentioned, validation check can be done for only one flag >> at a time. >> So helper function can't called with BOTH new values. >> But I think there's no problem with this as eventually these new values >> will be compared. >> e.g. flagA = 10(default 5), flagB = 20(default 5) and constraint: flagA >> * flagB <= 150 >> constraint functions will be called for their declared order. >> when constraint function for flagA is called: 10(new flagA) * 5(default >> flagB) -> PASS >> when constraint function for flagB is called: 10(new flagA) * 20(new >> flagB) -> FAIL. >> >> Thanks, >> Sangheon >> >> >> On 08/19/2015 03:58 PM, sangheon.kim wrote: >>> Hi Kim, >>> >>> Thank you for reviewing this. >>> >>> On 08/19/2015 02:59 PM, Kim Barrett wrote: >>>> On Aug 19, 2015, at 12:25 AM, sangheon.kim >>>> wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch for command-line validation for GC flags. >>>>> This includes adding ranges and implementing constraint functions >>>>> for GC flags. >>>>> >>>>> [?] >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8078555 >>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8078555/webrev.00/ >>>>> Testing: JPRT, UTE(vm.quick-pcl), tests at test/runtime/CommandLine >>>>> and local tests[1]. >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/gc/g1/g1_globals.hpp >>>> 87 product(size_t, G1SATBBufferSize, >>>> 1*K, \ >>>> 88 "Number of entries in an SATB log >>>> buffer.") \ >>>> 89 range(1, >>>> max_uintx) \ >>>> >>>> Shouldn't that be max_size_t? Oh, wait; we don't have that. Maybe we >>>> should. >>> It would be nice to have. >>> Let me handle from follow up CR. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/arguments.cpp >>>> 583 static bool set_fp_numeric_flag(char* name, char* value, >>>> Flag::Flags origin) { >>>> 584 errno = 0; >>>> 585 double v = strtod(value, NULL); >>>> 586 if (errno == ERANGE) { >>>> 587 return false; >>>> 588 } >>>> >>>> You and Dmitry already discussed checking the endptr. Good catch, >>>> Dmitry. >>>> >>>> I suggest returning false for any non-zero errno value. >>> Okay, I will change to (errno != 0). >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/arguments.cpp >>>> 722 #define NUMBER_RANGE "[0123456789eE+]" >>>> >>>> Missing "-" for negative exponents. >>> This definition is used for below decimal point. So we don't need '-' >>> here. >>> Currently we can reach strtod function above with '-1.1'. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>>> 48 static Flag::Error >>>> ParallelGCThreadsAndCMSWorkQueueDrainThreshold(bool verbose) { >>>> 61 Flag::Error ParallelGCThreadsConstraintFunc(uint value, bool >>>> verbose) { >>>> 90 Flag::Error ConcGCThreadsConstraintFunc(uint value, bool >>>> verbose) { >>>> >>>> These are associated with collectors that are excluded when >>>> INCLUDE_ALL_GCS is false. The bodies of these should be conditionally >>>> included based on that macro, and they should just return >>>> Flag::SUCCESS when the macro is false. >>> Okay. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>>> 142 Flag::Error OldPLABSizeConstraintFunc(size_t value, bool >>>> verbose) { >>>> 143 if (UseConcMarkSweepGC) { >>>> >>>> The UseConcMarkSweepGC clause should be conditionalized out if >>>> INCLUDE_ALL_GCS is false. >>>> >>>> Peeking ahead, it looks like there are quite a few constraint >>>> functions that should be similarly conditionalized. >>> Okay. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>>> 183 static Flag::Error >>>> CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(bool verbose) { >>>> ... >>>> 196 Flag::Error SoftRefLRUPolicyMSPerMBConstraintFunc(intx value, >>>> bool verbose) { >>>> 197 return CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(verbose); >>>> 198 } >>>> >>>> This doesn't look right. The Check helper function is using the >>>> current value of SoftRefLRUPolicyMSPerMB, and doesn't have access to >>>> the prospective new value, since the constraint function isn't passing >>>> it. >>>> >>>> I see that the Check helper is being used both here and for >>>> MaxHeapSize constraint function. I think the helper needs to be >>>> called with *both* values, and not refer to the current values at >>>> all. The SoftRefXXX checker would call Check with the argument value >>>> and the current value of MaxHeapSize. The MaxHeapSize checker would >>>> call Check with the current value of SoftRefXXX and the argument >>>> value. >>> Oh, right. >>> I will fix this. >>> >>>> >>>> Otherwise, updates that validate the value before performing the >>>> assignment will be using the old value for validation, rather than >>>> checking the new value as intended. >>>> >>>> This also brings up an interesting limitation of the present >>>> mechanism. If two options are related in some way, both need to have >>>> constraint checking functions to ensure the relationship remains valid >>>> after initial option checking. But this means that the initial option >>>> checking will check the relationship twice, and if there is a problem >>>> it will be reported twice. I don't have any easy suggestions for how >>>> to improve on this situation though. >>> Right. >>> This is current limitation. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/globals.hpp >>>> 1854 range(0, >>>> MarkStackSizeMax) \ >>>> >>>> Does this actually work? I'm not sure when the range values are >>>> evaluated. I suspect this wouldn't work properly in the face of later >>>> updates to MarkStackSizeMax. >>> Correct. >>> I will change their order to be 'MarkStackSizeMax' first. >>> >>> I will send next version of webrev soon. >>> >>> Thanks, >>> Sangheon >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> >>> >> >> >> From kim.barrett at oracle.com Fri Aug 21 21:34:14 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 21 Aug 2015 17:34:14 -0400 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55D6C5EC.9070202@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> Message-ID: <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> Comments below are for: http://cr.openjdk.java.net/~sangheki/8078555/webrev.01/ http://cr.openjdk.java.net/~sangheki/8078555/webrev.01_to_00/ No additional comments for: http://cr.openjdk.java.net/~sangheki/8078555/webrev.02/ http://cr.openjdk.java.net/~sangheki/8078555/webrev.02_to_01 ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp General comment - all the conditionalizations on INCLUDE_ALL_GCS seriously uglifies this code. We should be conditionalizing for that, but I wonder if there's a better way. Most of the conditionalizations are for effectively the entire constraint function. Rather than that, could we arrange for the relevant constraint functions to be unreferenced when not needed, and then just have a block conditionalization around the whole set of functions? One way to do this might be to add a NOT_INCLUDE_ALL_GCS macro and wrap the "constraint(...)" forms with that new macro where appropriate. This probably should be addressed under a separate RFE though. If I'd realized how ugly it would make the code, I probably wouldn't have suggested doing the conditionalization now. But now that it's here, I'm not sure its worth backing out. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 63 Flag::Error ParallelGCThreadsConstraintFunc(uint value, bool verbose) { [removed the following] 71 // G1, CMS and Parallel GC modes disallows ParallelGCThreads=0 72 if ((UseG1GC || UseConcMarkSweepGC || UseParallelGC) && (value == 0)) { 73 CommandLineError::print(verbose, "ParallelGCThreads cannot be zero\n"); 74 return Flag::VIOLATES_CONSTRAINT; 75 } Why was this removed? ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp #if INCLUDE_ALL_GCS 271 Flag::Error G1RSetRegionEntriesConstraintFunc(intx value, bool verbose) { 287 Flag::Error G1RSetSparseRegionEntriesConstraintFunc(intx value, bool verbose) { 303 Flag::Error G1YoungSurvRateNumRegionsSummaryConstraintFunc(intx value, bool verbose) { 317 Flag::Error G1HeapRegionSizeConstraintFunc(size_t value, bool verbose) { 332 Flag::Error G1NewSizePercentConstraintFunc(uintx value, bool verbose) { 346 Flag::Error G1MaxNewSizePercentConstraintFunc(uintx value, bool verbose) { #endif [pre-existing] Shouldn't these G1-specific constraint functions (whose options are declared in g1_globals.hpp) be declared and defined in G1-specific files? This should be handled as a separate issue. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.hpp 1857 product(size_t, MarkStackSize, NOT_LP64(32*K) LP64_ONLY(4*M), \ 1858 "Size of marking stack") \ 1859 range(0, MarkStackSizeMax) \ I raised an issue here previously, and re-ordering the declarations in the macros doesn't address the problem. The value of MarkStackSizeMax will be read at the time of the call to CommandLineFlagRangeList::init(). This is prior to any command line option processing for a value for MarkStackSizeMax. So the range won't reflect command line options. Option values cannot be used in the computation of ranges. Dependencies between options need to be handled via constraint functions. ------------------------------------------------------------------------------ From sangheon.kim at oracle.com Mon Aug 24 15:36:14 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 24 Aug 2015 08:36:14 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> Message-ID: <55DB39EE.9050102@oracle.com> Hi Kim, On 08/21/2015 02:34 PM, Kim Barrett wrote: > Comments below are for: > > http://cr.openjdk.java.net/~sangheki/8078555/webrev.01/ > http://cr.openjdk.java.net/~sangheki/8078555/webrev.01_to_00/ > > No additional comments for: > > http://cr.openjdk.java.net/~sangheki/8078555/webrev.02/ > http://cr.openjdk.java.net/~sangheki/8078555/webrev.02_to_01 > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > > General comment - all the conditionalizations on INCLUDE_ALL_GCS > seriously uglifies this code. We should be conditionalizing for that, > but I wonder if there's a better way. Most of the conditionalizations > are for effectively the entire constraint function. Rather than that, > could we arrange for the relevant constraint functions to be > unreferenced when not needed, and then just have a block > conditionalization around the whole set of functions? One way to do > this might be to add a NOT_INCLUDE_ALL_GCS macro and wrap the > "constraint(...)" forms with that new macro where appropriate. > > This probably should be addressed under a separate RFE though. > > If I'd realized how ugly it would make the code, I probably wouldn't > have suggested doing the conditionalization now. But now that it's > here, I'm not sure its worth backing out. I agree with you. How about leave as is and handle from a separate RFE? > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 63 Flag::Error ParallelGCThreadsConstraintFunc(uint value, bool verbose) { > [removed the following] > 71 // G1, CMS and Parallel GC modes disallows ParallelGCThreads=0 > 72 if ((UseG1GC || UseConcMarkSweepGC || UseParallelGC) && (value == 0)) { > 73 CommandLineError::print(verbose, "ParallelGCThreads cannot be zero\n"); > 74 return Flag::VIOLATES_CONSTRAINT; > 75 } > > Why was this removed? Disallowing ParallelGCThreads=0 is already checked before constraint check. (By Arguments::set_parnew_gc_flags(), set_parallel_gc_flags() and set_g1_gc_flags() ) > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > #if INCLUDE_ALL_GCS > 271 Flag::Error G1RSetRegionEntriesConstraintFunc(intx value, bool verbose) { > 287 Flag::Error G1RSetSparseRegionEntriesConstraintFunc(intx value, bool verbose) { > 303 Flag::Error G1YoungSurvRateNumRegionsSummaryConstraintFunc(intx value, bool verbose) { > 317 Flag::Error G1HeapRegionSizeConstraintFunc(size_t value, bool verbose) { > 332 Flag::Error G1NewSizePercentConstraintFunc(uintx value, bool verbose) { > 346 Flag::Error G1MaxNewSizePercentConstraintFunc(uintx value, bool verbose) { > #endif > > [pre-existing] > > Shouldn't these G1-specific constraint functions (whose options are > declared in g1_globals.hpp) be declared and defined in G1-specific > files? > > This should be handled as a separate issue. I'm not sure whether is it worth or not. But as I don't have a strong opinion on this, let me add this at follow-up issue. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.hpp > 1857 product(size_t, MarkStackSize, NOT_LP64(32*K) LP64_ONLY(4*M), \ > 1858 "Size of marking stack") \ > 1859 range(0, MarkStackSizeMax) \ > > I raised an issue here previously, and re-ordering the declarations in > the macros doesn't address the problem. > > The value of MarkStackSizeMax will be read at the time of the call to > CommandLineFlagRangeList::init(). This is prior to any command line > option processing for a value for MarkStackSizeMax. So the range > won't reflect command line options. > > Option values cannot be used in the computation of ranges. > Dependencies between options need to be handled via constraint > functions. You are right. I should think carefully when you left a comment before. Fixed. Let me send a webrev after hearing your opinion. Thanks, Sangheon > > ------------------------------------------------------------------------------ > > From derek.white at oracle.com Mon Aug 24 17:27:38 2015 From: derek.white at oracle.com (Derek White) Date: Mon, 24 Aug 2015 13:27:38 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55CA4E0E.2070503@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> <55B1119D.4030802@oracle.com> <55C41C20.90208@oracle.com> <55C83C5C.60702@oracle.com> <55C8D456.9030006@oracle.com> <5A08C1CB-58F9-4193-802F-767EE11F4D2B@oracle.com> <55CA4E0E.2070503@oracle.com> Message-ID: <55DB540A.4010804@oracle.com> RFR: This version incorporates Dave and Karen's suggestions to automatically handle deprecated-> obsolete transitions. This is implemented with a unified table of deprecated and obsolete options ("special_jvm_flags"). Karen also suggested (offline) that it would be good to verify that obsolete and expired options no longer have a "globals" variable defined. This revision adds debug checking of the special_jvm_flags table to check a bunch of constraints, such as deprecated version must be < obsolete version < expired version, and checks for duplicate table entries as well as looking for left-over "globals" variables. http://cr.openjdk.java.net/~drwhite/8066821/webrev.08 https://bugs.openjdk.java.net/browse/JDK-8066821 I also have a webrev of webrev.07 vs. webrev.08: http://cr.openjdk.java.net/~drwhite/8066821/webrev.7.v.8 Thanks for looking! - Derek On 8/11/15 3:33 PM, Derek White wrote: > Hi Karen, > > As much as I want to get this RFE over and out, I see your and David > H's point :-) > > I'll spin another rev... > > - Derek > > On 8/10/15 6:07 PM, Karen Kinnear wrote: >> Derek, >> >> Thank you for all of your work on this and responses to suggestions. >> >> I had a couple of questions/comments: >> >> I appreciate that you have created mechanisms to allow: >> 1. 2 step obsolete: obsolete_jvm_flags >> - step 1: obsolete: warn and ignore >> - step 2: expire >> - and I expect we will use this for most -XX flags, especially >> develop flags >> >> 2. 2 step deprecate: deprecated_jvm_flags >> - step 1: deprecate: warn and handle >> - step 2: expire >> >> I see this approach as useful for aliasing and for a few other flags, >> but not >> the common path. >> >> My concerns: >> >> With my understanding of how this is set up today, for the flags that >> are most exposed to >> customers, which would want the 3 step deprecation, it would be too >> easy for an engineer >> to add the flag to the deprecated_jvm_flags and forget to add it to >> the obsolete_jvm_flags, >> as the comments under deprecated_jvm_flags suggest. And we don't >> want folks to have >> to go back and do a second step later for flags if they could do it >> all at once. >> >> I think it would be confusing to add a flag to both >> deprecated_jvm_flags and obsolete_jvm_flags >> at the same time, since then the expiration release is not clear. >> >> 3. For product non-XX, commercial and common -XX flags what I would >> like to see is >> a three-step table which I would have called deprecated_jvm_flags, >> which did >> - step 1: deprecate: warn and handle >> - step 2: obsolete: warn and ignore >> - step 3: expire: unrecognized error >> >> Would you be willing to add a table like that which is the >> recommended approach >> for external supported flags? >> >> So one way to do this would be to change the current >> deprecated_jvm_flags to have >> three fields, so that the usual path would be to have three releases >> listed, and >> for aliased flags leave the middle field with the undefined version. >> >> Another approach would be to have the three fields and have it used by >> all three approaches, just fill in the steps that are appropriate. >> >> minor comment: >> >> >> 1. arguments.hpp >> Could you possibly change the comments from "and has expired (should >> be ignored)" to >> "and has expired (unrecognized error)" >> >> unless what you mean really is should be ignored, which is not the >> same expired. >> >> thanks, >> Karen >> >> >> >> On Aug 10, 2015, at 12:41 PM, Derek White wrote: >> >>> Thanks David! >>> >>> - Derek >>> >>> On 8/10/15 1:53 AM, David Holmes wrote: >>>> Hi Derek, >>>> >>>> I don't have any further comments. >>>> >>>> Thanks, >>>> David >>>> >>>> On 7/08/2015 12:46 PM, Derek White wrote: >>>>> Another RFR. >>>>> >>>>> I've updated based on David and Kim's last comments. >>>>> >>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>>> >>>>> I also have a webrev of webrev.06 vs. webrev.07: >>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/ >>>>> >>>>> [This webrev is confused about CommandLineOptionTest.java. I >>>>> double-checked with a recursive diff and the only differences are in >>>>> arguments.cpp and arguments.hpp.] >>>>> >>>>> Thanks for looking! >>>>> >>>>> - Derek >>>>> .... > From kim.barrett at oracle.com Mon Aug 24 17:51:38 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 24 Aug 2015 13:51:38 -0400 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DB39EE.9050102@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> Message-ID: <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> On Aug 24, 2015, at 11:36 AM, sangheon.kim wrote: > > Hi Kim, > > On 08/21/2015 02:34 PM, Kim Barrett wrote: >> Comments below are for: >> >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.01/ >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.01_to_00/ >> >> No additional comments for: >> >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.02/ >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.02_to_01 >> >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >> >> General comment - all the conditionalizations on INCLUDE_ALL_GCS >> seriously uglifies this code. We should be conditionalizing for that, >> but I wonder if there's a better way. Most of the conditionalizations >> are for effectively the entire constraint function. Rather than that, >> could we arrange for the relevant constraint functions to be >> unreferenced when not needed, and then just have a block >> conditionalization around the whole set of functions? One way to do >> this might be to add a NOT_INCLUDE_ALL_GCS macro and wrap the >> "constraint(...)" forms with that new macro where appropriate. >> >> This probably should be addressed under a separate RFE though. >> >> If I'd realized how ugly it would make the code, I probably wouldn't >> have suggested doing the conditionalization now. But now that it's >> here, I'm not sure its worth backing out. > I agree with you. > How about leave as is and handle from a separate RFE? OK. > >> >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >> 63 Flag::Error ParallelGCThreadsConstraintFunc(uint value, bool verbose) { >> [removed the following] >> 71 // G1, CMS and Parallel GC modes disallows ParallelGCThreads=0 >> 72 if ((UseG1GC || UseConcMarkSweepGC || UseParallelGC) && (value == 0)) { >> 73 CommandLineError::print(verbose, "ParallelGCThreads cannot be zero\n"); >> 74 return Flag::VIOLATES_CONSTRAINT; >> 75 } >> >> Why was this removed? > Disallowing ParallelGCThreads=0 is already checked before constraint check. > (By Arguments::set_parnew_gc_flags(), set_parallel_gc_flags() and set_g1_gc_flags() ) Ah, missed that. OK. > >> >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >> #if INCLUDE_ALL_GCS >> 271 Flag::Error G1RSetRegionEntriesConstraintFunc(intx value, bool verbose) { >> 287 Flag::Error G1RSetSparseRegionEntriesConstraintFunc(intx value, bool verbose) { >> 303 Flag::Error G1YoungSurvRateNumRegionsSummaryConstraintFunc(intx value, bool verbose) { >> 317 Flag::Error G1HeapRegionSizeConstraintFunc(size_t value, bool verbose) { >> 332 Flag::Error G1NewSizePercentConstraintFunc(uintx value, bool verbose) { >> 346 Flag::Error G1MaxNewSizePercentConstraintFunc(uintx value, bool verbose) { >> #endif >> >> [pre-existing] >> >> Shouldn't these G1-specific constraint functions (whose options are >> declared in g1_globals.hpp) be declared and defined in G1-specific >> files? >> >> This should be handled as a separate issue. > I'm not sure whether is it worth or not. > But as I don't have a strong opinion on this, let me add this at follow-up issue. OK. > >> >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/globals.hpp >> 1857 product(size_t, MarkStackSize, NOT_LP64(32*K) LP64_ONLY(4*M), \ >> 1858 "Size of marking stack") \ >> 1859 range(0, MarkStackSizeMax) \ >> >> I raised an issue here previously, and re-ordering the declarations in >> the macros doesn't address the problem. >> >> The value of MarkStackSizeMax will be read at the time of the call to >> CommandLineFlagRangeList::init(). This is prior to any command line >> option processing for a value for MarkStackSizeMax. So the range >> won't reflect command line options. >> >> Option values cannot be used in the computation of ranges. >> Dependencies between options need to be handled via constraint >> functions. > You are right. > I should think carefully when you left a comment before. > Fixed. Good. > > Let me send a webrev after hearing your opinion. OK. From sangheon.kim at oracle.com Mon Aug 24 19:06:15 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 24 Aug 2015 12:06:15 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> Message-ID: <55DB6B27.40704@oracle.com> Hi Kim, Here's webrev.03 which includes your comment for MarkStackSize constraint function. http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ And all your comments will be managed by https://bugs.openjdk.java.net/browse/JDK-8134348 . Thanks, Sangheon On 08/24/2015 10:51 AM, Kim Barrett wrote: > On Aug 24, 2015, at 11:36 AM, sangheon.kim wrote: >> Hi Kim, >> >> On 08/21/2015 02:34 PM, Kim Barrett wrote: >>> Comments below are for: >>> >>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.01/ >>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.01_to_00/ >>> >>> No additional comments for: >>> >>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.02/ >>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.02_to_01 >>> >>> ------------------------------------------------------------------------------ >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> >>> General comment - all the conditionalizations on INCLUDE_ALL_GCS >>> seriously uglifies this code. We should be conditionalizing for that, >>> but I wonder if there's a better way. Most of the conditionalizations >>> are for effectively the entire constraint function. Rather than that, >>> could we arrange for the relevant constraint functions to be >>> unreferenced when not needed, and then just have a block >>> conditionalization around the whole set of functions? One way to do >>> this might be to add a NOT_INCLUDE_ALL_GCS macro and wrap the >>> "constraint(...)" forms with that new macro where appropriate. >>> >>> This probably should be addressed under a separate RFE though. >>> >>> If I'd realized how ugly it would make the code, I probably wouldn't >>> have suggested doing the conditionalization now. But now that it's >>> here, I'm not sure its worth backing out. >> I agree with you. >> How about leave as is and handle from a separate RFE? > OK. > >>> ------------------------------------------------------------------------------ >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> 63 Flag::Error ParallelGCThreadsConstraintFunc(uint value, bool verbose) { >>> [removed the following] >>> 71 // G1, CMS and Parallel GC modes disallows ParallelGCThreads=0 >>> 72 if ((UseG1GC || UseConcMarkSweepGC || UseParallelGC) && (value == 0)) { >>> 73 CommandLineError::print(verbose, "ParallelGCThreads cannot be zero\n"); >>> 74 return Flag::VIOLATES_CONSTRAINT; >>> 75 } >>> >>> Why was this removed? >> Disallowing ParallelGCThreads=0 is already checked before constraint check. >> (By Arguments::set_parnew_gc_flags(), set_parallel_gc_flags() and set_g1_gc_flags() ) > Ah, missed that. OK. > >>> ------------------------------------------------------------------------------ >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >>> #if INCLUDE_ALL_GCS >>> 271 Flag::Error G1RSetRegionEntriesConstraintFunc(intx value, bool verbose) { >>> 287 Flag::Error G1RSetSparseRegionEntriesConstraintFunc(intx value, bool verbose) { >>> 303 Flag::Error G1YoungSurvRateNumRegionsSummaryConstraintFunc(intx value, bool verbose) { >>> 317 Flag::Error G1HeapRegionSizeConstraintFunc(size_t value, bool verbose) { >>> 332 Flag::Error G1NewSizePercentConstraintFunc(uintx value, bool verbose) { >>> 346 Flag::Error G1MaxNewSizePercentConstraintFunc(uintx value, bool verbose) { >>> #endif >>> >>> [pre-existing] >>> >>> Shouldn't these G1-specific constraint functions (whose options are >>> declared in g1_globals.hpp) be declared and defined in G1-specific >>> files? >>> >>> This should be handled as a separate issue. >> I'm not sure whether is it worth or not. >> But as I don't have a strong opinion on this, let me add this at follow-up issue. > OK. > >>> ------------------------------------------------------------------------------ >>> src/share/vm/runtime/globals.hpp >>> 1857 product(size_t, MarkStackSize, NOT_LP64(32*K) LP64_ONLY(4*M), \ >>> 1858 "Size of marking stack") \ >>> 1859 range(0, MarkStackSizeMax) \ >>> >>> I raised an issue here previously, and re-ordering the declarations in >>> the macros doesn't address the problem. >>> >>> The value of MarkStackSizeMax will be read at the time of the call to >>> CommandLineFlagRangeList::init(). This is prior to any command line >>> option processing for a value for MarkStackSizeMax. So the range >>> won't reflect command line options. >>> >>> Option values cannot be used in the computation of ranges. >>> Dependencies between options need to be handled via constraint >>> functions. >> You are right. >> I should think carefully when you left a comment before. >> Fixed. > Good. > >> Let me send a webrev after hearing your opinion. > OK. > From gerard.ziemski at oracle.com Mon Aug 24 20:53:00 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Mon, 24 Aug 2015 15:53:00 -0500 Subject: RFR 8134239(XS): compiler/arguments/CheckCICompilerCount.java still fails Message-ID: <55DB842C.2070909@oracle.com> Please review this trivial test change that updates CheckCICompilerCount test to match the constraints error message format, which changed before compiler/runtime repo sync took place with code that was still using the old format. References: webrev: http://cr.openjdk.java.net/~gziemski/8134239_rev0/ bugid: https://bugs.openjdk.java.net/browse/JDK-8134239 cheers From christian.tornqvist at oracle.com Mon Aug 24 20:59:58 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 24 Aug 2015 16:59:58 -0400 Subject: RFR 8134239(XS): compiler/arguments/CheckCICompilerCount.java still fails In-Reply-To: <55DB842C.2070909@oracle.com> References: <55DB842C.2070909@oracle.com> Message-ID: <011901d0deaf$d6471490$82d53db0$@oracle.com> Hi Gerard, Change looks good, thanks for fixing this. Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of gerard ziemski Sent: Monday, August 24, 2015 4:53 PM To: hotspot-dev at openjdk.java.net Developers Subject: RFR 8134239(XS): compiler/arguments/CheckCICompilerCount.java still fails Please review this trivial test change that updates CheckCICompilerCount test to match the constraints error message format, which changed before compiler/runtime repo sync took place with code that was still using the old format. References: webrev: http://cr.openjdk.java.net/~gziemski/8134239_rev0/ bugid: https://bugs.openjdk.java.net/browse/JDK-8134239 cheers From harold.seigel at oracle.com Mon Aug 24 21:02:30 2015 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 24 Aug 2015 17:02:30 -0400 Subject: RFR 8134239(XS): compiler/arguments/CheckCICompilerCount.java still fails In-Reply-To: <55DB842C.2070909@oracle.com> References: <55DB842C.2070909@oracle.com> Message-ID: <55DB8666.4000609@oracle.com> Hi Gerard, The change looks good. Thanks, Harold On 8/24/2015 4:53 PM, gerard ziemski wrote: > > Please review this trivial test change that updates > CheckCICompilerCount test to match the constraints error message > format, which changed before compiler/runtime repo sync took place > with code that was still using the old format. > > > References: > > webrev: http://cr.openjdk.java.net/~gziemski/8134239_rev0/ > bugid: https://bugs.openjdk.java.net/browse/JDK-8134239 > > > cheers From daniel.daugherty at oracle.com Mon Aug 24 21:08:24 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 24 Aug 2015 15:08:24 -0600 Subject: RFR 8134239(XS): compiler/arguments/CheckCICompilerCount.java still fails In-Reply-To: <55DB842C.2070909@oracle.com> References: <55DB842C.2070909@oracle.com> Message-ID: <55DB87C8.8070703@oracle.com> I'm confused. I thought this bug was fixed already. Did your previous fix get lost in a merge? Dan On 8/24/15 2:53 PM, gerard ziemski wrote: > > Please review this trivial test change that updates > CheckCICompilerCount test to match the constraints error message > format, which changed before compiler/runtime repo sync took place > with code that was still using the old format. > > > References: > > webrev: http://cr.openjdk.java.net/~gziemski/8134239_rev0/ > bugid: https://bugs.openjdk.java.net/browse/JDK-8134239 > > > cheers From gerard.ziemski at oracle.com Mon Aug 24 21:07:55 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Mon, 24 Aug 2015 16:07:55 -0500 Subject: RFR 8134239(XS): compiler/arguments/CheckCICompilerCount.java still fails In-Reply-To: <011901d0deaf$d6471490$82d53db0$@oracle.com> References: <55DB842C.2070909@oracle.com> <011901d0deaf$d6471490$82d53db0$@oracle.com> Message-ID: <55DB87AB.1000801@oracle.com> Thank you for the review! cheers On 08/24/2015 03:59 PM, Christian Tornqvist wrote: > Hi Gerard, > > Change looks good, thanks for fixing this. > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of gerard ziemski > Sent: Monday, August 24, 2015 4:53 PM > To: hotspot-dev at openjdk.java.net Developers > Subject: RFR 8134239(XS): compiler/arguments/CheckCICompilerCount.java still fails > > > Please review this trivial test change that updates CheckCICompilerCount test to match the constraints error message format, which changed before compiler/runtime repo sync took place with code that was still using the old format. > > > References: > > webrev: http://cr.openjdk.java.net/~gziemski/8134239_rev0/ > bugid: https://bugs.openjdk.java.net/browse/JDK-8134239 > > > cheers > > From gerard.ziemski at oracle.com Mon Aug 24 21:08:24 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Mon, 24 Aug 2015 16:08:24 -0500 Subject: RFR 8134239(XS): compiler/arguments/CheckCICompilerCount.java still fails In-Reply-To: <55DB8666.4000609@oracle.com> References: <55DB842C.2070909@oracle.com> <55DB8666.4000609@oracle.com> Message-ID: <55DB87C8.5030307@oracle.com> Thank you for the review! cheers On 08/24/2015 04:02 PM, harold seigel wrote: > Hi Gerard, > > The change looks good. > > Thanks, Harold > > On 8/24/2015 4:53 PM, gerard ziemski wrote: >> >> Please review this trivial test change that updates CheckCICompilerCount test to match the constraints error message >> format, which changed before compiler/runtime repo sync took place with code that was still using the old format. >> >> >> References: >> >> webrev: http://cr.openjdk.java.net/~gziemski/8134239_rev0/ >> bugid: https://bugs.openjdk.java.net/browse/JDK-8134239 >> >> >> cheers > > From gerard.ziemski at oracle.com Mon Aug 24 21:12:46 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Mon, 24 Aug 2015 16:12:46 -0500 Subject: RFR 8134239(XS): compiler/arguments/CheckCICompilerCount.java still fails In-Reply-To: <55DB87C8.8070703@oracle.com> References: <55DB842C.2070909@oracle.com> <55DB87C8.8070703@oracle.com> Message-ID: <55DB88CE.9060203@oracle.com> hi Dan, This is the same test, but a new test case, which compiler team added to this existing test, with their repo at the time using the old format. It's a bit confusing, but the issue is the timing of syncing of the compiler and runtime repos. cheers On 08/24/2015 04:08 PM, Daniel D. Daugherty wrote: > I'm confused. I thought this bug was fixed already. Did your > previous fix get lost in a merge? > > Dan > > > On 8/24/15 2:53 PM, gerard ziemski wrote: >> >> Please review this trivial test change that updates CheckCICompilerCount test to match the constraints error message >> format, which changed before compiler/runtime repo sync took place with code that was still using the old format. >> >> >> References: >> >> webrev: http://cr.openjdk.java.net/~gziemski/8134239_rev0/ >> bugid: https://bugs.openjdk.java.net/browse/JDK-8134239 >> >> >> cheers > > > From kim.barrett at oracle.com Mon Aug 24 21:16:08 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 24 Aug 2015 17:16:08 -0400 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DB6B27.40704@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> Message-ID: On Aug 24, 2015, at 3:06 PM, sangheon.kim wrote: > > Hi Kim, > > Here's webrev.03 which includes your comment for MarkStackSize constraint function. > > http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 > http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ > > And all your comments will be managed by https://bugs.openjdk.java.net/browse/JDK-8134348 . If the value of MarkStackSizeMax were changed later, there's nothing to verify MarkStackSize is still smaller. [This is related to my earlier comment about constraints between options being tested twice and failures reported twice.] Do we care in this case? Other than that, looks good. From daniel.daugherty at oracle.com Mon Aug 24 21:21:24 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 24 Aug 2015 15:21:24 -0600 Subject: RFR 8134239(XS): compiler/arguments/CheckCICompilerCount.java still fails In-Reply-To: <55DB88CE.9060203@oracle.com> References: <55DB842C.2070909@oracle.com> <55DB87C8.8070703@oracle.com> <55DB88CE.9060203@oracle.com> Message-ID: <55DB8AD4.3000201@oracle.com> Thanks for clarifying. Dan On 8/24/15 3:12 PM, gerard ziemski wrote: > hi Dan, > > This is the same test, but a new test case, which compiler team added > to this existing test, with their repo at the time using the old format. > > It's a bit confusing, but the issue is the timing of syncing of the > compiler and runtime repos. > > > cheers > > On 08/24/2015 04:08 PM, Daniel D. Daugherty wrote: >> I'm confused. I thought this bug was fixed already. Did your >> previous fix get lost in a merge? >> >> Dan >> >> >> On 8/24/15 2:53 PM, gerard ziemski wrote: >>> >>> Please review this trivial test change that updates >>> CheckCICompilerCount test to match the constraints error message >>> format, which changed before compiler/runtime repo sync took place >>> with code that was still using the old format. >>> >>> >>> References: >>> >>> webrev: http://cr.openjdk.java.net/~gziemski/8134239_rev0/ >>> bugid: https://bugs.openjdk.java.net/browse/JDK-8134239 >>> >>> >>> cheers >> >> >> From sangheon.kim at oracle.com Mon Aug 24 21:33:31 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 24 Aug 2015 14:33:31 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> Message-ID: <55DB8DAB.6030501@oracle.com> Hi Kim, On 08/24/2015 02:16 PM, Kim Barrett wrote: > On Aug 24, 2015, at 3:06 PM, sangheon.kim wrote: >> Hi Kim, >> >> Here's webrev.03 which includes your comment for MarkStackSize constraint function. >> >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >> >> And all your comments will be managed by https://bugs.openjdk.java.net/browse/JDK-8134348 . > If the value of MarkStackSizeMax were changed later, there's nothing > to verify MarkStackSize is still smaller. [This is related to my > earlier comment about constraints between options being tested twice > and failures reported twice.] Do we care in this case? If your concern is something like -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. Yes, in this case the order is important as ranges and constraint functions are verified by its order. MarkStackSizeMax will be verified first(its range) and MarkStackSize will be compared with verified MarkStackSizeMax. And as I said your original concern is current limitation. If we set CMSOldPLABMin and CMSOldPLABMax together with invalid values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), they will print out 2 failure messages. Thanks, Sangheon > > Other than that, looks good. > From david.holmes at oracle.com Tue Aug 25 06:07:01 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Aug 2015 16:07:01 +1000 Subject: RFR: 8133646: Internal Error: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond Message-ID: <55DC0605.6080400@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 webrev: http://cr.openjdk.java.net/~dholmes/8133646/webrev/ The error raised in this bug was not reproducible - it was only seen on one machine which was subsequently re-imaged to run Windows. A similar Solaris system did not reproduce the bug. Rather than just close this as not-reproducible I want to push the enhanced diagnostics that Vladimir provided here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019667.html which I've added to the two chunks of code that perform this thread sanity check. Thanks, David From vladimir.kozlov at oracle.com Tue Aug 25 07:51:37 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Aug 2015 00:51:37 -0700 Subject: RFR: 8133646: Internal Error: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <55DC0605.6080400@oracle.com> References: <55DC0605.6080400@oracle.com> Message-ID: <55DC1E89.9070208@oracle.com> Looks good. Thanks, Vladimir On 8/24/15 11:07 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 > > webrev: http://cr.openjdk.java.net/~dholmes/8133646/webrev/ > > The error raised in this bug was not reproducible - it was only seen on one machine which was subsequently re-imaged to > run Windows. A similar Solaris system did not reproduce the bug. > > Rather than just close this as not-reproducible I want to push the enhanced diagnostics that Vladimir provided here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019667.html > > which I've added to the two chunks of code that perform this thread sanity check. > > Thanks, > David From erik.joelsson at oracle.com Tue Aug 25 14:27:25 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 25 Aug 2015 16:27:25 +0200 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 Message-ID: <55DC7B4D.4010505@oracle.com> Hello, We are working towards upgrading the officially supported compilers for JDK 9 and on Solaris, the proposed new compiler is Solaris Studio 12 update 4. When attempting to build with that compiler, the hotspot build fails very early with: "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp", line 2331: Error: Could not find source for RegisterForm::addRegClass(const char*). This can be worked around by adding -template=extdef to the compiler flags. I propose we add this just when compiling adlc and for this particular version of Solaris Studio. See bug for further discussion of the issue. Bug: https://bugs.openjdk.java.net/browse/JDK-8134157 Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev/ /Erik From coleen.phillimore at oracle.com Tue Aug 25 16:28:36 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 25 Aug 2015 12:28:36 -0400 Subject: RFR: 8133646: Internal Error: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <55DC0605.6080400@oracle.com> References: <55DC0605.6080400@oracle.com> Message-ID: <55DC97B4.5020204@oracle.com> David, Can you add this duplicate code into a verify_thread() function? This would help if we are ever able to combine common code in stubRoutines_x86_32/64.cpp Thanks, Coleen On 8/25/15 2:07 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 > > webrev: http://cr.openjdk.java.net/~dholmes/8133646/webrev/ > > The error raised in this bug was not reproducible - it was only seen > on one machine which was subsequently re-imaged to run Windows. A > similar Solaris system did not reproduce the bug. > > Rather than just close this as not-reproducible I want to push the > enhanced diagnostics that Vladimir provided here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019667.html > > > which I've added to the two chunks of code that perform this thread > sanity check. > > Thanks, > David From daniel.daugherty at oracle.com Tue Aug 25 16:32:33 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 25 Aug 2015 10:32:33 -0600 Subject: RFR: 8133646: Internal Error: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <55DC0605.6080400@oracle.com> References: <55DC0605.6080400@oracle.com> Message-ID: <55DC98A1.6010104@oracle.com> On 8/25/15 12:07 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 > > webrev: http://cr.openjdk.java.net/~dholmes/8133646/webrev/ src/cpu/x86/vm/stubGenerator_x86_64.cpp I like the new diagnostics! Thumbs up! Dan > > The error raised in this bug was not reproducible - it was only seen > on one machine which was subsequently re-imaged to run Windows. A > similar Solaris system did not reproduce the bug. > > Rather than just close this as not-reproducible I want to push the > enhanced diagnostics that Vladimir provided here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019667.html > > > which I've added to the two chunks of code that perform this thread > sanity check. > > Thanks, > David From tim.bell at oracle.com Tue Aug 25 16:44:19 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 25 Aug 2015 09:44:19 -0700 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 In-Reply-To: <55DC7B4D.4010505@oracle.com> References: <55DC7B4D.4010505@oracle.com> Message-ID: <55DC9B63.1080703@oracle.com> Erik: > We are working towards upgrading the officially supported compilers > for JDK 9 and on Solaris, the proposed new compiler is Solaris Studio > 12 update 4. When attempting to build with that compiler, the hotspot > build fails very early with: > > "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp", > line 2331: Error: Could not find source for > RegisterForm::addRegClass(const char*). > > This can be worked around by adding -template=extdef to the compiler > flags. I propose we add this just when compiling adlc and for this > particular version of Solaris Studio. See bug for further discussion > of the issue. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134157 > Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev/ That is subtle. Looks good to me from a build perspective. I am not a HotSpot 'R'eviewer. Tim From vladimir.kozlov at oracle.com Tue Aug 25 16:54:15 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Aug 2015 09:54:15 -0700 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 In-Reply-To: <55DC7B4D.4010505@oracle.com> References: <55DC7B4D.4010505@oracle.com> Message-ID: <55DC9DB7.9070103@oracle.com> Looks good. Thanks, Vladimir On 8/25/15 7:27 AM, Erik Joelsson wrote: > Hello, > > We are working towards upgrading the officially supported compilers for JDK 9 and on Solaris, the proposed new compiler > is Solaris Studio 12 update 4. When attempting to build with that compiler, the hotspot build fails very early with: > > "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp", line 2331: Error: Could not find source for > RegisterForm::addRegClass(const char*). > > This can be worked around by adding -template=extdef to the compiler flags. I propose we add this just when compiling > adlc and for this particular version of Solaris Studio. See bug for further discussion of the issue. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134157 > Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev/ > > /Erik From karen.kinnear at oracle.com Tue Aug 25 18:05:36 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 25 Aug 2015 14:05:36 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55DB540A.4010804@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> <55B1119D.4030802@oracle.com> <55C41C20.90208@oracle.com> <55C83C5C.60702@oracle.com> <55C8D456.9030006@oracle.com> <5A08C1CB-58F9-4193-802F-767EE11F4D2B@oracle.com> <55CA4E0E.2070503@oracle.com> <55DB540A.4010804@oracle.com> Message-ID: Derek, Many thanks for the latest changes. And thank you for the verify_special_jvm_flags -- that will remind us to clean up the flags when the version number changes. So the expired_in information is for internal use only - we don't print that information for users, we simply tell them "in a future release". Looks good. No need for my further code review. Minor comments: 1. arguments.hpp line 421 "In the case" -> "In this case" 2. arguments.cpp comments I love the high level comments - could you possibly update them? - e.g. they still talk about the deprecated_jvm_flags and obsolete_jvm_flags tables. - e.g. expired and obsolete options should have their global variable definitions and related implementations removed ... comment line 2119 - extra spaces at the front? (or webrev artifact?) thanks very much, Karen On Aug 24, 2015, at 1:27 PM, Derek White wrote: > RFR: > > This version incorporates Dave and Karen's suggestions to automatically handle deprecated-> obsolete transitions. This is implemented with a unified table of deprecated and obsolete options ("special_jvm_flags"). > > Karen also suggested (offline) that it would be good to verify that obsolete and expired options no longer have a "globals" variable defined. This revision adds debug checking of the special_jvm_flags table to check a bunch of constraints, such as deprecated version must be < obsolete version < expired version, and checks for duplicate table entries as well as looking for left-over "globals" variables. > > http://cr.openjdk.java.net/~drwhite/8066821/webrev.08 > https://bugs.openjdk.java.net/browse/JDK-8066821 > > I also have a webrev of webrev.07 vs. webrev.08: > http://cr.openjdk.java.net/~drwhite/8066821/webrev.7.v.8 > > Thanks for looking! > > - Derek > > On 8/11/15 3:33 PM, Derek White wrote: >> Hi Karen, >> >> As much as I want to get this RFE over and out, I see your and David H's point :-) >> >> I'll spin another rev... >> >> - Derek >> >> On 8/10/15 6:07 PM, Karen Kinnear wrote: >>> Derek, >>> >>> Thank you for all of your work on this and responses to suggestions. >>> >>> I had a couple of questions/comments: >>> >>> I appreciate that you have created mechanisms to allow: >>> 1. 2 step obsolete: obsolete_jvm_flags >>> - step 1: obsolete: warn and ignore >>> - step 2: expire >>> - and I expect we will use this for most -XX flags, especially develop flags >>> >>> 2. 2 step deprecate: deprecated_jvm_flags >>> - step 1: deprecate: warn and handle >>> - step 2: expire >>> >>> I see this approach as useful for aliasing and for a few other flags, but not >>> the common path. >>> >>> My concerns: >>> >>> With my understanding of how this is set up today, for the flags that are most exposed to >>> customers, which would want the 3 step deprecation, it would be too easy for an engineer >>> to add the flag to the deprecated_jvm_flags and forget to add it to the obsolete_jvm_flags, >>> as the comments under deprecated_jvm_flags suggest. And we don't want folks to have >>> to go back and do a second step later for flags if they could do it all at once. >>> >>> I think it would be confusing to add a flag to both deprecated_jvm_flags and obsolete_jvm_flags >>> at the same time, since then the expiration release is not clear. >>> >>> 3. For product non-XX, commercial and common -XX flags what I would like to see is >>> a three-step table which I would have called deprecated_jvm_flags, which did >>> - step 1: deprecate: warn and handle >>> - step 2: obsolete: warn and ignore >>> - step 3: expire: unrecognized error >>> >>> Would you be willing to add a table like that which is the recommended approach >>> for external supported flags? >>> >>> So one way to do this would be to change the current deprecated_jvm_flags to have >>> three fields, so that the usual path would be to have three releases listed, and >>> for aliased flags leave the middle field with the undefined version. >>> >>> Another approach would be to have the three fields and have it used by >>> all three approaches, just fill in the steps that are appropriate. >>> >>> minor comment: >>> >>> >>> 1. arguments.hpp >>> Could you possibly change the comments from "and has expired (should be ignored)" to >>> "and has expired (unrecognized error)" >>> >>> unless what you mean really is should be ignored, which is not the same expired. >>> >>> thanks, >>> Karen >>> >>> >>> >>> On Aug 10, 2015, at 12:41 PM, Derek White wrote: >>> >>>> Thanks David! >>>> >>>> - Derek >>>> >>>> On 8/10/15 1:53 AM, David Holmes wrote: >>>>> Hi Derek, >>>>> >>>>> I don't have any further comments. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 7/08/2015 12:46 PM, Derek White wrote: >>>>>> Another RFR. >>>>>> >>>>>> I've updated based on David and Kim's last comments. >>>>>> >>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>>>> >>>>>> I also have a webrev of webrev.06 vs. webrev.07: >>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/ >>>>>> >>>>>> [This webrev is confused about CommandLineOptionTest.java. I >>>>>> double-checked with a recursive diff and the only differences are in >>>>>> arguments.cpp and arguments.hpp.] >>>>>> >>>>>> Thanks for looking! >>>>>> >>>>>> - Derek >>>>>> .... >> > From kim.barrett at oracle.com Tue Aug 25 18:13:11 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 25 Aug 2015 14:13:11 -0400 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 In-Reply-To: <55DC7B4D.4010505@oracle.com> References: <55DC7B4D.4010505@oracle.com> Message-ID: <887B4B02-6530-4E23-BCA0-E41B7DE3368E@oracle.com> On Aug 25, 2015, at 10:27 AM, Erik Joelsson wrote: > > Hello, > > We are working towards upgrading the officially supported compilers for JDK 9 and on Solaris, the proposed new compiler is Solaris Studio 12 update 4. When attempting to build with that compiler, the hotspot build fails very early with: > > "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp", line 2331: Error: Could not find source for RegisterForm::addRegClass(const char*). > > This can be worked around by adding -template=extdef to the compiler flags. I propose we add this just when compiling adlc and for this particular version of Solaris Studio. See bug for further discussion of the issue. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134157 > Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev/ > > /Erik I don?t think we should make this change. I think a better alternative than mixing different -template options would be to change adlc to use the ?include model? for template usage, as discussed in comments in the bug report. Also as discussed in the bug report, I don?t think we fully understand the problem, since there appears to be other code in hotspot that looks very similar and seemingly ought to run into the same problem. If only changing adlc as described doesn?t trip over the same problem with that other code, then I don?t think we actually understand the problem yet, and can?t evaluate proposed solutions. From daniel.daugherty at oracle.com Tue Aug 25 20:11:39 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 25 Aug 2015 14:11:39 -0600 Subject: assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <55CB05A6.1010503@sap.com> References: <7F953F1E7B01F54E9F0B51450984507D3993D390@DEWDFEMB19B.global.corp.sap> <55CA4122.3080504@oracle.com> <55CB05A6.1010503@sap.com> Message-ID: <55DCCBFB.7050201@oracle.com> Richard, I didn't see any response from the Serviceability Team, but maybe I missed it. In any case, I filed: JDK-8134434 JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase https://bugs.openjdk.java.net/browse/JDK-8134434 for your issue. Dan On 8/12/15 2:36 AM, Richard Reingruber wrote: > > Adding serviceability-dev at ... since this JVM/TI... > Thanks Dan. > > Sorry, forgot to add a stack trace. This is from amd64: > > Stack: [0x00007fe6cdacc000,0x00007fe6cdbcd000], > sp=0x00007fe6cdbc9d30, free space=1015k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0xfce6f1] VMError::report(outputStream*)+0x12fd > V [libjvm.so+0xfcfbed] VMError::report_and_die()+0x3fd > V [libjvm.so+0x86b82d] report_vm_error(char const*, int, char > const*, char const*)+0xb4 > V [libjvm.so+0xbe44ba] > JvmtiThreadState::clear_exception_detected()+0x4e > V [libjvm.so+0xbe3046] > JvmtiExport::clear_detected_exception(JavaThread*)+0x72 > V [libjvm.so+0xb50627] JVM_DoPrivileged+0x7e4 > C [libjava.so+0xd04e] > Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x42 > j > java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+0 > j ExceptionCaughtOutOfPhaseAssertion.main([Ljava/lang/String;)V+59 > v ~StubRoutines::call_stub > [...] > > I can reproduce this on amd64, sparcv9 and ppc64 with dbg builds of > the current openjdk9. > > Richard. > > > On 08/11/2015 08:38 PM, Daniel D. Daugherty wrote: >> Adding serviceability-dev at ... since this JVM/TI... >> >> Dan >> >> >> On 8/11/15 9:06 AM, Reingruber, Richard wrote: >>> Hi, >>> >>> I would like to report that the assertion >>> >>> assert(_exception_caught == false) failed: _exception_caught is >>> out of phase >>> >>> at jvmtiThreadState.hpp:170 fires when running the command >>> >>> ./images/jdk/bin/java >>> -agentlib:jdwp=transport=dt_socket,address=9000,server=y,suspend=n >>> -Xbatch ExceptionCaughtOutOfPhaseAssertion >>> >>> (when analyzing you might want to add -XX:-TieredCompilation >>> -XX:-Inline '-XX:CompileCommand=compileonly *::run') >>> >>> Source Code: >>> >>> import java.security.AccessController; >>> import java.security.PrivilegedAction; >>> public class ExceptionCaughtOutOfPhaseAssertion { >>> public static void main(String[] args) { >>> PrivilegedAction action = new HotThrowingAction(); >>> System.out.println("### Warm-up"); >>> for(int i=0; i<11000; i++) { >>> try { >>> action.run(); // call run() to get it compiled >>> } catch(Throwable t) { /* ignored */ } >>> } >>> System.out.println("### Warm-up done"); >>> System.out.println("### Executing privileged action"); >>> AccessController.doPrivileged(action); >>> } >>> public static class HotThrowingAction implements >>> PrivilegedAction { >>> public Object run() { >>> throw new Error(); >>> } >>> } >>> } >>> My Analysis: >>> >>> * Error is thrown in interpreted activation of run() >>> - JvmtiThreadState::_exception_detected is set to true >>> - JvmtiThreadState::_exception_caught is set to false >>> * Error is caught in main() method >>> - JvmtiThreadState::_exception_detected is set to false >>> - JvmtiThreadState::_exception_caught is set to true >>> * run() method is compiled >>> * PrivilegedAction is executed >>> * compiled activation of run() method >>> - Error object is allocated and initialized >>> - JavaThread::_should_post_on_exceptions_flag is checked and >>> found to be false >>> -> *no* uncommon trap >>> - compiled frame is popped, rethrow stub calls >>> OptoRuntime::rethrow_C() >>> - _exception_detected is *not* set, remains false >>> - _exception_caught is still true >>> * Java call in JVM_DoPrivileged() returns with pending exception >>> * CLEAR_PENDING_EXCEPTION triggers the assertion >>> >>> How to Fix? I'm not really an expert in this area, but here are my >>> two cent: >>> >>> (a) Improve the assertion ...but how?! Toggling JVMTI exception >>> notifications does not seem >>> to be synchronized with java execution. >>> >>> (b) Calling JvmtiExport::post_exception_throw() in >>> OptoRuntime::rethrow_C() is probably not possible, >>> because of the JRT_LEAF comment for rethrow_C(), but >>> _exception_detected = true could be set. >>> >>> (c) Remove the assertion. >>> >>> I guess (b) could be acceptable. >>> >>> What do you think? >>> >>> Best regards, >>> Richard. >> From derek.white at oracle.com Tue Aug 25 22:02:42 2015 From: derek.white at oracle.com (Derek White) Date: Tue, 25 Aug 2015 18:02:42 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> <55B1119D.4030802@oracle.com> <55C41C20.90208@oracle.com> <55C83C5C.60702@oracle.com> <55C8D456.9030006@oracle.com> <5A08C1CB-58F9-4193-802F-767EE11F4D2B@oracle.com> <55CA4E0E.2070503@oracle.com> <55DB540A.4010804@oracle.com> Message-ID: <55DCE602.3040801@oracle.com> Thanks Karen! If I don't get any other feedback, can I get you to sponsor the change for me? After folding in your fixes... - Derek On 8/25/15 2:05 PM, Karen Kinnear wrote: > Derek, > > Many thanks for the latest changes. And thank you for the verify_special_jvm_flags -- that will remind us to > clean up the flags when the version number changes. So the expired_in information is for internal use only - we > don't print that information for users, we simply tell them "in a future release". > > Looks good. No need for my further code review. > > Minor comments: > 1. arguments.hpp > line 421 "In the case" -> "In this case" > > 2. arguments.cpp comments > > I love the high level comments - could you possibly update them? > - e.g. they still talk about the deprecated_jvm_flags and obsolete_jvm_flags tables. > - e.g. expired and obsolete options should have their global variable definitions and > related implementations removed ... > > comment line 2119 - extra spaces at the front? (or webrev artifact?) > > thanks very much, > Karen > > > > > On Aug 24, 2015, at 1:27 PM, Derek White wrote: > >> RFR: >> >> This version incorporates Dave and Karen's suggestions to automatically handle deprecated-> obsolete transitions. This is implemented with a unified table of deprecated and obsolete options ("special_jvm_flags"). >> >> Karen also suggested (offline) that it would be good to verify that obsolete and expired options no longer have a "globals" variable defined. This revision adds debug checking of the special_jvm_flags table to check a bunch of constraints, such as deprecated version must be < obsolete version < expired version, and checks for duplicate table entries as well as looking for left-over "globals" variables. >> >> http://cr.openjdk.java.net/~drwhite/8066821/webrev.08 >> https://bugs.openjdk.java.net/browse/JDK-8066821 >> >> I also have a webrev of webrev.07 vs. webrev.08: >> http://cr.openjdk.java.net/~drwhite/8066821/webrev.7.v.8 >> >> Thanks for looking! >> >> - Derek >> >> On 8/11/15 3:33 PM, Derek White wrote: >>> Hi Karen, >>> >>> As much as I want to get this RFE over and out, I see your and David H's point :-) >>> >>> I'll spin another rev... >>> >>> - Derek >>> >>> On 8/10/15 6:07 PM, Karen Kinnear wrote: >>>> Derek, >>>> >>>> Thank you for all of your work on this and responses to suggestions. >>>> >>>> I had a couple of questions/comments: >>>> >>>> I appreciate that you have created mechanisms to allow: >>>> 1. 2 step obsolete: obsolete_jvm_flags >>>> - step 1: obsolete: warn and ignore >>>> - step 2: expire >>>> - and I expect we will use this for most -XX flags, especially develop flags >>>> >>>> 2. 2 step deprecate: deprecated_jvm_flags >>>> - step 1: deprecate: warn and handle >>>> - step 2: expire >>>> >>>> I see this approach as useful for aliasing and for a few other flags, but not >>>> the common path. >>>> >>>> My concerns: >>>> >>>> With my understanding of how this is set up today, for the flags that are most exposed to >>>> customers, which would want the 3 step deprecation, it would be too easy for an engineer >>>> to add the flag to the deprecated_jvm_flags and forget to add it to the obsolete_jvm_flags, >>>> as the comments under deprecated_jvm_flags suggest. And we don't want folks to have >>>> to go back and do a second step later for flags if they could do it all at once. >>>> >>>> I think it would be confusing to add a flag to both deprecated_jvm_flags and obsolete_jvm_flags >>>> at the same time, since then the expiration release is not clear. >>>> >>>> 3. For product non-XX, commercial and common -XX flags what I would like to see is >>>> a three-step table which I would have called deprecated_jvm_flags, which did >>>> - step 1: deprecate: warn and handle >>>> - step 2: obsolete: warn and ignore >>>> - step 3: expire: unrecognized error >>>> >>>> Would you be willing to add a table like that which is the recommended approach >>>> for external supported flags? >>>> >>>> So one way to do this would be to change the current deprecated_jvm_flags to have >>>> three fields, so that the usual path would be to have three releases listed, and >>>> for aliased flags leave the middle field with the undefined version. >>>> >>>> Another approach would be to have the three fields and have it used by >>>> all three approaches, just fill in the steps that are appropriate. >>>> >>>> minor comment: >>>> >>>> >>>> 1. arguments.hpp >>>> Could you possibly change the comments from "and has expired (should be ignored)" to >>>> "and has expired (unrecognized error)" >>>> >>>> unless what you mean really is should be ignored, which is not the same expired. >>>> >>>> thanks, >>>> Karen >>>> >>>> >>>> >>>> On Aug 10, 2015, at 12:41 PM, Derek White wrote: >>>> >>>>> Thanks David! >>>>> >>>>> - Derek >>>>> >>>>> On 8/10/15 1:53 AM, David Holmes wrote: >>>>>> Hi Derek, >>>>>> >>>>>> I don't have any further comments. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 7/08/2015 12:46 PM, Derek White wrote: >>>>>>> Another RFR. >>>>>>> >>>>>>> I've updated based on David and Kim's last comments. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>>>>> >>>>>>> I also have a webrev of webrev.06 vs. webrev.07: >>>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/ >>>>>>> >>>>>>> [This webrev is confused about CommandLineOptionTest.java. I >>>>>>> double-checked with a recursive diff and the only differences are in >>>>>>> arguments.cpp and arguments.hpp.] >>>>>>> >>>>>>> Thanks for looking! >>>>>>> >>>>>>> - Derek >>>>>>> .... From david.holmes at oracle.com Wed Aug 26 02:17:19 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Aug 2015 12:17:19 +1000 Subject: RFR: 8133646: Internal Error: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <55DC97B4.5020204@oracle.com> References: <55DC0605.6080400@oracle.com> <55DC97B4.5020204@oracle.com> Message-ID: <55DD21AF.9020104@oracle.com> Hi Coleen, Thanks for the review. On 26/08/2015 2:28 AM, Coleen Phillimore wrote: > > David, > Can you add this duplicate code into a verify_thread() function? This > would help if we are ever able to combine common code in > stubRoutines_x86_32/64.cpp I'm so grateful you posed that as a question not a request. :) Answer: no. The duplicated structure is pre-existing, and the error messages differ so the context would have to be passed in. I'm totally unfamiliar with playing in the macroassembler so would be unsure how to factor this out into a separate function without messing up register usage, or using the correct "variables" from the "calling context". Also note that for some reason these sanity checks don't exist on x86_32, nor sparc (only aarch64 also has it presumably based on the x86_64 version). I think the time to factor this out would be if/when we do the code combining. Thanks, David > Thanks, > Coleen > > On 8/25/15 2:07 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8133646/webrev/ >> >> The error raised in this bug was not reproducible - it was only seen >> on one machine which was subsequently re-imaged to run Windows. A >> similar Solaris system did not reproduce the bug. >> >> Rather than just close this as not-reproducible I want to push the >> enhanced diagnostics that Vladimir provided here: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019667.html >> >> >> which I've added to the two chunks of code that perform this thread >> sanity check. >> >> Thanks, >> David > From david.holmes at oracle.com Wed Aug 26 02:17:38 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Aug 2015 12:17:38 +1000 Subject: RFR: 8133646: Internal Error: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <55DC1E89.9070208@oracle.com> References: <55DC0605.6080400@oracle.com> <55DC1E89.9070208@oracle.com> Message-ID: <55DD21C2.1060004@oracle.com> Thanks Vladimir! David On 25/08/2015 5:51 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 8/24/15 11:07 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8133646/webrev/ >> >> The error raised in this bug was not reproducible - it was only seen >> on one machine which was subsequently re-imaged to >> run Windows. A similar Solaris system did not reproduce the bug. >> >> Rather than just close this as not-reproducible I want to push the >> enhanced diagnostics that Vladimir provided here: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019667.html >> >> >> which I've added to the two chunks of code that perform this thread >> sanity check. >> >> Thanks, >> David From david.holmes at oracle.com Wed Aug 26 02:17:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Aug 2015 12:17:51 +1000 Subject: RFR: 8133646: Internal Error: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <55DC98A1.6010104@oracle.com> References: <55DC0605.6080400@oracle.com> <55DC98A1.6010104@oracle.com> Message-ID: <55DD21CF.609@oracle.com> Thanks Dan! David On 26/08/2015 2:32 AM, Daniel D. Daugherty wrote: > On 8/25/15 12:07 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8133646/webrev/ > > src/cpu/x86/vm/stubGenerator_x86_64.cpp > I like the new diagnostics! > > Thumbs up! > > Dan > > >> >> The error raised in this bug was not reproducible - it was only seen >> on one machine which was subsequently re-imaged to run Windows. A >> similar Solaris system did not reproduce the bug. >> >> Rather than just close this as not-reproducible I want to push the >> enhanced diagnostics that Vladimir provided here: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019667.html >> >> >> which I've added to the two chunks of code that perform this thread >> sanity check. >> >> Thanks, >> David > From david.holmes at oracle.com Wed Aug 26 03:21:35 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Aug 2015 13:21:35 +1000 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 In-Reply-To: <887B4B02-6530-4E23-BCA0-E41B7DE3368E@oracle.com> References: <55DC7B4D.4010505@oracle.com> <887B4B02-6530-4E23-BCA0-E41B7DE3368E@oracle.com> Message-ID: <55DD30BF.40604@oracle.com> On 26/08/2015 4:13 AM, Kim Barrett wrote: > On Aug 25, 2015, at 10:27 AM, Erik Joelsson wrote: >> >> Hello, >> >> We are working towards upgrading the officially supported compilers for JDK 9 and on Solaris, the proposed new compiler is Solaris Studio 12 update 4. When attempting to build with that compiler, the hotspot build fails very early with: >> >> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp", line 2331: Error: Could not find source for RegisterForm::addRegClass(const char*). >> >> This can be worked around by adding -template=extdef to the compiler flags. I propose we add this just when compiling adlc and for this particular version of Solaris Studio. See bug for further discussion of the issue. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8134157 >> Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev/ >> >> /Erik > > I don?t think we should make this change. Agreed. The need for the change makes no sense as nothing has changed: the code hasn't changed and the use of this flag has not changed. Hence this seems to be a compiler issue. David ---- > I think a better alternative than mixing different -template options would be to change adlc to use the ?include model? for template usage, as discussed in comments in the bug report. > > Also as discussed in the bug report, I don?t think we fully understand the problem, since there appears to be other code in hotspot that looks very similar and seemingly ought to run into the same problem. If only changing adlc as described doesn?t trip over the same problem with that other code, then I don?t think we actually understand the problem yet, and can?t evaluate proposed solutions. > From coleen.phillimore at oracle.com Wed Aug 26 11:02:23 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 26 Aug 2015 07:02:23 -0400 Subject: RFR: 8133646: Internal Error: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <55DD21AF.9020104@oracle.com> References: <55DC0605.6080400@oracle.com> <55DC97B4.5020204@oracle.com> <55DD21AF.9020104@oracle.com> Message-ID: <07D63387-FB04-4294-8E23-115FEC8AAC24@oracle.com> That's ok. Reviewed Coleen Sent from my iPhone > On Aug 25, 2015, at 10:17 PM, David Holmes wrote: > > Hi Coleen, > > Thanks for the review. > >> On 26/08/2015 2:28 AM, Coleen Phillimore wrote: >> >> David, >> Can you add this duplicate code into a verify_thread() function? This >> would help if we are ever able to combine common code in >> stubRoutines_x86_32/64.cpp > > I'm so grateful you posed that as a question not a request. :) Answer: no. > > The duplicated structure is pre-existing, and the error messages differ so the context would have to be passed in. I'm totally unfamiliar with playing in the macroassembler so would be unsure how to factor this out into a separate function without messing up register usage, or using the correct "variables" from the "calling context". > > Also note that for some reason these sanity checks don't exist on x86_32, nor sparc (only aarch64 also has it presumably based on the x86_64 version). I think the time to factor this out would be if/when we do the code combining. > > Thanks, > David > >> Thanks, >> Coleen >> >>> On 8/25/15 2:07 AM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/8133646/webrev/ >>> >>> The error raised in this bug was not reproducible - it was only seen >>> on one machine which was subsequently re-imaged to run Windows. A >>> similar Solaris system did not reproduce the bug. >>> >>> Rather than just close this as not-reproducible I want to push the >>> enhanced diagnostics that Vladimir provided here: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019667.html >>> >>> >>> which I've added to the two chunks of code that perform this thread >>> sanity check. >>> >>> Thanks, >>> David >> From david.holmes at oracle.com Wed Aug 26 11:29:38 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Aug 2015 21:29:38 +1000 Subject: RFR: 8133646: Internal Error: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <07D63387-FB04-4294-8E23-115FEC8AAC24@oracle.com> References: <55DC0605.6080400@oracle.com> <55DC97B4.5020204@oracle.com> <55DD21AF.9020104@oracle.com> <07D63387-FB04-4294-8E23-115FEC8AAC24@oracle.com> Message-ID: <55DDA322.8010307@oracle.com> Thanks Coleen! David On 26/08/2015 9:02 PM, Coleen Phillimore wrote: > That's ok. > Reviewed > Coleen > > Sent from my iPhone > >> On Aug 25, 2015, at 10:17 PM, David Holmes wrote: >> >> Hi Coleen, >> >> Thanks for the review. >> >>> On 26/08/2015 2:28 AM, Coleen Phillimore wrote: >>> >>> David, >>> Can you add this duplicate code into a verify_thread() function? This >>> would help if we are ever able to combine common code in >>> stubRoutines_x86_32/64.cpp >> >> I'm so grateful you posed that as a question not a request. :) Answer: no. >> >> The duplicated structure is pre-existing, and the error messages differ so the context would have to be passed in. I'm totally unfamiliar with playing in the macroassembler so would be unsure how to factor this out into a separate function without messing up register usage, or using the correct "variables" from the "calling context". >> >> Also note that for some reason these sanity checks don't exist on x86_32, nor sparc (only aarch64 also has it presumably based on the x86_64 version). I think the time to factor this out would be if/when we do the code combining. >> >> Thanks, >> David >> >>> Thanks, >>> Coleen >>> >>>> On 8/25/15 2:07 AM, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 >>>> >>>> webrev: http://cr.openjdk.java.net/~dholmes/8133646/webrev/ >>>> >>>> The error raised in this bug was not reproducible - it was only seen >>>> on one machine which was subsequently re-imaged to run Windows. A >>>> similar Solaris system did not reproduce the bug. >>>> >>>> Rather than just close this as not-reproducible I want to push the >>>> enhanced diagnostics that Vladimir provided here: >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019667.html >>>> >>>> >>>> which I've added to the two chunks of code that perform this thread >>>> sanity check. >>>> >>>> Thanks, >>>> David >>> From erik.joelsson at oracle.com Wed Aug 26 11:44:41 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 26 Aug 2015 13:44:41 +0200 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 In-Reply-To: <55DD30BF.40604@oracle.com> References: <55DC7B4D.4010505@oracle.com> <887B4B02-6530-4E23-BCA0-E41B7DE3368E@oracle.com> <55DD30BF.40604@oracle.com> Message-ID: <55DDA6A9.3070909@oracle.com> Further investigation revealed that this "error" was actually just a warning being upgraded to error by -errwarn. The warning is only activated by +w, which is turned on for adlc but not for the rest of the hotspot build. Based on this, I have revised my proposal to just disabling this warning for adlc and the particular compiler version. Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev.01/ /Erik On 2015-08-26 05:21, David Holmes wrote: > On 26/08/2015 4:13 AM, Kim Barrett wrote: >> On Aug 25, 2015, at 10:27 AM, Erik Joelsson >> wrote: >>> >>> Hello, >>> >>> We are working towards upgrading the officially supported compilers >>> for JDK 9 and on Solaris, the proposed new compiler is Solaris >>> Studio 12 update 4. When attempting to build with that compiler, the >>> hotspot build fails very early with: >>> >>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp", >>> line 2331: Error: Could not find source for >>> RegisterForm::addRegClass(const char*). >>> >>> This can be worked around by adding -template=extdef to the compiler >>> flags. I propose we add this just when compiling adlc and for this >>> particular version of Solaris Studio. See bug for further discussion >>> of the issue. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134157 >>> Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev/ >>> >>> /Erik >> >> I don?t think we should make this change. > > Agreed. The need for the change makes no sense as nothing has changed: > the code hasn't changed and the use of this flag has not changed. > Hence this seems to be a compiler issue. > > David > ---- > >> I think a better alternative than mixing different -template options >> would be to change adlc to use the ?include model? for template >> usage, as discussed in comments in the bug report. >> >> Also as discussed in the bug report, I don?t think we fully >> understand the problem, since there appears to be other code in >> hotspot that looks very similar and seemingly ought to run into the >> same problem. If only changing adlc as described doesn?t trip over >> the same problem with that other code, then I don?t think we actually >> understand the problem yet, and can?t evaluate proposed solutions. >> From david.holmes at oracle.com Wed Aug 26 12:45:19 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Aug 2015 22:45:19 +1000 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 In-Reply-To: <55DDA6A9.3070909@oracle.com> References: <55DC7B4D.4010505@oracle.com> <887B4B02-6530-4E23-BCA0-E41B7DE3368E@oracle.com> <55DD30BF.40604@oracle.com> <55DDA6A9.3070909@oracle.com> Message-ID: <55DDB4DF.8050804@oracle.com> On 26/08/2015 9:44 PM, Erik Joelsson wrote: > Further investigation revealed that this "error" was actually just a > warning being upgraded to error by -errwarn. The warning is only > activated by +w, which is turned on for adlc but not for the rest of the > hotspot build. Based on this, I have revised my proposal to just > disabling this warning for adlc and the particular compiler version. > > Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev.01/ Sorry but as per bug report I still object to simply hiding this problem when we don't understand it. The code did not change and the compiler option did not change, but the new compiler gives this strange warning the implications of which are unclear. David ----- > /Erik > > On 2015-08-26 05:21, David Holmes wrote: >> On 26/08/2015 4:13 AM, Kim Barrett wrote: >>> On Aug 25, 2015, at 10:27 AM, Erik Joelsson >>> wrote: >>>> >>>> Hello, >>>> >>>> We are working towards upgrading the officially supported compilers >>>> for JDK 9 and on Solaris, the proposed new compiler is Solaris >>>> Studio 12 update 4. When attempting to build with that compiler, the >>>> hotspot build fails very early with: >>>> >>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp", >>>> line 2331: Error: Could not find source for >>>> RegisterForm::addRegClass(const char*). >>>> >>>> This can be worked around by adding -template=extdef to the compiler >>>> flags. I propose we add this just when compiling adlc and for this >>>> particular version of Solaris Studio. See bug for further discussion >>>> of the issue. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134157 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev/ >>>> >>>> /Erik >>> >>> I don?t think we should make this change. >> >> Agreed. The need for the change makes no sense as nothing has changed: >> the code hasn't changed and the use of this flag has not changed. >> Hence this seems to be a compiler issue. >> >> David >> ---- >> >>> I think a better alternative than mixing different -template options >>> would be to change adlc to use the ?include model? for template >>> usage, as discussed in comments in the bug report. >>> >>> Also as discussed in the bug report, I don?t think we fully >>> understand the problem, since there appears to be other code in >>> hotspot that looks very similar and seemingly ought to run into the >>> same problem. If only changing adlc as described doesn?t trip over >>> the same problem with that other code, then I don?t think we actually >>> understand the problem yet, and can?t evaluate proposed solutions. >>> > From daniel.daugherty at oracle.com Wed Aug 26 13:04:14 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 26 Aug 2015 07:04:14 -0600 Subject: RFR: 8133646: Internal Error: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <55DD21AF.9020104@oracle.com> References: <55DC0605.6080400@oracle.com> <55DC97B4.5020204@oracle.com> <55DD21AF.9020104@oracle.com> Message-ID: <55DDB94E.7070507@oracle.com> On 8/25/15 8:17 PM, David Holmes wrote: > Hi Coleen, > > Thanks for the review. > > On 26/08/2015 2:28 AM, Coleen Phillimore wrote: >> >> David, >> Can you add this duplicate code into a verify_thread() function? This >> would help if we are ever able to combine common code in >> stubRoutines_x86_32/64.cpp > > I'm so grateful you posed that as a question not a request. :) Answer: > no. > > The duplicated structure is pre-existing, and the error messages > differ so the context would have to be passed in. I'm totally > unfamiliar with playing in the macroassembler so would be unsure how > to factor this out into a separate function without messing up > register usage, or using the correct "variables" from the "calling > context". > > Also note that for some reason these sanity checks don't exist on > x86_32, nor sparc (only aarch64 also has it presumably based on the > x86_64 version). I think the time to factor this out would be if/when > we do the code combining. We do have a similar check on x86_32: src/cpu/x86/vm/stubGenerator_x86_32.cpp: 343 address generate_catch_exception() { 351 #ifdef ASSERT 352 // verify that threads correspond 353 { Label L; 354 __ get_thread(rbx); 355 __ cmpptr(rbx, rcx); 356 __ jcc(Assembler::equal, L); 357 __ stop("StubRoutines::catch_exception: threads must correspond"); 358 __ bind(L); 359 } 360 #endif The check is much simpler because we don't have enough registers on x86_32 to set aside one for the thread. On SPARC we have this: src/cpu/sparc/vm/stubGenerator_sparc.cpp: 322 address generate_catch_exception() { 326 // verify that thread corresponds 327 __ verify_thread(); There are lots of other calls to verify_thread() sprinkled through the SPARC code... src/cpu/sparc/vm/macroAssembler_sparc.cpp: 398 void MacroAssembler::verify_thread() { 399 if (VerifyThread) { 400 // NOTE: this chops off the heads of the 64-bit O registers. 401 #ifdef CC_INTERP 402 save_frame(0); 403 #else 404 // make sure G2_thread contains the right value 405 save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod for -Xprof) 406 mov(G1, L1); // avoid clobbering G1 407 // G2 saved below 408 mov(G3, L3); // avoid clobbering G3 409 mov(G4, L4); // avoid clobbering G4 410 mov(G5_method, L5); // avoid clobbering G5_method 411 #endif /* CC_INTERP */ 412 #if defined(COMPILER2) && !defined(_LP64) 413 // Save & restore possible 64-bit Long arguments in G-regs 414 srlx(G1,32,L0); 415 srlx(G4,32,L6); 416 #endif 417 call(CAST_FROM_FN_PTR(address,verify_thread_subroutine), relocInfo:: runtime_call_type); 418 delayed()->mov(G2_thread, O0); 419 420 mov(L1, G1); // Restore G1 421 // G2 restored below 422 mov(L3, G3); // restore G3 423 mov(L4, G4); // restore G4 424 mov(L5, G5_method); // restore G5_method 425 #if defined(COMPILER2) && !defined(_LP64) 426 // Save & restore possible 64-bit Long arguments in G-regs 427 sllx(L0,32,G2); // Move old high G1 bits high in G2 428 srl(G1, 0,G1); // Clear current high G1 bits 429 or3 (G1,G2,G1); // Recover 64-bit G1 430 sllx(L6,32,G2); // Move old high G4 bits high in G2 431 srl(G4, 0,G4); // Clear current high G4 bits 432 or3 (G4,G2,G4); // Recover 64-bit G4 433 #endif 434 restore(O0, 0, G2_thread); 435 } 436 } Does anyone else have a headache after reading verify_thread()? :-) Dan > > Thanks, > David > >> Thanks, >> Coleen >> >> On 8/25/15 2:07 AM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/8133646/webrev/ >>> >>> The error raised in this bug was not reproducible - it was only seen >>> on one machine which was subsequently re-imaged to run Windows. A >>> similar Solaris system did not reproduce the bug. >>> >>> Rather than just close this as not-reproducible I want to push the >>> enhanced diagnostics that Vladimir provided here: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019667.html >>> >>> >>> >>> which I've added to the two chunks of code that perform this thread >>> sanity check. >>> >>> Thanks, >>> David >> From aph at redhat.com Wed Aug 26 14:12:42 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Aug 2015 15:12:42 +0100 Subject: @Finalized In-Reply-To: <55DDC69D.5090904@cs.oswego.edu> References: <55DDC69D.5090904@cs.oswego.edu> Message-ID: <55DDC95A.5000701@redhat.com> On 08/26/2015 03:01 PM, Doug Lea wrote: > This is an issue of large importance to a small audience, > and is at the moment an orphan. To work out, I think it > requires at least some involvement from compiler and/or IDE > developers. If you are or know of someone who might be interested > in pursuing, please encourage them/yourself to consider it. At the minimum, all this needs is an empty native method. That's not the most efficient long-term solution but it is enough. Andrew. From richard.reingruber at sap.com Wed Aug 26 14:55:56 2015 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 26 Aug 2015 14:55:56 +0000 Subject: assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <55DCCBFB.7050201@oracle.com> References: <7F953F1E7B01F54E9F0B51450984507D3993D390@DEWDFEMB19B.global.corp.sap> <55CA4122.3080504@oracle.com> <55CB05A6.1010503@sap.com> <55DCCBFB.7050201@oracle.com> Message-ID: <7F953F1E7B01F54E9F0B51450984507D39940668@DEWDFEMB19B.global.corp.sap> Hi Daniel, > I didn't see any response from the Serviceability Team Me neither. Thanks for filing a bug for the issue. Richard. -----Original Message----- From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Dienstag, 25. August 2015 22:12 To: Reingruber, Richard Cc: hotspot-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: Re: assert(_exception_caught == false) failed: _exception_caught is out of phase Richard, I didn't see any response from the Serviceability Team, but maybe I missed it. In any case, I filed: JDK-8134434 JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase https://bugs.openjdk.java.net/browse/JDK-8134434 for your issue. Dan On 8/12/15 2:36 AM, Richard Reingruber wrote: > > Adding serviceability-dev at ... since this JVM/TI... > Thanks Dan. > > Sorry, forgot to add a stack trace. This is from amd64: > > Stack: [0x00007fe6cdacc000,0x00007fe6cdbcd000], > sp=0x00007fe6cdbc9d30, free space=1015k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0xfce6f1] VMError::report(outputStream*)+0x12fd > V [libjvm.so+0xfcfbed] VMError::report_and_die()+0x3fd > V [libjvm.so+0x86b82d] report_vm_error(char const*, int, char > const*, char const*)+0xb4 > V [libjvm.so+0xbe44ba] > JvmtiThreadState::clear_exception_detected()+0x4e > V [libjvm.so+0xbe3046] > JvmtiExport::clear_detected_exception(JavaThread*)+0x72 > V [libjvm.so+0xb50627] JVM_DoPrivileged+0x7e4 > C [libjava.so+0xd04e] > Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x42 > j > java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+0 > j ExceptionCaughtOutOfPhaseAssertion.main([Ljava/lang/String;)V+59 > v ~StubRoutines::call_stub > [...] > > I can reproduce this on amd64, sparcv9 and ppc64 with dbg builds of > the current openjdk9. > > Richard. > > > On 08/11/2015 08:38 PM, Daniel D. Daugherty wrote: >> Adding serviceability-dev at ... since this JVM/TI... >> >> Dan >> >> >> On 8/11/15 9:06 AM, Reingruber, Richard wrote: >>> Hi, >>> >>> I would like to report that the assertion >>> >>> assert(_exception_caught == false) failed: _exception_caught is >>> out of phase >>> >>> at jvmtiThreadState.hpp:170 fires when running the command >>> >>> ./images/jdk/bin/java >>> -agentlib:jdwp=transport=dt_socket,address=9000,server=y,suspend=n >>> -Xbatch ExceptionCaughtOutOfPhaseAssertion >>> >>> (when analyzing you might want to add -XX:-TieredCompilation >>> -XX:-Inline '-XX:CompileCommand=compileonly *::run') >>> >>> Source Code: >>> >>> import java.security.AccessController; >>> import java.security.PrivilegedAction; >>> public class ExceptionCaughtOutOfPhaseAssertion { >>> public static void main(String[] args) { >>> PrivilegedAction action = new HotThrowingAction(); >>> System.out.println("### Warm-up"); >>> for(int i=0; i<11000; i++) { >>> try { >>> action.run(); // call run() to get it compiled >>> } catch(Throwable t) { /* ignored */ } >>> } >>> System.out.println("### Warm-up done"); >>> System.out.println("### Executing privileged action"); >>> AccessController.doPrivileged(action); >>> } >>> public static class HotThrowingAction implements >>> PrivilegedAction { >>> public Object run() { >>> throw new Error(); >>> } >>> } >>> } >>> My Analysis: >>> >>> * Error is thrown in interpreted activation of run() >>> - JvmtiThreadState::_exception_detected is set to true >>> - JvmtiThreadState::_exception_caught is set to false >>> * Error is caught in main() method >>> - JvmtiThreadState::_exception_detected is set to false >>> - JvmtiThreadState::_exception_caught is set to true >>> * run() method is compiled >>> * PrivilegedAction is executed >>> * compiled activation of run() method >>> - Error object is allocated and initialized >>> - JavaThread::_should_post_on_exceptions_flag is checked and >>> found to be false >>> -> *no* uncommon trap >>> - compiled frame is popped, rethrow stub calls >>> OptoRuntime::rethrow_C() >>> - _exception_detected is *not* set, remains false >>> - _exception_caught is still true >>> * Java call in JVM_DoPrivileged() returns with pending exception >>> * CLEAR_PENDING_EXCEPTION triggers the assertion >>> >>> How to Fix? I'm not really an expert in this area, but here are my >>> two cent: >>> >>> (a) Improve the assertion ...but how?! Toggling JVMTI exception >>> notifications does not seem >>> to be synchronized with java execution. >>> >>> (b) Calling JvmtiExport::post_exception_throw() in >>> OptoRuntime::rethrow_C() is probably not possible, >>> because of the JRT_LEAF comment for rethrow_C(), but >>> _exception_detected = true could be set. >>> >>> (c) Remove the assertion. >>> >>> I guess (b) could be acceptable. >>> >>> What do you think? >>> >>> Best regards, >>> Richard. >> From dl at cs.oswego.edu Wed Aug 26 15:07:12 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 26 Aug 2015 11:07:12 -0400 Subject: @Finalized In-Reply-To: <55DDC95A.5000701@redhat.com> References: <55DDC69D.5090904@cs.oswego.edu> <55DDC95A.5000701@redhat.com> Message-ID: <55DDD620.2000500@cs.oswego.edu> On 08/26/2015 10:12 AM, Andrew Haley wrote: > On 08/26/2015 03:01 PM, Doug Lea wrote: >> This is an issue of large importance to a small audience, >> and is at the moment an orphan. To work out, I think it >> requires at least some involvement from compiler and/or IDE >> developers. If you are or know of someone who might be interested >> in pursuing, please encourage them/yourself to consider it. > > At the minimum, all this needs is an empty native method. That's not > the most efficient long-term solution but it is enough. > Right. The reachabilityFence method itself is already in jdk9/sandbox (thanks to Aleksey). The annotation isn't, and can't be until compiler and IDE folks discuss whether and how to support it. -Doug From ysr1729 at gmail.com Tue Aug 25 19:56:15 2015 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 25 Aug 2015 12:56:15 -0700 Subject: race condition in GC logs In-Reply-To: References: <9E79C717-7C53-49F5-AD0F-C003A03F11E5@kodewerk.com> <55D30D50.8060302@oracle.com> <55D32774.2090903@oracle.com> Message-ID: -bcc/hotspot-dev +cc/hotspot-gc-dev I have a patch for JDK-8133818 (on JDK 8): as suggested here earlier, besides splitting out Cleaners, it also reports JNI wk refs by counting them on-the-fly much like for other Reference types. I'll attach it to the ticket once my testing completes. thanks. -- ramki On Wed, Aug 19, 2015 at 3:20 PM, Kirk Pepperdine wrote: > Hi Bengt, > > Thanks for filing. I really didn?t consider this a bug but it seems > reasonable to add clarity in the log. > > ? Kirk > > > On Aug 18, 2015, at 8:39 AM, Bengt Rutisson > wrote: > > > > > > > > On 2015-08-18 12:47, Bengt Rutisson wrote: > >> > >> Hi Kirk, > >> > >> On 2015-08-18 12:31, Kirk Pepperdine wrote: > >>> Hi all, > >>> > >>> I found this.. in a few logs. Before I started trolling the source > trying to sort out what the second PhantomReferences count was, I pinged > Charlie and asked him. He suggested it was a (concurrency??) bug witnessed > only once by someone else. I?ve now seen it in several logs where the > numbers reported are different. Sorry for being lazy for not trolling the > code before asking but is this a bug? > >> > >> The second ref count is for cleaner references. They used to be treated > the same way as phantom references, but a recent improvement was to > separate the handling of the cleaners to after all phantom references have > been handled. So, the first count is the "real" phantom references and the > second count is the cleaner references. > >> > >> It's confusing logging, I agree. > >> > >> This came in with this fix: > >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2194fdf3fbd9 > >> > >> since this adds one more call to preclean_discovered_reflist(), which > is the method that prints the refs count. > > > > Thomas was nice and created a bug report for this :) > > > > Additional number of processed references printed with > -XX:+PrintReferenceGC after JDK-8047125 > > https://bugs.openjdk.java.net/browse/JDK-8133818 > > > > Bengt > > > >> > >> Thanks, > >> Bengt > >> > >>> > >>> Regards, > >>> Kirk > >>> > >>> Java HotSpot(TM) 64-Bit Server VM (25.51-b03) for linux-amd64 JRE > (1.8.0_51-b16), built on Jun 8 2015 19:28:07 by "java_re" with gcc 4.3.0 > 20080428 (Red Hat 4.3.0-8) > >>> Memory: 4k page, physical 9570132k(9340292k free), swap > 4095996k(4095996k free) > >>> CommandLine flags: -XX:+AggressiveOpts -XX:G1HeapRegionSize=16777216 > -XX:InitialHeapSize=3221225472 -XX:InitiatingHeapOccupancyPercent=75 > -XX:+ManagementServer -XX:MaxGCPauseMillis=250 -XX:MaxHeapSize=3221225472 > -XX:+ParallelRefProcEnabled -XX:+PerfDisableSharedMem > -XX:+PrintAdaptiveSizePolicy -XX:+PrintGC > -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps > -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC > -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers > -XX:+UseCompressedOops -XX:+UseG1GC -XX:+UseLargePages > >>> 0.198: [G1Ergonomics (Heap Sizing) expand the heap, requested > expansion amount: 3221225472 bytes, attempted expansion amount: 3221225472 > bytes] > >>> 2015-08-11T08:23:02.219+0200: 7.630: [GC pause (G1 Evacuation Pause) > (young) > >>> Desired survivor size 16777216 bytes, new threshold 15 (max 15) > >>> 7.631: [G1Ergonomics (CSet Construction) start choosing CSet, > _pending_cards: 0, predicted base time: 10.00 ms, remaining time: 240.00 > ms, target pause time: 250.00 ms] > >>> 7.631: [G1Ergonomics (CSet Construction) add young regions to CSet, > eden: 9 regions, survivors: 0 regions, predicted young region time: 3626.58 > ms] > >>> 7.631: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: > 9 regions, survivors: 0 regions, old: 0 regions, predicted pause time: > 3636.58 ms, target pause time: 250.00 ms] > >>> 7.642: [SoftReference, 0 refs, 0.0006965 secs]7.643: [WeakReference, > 40 refs, 0.0003039 secs]7.643: [FinalReference, 3477 refs, 0.0036191 > secs]7.647: [PhantomReference, 0 refs, 0 refs, 0.0006649 secs]7.647: [JNI > Weak Reference, 0.0000119 secs], 0.0173298 secs] > >> > > > > From derek.white at oracle.com Wed Aug 26 17:59:33 2015 From: derek.white at oracle.com (Derek White) Date: Wed, 26 Aug 2015 13:59:33 -0400 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DB8DAB.6030501@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> Message-ID: <55DDFE85.3080904@oracle.com> Hi Sangheon, I haven't reviewed the actual ranges and constraints yet, but one thing you might want to consider: For the test cases, you may want synchronize the GC specified to ProcessBuilder with the "@requires gc=" tags. This prevents the test harness from running G1 tests when the test harness is trying to run CMS test, etc, and also avoids potential confusing test failures. @requires vm.gc=="G1" | vm.gc=="null" (or specify Parallel GC as needed). This is for: TestG1ConcMarkStepDurationMillis.java (G1) TestObjectTenuringFlags.java (Parallel) TestInitialTenuringThreshold.java (Parallel) TestG1HeapRegionSize.java (G1) - Derek On 8/24/15 5:33 PM, sangheon.kim wrote: > Hi Kim, > > On 08/24/2015 02:16 PM, Kim Barrett wrote: >> On Aug 24, 2015, at 3:06 PM, sangheon.kim >> wrote: >>> Hi Kim, >>> >>> Here's webrev.03 which includes your comment for MarkStackSize >>> constraint function. >>> >>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>> >>> And all your comments will be managed by >>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >> If the value of MarkStackSizeMax were changed later, there's nothing >> to verify MarkStackSize is still smaller. [This is related to my >> earlier comment about constraints between options being tested twice >> and failures reported twice.] Do we care in this case? > If your concern is something like > -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. > Yes, in this case the order is important as ranges and constraint > functions are verified by its order. > MarkStackSizeMax will be verified first(its range) and MarkStackSize > will be compared with verified MarkStackSizeMax. > > And as I said your original concern is current limitation. > If we set CMSOldPLABMin and CMSOldPLABMax together with invalid values > (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), > they will print out 2 failure messages. > > Thanks, > Sangheon > >> >> Other than that, looks good. >> > From gerard.ziemski at oracle.com Wed Aug 26 18:05:14 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Wed, 26 Aug 2015 13:05:14 -0500 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DB8DAB.6030501@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> Message-ID: <55DDFFDA.8060909@oracle.com> hi Sangheon, If you are still working on the webrev, can you please update INITIAL_RANGES_SIZE and INITIAL_CONSTRAINTS_SIZE initial values to account for the new ranges and constraint, so that we avoid dynamically resizing memory at startup? If you don't get to it, then that it's OK too - I will make sure they have their values updated in my upcoming webrev. cheers On 08/24/2015 04:33 PM, sangheon.kim wrote: > Hi Kim, > > On 08/24/2015 02:16 PM, Kim Barrett wrote: >> On Aug 24, 2015, at 3:06 PM, sangheon.kim wrote: >>> Hi Kim, >>> >>> Here's webrev.03 which includes your comment for MarkStackSize constraint function. >>> >>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>> >>> And all your comments will be managed by https://bugs.openjdk.java.net/browse/JDK-8134348 . >> If the value of MarkStackSizeMax were changed later, there's nothing >> to verify MarkStackSize is still smaller. [This is related to my >> earlier comment about constraints between options being tested twice >> and failures reported twice.] Do we care in this case? > If your concern is something like > -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. > Yes, in this case the order is important as ranges and constraint functions are verified by its order. > MarkStackSizeMax will be verified first(its range) and MarkStackSize will be compared with verified MarkStackSizeMax. > > And as I said your original concern is current limitation. > If we set CMSOldPLABMin and CMSOldPLABMax together with invalid values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), > they will print out 2 failure messages. > > Thanks, > Sangheon > >> >> Other than that, looks good. >> > > > From kim.barrett at oracle.com Wed Aug 26 18:37:19 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 26 Aug 2015 14:37:19 -0400 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 In-Reply-To: <55DDA6A9.3070909@oracle.com> References: <55DC7B4D.4010505@oracle.com> <887B4B02-6530-4E23-BCA0-E41B7DE3368E@oracle.com> <55DD30BF.40604@oracle.com> <55DDA6A9.3070909@oracle.com> Message-ID: <6B336485-5BE0-4154-820E-41D6F8C1BB3E@oracle.com> On Aug 26, 2015, at 7:44 AM, Erik Joelsson wrote: > > Further investigation revealed that this "error" was actually just a warning being upgraded to error by -errwarn. The warning is only activated by +w, which is turned on for adlc but not for the rest of the hotspot build. Based on this, I have revised my proposal to just disabling this warning for adlc and the particular compiler version. > > Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev.01/ I think the new approach is good, e.g. disable the specific warning. However, only doing so for this one compiler rev (I assume 513 corresponds to SS12u4?) seems like a mistake to me. I don't expect the warning to go away with future compiler versions. From sangheon.kim at oracle.com Wed Aug 26 18:41:44 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 26 Aug 2015 11:41:44 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DDFFDA.8060909@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFFDA.8060909@oracle.com> Message-ID: <55DE0868.1010802@oracle.com> Hi Gerard, On 08/26/2015 11:05 AM, gerard ziemski wrote: > hi Sangheon, > > If you are still working on the webrev, can you please update > INITIAL_RANGES_SIZE and INITIAL_CONSTRAINTS_SIZE initial values to > account for the new ranges and constraint, so that we avoid > dynamically resizing memory at startup? Oh, you are right. Thank you for the comment. I will change them to current actual sizes of 'range=165' and 'constraint=40'. These will be included on next webrev. Thanks, Sangheon > > If you don't get to it, then that it's OK too - I will make sure they > have their values updated in my upcoming webrev. > > > cheers > > On 08/24/2015 04:33 PM, sangheon.kim wrote: >> Hi Kim, >> >> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>> wrote: >>>> Hi Kim, >>>> >>>> Here's webrev.03 which includes your comment for MarkStackSize >>>> constraint function. >>>> >>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>> >>>> And all your comments will be managed by >>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>> If the value of MarkStackSizeMax were changed later, there's nothing >>> to verify MarkStackSize is still smaller. [This is related to my >>> earlier comment about constraints between options being tested twice >>> and failures reported twice.] Do we care in this case? >> If your concern is something like >> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >> Yes, in this case the order is important as ranges and constraint >> functions are verified by its order. >> MarkStackSizeMax will be verified first(its range) and MarkStackSize >> will be compared with verified MarkStackSizeMax. >> >> And as I said your original concern is current limitation. >> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >> they will print out 2 failure messages. >> >> Thanks, >> Sangheon >> >>> >>> Other than that, looks good. >>> >> >> >> From sangheon.kim at oracle.com Wed Aug 26 18:51:06 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 26 Aug 2015 11:51:06 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DDFE85.3080904@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> Message-ID: <55DE0A9A.5030806@oracle.com> Hi Derek, Thank you for looking at this! On 08/26/2015 10:59 AM, Derek White wrote: > Hi Sangheon, > > I haven't reviewed the actual ranges and constraints yet, but one > thing you might want to consider: > > For the test cases, you may want synchronize the GC specified to > ProcessBuilder with the "@requires gc=" tags. This prevents the test > harness from running G1 tests when the test harness is trying to run > CMS test, etc, and also avoids potential confusing test failures. > > @requires vm.gc=="G1" | vm.gc=="null" > (or specify Parallel GC as needed). Thank you for the explanation. I didn't know about this. So it seems like vm.gc=="null" means not specifying vm option. > > This is for: > TestG1ConcMarkStepDurationMillis.java (G1) > TestObjectTenuringFlags.java (Parallel) > TestInitialTenuringThreshold.java (Parallel) > TestG1HeapRegionSize.java (G1) Okay, I will add these tags at next webrev. Thanks, Sangheon > > - Derek > > On 8/24/15 5:33 PM, sangheon.kim wrote: >> Hi Kim, >> >> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>> wrote: >>>> Hi Kim, >>>> >>>> Here's webrev.03 which includes your comment for MarkStackSize >>>> constraint function. >>>> >>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>> >>>> And all your comments will be managed by >>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>> If the value of MarkStackSizeMax were changed later, there's nothing >>> to verify MarkStackSize is still smaller. [This is related to my >>> earlier comment about constraints between options being tested twice >>> and failures reported twice.] Do we care in this case? >> If your concern is something like >> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >> Yes, in this case the order is important as ranges and constraint >> functions are verified by its order. >> MarkStackSizeMax will be verified first(its range) and MarkStackSize >> will be compared with verified MarkStackSizeMax. >> >> And as I said your original concern is current limitation. >> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >> they will print out 2 failure messages. >> >> Thanks, >> Sangheon >> >>> >>> Other than that, looks good. >>> >> > From aleksey.shipilev at oracle.com Wed Aug 26 19:01:53 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 26 Aug 2015 22:01:53 +0300 Subject: @Finalized In-Reply-To: <55DDD620.2000500@cs.oswego.edu> References: <55DDC69D.5090904@cs.oswego.edu> <55DDC95A.5000701@redhat.com> <55DDD620.2000500@cs.oswego.edu> Message-ID: <55DE0D21.8050207@oracle.com> On 08/26/2015 06:07 PM, Doug Lea wrote: > On 08/26/2015 10:12 AM, Andrew Haley wrote: >> On 08/26/2015 03:01 PM, Doug Lea wrote: >>> This is an issue of large importance to a small audience, >>> and is at the moment an orphan. To work out, I think it >>> requires at least some involvement from compiler and/or IDE >>> developers. If you are or know of someone who might be interested >>> in pursuing, please encourage them/yourself to consider it. >> >> At the minimum, all this needs is an empty native method. That's not >> the most efficient long-term solution but it is enough. > > Right. The reachabilityFence method itself is already in > jdk9/sandbox (thanks to Aleksey). Well, it's not really pushed anywhere yet: https://bugs.openjdk.java.net/browse/JDK-8133348 -Aleksey From adinn at redhat.com Wed Aug 26 19:04:56 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 26 Aug 2015 20:04:56 +0100 Subject: @Finalized In-Reply-To: <55DE0D21.8050207@oracle.com> References: <55DDC69D.5090904@cs.oswego.edu> <55DDC95A.5000701@redhat.com> <55DDD620.2000500@cs.oswego.edu> <55DE0D21.8050207@oracle.com> Message-ID: <55DE0DD8.9060901@redhat.com> On 26/08/15 20:01, Aleksey Shipilev wrote: > On 08/26/2015 06:07 PM, Doug Lea wrote: >> On 08/26/2015 10:12 AM, Andrew Haley wrote: >>> On 08/26/2015 03:01 PM, Doug Lea wrote: >>>> This is an issue of large importance to a small audience, >>>> and is at the moment an orphan. To work out, I think it >>>> requires at least some involvement from compiler and/or IDE >>>> developers. If you are or know of someone who might be interested >>>> in pursuing, please encourage them/yourself to consider it. >>> >>> At the minimum, all this needs is an empty native method. That's not >>> the most efficient long-term solution but it is enough. >> >> Right. The reachabilityFence method itself is already in >> jdk9/sandbox (thanks to Aleksey). > > Well, it's not really pushed anywhere yet: > https://bugs.openjdk.java.net/browse/JDK-8133348 Well, that was easy. What did you do in the afternoon? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From jon.masamitsu at oracle.com Wed Aug 26 20:57:36 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 26 Aug 2015 13:57:36 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DE0A9A.5030806@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> Message-ID: <55DE2840.7040306@oracle.com> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/runtime/commandLineFlagConstraintsGC.cpp.frames.html Seems to me that a user should be able to set the default value for a flag on the command line without getting an error. Below if I set G1RSetRegionEntries to 0, I get a constraint violation. 271 Flag::Error G1RSetRegionEntriesConstraintFunc(intx value, bool verbose) { 272 if (!UseG1GC) return Flag::SUCCESS; 273 274 // Default value of G1RSetRegionEntries=0 means will be set ergonomically. 275 // Minimum value is 1. 276 if (FLAG_IS_CMDLINE(G1RSetRegionEntries) && (value < 1)) { 277 CommandLineError::print(verbose, 278 "G1RSetRegionEntries (" INTX_FORMAT ") must be " 279 "greater than or equal to 1\n", 280 value); 281 return Flag::VIOLATES_CONSTRAINT; 282 } else { 283 return Flag::SUCCESS; 284 } 285 } On 8/26/2015 11:51 AM, sangheon.kim wrote: > Hi Derek, > > Thank you for looking at this! > > On 08/26/2015 10:59 AM, Derek White wrote: >> Hi Sangheon, >> >> I haven't reviewed the actual ranges and constraints yet, but one >> thing you might want to consider: >> >> For the test cases, you may want synchronize the GC specified to >> ProcessBuilder with the "@requires gc=" tags. This prevents the test >> harness from running G1 tests when the test harness is trying to run >> CMS test, etc, and also avoids potential confusing test failures. >> >> @requires vm.gc=="G1" | vm.gc=="null" >> (or specify Parallel GC as needed). > Thank you for the explanation. > I didn't know about this. > > So it seems like vm.gc=="null" means not specifying vm option. > >> >> This is for: >> TestG1ConcMarkStepDurationMillis.java (G1) >> TestObjectTenuringFlags.java (Parallel) >> TestInitialTenuringThreshold.java (Parallel) >> TestG1HeapRegionSize.java (G1) > Okay, I will add these tags at next webrev. > > Thanks, > Sangheon > > >> >> - Derek >> >> On 8/24/15 5:33 PM, sangheon.kim wrote: >>> Hi Kim, >>> >>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>> wrote: >>>>> Hi Kim, >>>>> >>>>> Here's webrev.03 which includes your comment for MarkStackSize >>>>> constraint function. >>>>> >>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>> >>>>> And all your comments will be managed by >>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>> If the value of MarkStackSizeMax were changed later, there's nothing >>>> to verify MarkStackSize is still smaller. [This is related to my >>>> earlier comment about constraints between options being tested twice >>>> and failures reported twice.] Do we care in this case? >>> If your concern is something like >>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>> Yes, in this case the order is important as ranges and constraint >>> functions are verified by its order. >>> MarkStackSizeMax will be verified first(its range) and MarkStackSize >>> will be compared with verified MarkStackSizeMax. >>> >>> And as I said your original concern is current limitation. >>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>> they will print out 2 failure messages. >>> >>> Thanks, >>> Sangheon >>> >>>> >>>> Other than that, looks good. >>>> >>> >> > From jon.masamitsu at oracle.com Wed Aug 26 21:10:05 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 26 Aug 2015 14:10:05 -0700 Subject: Fwd: Re: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DE22CE.7080600@oracle.com> References: <55DE22CE.7080600@oracle.com> Message-ID: <55DE2B2D.9070605@oracle.com> Forwarding to list -------- Forwarded Message -------- Subject: Re: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing Date: Wed, 26 Aug 2015 13:34:22 -0700 From: Jon Masamitsu Organization: Oracle Corporation To: sangheon.kim http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/gc/g1/g1_globals.hpp.frames.html How was the 1*G maximum chosen? 114 product(size_t, G1UpdateBufferSize, 256, \ 115 "Size of an update buffer") \ 116 range(1, 1*G) Maybe this was already discussed? Jon On 8/26/2015 11:51 AM, sangheon.kim wrote: > Hi Derek, > > Thank you for looking at this! > > On 08/26/2015 10:59 AM, Derek White wrote: >> Hi Sangheon, >> >> I haven't reviewed the actual ranges and constraints yet, but one >> thing you might want to consider: >> >> For the test cases, you may want synchronize the GC specified to >> ProcessBuilder with the "@requires gc=" tags. This prevents the test >> harness from running G1 tests when the test harness is trying to run >> CMS test, etc, and also avoids potential confusing test failures. >> >> @requires vm.gc=="G1" | vm.gc=="null" >> (or specify Parallel GC as needed). > Thank you for the explanation. > I didn't know about this. > > So it seems like vm.gc=="null" means not specifying vm option. > >> >> This is for: >> TestG1ConcMarkStepDurationMillis.java (G1) >> TestObjectTenuringFlags.java (Parallel) >> TestInitialTenuringThreshold.java (Parallel) >> TestG1HeapRegionSize.java (G1) > Okay, I will add these tags at next webrev. > > Thanks, > Sangheon > > >> >> - Derek >> >> On 8/24/15 5:33 PM, sangheon.kim wrote: >>> Hi Kim, >>> >>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>> wrote: >>>>> Hi Kim, >>>>> >>>>> Here's webrev.03 which includes your comment for MarkStackSize >>>>> constraint function. >>>>> >>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>> >>>>> And all your comments will be managed by >>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>> If the value of MarkStackSizeMax were changed later, there's nothing >>>> to verify MarkStackSize is still smaller. [This is related to my >>>> earlier comment about constraints between options being tested twice >>>> and failures reported twice.] Do we care in this case? >>> If your concern is something like >>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>> Yes, in this case the order is important as ranges and constraint >>> functions are verified by its order. >>> MarkStackSizeMax will be verified first(its range) and MarkStackSize >>> will be compared with verified MarkStackSizeMax. >>> >>> And as I said your original concern is current limitation. >>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>> they will print out 2 failure messages. >>> >>> Thanks, >>> Sangheon >>> >>>> >>>> Other than that, looks good. >>>> >>> >> > From jon.masamitsu at oracle.com Wed Aug 26 21:56:34 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 26 Aug 2015 14:56:34 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DE2682.8020209@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE22CE.7080600@oracle.com> <55DE2682.8020209@oracle.com> Message-ID: <55DE3612.80101@oracle.com> On 8/26/2015 1:50 PM, sangheon.kim wrote: > Hi Jon, > > On 08/26/2015 01:34 PM, Jon Masamitsu wrote: >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/gc/g1/g1_globals.hpp.frames.html >> >> >> How was the 1*G maximum chosen? >> >> 114 product(size_t, G1UpdateBufferSize, >> 256, \ >> 115 "Size of an update >> buffer") \ >> 116 range(1, 1*G) >> >> >> Maybe this was already discussed? > You have eagles eye! :) > Personally I asked to Thomas and his suggestion was 'I think something > in the MB range should be "enough" '. > > I know that 1G is quite different from MB range but I wanted to find > not making problem range. > One point that would make problem is > 'G1CollectedHeap::pending_card_num()'. > '(buffer_size * buffer_num + extra_cards)' should not overflow and I > think 1G would be safe enough. 1G seems too large on a 32bit system. I don't know how large buffer_num can get but can image it can get large in some instances. Having said that this is not necessarily something that can be fixed at flag validation time. This may be one of those cases where the calculated numbers are too dynamic to catch early. If you can make the check different on a 32bit system, 32M might be a better number on a 32bit system. Leave it 1G on a 64bit system. Jon > But I know that it is too large as a buffer size. :( > Any suggestion for this? > > Sangheon > > >> >> Jon >> >> On 8/26/2015 11:51 AM, sangheon.kim wrote: >>> Hi Derek, >>> >>> Thank you for looking at this! >>> >>> On 08/26/2015 10:59 AM, Derek White wrote: >>>> Hi Sangheon, >>>> >>>> I haven't reviewed the actual ranges and constraints yet, but one >>>> thing you might want to consider: >>>> >>>> For the test cases, you may want synchronize the GC specified to >>>> ProcessBuilder with the "@requires gc=" tags. This prevents the >>>> test harness from running G1 tests when the test harness is trying >>>> to run CMS test, etc, and also avoids potential confusing test >>>> failures. >>>> >>>> @requires vm.gc=="G1" | vm.gc=="null" >>>> (or specify Parallel GC as needed). >>> Thank you for the explanation. >>> I didn't know about this. >>> >>> So it seems like vm.gc=="null" means not specifying vm option. >>> >>>> >>>> This is for: >>>> TestG1ConcMarkStepDurationMillis.java (G1) >>>> TestObjectTenuringFlags.java (Parallel) >>>> TestInitialTenuringThreshold.java (Parallel) >>>> TestG1HeapRegionSize.java (G1) >>> Okay, I will add these tags at next webrev. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> - Derek >>>> >>>> On 8/24/15 5:33 PM, sangheon.kim wrote: >>>>> Hi Kim, >>>>> >>>>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>>>> wrote: >>>>>>> Hi Kim, >>>>>>> >>>>>>> Here's webrev.03 which includes your comment for MarkStackSize >>>>>>> constraint function. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>>>> >>>>>>> And all your comments will be managed by >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>>>> If the value of MarkStackSizeMax were changed later, there's nothing >>>>>> to verify MarkStackSize is still smaller. [This is related to my >>>>>> earlier comment about constraints between options being tested twice >>>>>> and failures reported twice.] Do we care in this case? >>>>> If your concern is something like >>>>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>>>> Yes, in this case the order is important as ranges and constraint >>>>> functions are verified by its order. >>>>> MarkStackSizeMax will be verified first(its range) and >>>>> MarkStackSize will be compared with verified MarkStackSizeMax. >>>>> >>>>> And as I said your original concern is current limitation. >>>>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>>>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>>>> they will print out 2 failure messages. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>>> >>>>>> Other than that, looks good. >>>>>> >>>>> >>>> >>> >> > From sangheon.kim at oracle.com Wed Aug 26 22:18:50 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 26 Aug 2015 15:18:50 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DE2840.7040306@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE2840.7040306@oracle.com> Message-ID: <55DE3B4A.4030602@oracle.com> Hi Jon, Thank you for the review. On 08/26/2015 01:57 PM, Jon Masamitsu wrote: > http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/runtime/commandLineFlagConstraintsGC.cpp.frames.html > > > Seems to me that a user should be able to set the default value for > a flag on the command line without getting an error. Below if I set > G1RSetRegionEntries to 0, I get a constraint violation. I agree with you. Let me change both constraint functions(G1RSetRegionEntries, G1RSetSparseRegionEntries) and related codes(HeapRegionRemSet::setup_remset_size). FYI, if we don't stop with zero by constraint function, it fires assert under current code. These will be included at next webrev. Thanks, Sangheon > > 271 Flag::Error G1RSetRegionEntriesConstraintFunc(intx value, bool > verbose) { > 272 if (!UseG1GC) return Flag::SUCCESS; > 273 > 274 // Default value of G1RSetRegionEntries=0 means will be set > ergonomically. > 275 // Minimum value is 1. > 276 if (FLAG_IS_CMDLINE(G1RSetRegionEntries) && (value < 1)) { > 277 CommandLineError::print(verbose, > 278 "G1RSetRegionEntries (" INTX_FORMAT ") must be " > 279 "greater than or equal to 1\n", > 280 value); > 281 return Flag::VIOLATES_CONSTRAINT; > 282 } else { > 283 return Flag::SUCCESS; > 284 } > 285 } > > > > On 8/26/2015 11:51 AM, sangheon.kim wrote: >> Hi Derek, >> >> Thank you for looking at this! >> >> On 08/26/2015 10:59 AM, Derek White wrote: >>> Hi Sangheon, >>> >>> I haven't reviewed the actual ranges and constraints yet, but one >>> thing you might want to consider: >>> >>> For the test cases, you may want synchronize the GC specified to >>> ProcessBuilder with the "@requires gc=" tags. This prevents the test >>> harness from running G1 tests when the test harness is trying to run >>> CMS test, etc, and also avoids potential confusing test failures. >>> >>> @requires vm.gc=="G1" | vm.gc=="null" >>> (or specify Parallel GC as needed). >> Thank you for the explanation. >> I didn't know about this. >> >> So it seems like vm.gc=="null" means not specifying vm option. >> >>> >>> This is for: >>> TestG1ConcMarkStepDurationMillis.java (G1) >>> TestObjectTenuringFlags.java (Parallel) >>> TestInitialTenuringThreshold.java (Parallel) >>> TestG1HeapRegionSize.java (G1) >> Okay, I will add these tags at next webrev. >> >> Thanks, >> Sangheon >> >> >>> >>> - Derek >>> >>> On 8/24/15 5:33 PM, sangheon.kim wrote: >>>> Hi Kim, >>>> >>>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>>> wrote: >>>>>> Hi Kim, >>>>>> >>>>>> Here's webrev.03 which includes your comment for MarkStackSize >>>>>> constraint function. >>>>>> >>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>>> >>>>>> And all your comments will be managed by >>>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>>> If the value of MarkStackSizeMax were changed later, there's nothing >>>>> to verify MarkStackSize is still smaller. [This is related to my >>>>> earlier comment about constraints between options being tested twice >>>>> and failures reported twice.] Do we care in this case? >>>> If your concern is something like >>>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>>> Yes, in this case the order is important as ranges and constraint >>>> functions are verified by its order. >>>> MarkStackSizeMax will be verified first(its range) and >>>> MarkStackSize will be compared with verified MarkStackSizeMax. >>>> >>>> And as I said your original concern is current limitation. >>>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>>> they will print out 2 failure messages. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>>> >>>>> Other than that, looks good. >>>>> >>>> >>> >> > From sangheon.kim at oracle.com Wed Aug 26 22:30:41 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 26 Aug 2015 15:30:41 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DE3612.80101@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE22CE.7080600@oracle.com> <55DE2682.8020209@oracle.com> <55DE3612.80101@oracle.com> Message-ID: <55DE3E11.4010505@oracle.com> On 08/26/2015 02:56 PM, Jon Masamitsu wrote: > > > On 8/26/2015 1:50 PM, sangheon.kim wrote: >> Hi Jon, >> >> On 08/26/2015 01:34 PM, Jon Masamitsu wrote: >>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/gc/g1/g1_globals.hpp.frames.html >>> >>> >>> How was the 1*G maximum chosen? >>> >>> 114 product(size_t, G1UpdateBufferSize, >>> 256, \ >>> 115 "Size of an update >>> buffer") \ >>> 116 range(1, 1*G) >>> >>> >>> Maybe this was already discussed? >> You have eagles eye! :) >> Personally I asked to Thomas and his suggestion was 'I think >> something in the MB range should be "enough" '. >> >> I know that 1G is quite different from MB range but I wanted to find >> not making problem range. >> One point that would make problem is >> 'G1CollectedHeap::pending_card_num()'. >> '(buffer_size * buffer_num + extra_cards)' should not overflow and I >> think 1G would be safe enough. > > 1G seems too large on a 32bit system. I don't know how large buffer_num > can get but can image it can get large in some instances. > > Having said that this is not necessarily something that can be fixed at > flag validation time. This may be one of those cases where the > calculated > numbers are too dynamic to catch early. If you can make the check > different on a 32bit system, 32M might be a better number on a > 32bit system. Leave it 1G on a 64bit system. Okay, I will change as you mentioned. range(1, NOT_LP64(32*M) LP64_ONLY(1*G)) This will be included at next webrev. Thanks, Sangheon > > Jon > >> But I know that it is too large as a buffer size. :( >> Any suggestion for this? >> >> Sangheon >> >> >>> >>> Jon >>> >>> On 8/26/2015 11:51 AM, sangheon.kim wrote: >>>> Hi Derek, >>>> >>>> Thank you for looking at this! >>>> >>>> On 08/26/2015 10:59 AM, Derek White wrote: >>>>> Hi Sangheon, >>>>> >>>>> I haven't reviewed the actual ranges and constraints yet, but one >>>>> thing you might want to consider: >>>>> >>>>> For the test cases, you may want synchronize the GC specified to >>>>> ProcessBuilder with the "@requires gc=" tags. This prevents the >>>>> test harness from running G1 tests when the test harness is trying >>>>> to run CMS test, etc, and also avoids potential confusing test >>>>> failures. >>>>> >>>>> @requires vm.gc=="G1" | vm.gc=="null" >>>>> (or specify Parallel GC as needed). >>>> Thank you for the explanation. >>>> I didn't know about this. >>>> >>>> So it seems like vm.gc=="null" means not specifying vm option. >>>> >>>>> >>>>> This is for: >>>>> TestG1ConcMarkStepDurationMillis.java (G1) >>>>> TestObjectTenuringFlags.java (Parallel) >>>>> TestInitialTenuringThreshold.java (Parallel) >>>>> TestG1HeapRegionSize.java (G1) >>>> Okay, I will add these tags at next webrev. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> - Derek >>>>> >>>>> On 8/24/15 5:33 PM, sangheon.kim wrote: >>>>>> Hi Kim, >>>>>> >>>>>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>>>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>>>>> wrote: >>>>>>>> Hi Kim, >>>>>>>> >>>>>>>> Here's webrev.03 which includes your comment for MarkStackSize >>>>>>>> constraint function. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>>>>> >>>>>>>> And all your comments will be managed by >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>>>>> If the value of MarkStackSizeMax were changed later, there's >>>>>>> nothing >>>>>>> to verify MarkStackSize is still smaller. [This is related to my >>>>>>> earlier comment about constraints between options being tested >>>>>>> twice >>>>>>> and failures reported twice.] Do we care in this case? >>>>>> If your concern is something like >>>>>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>>>>> Yes, in this case the order is important as ranges and constraint >>>>>> functions are verified by its order. >>>>>> MarkStackSizeMax will be verified first(its range) and >>>>>> MarkStackSize will be compared with verified MarkStackSizeMax. >>>>>> >>>>>> And as I said your original concern is current limitation. >>>>>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>>>>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>>>>> they will print out 2 failure messages. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>>> >>>>>>> Other than that, looks good. >>>>>>> >>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Wed Aug 26 22:56:57 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Aug 2015 08:56:57 +1000 Subject: RFR: 8133646: Internal Error: x86/vm/macroAssembler_x86.cpp:886 DEBUG MESSAGE: StubRoutines::call_stub: threads must correspond In-Reply-To: <55DDB94E.7070507@oracle.com> References: <55DC0605.6080400@oracle.com> <55DC97B4.5020204@oracle.com> <55DD21AF.9020104@oracle.com> <55DDB94E.7070507@oracle.com> Message-ID: <55DE4439.4010409@oracle.com> On 26/08/2015 11:04 PM, Daniel D. Daugherty wrote: > > On 8/25/15 8:17 PM, David Holmes wrote: >> Hi Coleen, >> >> Thanks for the review. >> >> On 26/08/2015 2:28 AM, Coleen Phillimore wrote: >>> >>> David, >>> Can you add this duplicate code into a verify_thread() function? This >>> would help if we are ever able to combine common code in >>> stubRoutines_x86_32/64.cpp >> >> I'm so grateful you posed that as a question not a request. :) Answer: >> no. >> >> The duplicated structure is pre-existing, and the error messages >> differ so the context would have to be passed in. I'm totally >> unfamiliar with playing in the macroassembler so would be unsure how >> to factor this out into a separate function without messing up >> register usage, or using the correct "variables" from the "calling >> context". >> >> Also note that for some reason these sanity checks don't exist on >> x86_32, nor sparc (only aarch64 also has it presumably based on the >> x86_64 version). I think the time to factor this out would be if/when >> we do the code combining. > > We do have a similar check on x86_32: > > src/cpu/x86/vm/stubGenerator_x86_32.cpp: > > 343 address generate_catch_exception() { > > 351 #ifdef ASSERT > 352 // verify that threads correspond > 353 { Label L; > 354 __ get_thread(rbx); > 355 __ cmpptr(rbx, rcx); > 356 __ jcc(Assembler::equal, L); > 357 __ stop("StubRoutines::catch_exception: threads must > correspond"); > 358 __ bind(L); > 359 } > 360 #endif > > The check is much simpler because we don't have enough registers > on x86_32 to set aside one for the thread. Thanks Dan. Yes I misspoke. I had seen this but as it only has one check there was no need for any additional diagnostics. > On SPARC we have this: > > src/cpu/sparc/vm/stubGenerator_sparc.cpp: > > 322 address generate_catch_exception() { > > 326 // verify that thread corresponds > 327 __ verify_thread(); > > There are lots of other calls to verify_thread() sprinkled > through the SPARC code... > > src/cpu/sparc/vm/macroAssembler_sparc.cpp: > > 398 void MacroAssembler::verify_thread() { > 399 if (VerifyThread) { > 400 // NOTE: this chops off the heads of the 64-bit O registers. > 401 #ifdef CC_INTERP > 402 save_frame(0); > 403 #else > 404 // make sure G2_thread contains the right value > 405 save_frame_and_mov(0, Lmethod, Lmethod); // to avoid > clobbering O0 > (and propagate Lmethod for -Xprof) > 406 mov(G1, L1); // avoid clobbering G1 > 407 // G2 saved below > 408 mov(G3, L3); // avoid clobbering G3 > 409 mov(G4, L4); // avoid clobbering G4 > 410 mov(G5_method, L5); // avoid clobbering G5_method > 411 #endif /* CC_INTERP */ > 412 #if defined(COMPILER2) && !defined(_LP64) > 413 // Save & restore possible 64-bit Long arguments in G-regs > 414 srlx(G1,32,L0); > 415 srlx(G4,32,L6); > 416 #endif > 417 call(CAST_FROM_FN_PTR(address,verify_thread_subroutine), > relocInfo:: > runtime_call_type); > 418 delayed()->mov(G2_thread, O0); > 419 > 420 mov(L1, G1); // Restore G1 > 421 // G2 restored below > 422 mov(L3, G3); // restore G3 > 423 mov(L4, G4); // restore G4 > 424 mov(L5, G5_method); // restore G5_method > 425 #if defined(COMPILER2) && !defined(_LP64) > 426 // Save & restore possible 64-bit Long arguments in G-regs > 427 sllx(L0,32,G2); // Move old high G1 bits high > in G2 > 428 srl(G1, 0,G1); // Clear current high G1 bits > 429 or3 (G1,G2,G1); // Recover 64-bit G1 > 430 sllx(L6,32,G2); // Move old high G4 bits high > in G2 > 431 srl(G4, 0,G4); // Clear current high G4 bits > 432 or3 (G4,G2,G4); // Recover 64-bit G4 > 433 #endif > 434 restore(O0, 0, G2_thread); > 435 } > 436 } > > Does anyone else have a headache after reading verify_thread()? :-) I hadn't caught this - so thanks very much. Despite the apparent complexity the crux of the above is the call to: static Thread* verify_thread_subroutine(Thread* gthread_value) { Thread* correct_value = ThreadLocalStorage::thread(); guarantee(gthread_value == correct_value, "G2_thread value must be the thread"); return correct_value; } which only does the same single-check that the x32 version does. So bottom line: I'll push the x64 additions. Thanks again, David > Dan > > >> >> Thanks, >> David >> >>> Thanks, >>> Coleen >>> >>> On 8/25/15 2:07 AM, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8133646 >>>> >>>> webrev: http://cr.openjdk.java.net/~dholmes/8133646/webrev/ >>>> >>>> The error raised in this bug was not reproducible - it was only seen >>>> on one machine which was subsequently re-imaged to run Windows. A >>>> similar Solaris system did not reproduce the bug. >>>> >>>> Rather than just close this as not-reproducible I want to push the >>>> enhanced diagnostics that Vladimir provided here: >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019667.html >>>> >>>> >>>> >>>> which I've added to the two chunks of code that perform this thread >>>> sanity check. >>>> >>>> Thanks, >>>> David >>> > From sangheon.kim at oracle.com Thu Aug 27 00:37:10 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 26 Aug 2015 17:37:10 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DE3B4A.4030602@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE2840.7040306@oracle.com> <55DE3B4A.4030602@oracle.com> Message-ID: <55DE5BB6.1090606@oracle.com> Hi Jon, On 08/26/2015 03:18 PM, sangheon.kim wrote: > Hi Jon, > > Thank you for the review. > > On 08/26/2015 01:57 PM, Jon Masamitsu wrote: >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/runtime/commandLineFlagConstraintsGC.cpp.frames.html >> >> >> Seems to me that a user should be able to set the default value for >> a flag on the command line without getting an error. Below if I set >> G1RSetRegionEntries to 0, I get a constraint violation. > I agree with you. > Let me change both constraint functions(G1RSetRegionEntries, > G1RSetSparseRegionEntries) and related > codes(HeapRegionRemSet::setup_remset_size). Looking at the some flags, our codes are working differently for default value of zero vs. manually set value of zero. We are just calling FLAG_IS_DEFAULT(xxx) to check whether it is set(default value) or not. So it seems like xxx=0 is not recognized as default value even though xxx's default value is zero. What do you think? Please look at MaxGCPauseMillis, GCPauseIntervalMillis, G1RSetSparseRegionEntries and G1RSetRegionEntries. Thanks, Sangheon > > FYI, if we don't stop with zero by constraint function, it fires > assert under current code. > > These will be included at next webrev. > > Thanks, > Sangheon > >> >> 271 Flag::Error G1RSetRegionEntriesConstraintFunc(intx value, bool >> verbose) { >> 272 if (!UseG1GC) return Flag::SUCCESS; >> 273 >> 274 // Default value of G1RSetRegionEntries=0 means will be set >> ergonomically. >> 275 // Minimum value is 1. >> 276 if (FLAG_IS_CMDLINE(G1RSetRegionEntries) && (value < 1)) { >> 277 CommandLineError::print(verbose, >> 278 "G1RSetRegionEntries (" INTX_FORMAT ") must be " >> 279 "greater than or equal to 1\n", >> 280 value); >> 281 return Flag::VIOLATES_CONSTRAINT; >> 282 } else { >> 283 return Flag::SUCCESS; >> 284 } >> 285 } >> >> >> >> On 8/26/2015 11:51 AM, sangheon.kim wrote: >>> Hi Derek, >>> >>> Thank you for looking at this! >>> >>> On 08/26/2015 10:59 AM, Derek White wrote: >>>> Hi Sangheon, >>>> >>>> I haven't reviewed the actual ranges and constraints yet, but one >>>> thing you might want to consider: >>>> >>>> For the test cases, you may want synchronize the GC specified to >>>> ProcessBuilder with the "@requires gc=" tags. This prevents the >>>> test harness from running G1 tests when the test harness is trying >>>> to run CMS test, etc, and also avoids potential confusing test >>>> failures. >>>> >>>> @requires vm.gc=="G1" | vm.gc=="null" >>>> (or specify Parallel GC as needed). >>> Thank you for the explanation. >>> I didn't know about this. >>> >>> So it seems like vm.gc=="null" means not specifying vm option. >>> >>>> >>>> This is for: >>>> TestG1ConcMarkStepDurationMillis.java (G1) >>>> TestObjectTenuringFlags.java (Parallel) >>>> TestInitialTenuringThreshold.java (Parallel) >>>> TestG1HeapRegionSize.java (G1) >>> Okay, I will add these tags at next webrev. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> - Derek >>>> >>>> On 8/24/15 5:33 PM, sangheon.kim wrote: >>>>> Hi Kim, >>>>> >>>>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>>>> wrote: >>>>>>> Hi Kim, >>>>>>> >>>>>>> Here's webrev.03 which includes your comment for MarkStackSize >>>>>>> constraint function. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>>>> >>>>>>> And all your comments will be managed by >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>>>> If the value of MarkStackSizeMax were changed later, there's nothing >>>>>> to verify MarkStackSize is still smaller. [This is related to my >>>>>> earlier comment about constraints between options being tested twice >>>>>> and failures reported twice.] Do we care in this case? >>>>> If your concern is something like >>>>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>>>> Yes, in this case the order is important as ranges and constraint >>>>> functions are verified by its order. >>>>> MarkStackSizeMax will be verified first(its range) and >>>>> MarkStackSize will be compared with verified MarkStackSizeMax. >>>>> >>>>> And as I said your original concern is current limitation. >>>>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>>>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>>>> they will print out 2 failure messages. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>>> >>>>>> Other than that, looks good. >>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Thu Aug 27 02:28:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Aug 2015 12:28:43 +1000 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 In-Reply-To: <55DDB4DF.8050804@oracle.com> References: <55DC7B4D.4010505@oracle.com> <887B4B02-6530-4E23-BCA0-E41B7DE3368E@oracle.com> <55DD30BF.40604@oracle.com> <55DDA6A9.3070909@oracle.com> <55DDB4DF.8050804@oracle.com> Message-ID: <55DE75DB.8080900@oracle.com> On 26/08/2015 10:45 PM, David Holmes wrote: > On 26/08/2015 9:44 PM, Erik Joelsson wrote: >> Further investigation revealed that this "error" was actually just a >> warning being upgraded to error by -errwarn. The warning is only >> activated by +w, which is turned on for adlc but not for the rest of the >> hotspot build. Based on this, I have revised my proposal to just >> disabling this warning for adlc and the particular compiler version. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev.01/ > > Sorry but as per bug report I still object to simply hiding this problem > when we don't understand it. The code did not change and the compiler > option did not change, but the new compiler gives this strange warning > the implications of which are unclear. Based on Kim's updates in the bug report I am now more comfortable with disabling the warning. I agree with Kim's comment that we should disable for >= SS12u4. Thanks, David > David > ----- > >> /Erik >> >> On 2015-08-26 05:21, David Holmes wrote: >>> On 26/08/2015 4:13 AM, Kim Barrett wrote: >>>> On Aug 25, 2015, at 10:27 AM, Erik Joelsson >>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> We are working towards upgrading the officially supported compilers >>>>> for JDK 9 and on Solaris, the proposed new compiler is Solaris >>>>> Studio 12 update 4. When attempting to build with that compiler, the >>>>> hotspot build fails very early with: >>>>> >>>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp", >>>>> >>>>> line 2331: Error: Could not find source for >>>>> RegisterForm::addRegClass(const char*). >>>>> >>>>> This can be worked around by adding -template=extdef to the compiler >>>>> flags. I propose we add this just when compiling adlc and for this >>>>> particular version of Solaris Studio. See bug for further discussion >>>>> of the issue. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134157 >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev/ >>>>> >>>>> /Erik >>>> >>>> I don?t think we should make this change. >>> >>> Agreed. The need for the change makes no sense as nothing has changed: >>> the code hasn't changed and the use of this flag has not changed. >>> Hence this seems to be a compiler issue. >>> >>> David >>> ---- >>> >>>> I think a better alternative than mixing different -template options >>>> would be to change adlc to use the ?include model? for template >>>> usage, as discussed in comments in the bug report. >>>> >>>> Also as discussed in the bug report, I don?t think we fully >>>> understand the problem, since there appears to be other code in >>>> hotspot that looks very similar and seemingly ought to run into the >>>> same problem. If only changing adlc as described doesn?t trip over >>>> the same problem with that other code, then I don?t think we actually >>>> understand the problem yet, and can?t evaluate proposed solutions. >>>> >> From jon.masamitsu at oracle.com Thu Aug 27 03:10:36 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 26 Aug 2015 20:10:36 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DE0A9A.5030806@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> Message-ID: <55DE7FAC.90900@oracle.com> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/runtime/commandLineFlagConstraintsGC.cpp.frames.html Minor point. 303 Flag::Error G1YoungSurvRateNumRegionsSummaryConstraintFunc(intx value, bool verbose) { 304 if (!UseG1GC) return Flag::SUCCESS; 305 306 if (value > (intx)HeapRegionBounds::target_number()) { 307 CommandLineError::print(verbose, 308 "G1YoungSurvRateNumRegionsSummary (" INTX_FORMAT ") must be " 309 "less than or equal to region amount (" SIZE_FORMAT ")\n", I think "less than or equal to region count" sounds better ("count" instead of "amount"). http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/gc/g1/g1_globals.hpp.frames.html 261 develop(uintx, G1DummyRegionsPerGC, 0, \ 262 "The number of dummy regions G1 will allocate at the end of " \ 263 "each evacuation pause in order to artificially fill up the " \ 264 "heap and stress the marking implementation.") \ 265 range(0, 1000) Is 1000 large enough? Have I already asked that? Is that enough to fill a 100g heap? More later. Jon On 8/26/2015 11:51 AM, sangheon.kim wrote: > Hi Derek, > > Thank you for looking at this! > > On 08/26/2015 10:59 AM, Derek White wrote: >> Hi Sangheon, >> >> I haven't reviewed the actual ranges and constraints yet, but one >> thing you might want to consider: >> >> For the test cases, you may want synchronize the GC specified to >> ProcessBuilder with the "@requires gc=" tags. This prevents the test >> harness from running G1 tests when the test harness is trying to run >> CMS test, etc, and also avoids potential confusing test failures. >> >> @requires vm.gc=="G1" | vm.gc=="null" >> (or specify Parallel GC as needed). > Thank you for the explanation. > I didn't know about this. > > So it seems like vm.gc=="null" means not specifying vm option. > >> >> This is for: >> TestG1ConcMarkStepDurationMillis.java (G1) >> TestObjectTenuringFlags.java (Parallel) >> TestInitialTenuringThreshold.java (Parallel) >> TestG1HeapRegionSize.java (G1) > Okay, I will add these tags at next webrev. > > Thanks, > Sangheon > > >> >> - Derek >> >> On 8/24/15 5:33 PM, sangheon.kim wrote: >>> Hi Kim, >>> >>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>> wrote: >>>>> Hi Kim, >>>>> >>>>> Here's webrev.03 which includes your comment for MarkStackSize >>>>> constraint function. >>>>> >>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>> >>>>> And all your comments will be managed by >>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>> If the value of MarkStackSizeMax were changed later, there's nothing >>>> to verify MarkStackSize is still smaller. [This is related to my >>>> earlier comment about constraints between options being tested twice >>>> and failures reported twice.] Do we care in this case? >>> If your concern is something like >>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>> Yes, in this case the order is important as ranges and constraint >>> functions are verified by its order. >>> MarkStackSizeMax will be verified first(its range) and MarkStackSize >>> will be compared with verified MarkStackSizeMax. >>> >>> And as I said your original concern is current limitation. >>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>> they will print out 2 failure messages. >>> >>> Thanks, >>> Sangheon >>> >>>> >>>> Other than that, looks good. >>>> >>> >> > From david.holmes at oracle.com Thu Aug 27 04:55:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Aug 2015 14:55:34 +1000 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55DCE602.3040801@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> <55B1119D.4030802@oracle.com> <55C41C20.90208@oracle.com> <55C83C5C.60702@oracle.com> <55C8D456.9030006@oracle.com> <5A08C1CB-58F9-4193-802F-767EE11F4D2B@oracle.com> <55CA4E0E.2070503@oracle.com> <55DB540A.4010804@oracle.com> <55DCE602.3040801@oracle.com> Message-ID: <55DE9846.8050008@oracle.com> On 26/08/2015 8:02 AM, Derek White wrote: > Thanks Karen! > > If I don't get any other feedback, can I get you to sponsor the change > for me? After folding in your fixes... I need to see those fixes first as I got quite confused trying to reconcile the code with the documentation. I'm unclear why is_obsolete doesn't care about EXPIRED but is_deprecated does? Also you often state something like "fits into the range specified" but it is unclear what range you are referring to. Thanks, David > - Derek > > On 8/25/15 2:05 PM, Karen Kinnear wrote: >> Derek, >> >> Many thanks for the latest changes. And thank you for the >> verify_special_jvm_flags -- that will remind us to >> clean up the flags when the version number changes. So the expired_in >> information is for internal use only - we >> don't print that information for users, we simply tell them "in a >> future release". >> >> Looks good. No need for my further code review. >> >> Minor comments: >> 1. arguments.hpp >> line 421 "In the case" -> "In this case" >> >> 2. arguments.cpp comments >> >> I love the high level comments - could you possibly update them? >> - e.g. they still talk about the deprecated_jvm_flags and >> obsolete_jvm_flags tables. >> - e.g. expired and obsolete options should have their global >> variable definitions and >> related implementations removed ... >> >> comment line 2119 - extra spaces at the front? (or webrev artifact?) >> >> thanks very much, >> Karen >> >> >> >> >> On Aug 24, 2015, at 1:27 PM, Derek White wrote: >> >>> RFR: >>> >>> This version incorporates Dave and Karen's suggestions to >>> automatically handle deprecated-> obsolete transitions. This is >>> implemented with a unified table of deprecated and obsolete options >>> ("special_jvm_flags"). >>> >>> Karen also suggested (offline) that it would be good to verify that >>> obsolete and expired options no longer have a "globals" variable >>> defined. This revision adds debug checking of the special_jvm_flags >>> table to check a bunch of constraints, such as deprecated version >>> must be < obsolete version < expired version, and checks for >>> duplicate table entries as well as looking for left-over "globals" >>> variables. >>> >>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.08 >>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>> >>> I also have a webrev of webrev.07 vs. webrev.08: >>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.7.v.8 >>> >>> Thanks for looking! >>> >>> - Derek >>> >>> On 8/11/15 3:33 PM, Derek White wrote: >>>> Hi Karen, >>>> >>>> As much as I want to get this RFE over and out, I see your and David >>>> H's point :-) >>>> >>>> I'll spin another rev... >>>> >>>> - Derek >>>> >>>> On 8/10/15 6:07 PM, Karen Kinnear wrote: >>>>> Derek, >>>>> >>>>> Thank you for all of your work on this and responses to suggestions. >>>>> >>>>> I had a couple of questions/comments: >>>>> >>>>> I appreciate that you have created mechanisms to allow: >>>>> 1. 2 step obsolete: obsolete_jvm_flags >>>>> - step 1: obsolete: warn and ignore >>>>> - step 2: expire >>>>> - and I expect we will use this for most -XX flags, especially >>>>> develop flags >>>>> >>>>> 2. 2 step deprecate: deprecated_jvm_flags >>>>> - step 1: deprecate: warn and handle >>>>> - step 2: expire >>>>> >>>>> I see this approach as useful for aliasing and for a few other >>>>> flags, but not >>>>> the common path. >>>>> >>>>> My concerns: >>>>> >>>>> With my understanding of how this is set up today, for the flags >>>>> that are most exposed to >>>>> customers, which would want the 3 step deprecation, it would be too >>>>> easy for an engineer >>>>> to add the flag to the deprecated_jvm_flags and forget to add it to >>>>> the obsolete_jvm_flags, >>>>> as the comments under deprecated_jvm_flags suggest. And we don't >>>>> want folks to have >>>>> to go back and do a second step later for flags if they could do it >>>>> all at once. >>>>> >>>>> I think it would be confusing to add a flag to both >>>>> deprecated_jvm_flags and obsolete_jvm_flags >>>>> at the same time, since then the expiration release is not clear. >>>>> >>>>> 3. For product non-XX, commercial and common -XX flags what I would >>>>> like to see is >>>>> a three-step table which I would have called deprecated_jvm_flags, >>>>> which did >>>>> - step 1: deprecate: warn and handle >>>>> - step 2: obsolete: warn and ignore >>>>> - step 3: expire: unrecognized error >>>>> >>>>> Would you be willing to add a table like that which is the >>>>> recommended approach >>>>> for external supported flags? >>>>> >>>>> So one way to do this would be to change the current >>>>> deprecated_jvm_flags to have >>>>> three fields, so that the usual path would be to have three >>>>> releases listed, and >>>>> for aliased flags leave the middle field with the undefined version. >>>>> >>>>> Another approach would be to have the three fields and have it used by >>>>> all three approaches, just fill in the steps that are appropriate. >>>>> >>>>> minor comment: >>>>> >>>>> >>>>> 1. arguments.hpp >>>>> Could you possibly change the comments from "and has expired >>>>> (should be ignored)" to >>>>> "and has expired (unrecognized error)" >>>>> >>>>> unless what you mean really is should be ignored, which is not the >>>>> same expired. >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> >>>>> >>>>> On Aug 10, 2015, at 12:41 PM, Derek White wrote: >>>>> >>>>>> Thanks David! >>>>>> >>>>>> - Derek >>>>>> >>>>>> On 8/10/15 1:53 AM, David Holmes wrote: >>>>>>> Hi Derek, >>>>>>> >>>>>>> I don't have any further comments. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 7/08/2015 12:46 PM, Derek White wrote: >>>>>>>> Another RFR. >>>>>>>> >>>>>>>> I've updated based on David and Kim's last comments. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/ >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>>>>>> >>>>>>>> I also have a webrev of webrev.06 vs. webrev.07: >>>>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/ >>>>>>>> >>>>>>>> [This webrev is confused about CommandLineOptionTest.java. I >>>>>>>> double-checked with a recursive diff and the only differences >>>>>>>> are in >>>>>>>> arguments.cpp and arguments.hpp.] >>>>>>>> >>>>>>>> Thanks for looking! >>>>>>>> >>>>>>>> - Derek >>>>>>>> .... > From sangheon.kim at oracle.com Thu Aug 27 08:42:40 2015 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Thu, 27 Aug 2015 01:42:40 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DE7FAC.90900@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE7FAC.90900@oracle.com> Message-ID: Hi Jon, > On Aug 26, 2015, at 8:10 PM, Jon Masamitsu wrote: > > http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/runtime/commandLineFlagConstraintsGC.cpp.frames.html > > Minor point. > > 303 Flag::Error G1YoungSurvRateNumRegionsSummaryConstraintFunc(intx value, bool verbose) { > 304 if (!UseG1GC) return Flag::SUCCESS; > 305 > 306 if (value > (intx)HeapRegionBounds::target_number()) { > 307 CommandLineError::print(verbose, > 308 "G1YoungSurvRateNumRegionsSummary (" INTX_FORMAT ") must be " > 309 "less than or equal to region amount (" SIZE_FORMAT ")\n", > > I think "less than or equal to region count" sounds better ("count" instead of "amount"). Okay. I will fix it as your suggestion. > > http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/gc/g1/g1_globals.hpp.frames.html > > 261 develop(uintx, G1DummyRegionsPerGC, 0, \ > 262 "The number of dummy regions G1 will allocate at the end of " \ > 263 "each evacuation pause in order to artificially fill up the " \ > 264 "heap and stress the marking implementation.") \ > 265 range(0, 1000) > > Is 1000 large enough? Have I already asked that? Is that enough to fill a 100g heap? Let me cancel adding a range here and handle from different CR. > More later. Okay. Thanks, Sangheon > > Jon > >> On 8/26/2015 11:51 AM, sangheon.kim wrote: >> Hi Derek, >> >> Thank you for looking at this! >> >>> On 08/26/2015 10:59 AM, Derek White wrote: >>> Hi Sangheon, >>> >>> I haven't reviewed the actual ranges and constraints yet, but one thing you might want to consider: >>> >>> For the test cases, you may want synchronize the GC specified to ProcessBuilder with the "@requires gc=" tags. This prevents the test harness from running G1 tests when the test harness is trying to run CMS test, etc, and also avoids potential confusing test failures. >>> >>> @requires vm.gc=="G1" | vm.gc=="null" >>> (or specify Parallel GC as needed). >> Thank you for the explanation. >> I didn't know about this. >> >> So it seems like vm.gc=="null" means not specifying vm option. >> >>> >>> This is for: >>> TestG1ConcMarkStepDurationMillis.java (G1) >>> TestObjectTenuringFlags.java (Parallel) >>> TestInitialTenuringThreshold.java (Parallel) >>> TestG1HeapRegionSize.java (G1) >> Okay, I will add these tags at next webrev. >> >> Thanks, >> Sangheon >> >> >>> >>> - Derek >>> >>>> On 8/24/15 5:33 PM, sangheon.kim wrote: >>>> Hi Kim, >>>> >>>>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim wrote: >>>>>> Hi Kim, >>>>>> >>>>>> Here's webrev.03 which includes your comment for MarkStackSize constraint function. >>>>>> >>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>>> >>>>>> And all your comments will be managed by https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>>> If the value of MarkStackSizeMax were changed later, there's nothing >>>>> to verify MarkStackSize is still smaller. [This is related to my >>>>> earlier comment about constraints between options being tested twice >>>>> and failures reported twice.] Do we care in this case? >>>> If your concern is something like >>>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>>> Yes, in this case the order is important as ranges and constraint functions are verified by its order. >>>> MarkStackSizeMax will be verified first(its range) and MarkStackSize will be compared with verified MarkStackSizeMax. >>>> >>>> And as I said your original concern is current limitation. >>>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>>> they will print out 2 failure messages. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>>> >>>>> Other than that, looks good. > From erik.joelsson at oracle.com Thu Aug 27 08:51:56 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Aug 2015 10:51:56 +0200 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 In-Reply-To: <6B336485-5BE0-4154-820E-41D6F8C1BB3E@oracle.com> References: <55DC7B4D.4010505@oracle.com> <887B4B02-6530-4E23-BCA0-E41B7DE3368E@oracle.com> <55DD30BF.40604@oracle.com> <55DDA6A9.3070909@oracle.com> <6B336485-5BE0-4154-820E-41D6F8C1BB3E@oracle.com> Message-ID: <55DECFAC.8010507@oracle.com> Hello, You are probably right regarding the future versions of the Solaris Studio compiler. Here is a new webrev with the check being >= 513 (which is indeed 12.4). http://cr.openjdk.java.net/~erikj/8134157/webrev.02/ I still only apply it to adlc as that's where +w is active. I doubt +w will be activated for the rest of hotspot anytime soon as the amount of warnings triggered is quite substantial. /Erik On 2015-08-26 20:37, Kim Barrett wrote: > On Aug 26, 2015, at 7:44 AM, Erik Joelsson wrote: >> Further investigation revealed that this "error" was actually just a warning being upgraded to error by -errwarn. The warning is only activated by +w, which is turned on for adlc but not for the rest of the hotspot build. Based on this, I have revised my proposal to just disabling this warning for adlc and the particular compiler version. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev.01/ > I think the new approach is good, e.g. disable the specific warning. > However, only doing so for this one compiler rev (I assume 513 > corresponds to SS12u4?) seems like a mistake to me. I don't expect the > warning to go away with future compiler versions. > > From david.holmes at oracle.com Thu Aug 27 09:09:20 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Aug 2015 19:09:20 +1000 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 In-Reply-To: <55DECFAC.8010507@oracle.com> References: <55DC7B4D.4010505@oracle.com> <887B4B02-6530-4E23-BCA0-E41B7DE3368E@oracle.com> <55DD30BF.40604@oracle.com> <55DDA6A9.3070909@oracle.com> <6B336485-5BE0-4154-820E-41D6F8C1BB3E@oracle.com> <55DECFAC.8010507@oracle.com> Message-ID: <55DED3C0.4080203@oracle.com> Ship it! :) Thanks, David On 27/08/2015 6:51 PM, Erik Joelsson wrote: > Hello, > > You are probably right regarding the future versions of the Solaris > Studio compiler. Here is a new webrev with the check being >= 513 (which > is indeed 12.4). > > http://cr.openjdk.java.net/~erikj/8134157/webrev.02/ > > I still only apply it to adlc as that's where +w is active. I doubt +w > will be activated for the rest of hotspot anytime soon as the amount of > warnings triggered is quite substantial. > > /Erik > > On 2015-08-26 20:37, Kim Barrett wrote: >> On Aug 26, 2015, at 7:44 AM, Erik Joelsson >> wrote: >>> Further investigation revealed that this "error" was actually just a >>> warning being upgraded to error by -errwarn. The warning is only >>> activated by +w, which is turned on for adlc but not for the rest of >>> the hotspot build. Based on this, I have revised my proposal to just >>> disabling this warning for adlc and the particular compiler version. >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev.01/ >> I think the new approach is good, e.g. disable the specific warning. >> However, only doing so for this one compiler rev (I assume 513 >> corresponds to SS12u4?) seems like a mistake to me. I don't expect the >> warning to go away with future compiler versions. >> >> > From magnus.ihse.bursie at oracle.com Thu Aug 27 09:31:27 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 27 Aug 2015 11:31:27 +0200 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 In-Reply-To: <55DECFAC.8010507@oracle.com> References: <55DC7B4D.4010505@oracle.com> <887B4B02-6530-4E23-BCA0-E41B7DE3368E@oracle.com> <55DD30BF.40604@oracle.com> <55DDA6A9.3070909@oracle.com> <6B336485-5BE0-4154-820E-41D6F8C1BB3E@oracle.com> <55DECFAC.8010507@oracle.com> Message-ID: <55DED8EF.8030602@oracle.com> On 2015-08-27 10:51, Erik Joelsson wrote: > Hello, > > You are probably right regarding the future versions of the Solaris > Studio compiler. Here is a new webrev with the check being >= 513 > (which is indeed 12.4). > > http://cr.openjdk.java.net/~erikj/8134157/webrev.02/ > > I still only apply it to adlc as that's where +w is active. I doubt +w > will be activated for the rest of hotspot anytime soon as the amount > of warnings triggered is quite substantial. Looks good to me. /Magnus > > /Erik > > On 2015-08-26 20:37, Kim Barrett wrote: >> On Aug 26, 2015, at 7:44 AM, Erik Joelsson >> wrote: >>> Further investigation revealed that this "error" was actually just a >>> warning being upgraded to error by -errwarn. The warning is only >>> activated by +w, which is turned on for adlc but not for the rest of >>> the hotspot build. Based on this, I have revised my proposal to just >>> disabling this warning for adlc and the particular compiler version. >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8134157/webrev.01/ >> I think the new approach is good, e.g. disable the specific warning. >> However, only doing so for this one compiler rev (I assume 513 >> corresponds to SS12u4?) seems like a mistake to me. I don't expect the >> warning to go away with future compiler versions. >> >> > From kim.barrett at oracle.com Thu Aug 27 15:44:58 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 27 Aug 2015 11:44:58 -0400 Subject: RFR: JDK-8134157: adlc fails to compile with SS12u4 In-Reply-To: <55DECFAC.8010507@oracle.com> References: <55DC7B4D.4010505@oracle.com> <887B4B02-6530-4E23-BCA0-E41B7DE3368E@oracle.com> <55DD30BF.40604@oracle.com> <55DDA6A9.3070909@oracle.com> <6B336485-5BE0-4154-820E-41D6F8C1BB3E@oracle.com> <55DECFAC.8010507@oracle.com> Message-ID: <2D3F5543-07A2-40FE-BD73-908751F44B46@oracle.com> On Aug 27, 2015, at 4:51 AM, Erik Joelsson wrote: > > Hello, > > You are probably right regarding the future versions of the Solaris Studio compiler. Here is a new webrev with the check being >= 513 (which is indeed 12.4). > > http://cr.openjdk.java.net/~erikj/8134157/webrev.02/ > > I still only apply it to adlc as that's where +w is active. I doubt +w will be activated for the rest of hotspot anytime soon as the amount of warnings triggered is quite substantial. Looks good. From jon.masamitsu at oracle.com Thu Aug 27 16:53:02 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 27 Aug 2015 09:53:02 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DE0A9A.5030806@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> Message-ID: <55DF406E.9000405@oracle.com> Sangheon, A general question. A constraint function such as 49 static Flag::Error ParallelGCThreadsAndCMSWorkQueueDrainThreshold(uint threads, uintx threshold, bool verbose) { 50 // CMSWorkQueueDrainThreshold is verified to be less than max_juint 51 if (UseConcMarkSweepGC && (threads > (uint)(max_jint / (uint)threshold))) { 52 CommandLineError::print(verbose, 53 "ParallelGCThreads (" UINT32_FORMAT ") or CMSWorkQueueDrainThreshold (" 54 UINTX_FORMAT ") is too large\n", 55 threads, threshold); 56 return Flag::VIOLATES_CONSTRAINT; 57 } 58 return Flag::SUCCESS; 59 } takes parameters that should only be ParallelGCThreads for "threads" and only CMSWorkQueueDrainThreshold for "threshold". Is that right? Jon On 08/26/2015 11:51 AM, sangheon.kim wrote: > Hi Derek, > > Thank you for looking at this! > > On 08/26/2015 10:59 AM, Derek White wrote: >> Hi Sangheon, >> >> I haven't reviewed the actual ranges and constraints yet, but one >> thing you might want to consider: >> >> For the test cases, you may want synchronize the GC specified to >> ProcessBuilder with the "@requires gc=" tags. This prevents the test >> harness from running G1 tests when the test harness is trying to run >> CMS test, etc, and also avoids potential confusing test failures. >> >> @requires vm.gc=="G1" | vm.gc=="null" >> (or specify Parallel GC as needed). > Thank you for the explanation. > I didn't know about this. > > So it seems like vm.gc=="null" means not specifying vm option. > >> >> This is for: >> TestG1ConcMarkStepDurationMillis.java (G1) >> TestObjectTenuringFlags.java (Parallel) >> TestInitialTenuringThreshold.java (Parallel) >> TestG1HeapRegionSize.java (G1) > Okay, I will add these tags at next webrev. > > Thanks, > Sangheon > > >> >> - Derek >> >> On 8/24/15 5:33 PM, sangheon.kim wrote: >>> Hi Kim, >>> >>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>> wrote: >>>>> Hi Kim, >>>>> >>>>> Here's webrev.03 which includes your comment for MarkStackSize >>>>> constraint function. >>>>> >>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>> >>>>> And all your comments will be managed by >>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>> If the value of MarkStackSizeMax were changed later, there's nothing >>>> to verify MarkStackSize is still smaller. [This is related to my >>>> earlier comment about constraints between options being tested twice >>>> and failures reported twice.] Do we care in this case? >>> If your concern is something like >>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>> Yes, in this case the order is important as ranges and constraint >>> functions are verified by its order. >>> MarkStackSizeMax will be verified first(its range) and MarkStackSize >>> will be compared with verified MarkStackSizeMax. >>> >>> And as I said your original concern is current limitation. >>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>> they will print out 2 failure messages. >>> >>> Thanks, >>> Sangheon >>> >>>> >>>> Other than that, looks good. >>>> >>> >> > From kim.barrett at oracle.com Thu Aug 27 16:58:19 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 27 Aug 2015 12:58:19 -0400 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DF406E.9000405@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DF406E.9000405@oracle.com> Message-ID: On Aug 27, 2015, at 12:53 PM, Jon Masamitsu wrote: > > Sangheon, > > A general question. A constraint function such as > > 49 static Flag::Error ParallelGCThreadsAndCMSWorkQueueDrainThreshold(uint threads, uintx threshold, bool verbose) { > 50 // CMSWorkQueueDrainThreshold is verified to be less than max_juint > 51 if (UseConcMarkSweepGC && (threads > (uint)(max_jint / (uint)threshold))) { > 52 CommandLineError::print(verbose, > 53 "ParallelGCThreads (" UINT32_FORMAT ") or CMSWorkQueueDrainThreshold (" > 54 UINTX_FORMAT ") is too large\n", > 55 threads, threshold); > 56 return Flag::VIOLATES_CONSTRAINT; > 57 } > 58 return Flag::SUCCESS; > 59 } > > takes parameters that should only be ParallelGCThreads for "threads" and > only CMSWorkQueueDrainThreshold for "threshold". Is that right? Or the proposed new value for one or the other. Which is why they are arguments rather just directly referring to the variables. From sangheon.kim at oracle.com Thu Aug 27 17:08:41 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 27 Aug 2015 10:08:41 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DF406E.9000405@oracle.com> Message-ID: <55DF4419.3070308@oracle.com> Hi Jon and Kim, On 08/27/2015 09:58 AM, Kim Barrett wrote: > On Aug 27, 2015, at 12:53 PM, Jon Masamitsu wrote: >> Sangheon, >> >> A general question. A constraint function such as >> >> 49 static Flag::Error ParallelGCThreadsAndCMSWorkQueueDrainThreshold(uint threads, uintx threshold, bool verbose) { >> 50 // CMSWorkQueueDrainThreshold is verified to be less than max_juint >> 51 if (UseConcMarkSweepGC && (threads > (uint)(max_jint / (uint)threshold))) { >> 52 CommandLineError::print(verbose, >> 53 "ParallelGCThreads (" UINT32_FORMAT ") or CMSWorkQueueDrainThreshold (" >> 54 UINTX_FORMAT ") is too large\n", >> 55 threads, threshold); >> 56 return Flag::VIOLATES_CONSTRAINT; >> 57 } >> 58 return Flag::SUCCESS; >> 59 } >> >> takes parameters that should only be ParallelGCThreads for "threads" and >> only CMSWorkQueueDrainThreshold for "threshold". Is that right? > Or the proposed new value for one or the other. Which is why they are arguments rather > just directly referring to the variables. Thanks Kim, he already answered correctly. Thanks, Sangheon > From jon.masamitsu at oracle.com Thu Aug 27 18:18:36 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 27 Aug 2015 11:18:36 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DF5439.3080000@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DF5439.3080000@oracle.com> Message-ID: <55DF547C.6090306@oracle.com> On 08/27/2015 11:17 AM, Jon Masamitsu wrote: > http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/runtime/commandLineFlagConstraintsGC.cpp.frames.html > > > I'd suggest adding more explanation about why the constraint failed. > > 190 static Flag::Error > CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(size_t maxHeap, intx > softRef, bool verbose) { > 191 if ((softRef > 0) && ((maxHeap / M) > (max_uintx / softRef))) { > 192 CommandLineError::print(verbose, > > "Desired life time of SoftReferences cannot be expressed > correctly. " > > > 193 "MaxHeapSize (" SIZE_FORMAT ") or > SoftRefLRUPolicyMSPerMB " > 194 "(" INTX_FORMAT ") is too large\n", > 195 maxHeap, softRef); > 196 return Flag::VIOLATES_CONSTRAINT; > 197 } else { > > > Should there be a call to MinPLABSizeBounds() in this function? There > are checks that the values is not greater than the maximum but > not a check that the value is less than the minimum. > > 374 Flag::Error CMSOldPLABMinConstraintFunc(size_t value, bool > verbose) { > 375 Flag::Error status = Flag::SUCCESS; > 376 > 377 #if INCLUDE_ALL_GCS > 378 if (UseConcMarkSweepGC) { > 379 if (value > CMSOldPLABMax) { > 380 CommandLineError::print(verbose, > 381 "CMSOldPLABMin (" SIZE_FORMAT ") > must be " > 382 "less than or equal to > CMSOldPLABMax (" SIZE_FORMAT ")\n", > 383 value, CMSOldPLABMax); > 384 return Flag::VIOLATES_CONSTRAINT; > 385 } > 386 status = MaxPLABSizeBounds("CMSOldPLABMin", value, verbose); > 387 } > 388 #endif > 389 return status; > 390 } > > That's all. > > Jon > > > On 08/26/2015 11:51 AM, sangheon.kim wrote: >> Hi Derek, >> >> Thank you for looking at this! >> >> On 08/26/2015 10:59 AM, Derek White wrote: >>> Hi Sangheon, >>> >>> I haven't reviewed the actual ranges and constraints yet, but one >>> thing you might want to consider: >>> >>> For the test cases, you may want synchronize the GC specified to >>> ProcessBuilder with the "@requires gc=" tags. This prevents the test >>> harness from running G1 tests when the test harness is trying to run >>> CMS test, etc, and also avoids potential confusing test failures. >>> >>> @requires vm.gc=="G1" | vm.gc=="null" >>> (or specify Parallel GC as needed). >> Thank you for the explanation. >> I didn't know about this. >> >> So it seems like vm.gc=="null" means not specifying vm option. >> >>> >>> This is for: >>> TestG1ConcMarkStepDurationMillis.java (G1) >>> TestObjectTenuringFlags.java (Parallel) >>> TestInitialTenuringThreshold.java (Parallel) >>> TestG1HeapRegionSize.java (G1) >> Okay, I will add these tags at next webrev. >> >> Thanks, >> Sangheon >> >> >>> >>> - Derek >>> >>> On 8/24/15 5:33 PM, sangheon.kim wrote: >>>> Hi Kim, >>>> >>>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>>> wrote: >>>>>> Hi Kim, >>>>>> >>>>>> Here's webrev.03 which includes your comment for MarkStackSize >>>>>> constraint function. >>>>>> >>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>>> >>>>>> And all your comments will be managed by >>>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>>> If the value of MarkStackSizeMax were changed later, there's nothing >>>>> to verify MarkStackSize is still smaller. [This is related to my >>>>> earlier comment about constraints between options being tested twice >>>>> and failures reported twice.] Do we care in this case? >>>> If your concern is something like >>>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>>> Yes, in this case the order is important as ranges and constraint >>>> functions are verified by its order. >>>> MarkStackSizeMax will be verified first(its range) and >>>> MarkStackSize will be compared with verified MarkStackSizeMax. >>>> >>>> And as I said your original concern is current limitation. >>>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>>> they will print out 2 failure messages. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>>> >>>>> Other than that, looks good. >>>>> >>>> >>> >> > From sangheon.kim at oracle.com Thu Aug 27 19:44:48 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 27 Aug 2015 12:44:48 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DF5439.3080000@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DF5439.3080000@oracle.com> Message-ID: <55DF68B0.5050605@oracle.com> On 08/27/2015 11:17 AM, Jon Masamitsu wrote: > http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/runtime/commandLineFlagConstraintsGC.cpp.frames.html > > > I'd suggest adding more explanation about why the constraint failed. > > 190 static Flag::Error > CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(size_t maxHeap, intx > softRef, bool verbose) { > 191 if ((softRef > 0) && ((maxHeap / M) > (max_uintx / softRef))) { > 192 CommandLineError::print(verbose, > > "Desired life time of SoftReferences cannot be expressed > correctly. " > > > 193 "MaxHeapSize (" SIZE_FORMAT ") or > SoftRefLRUPolicyMSPerMB " > 194 "(" INTX_FORMAT ") is too large\n", > 195 maxHeap, softRef); > 196 return Flag::VIOLATES_CONSTRAINT; > 197 } else { > Your suggestion is adding "Desired ... correctly.", right? Okay, I will add it. > > Should there be a call to MinPLABSizeBounds() in this function? There > are checks that the values is not greater than the maximum but > not a check that the value is less than the minimum. > > 374 Flag::Error CMSOldPLABMinConstraintFunc(size_t value, bool > verbose) { > 375 Flag::Error status = Flag::SUCCESS; > 376 > 377 #if INCLUDE_ALL_GCS > 378 if (UseConcMarkSweepGC) { > 379 if (value > CMSOldPLABMax) { > 380 CommandLineError::print(verbose, > 381 "CMSOldPLABMin (" SIZE_FORMAT ") > must be " > 382 "less than or equal to > CMSOldPLABMax (" SIZE_FORMAT ")\n", > 383 value, CMSOldPLABMax); > 384 return Flag::VIOLATES_CONSTRAINT; > 385 } > 386 status = MaxPLABSizeBounds("CMSOldPLABMin", value, verbose); > 387 } > 388 #endif > 389 return status; > 390 } Didn't added same reason of OldPLABSizeConstraintFunc(). As OldPLABSize for CMS has different meaning, it cannot compared with MinPLABSizeBounds(). (from globals.hpp: Minimum size of CMS gen promotion LAB caches per worker per block size.) FYI, default CMSOldPLABMin is 16 while PLAB::min_size() on my linux machine returns 256. Thanks, Sangheon > > That's all. > > Jon > > > On 08/26/2015 11:51 AM, sangheon.kim wrote: >> Hi Derek, >> >> Thank you for looking at this! >> >> On 08/26/2015 10:59 AM, Derek White wrote: >>> Hi Sangheon, >>> >>> I haven't reviewed the actual ranges and constraints yet, but one >>> thing you might want to consider: >>> >>> For the test cases, you may want synchronize the GC specified to >>> ProcessBuilder with the "@requires gc=" tags. This prevents the test >>> harness from running G1 tests when the test harness is trying to run >>> CMS test, etc, and also avoids potential confusing test failures. >>> >>> @requires vm.gc=="G1" | vm.gc=="null" >>> (or specify Parallel GC as needed). >> Thank you for the explanation. >> I didn't know about this. >> >> So it seems like vm.gc=="null" means not specifying vm option. >> >>> >>> This is for: >>> TestG1ConcMarkStepDurationMillis.java (G1) >>> TestObjectTenuringFlags.java (Parallel) >>> TestInitialTenuringThreshold.java (Parallel) >>> TestG1HeapRegionSize.java (G1) >> Okay, I will add these tags at next webrev. >> >> Thanks, >> Sangheon >> >> >>> >>> - Derek >>> >>> On 8/24/15 5:33 PM, sangheon.kim wrote: >>>> Hi Kim, >>>> >>>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>>> wrote: >>>>>> Hi Kim, >>>>>> >>>>>> Here's webrev.03 which includes your comment for MarkStackSize >>>>>> constraint function. >>>>>> >>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>>> >>>>>> And all your comments will be managed by >>>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>>> If the value of MarkStackSizeMax were changed later, there's nothing >>>>> to verify MarkStackSize is still smaller. [This is related to my >>>>> earlier comment about constraints between options being tested twice >>>>> and failures reported twice.] Do we care in this case? >>>> If your concern is something like >>>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>>> Yes, in this case the order is important as ranges and constraint >>>> functions are verified by its order. >>>> MarkStackSizeMax will be verified first(its range) and >>>> MarkStackSize will be compared with verified MarkStackSizeMax. >>>> >>>> And as I said your original concern is current limitation. >>>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>>> they will print out 2 failure messages. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>>> >>>>> Other than that, looks good. >>>>> >>>> >>> >> > From jon.masamitsu at oracle.com Thu Aug 27 19:58:42 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 27 Aug 2015 12:58:42 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DF68B0.5050605@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DF5439.3080000@oracle.com> <55DF68B0.5050605@oracle.com> Message-ID: <55DF6BF2.4040601@oracle.com> On 08/27/2015 12:44 PM, sangheon.kim wrote: > > > On 08/27/2015 11:17 AM, Jon Masamitsu wrote: >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/runtime/commandLineFlagConstraintsGC.cpp.frames.html >> >> >> I'd suggest adding more explanation about why the constraint failed. >> >> 190 static Flag::Error >> CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB(size_t maxHeap, intx >> softRef, bool verbose) { >> 191 if ((softRef > 0) && ((maxHeap / M) > (max_uintx / softRef))) { >> 192 CommandLineError::print(verbose, >> >> "Desired life time of SoftReferences cannot be expressed >> correctly. " >> >> >> 193 "MaxHeapSize (" SIZE_FORMAT ") or >> SoftRefLRUPolicyMSPerMB " >> 194 "(" INTX_FORMAT ") is too large\n", >> 195 maxHeap, softRef); >> 196 return Flag::VIOLATES_CONSTRAINT; >> 197 } else { >> > Your suggestion is adding "Desired ... correctly.", right? > Okay, I will add it. Yes. > >> >> Should there be a call to MinPLABSizeBounds() in this function? There >> are checks that the values is not greater than the maximum but >> not a check that the value is less than the minimum. >> >> 374 Flag::Error CMSOldPLABMinConstraintFunc(size_t value, bool >> verbose) { >> 375 Flag::Error status = Flag::SUCCESS; >> 376 >> 377 #if INCLUDE_ALL_GCS >> 378 if (UseConcMarkSweepGC) { >> 379 if (value > CMSOldPLABMax) { >> 380 CommandLineError::print(verbose, >> 381 "CMSOldPLABMin (" SIZE_FORMAT ") >> must be " >> 382 "less than or equal to >> CMSOldPLABMax (" SIZE_FORMAT ")\n", >> 383 value, CMSOldPLABMax); >> 384 return Flag::VIOLATES_CONSTRAINT; >> 385 } >> 386 status = MaxPLABSizeBounds("CMSOldPLABMin", value, verbose); >> 387 } >> 388 #endif >> 389 return status; >> 390 } > Didn't added same reason of OldPLABSizeConstraintFunc(). > As OldPLABSize for CMS has different meaning, it cannot compared with > MinPLABSizeBounds(). > (from globals.hpp: Minimum size of CMS gen promotion LAB caches per > worker per block size.) Ok. Reviewed. Jon > > FYI, default CMSOldPLABMin is 16 while PLAB::min_size() on my linux > machine returns 256. > > Thanks, > Sangheon > > >> >> That's all. >> >> Jon >> >> >> On 08/26/2015 11:51 AM, sangheon.kim wrote: >>> Hi Derek, >>> >>> Thank you for looking at this! >>> >>> On 08/26/2015 10:59 AM, Derek White wrote: >>>> Hi Sangheon, >>>> >>>> I haven't reviewed the actual ranges and constraints yet, but one >>>> thing you might want to consider: >>>> >>>> For the test cases, you may want synchronize the GC specified to >>>> ProcessBuilder with the "@requires gc=" tags. This prevents the >>>> test harness from running G1 tests when the test harness is trying >>>> to run CMS test, etc, and also avoids potential confusing test >>>> failures. >>>> >>>> @requires vm.gc=="G1" | vm.gc=="null" >>>> (or specify Parallel GC as needed). >>> Thank you for the explanation. >>> I didn't know about this. >>> >>> So it seems like vm.gc=="null" means not specifying vm option. >>> >>>> >>>> This is for: >>>> TestG1ConcMarkStepDurationMillis.java (G1) >>>> TestObjectTenuringFlags.java (Parallel) >>>> TestInitialTenuringThreshold.java (Parallel) >>>> TestG1HeapRegionSize.java (G1) >>> Okay, I will add these tags at next webrev. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> - Derek >>>> >>>> On 8/24/15 5:33 PM, sangheon.kim wrote: >>>>> Hi Kim, >>>>> >>>>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>>>> wrote: >>>>>>> Hi Kim, >>>>>>> >>>>>>> Here's webrev.03 which includes your comment for MarkStackSize >>>>>>> constraint function. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>>>> >>>>>>> And all your comments will be managed by >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>>>> If the value of MarkStackSizeMax were changed later, there's nothing >>>>>> to verify MarkStackSize is still smaller. [This is related to my >>>>>> earlier comment about constraints between options being tested twice >>>>>> and failures reported twice.] Do we care in this case? >>>>> If your concern is something like >>>>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>>>> Yes, in this case the order is important as ranges and constraint >>>>> functions are verified by its order. >>>>> MarkStackSizeMax will be verified first(its range) and >>>>> MarkStackSize will be compared with verified MarkStackSizeMax. >>>>> >>>>> And as I said your original concern is current limitation. >>>>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>>>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>>>> they will print out 2 failure messages. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>>> >>>>>> Other than that, looks good. >>>>>> >>>>> >>>> >>> >> > From derek.white at oracle.com Thu Aug 27 21:53:12 2015 From: derek.white at oracle.com (Derek White) Date: Thu, 27 Aug 2015 17:53:12 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55DE9846.8050008@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> <55B1119D.4030802@oracle.com> <55C41C20.90208@oracle.com> <55C83C5C.60702@oracle.com> <55C8D456.9030006@oracle.com> <5A08C1CB-58F9-4193-802F-767EE11F4D2B@oracle.com> <55CA4E0E.2070503@oracle.com> <55DB540A.4010804@oracle.com> <55DCE602.3040801@oracle.com> <55DE9846.8050008@oracle.com> Message-ID: <55DF86C8.3030200@oracle.com> Hi David, Comments inline... On 8/27/15 12:55 AM, David Holmes wrote: > On 26/08/2015 8:02 AM, Derek White wrote: >> Thanks Karen! >> >> If I don't get any other feedback, can I get you to sponsor the change >> for me? After folding in your fixes... > > I need to see those fixes first as I got quite confused trying to > reconcile the code with the documentation. OK, I've integrated Karen's final documentation feedback. > I'm unclear why is_obsolete doesn't care about EXPIRED but > is_deprecated does? Because the caller of is_obsolete doesn't care about EXPIRED but the caller of is_deprecated does :-) In the first case, Arguments::process_argument has already tried processing the argument as a normal, aliased, or deprecated flag, and failed. Right before it starts whining about illegal flags it checks to see if it's obsolete, and if so prints the warning and continues on to the next flag. If the flag isn't obsolete then it must be non-existent. But process_argument treats both cases the same (it's in the definition of EXPIRED). In any case, that was the contract for the original is_newly_obsolete() method. In the "is_deprecated" case, the caller (parse_argument) is in the middle of handling a real-life global flag, but it needs to decide if should print a deprecation warning, or treat it as a normal flag, or note that the flag is now obsolete or expired, in which case it has to bail out of parse_argument. So parse_argument needs to know three states. > Also you often state something like "fits into the range specified" > but it is unclear what range you are referring to. I simplified both the code and documentation you mentioned. The implementations had gotten "overly factored". I hope you find the new code and documentation clearer. I have a JPRT build out running, but are the new webrevs: http://cr.openjdk.java.net/~drwhite/8066821/webrev.09 http://cr.openjdk.java.net/~drwhite/8066821/webrev.8.v.9 http://cr.openjdk.java.net/~drwhite/8066821/webrev.7.v.9 Thanks for your comments! - Derek > > Thanks, > David > >> - Derek >> >> On 8/25/15 2:05 PM, Karen Kinnear wrote: >>> Derek, >>> >>> Many thanks for the latest changes. And thank you for the >>> verify_special_jvm_flags -- that will remind us to >>> clean up the flags when the version number changes. So the expired_in >>> information is for internal use only - we >>> don't print that information for users, we simply tell them "in a >>> future release". >>> >>> Looks good. No need for my further code review. >>> >>> Minor comments: >>> 1. arguments.hpp >>> line 421 "In the case" -> "In this case" >>> >>> 2. arguments.cpp comments >>> >>> I love the high level comments - could you possibly update them? >>> - e.g. they still talk about the deprecated_jvm_flags and >>> obsolete_jvm_flags tables. >>> - e.g. expired and obsolete options should have their global >>> variable definitions and >>> related implementations removed ... >>> >>> comment line 2119 - extra spaces at the front? (or webrev artifact?) >>> >>> thanks very much, >>> Karen >>> >>> >>> >>> >>> On Aug 24, 2015, at 1:27 PM, Derek White wrote: >>> >>>> RFR: >>>> >>>> This version incorporates Dave and Karen's suggestions to >>>> automatically handle deprecated-> obsolete transitions. This is >>>> implemented with a unified table of deprecated and obsolete options >>>> ("special_jvm_flags"). >>>> >>>> Karen also suggested (offline) that it would be good to verify that >>>> obsolete and expired options no longer have a "globals" variable >>>> defined. This revision adds debug checking of the special_jvm_flags >>>> table to check a bunch of constraints, such as deprecated version >>>> must be < obsolete version < expired version, and checks for >>>> duplicate table entries as well as looking for left-over "globals" >>>> variables. >>>> >>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.08 >>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>> >>>> I also have a webrev of webrev.07 vs. webrev.08: >>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.7.v.8 >>>> >>>> Thanks for looking! >>>> >>>> - Derek >>>> >>>> On 8/11/15 3:33 PM, Derek White wrote: >>>>> Hi Karen, >>>>> >>>>> As much as I want to get this RFE over and out, I see your and David >>>>> H's point :-) >>>>> >>>>> I'll spin another rev... >>>>> >>>>> - Derek >>>>> >>>>> On 8/10/15 6:07 PM, Karen Kinnear wrote: >>>>>> Derek, >>>>>> >>>>>> Thank you for all of your work on this and responses to suggestions. >>>>>> >>>>>> I had a couple of questions/comments: >>>>>> >>>>>> I appreciate that you have created mechanisms to allow: >>>>>> 1. 2 step obsolete: obsolete_jvm_flags >>>>>> - step 1: obsolete: warn and ignore >>>>>> - step 2: expire >>>>>> - and I expect we will use this for most -XX flags, especially >>>>>> develop flags >>>>>> >>>>>> 2. 2 step deprecate: deprecated_jvm_flags >>>>>> - step 1: deprecate: warn and handle >>>>>> - step 2: expire >>>>>> >>>>>> I see this approach as useful for aliasing and for a few other >>>>>> flags, but not >>>>>> the common path. >>>>>> >>>>>> My concerns: >>>>>> >>>>>> With my understanding of how this is set up today, for the flags >>>>>> that are most exposed to >>>>>> customers, which would want the 3 step deprecation, it would be too >>>>>> easy for an engineer >>>>>> to add the flag to the deprecated_jvm_flags and forget to add it to >>>>>> the obsolete_jvm_flags, >>>>>> as the comments under deprecated_jvm_flags suggest. And we don't >>>>>> want folks to have >>>>>> to go back and do a second step later for flags if they could do it >>>>>> all at once. >>>>>> >>>>>> I think it would be confusing to add a flag to both >>>>>> deprecated_jvm_flags and obsolete_jvm_flags >>>>>> at the same time, since then the expiration release is not clear. >>>>>> >>>>>> 3. For product non-XX, commercial and common -XX flags what I would >>>>>> like to see is >>>>>> a three-step table which I would have called deprecated_jvm_flags, >>>>>> which did >>>>>> - step 1: deprecate: warn and handle >>>>>> - step 2: obsolete: warn and ignore >>>>>> - step 3: expire: unrecognized error >>>>>> >>>>>> Would you be willing to add a table like that which is the >>>>>> recommended approach >>>>>> for external supported flags? >>>>>> >>>>>> So one way to do this would be to change the current >>>>>> deprecated_jvm_flags to have >>>>>> three fields, so that the usual path would be to have three >>>>>> releases listed, and >>>>>> for aliased flags leave the middle field with the undefined version. >>>>>> >>>>>> Another approach would be to have the three fields and have it >>>>>> used by >>>>>> all three approaches, just fill in the steps that are appropriate. >>>>>> >>>>>> minor comment: >>>>>> >>>>>> >>>>>> 1. arguments.hpp >>>>>> Could you possibly change the comments from "and has expired >>>>>> (should be ignored)" to >>>>>> "and has expired (unrecognized error)" >>>>>> >>>>>> unless what you mean really is should be ignored, which is not the >>>>>> same expired. >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> >>>>>> >>>>>> On Aug 10, 2015, at 12:41 PM, Derek White wrote: >>>>>> >>>>>>> Thanks David! >>>>>>> >>>>>>> - Derek >>>>>>> >>>>>>> On 8/10/15 1:53 AM, David Holmes wrote: >>>>>>>> Hi Derek, >>>>>>>> >>>>>>>> I don't have any further comments. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 7/08/2015 12:46 PM, Derek White wrote: >>>>>>>>> Another RFR. >>>>>>>>> >>>>>>>>> I've updated based on David and Kim's last comments. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/ >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>>>>>>> >>>>>>>>> I also have a webrev of webrev.06 vs. webrev.07: >>>>>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/ >>>>>>>>> >>>>>>>>> [This webrev is confused about CommandLineOptionTest.java. I >>>>>>>>> double-checked with a recursive diff and the only differences >>>>>>>>> are in >>>>>>>>> arguments.cpp and arguments.hpp.] >>>>>>>>> >>>>>>>>> Thanks for looking! >>>>>>>>> >>>>>>>>> - Derek >>>>>>>>> .... >> From sangheon.kim at oracle.com Thu Aug 27 22:29:47 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 27 Aug 2015 15:29:47 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DE5BB6.1090606@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE2840.7040306@oracle.com> <55DE3B4A.4030602@oracle.com> <55DE5BB6.1090606@oracle.com> Message-ID: <55DF8F5B.5090803@oracle.com> Forwarding to public alias. >> >> On 08/26/2015 05:37 PM, sangheon.kim wrote: >>> Hi Jon, >>> >>> >>> On 08/26/2015 03:18 PM, sangheon.kim wrote: >>>> Hi Jon, >>>> >>>> Thank you for the review. >>>> >>>> On 08/26/2015 01:57 PM, Jon Masamitsu wrote: >>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/runtime/commandLineFlagConstraintsGC.cpp.frames.html >>>>> >>>>> >>>>> Seems to me that a user should be able to set the default value for >>>>> a flag on the command line without getting an error. Below if I set >>>>> G1RSetRegionEntries to 0, I get a constraint violation. >>>> I agree with you. >>>> Let me change both constraint functions(G1RSetRegionEntries, >>>> G1RSetSparseRegionEntries) and related >>>> codes(HeapRegionRemSet::setup_remset_size). >>> Looking at the some flags, our codes are working differently for >>> default value of zero vs. manually set value of zero. >>> We are just calling FLAG_IS_DEFAULT(xxx) to check whether it is >>> set(default value) or not. >>> So it seems like xxx=0 is not recognized as default value even >>> though xxx's default value is zero. >>> What do you think? >>> Please look at MaxGCPauseMillis, GCPauseIntervalMillis, >>> G1RSetSparseRegionEntries and G1RSetRegionEntries. > You are right. We should not let the user set the flag to the default > value in the cases of G1RSetRegionEntries and G1RSetSparseRegionEntries. > > For MaxGCPauseMillis and GCPauseIntervalMillis the users should not be > allowed to set the > values to 0. That is already checked in the G1ColllectedHeap > constructor. I don't think you > need to make any added changes for those. > > Does that answer your questions? Yes, thank you for the answer. So I will not change for your comment of 'setting 0 for G1RSetRegionEntries'. Thanks, Sangheon > > Jon >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> FYI, if we don't stop with zero by constraint function, it fires >>>> assert under current code. >>>> >>>> These will be included at next webrev. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>>> >>>>> 271 Flag::Error G1RSetRegionEntriesConstraintFunc(intx value, bool >>>>> verbose) { >>>>> 272 if (!UseG1GC) return Flag::SUCCESS; >>>>> 273 >>>>> 274 // Default value of G1RSetRegionEntries=0 means will be set >>>>> ergonomically. >>>>> 275 // Minimum value is 1. >>>>> 276 if (FLAG_IS_CMDLINE(G1RSetRegionEntries) && (value < 1)) { >>>>> 277 CommandLineError::print(verbose, >>>>> 278 "G1RSetRegionEntries (" INTX_FORMAT ") must be " >>>>> 279 "greater than or equal to 1\n", >>>>> 280 value); >>>>> 281 return Flag::VIOLATES_CONSTRAINT; >>>>> 282 } else { >>>>> 283 return Flag::SUCCESS; >>>>> 284 } >>>>> 285 } >>>>> >>>>> >>>>> >>>>> On 8/26/2015 11:51 AM, sangheon.kim wrote: >>>>>> Hi Derek, >>>>>> >>>>>> Thank you for looking at this! >>>>>> >>>>>> On 08/26/2015 10:59 AM, Derek White wrote: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> I haven't reviewed the actual ranges and constraints yet, but >>>>>>> one thing you might want to consider: >>>>>>> >>>>>>> For the test cases, you may want synchronize the GC specified to >>>>>>> ProcessBuilder with the "@requires gc=" tags. This prevents the >>>>>>> test harness from running G1 tests when the test harness is >>>>>>> trying to run CMS test, etc, and also avoids potential confusing >>>>>>> test failures. >>>>>>> >>>>>>> @requires vm.gc=="G1" | vm.gc=="null" >>>>>>> (or specify Parallel GC as needed). >>>>>> Thank you for the explanation. >>>>>> I didn't know about this. >>>>>> >>>>>> So it seems like vm.gc=="null" means not specifying vm option. >>>>>> >>>>>>> >>>>>>> This is for: >>>>>>> TestG1ConcMarkStepDurationMillis.java (G1) >>>>>>> TestObjectTenuringFlags.java (Parallel) >>>>>>> TestInitialTenuringThreshold.java (Parallel) >>>>>>> TestG1HeapRegionSize.java (G1) >>>>>> Okay, I will add these tags at next webrev. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> - Derek >>>>>>> >>>>>>> On 8/24/15 5:33 PM, sangheon.kim wrote: >>>>>>>> Hi Kim, >>>>>>>> >>>>>>>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>>>>>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>>>>>>> wrote: >>>>>>>>>> Hi Kim, >>>>>>>>>> >>>>>>>>>> Here's webrev.03 which includes your comment for >>>>>>>>>> MarkStackSize constraint function. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>>>>>>> >>>>>>>>>> And all your comments will be managed by >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>>>>>>> If the value of MarkStackSizeMax were changed later, there's >>>>>>>>> nothing >>>>>>>>> to verify MarkStackSize is still smaller. [This is related to my >>>>>>>>> earlier comment about constraints between options being tested >>>>>>>>> twice >>>>>>>>> and failures reported twice.] Do we care in this case? >>>>>>>> If your concern is something like >>>>>>>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>>>>>>> Yes, in this case the order is important as ranges and >>>>>>>> constraint functions are verified by its order. >>>>>>>> MarkStackSizeMax will be verified first(its range) and >>>>>>>> MarkStackSize will be compared with verified MarkStackSizeMax. >>>>>>>> >>>>>>>> And as I said your original concern is current limitation. >>>>>>>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>>>>>>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>>>>>>> they will print out 2 failure messages. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>>> >>>>>>>>> Other than that, looks good. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From sangheon.kim at oracle.com Fri Aug 28 06:44:16 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 27 Aug 2015 23:44:16 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55DE3E11.4010505@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE22CE.7080600@oracle.com> <55DE2682.8020209@oracle.com> <55DE3612.80101@oracle.com> <55DE3E11.4010505@oracle.com> Message-ID: <55E00340.7020509@oracle.com> Hi Jon, Gerard and Derek, Here's the new webrev which includes: 1. @requires vm.gc==xx for 4 test cases. (Derek) 2. Change INITIAL_RANGES_SIZE and INITIAL_CONSTRAINTS_SIZE to current actual size. (Gerard) 3. Range of G1UpdateBufferSize is 'NOT_LP64(32*M) LP64_ONLY(1*G)'. (Jon) 4. 'amount' to 'count' at G1YoungSurvRateNumRegionsSummaryConstraintFunc. (Jon) 5. Add more explanation for CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB. (Jon) http://cr.openjdk.java.net/~sangheki/8078555/webrev.04 http://cr.openjdk.java.net/~sangheki/8078555/webrev.04_to_03 Thanks, Sangheon On 08/26/2015 03:30 PM, sangheon.kim wrote: > > > On 08/26/2015 02:56 PM, Jon Masamitsu wrote: >> >> >> On 8/26/2015 1:50 PM, sangheon.kim wrote: >>> Hi Jon, >>> >>> On 08/26/2015 01:34 PM, Jon Masamitsu wrote: >>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/gc/g1/g1_globals.hpp.frames.html >>>> >>>> >>>> How was the 1*G maximum chosen? >>>> >>>> 114 product(size_t, G1UpdateBufferSize, >>>> 256, \ >>>> 115 "Size of an update >>>> buffer") \ >>>> 116 range(1, 1*G) >>>> >>>> >>>> Maybe this was already discussed? >>> You have eagles eye! :) >>> Personally I asked to Thomas and his suggestion was 'I think >>> something in the MB range should be "enough" '. >>> >>> I know that 1G is quite different from MB range but I wanted to find >>> not making problem range. >>> One point that would make problem is >>> 'G1CollectedHeap::pending_card_num()'. >>> '(buffer_size * buffer_num + extra_cards)' should not overflow and I >>> think 1G would be safe enough. >> >> 1G seems too large on a 32bit system. I don't know how large buffer_num >> can get but can image it can get large in some instances. >> >> Having said that this is not necessarily something that can be fixed at >> flag validation time. This may be one of those cases where the >> calculated >> numbers are too dynamic to catch early. If you can make the check >> different on a 32bit system, 32M might be a better number on a >> 32bit system. Leave it 1G on a 64bit system. > Okay, I will change as you mentioned. > range(1, NOT_LP64(32*M) LP64_ONLY(1*G)) > > This will be included at next webrev. > > Thanks, > Sangheon > > >> >> Jon >> >>> But I know that it is too large as a buffer size. :( >>> Any suggestion for this? >>> >>> Sangheon >>> >>> >>>> >>>> Jon >>>> >>>> On 8/26/2015 11:51 AM, sangheon.kim wrote: >>>>> Hi Derek, >>>>> >>>>> Thank you for looking at this! >>>>> >>>>> On 08/26/2015 10:59 AM, Derek White wrote: >>>>>> Hi Sangheon, >>>>>> >>>>>> I haven't reviewed the actual ranges and constraints yet, but one >>>>>> thing you might want to consider: >>>>>> >>>>>> For the test cases, you may want synchronize the GC specified to >>>>>> ProcessBuilder with the "@requires gc=" tags. This prevents the >>>>>> test harness from running G1 tests when the test harness is >>>>>> trying to run CMS test, etc, and also avoids potential confusing >>>>>> test failures. >>>>>> >>>>>> @requires vm.gc=="G1" | vm.gc=="null" >>>>>> (or specify Parallel GC as needed). >>>>> Thank you for the explanation. >>>>> I didn't know about this. >>>>> >>>>> So it seems like vm.gc=="null" means not specifying vm option. >>>>> >>>>>> >>>>>> This is for: >>>>>> TestG1ConcMarkStepDurationMillis.java (G1) >>>>>> TestObjectTenuringFlags.java (Parallel) >>>>>> TestInitialTenuringThreshold.java (Parallel) >>>>>> TestG1HeapRegionSize.java (G1) >>>>> Okay, I will add these tags at next webrev. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> - Derek >>>>>> >>>>>> On 8/24/15 5:33 PM, sangheon.kim wrote: >>>>>>> Hi Kim, >>>>>>> >>>>>>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>>>>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>>>>>> wrote: >>>>>>>>> Hi Kim, >>>>>>>>> >>>>>>>>> Here's webrev.03 which includes your comment for MarkStackSize >>>>>>>>> constraint function. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>>>>>> >>>>>>>>> And all your comments will be managed by >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>>>>>> If the value of MarkStackSizeMax were changed later, there's >>>>>>>> nothing >>>>>>>> to verify MarkStackSize is still smaller. [This is related to my >>>>>>>> earlier comment about constraints between options being tested >>>>>>>> twice >>>>>>>> and failures reported twice.] Do we care in this case? >>>>>>> If your concern is something like >>>>>>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>>>>>> Yes, in this case the order is important as ranges and >>>>>>> constraint functions are verified by its order. >>>>>>> MarkStackSizeMax will be verified first(its range) and >>>>>>> MarkStackSize will be compared with verified MarkStackSizeMax. >>>>>>> >>>>>>> And as I said your original concern is current limitation. >>>>>>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>>>>>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>>>>>> they will print out 2 failure messages. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>>> >>>>>>>> Other than that, looks good. >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From kim.barrett at oracle.com Fri Aug 28 16:50:29 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 28 Aug 2015 12:50:29 -0400 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55E00340.7020509@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE22CE.7080600@oracle.com> <55DE2682.8020209@oracle.com> <55DE3612.80101@oracle.com> <55DE3E11.4010505@oracle.com> <55E00340.7020509@oracle.com> Message-ID: <8F2549AA-F0EC-4D15-8862-B10913DBC11F@oracle.com> On Aug 28, 2015, at 2:44 AM, sangheon.kim wrote: > > Hi Jon, Gerard and Derek, > > Here's the new webrev which includes: > 1. @requires vm.gc==xx for 4 test cases. (Derek) > 2. Change INITIAL_RANGES_SIZE and INITIAL_CONSTRAINTS_SIZE to current actual size. (Gerard) > 3. Range of G1UpdateBufferSize is 'NOT_LP64(32*M) LP64_ONLY(1*G)'. (Jon) > 4. 'amount' to 'count' at G1YoungSurvRateNumRegionsSummaryConstraintFunc. (Jon) > 5. Add more explanation for CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB. (Jon) > > http://cr.openjdk.java.net/~sangheki/8078555/webrev.04 > http://cr.openjdk.java.net/~sangheki/8078555/webrev.04_to_03 One trivial nit, and a question: ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 193 "Desired life time of SoftReferences cannot be expressed correctly. " "life time" => "lifetime" ------------------------------------------------------------------------------ > 1. @requires vm.gc==xx for 4 test cases. (Derek) Is this actually needed? I'm not sure how the process builder works. Does it use any options from the calling process? If not, then I don't think these new @requires are needed. Hm, I see lots of G1 tests that use the process builder and don't have @requires lines, which argues this block of changes is not needed. Sorry I didn't notice this when the change was suggested. ------------------------------------------------------------------------------ Otherwise, looks good. From sangheon.kim at oracle.com Fri Aug 28 17:27:11 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Fri, 28 Aug 2015 10:27:11 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <8F2549AA-F0EC-4D15-8862-B10913DBC11F@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE22CE.7080600@oracle.com> <55DE2682.8020209@oracle.com> <55DE3612.80101@oracle.com> <55DE3E11.4010505@oracle.com> <55E00340.7020509@oracle.com> <8F2549AA-F0EC-4D15-8862-B10913DBC11F@oracle.com> Message-ID: <55E099EF.8050807@oracle.com> Hi Kim, On 08/28/2015 09:50 AM, Kim Barrett wrote: > On Aug 28, 2015, at 2:44 AM, sangheon.kim wrote: >> Hi Jon, Gerard and Derek, >> >> Here's the new webrev which includes: >> 1. @requires vm.gc==xx for 4 test cases. (Derek) >> 2. Change INITIAL_RANGES_SIZE and INITIAL_CONSTRAINTS_SIZE to current actual size. (Gerard) >> 3. Range of G1UpdateBufferSize is 'NOT_LP64(32*M) LP64_ONLY(1*G)'. (Jon) >> 4. 'amount' to 'count' at G1YoungSurvRateNumRegionsSummaryConstraintFunc. (Jon) >> 5. Add more explanation for CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB. (Jon) >> >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.04 >> http://cr.openjdk.java.net/~sangheki/8078555/webrev.04_to_03 > One trivial nit, and a question: > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 193 "Desired life time of SoftReferences cannot be expressed correctly. " > > "life time" => "lifetime" Okay, fixed. > > ------------------------------------------------------------------------------ >> 1. @requires vm.gc==xx for 4 test cases. (Derek) > Is this actually needed? I'm not sure how the process builder works. > Does it use any options from the calling process? If you are asking about any options are passed via @run tag, NO these 4 tests don't use them. e.g. @run main/othervm -XX:xxxxx I added them as ProcessTools.createJavaProcessBuilder() takes specific GC mode options. Maybe I am misunderstanding the tag. Anyone can give clear advice for this? Derek? > If not, then I > don't think these new @requires are needed. > > Hm, I see lots of G1 tests that use the process builder and don't have > @requires lines, which argues this block of changes is not needed. Right. > > Sorry I didn't notice this when the change was suggested. Not at all. Thanks, Sangheon > > ------------------------------------------------------------------------------ > > Otherwise, looks good. > From jon.masamitsu at oracle.com Fri Aug 28 19:01:54 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 28 Aug 2015 12:01:54 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55E00340.7020509@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE22CE.7080600@oracle.com> <55DE2682.8020209@oracle.com> <55DE3612.80101@oracle.com> <55DE3E11.4010505@oracle.com> <55E00340.7020509@oracle.com> Message-ID: <55E0B022.8010202@oracle.com> Changes look good. Jon On 8/27/2015 11:44 PM, sangheon.kim wrote: > Hi Jon, Gerard and Derek, > > Here's the new webrev which includes: > 1. @requires vm.gc==xx for 4 test cases. (Derek) > 2. Change INITIAL_RANGES_SIZE and INITIAL_CONSTRAINTS_SIZE to current > actual size. (Gerard) > 3. Range of G1UpdateBufferSize is 'NOT_LP64(32*M) LP64_ONLY(1*G)'. (Jon) > 4. 'amount' to 'count' at > G1YoungSurvRateNumRegionsSummaryConstraintFunc. (Jon) > 5. Add more explanation for > CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB. (Jon) > > http://cr.openjdk.java.net/~sangheki/8078555/webrev.04 > http://cr.openjdk.java.net/~sangheki/8078555/webrev.04_to_03 > > Thanks, > Sangheon > > > On 08/26/2015 03:30 PM, sangheon.kim wrote: >> >> >> On 08/26/2015 02:56 PM, Jon Masamitsu wrote: >>> >>> >>> On 8/26/2015 1:50 PM, sangheon.kim wrote: >>>> Hi Jon, >>>> >>>> On 08/26/2015 01:34 PM, Jon Masamitsu wrote: >>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/gc/g1/g1_globals.hpp.frames.html >>>>> >>>>> >>>>> How was the 1*G maximum chosen? >>>>> >>>>> 114 product(size_t, G1UpdateBufferSize, >>>>> 256, \ >>>>> 115 "Size of an update >>>>> buffer") \ >>>>> 116 range(1, 1*G) >>>>> >>>>> >>>>> Maybe this was already discussed? >>>> You have eagles eye! :) >>>> Personally I asked to Thomas and his suggestion was 'I think >>>> something in the MB range should be "enough" '. >>>> >>>> I know that 1G is quite different from MB range but I wanted to >>>> find not making problem range. >>>> One point that would make problem is >>>> 'G1CollectedHeap::pending_card_num()'. >>>> '(buffer_size * buffer_num + extra_cards)' should not overflow and >>>> I think 1G would be safe enough. >>> >>> 1G seems too large on a 32bit system. I don't know how large >>> buffer_num >>> can get but can image it can get large in some instances. >>> >>> Having said that this is not necessarily something that can be fixed at >>> flag validation time. This may be one of those cases where the >>> calculated >>> numbers are too dynamic to catch early. If you can make the check >>> different on a 32bit system, 32M might be a better number on a >>> 32bit system. Leave it 1G on a 64bit system. >> Okay, I will change as you mentioned. >> range(1, NOT_LP64(32*M) LP64_ONLY(1*G)) >> >> This will be included at next webrev. >> >> Thanks, >> Sangheon >> >> >>> >>> Jon >>> >>>> But I know that it is too large as a buffer size. :( >>>> Any suggestion for this? >>>> >>>> Sangheon >>>> >>>> >>>>> >>>>> Jon >>>>> >>>>> On 8/26/2015 11:51 AM, sangheon.kim wrote: >>>>>> Hi Derek, >>>>>> >>>>>> Thank you for looking at this! >>>>>> >>>>>> On 08/26/2015 10:59 AM, Derek White wrote: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> I haven't reviewed the actual ranges and constraints yet, but >>>>>>> one thing you might want to consider: >>>>>>> >>>>>>> For the test cases, you may want synchronize the GC specified to >>>>>>> ProcessBuilder with the "@requires gc=" tags. This prevents the >>>>>>> test harness from running G1 tests when the test harness is >>>>>>> trying to run CMS test, etc, and also avoids potential confusing >>>>>>> test failures. >>>>>>> >>>>>>> @requires vm.gc=="G1" | vm.gc=="null" >>>>>>> (or specify Parallel GC as needed). >>>>>> Thank you for the explanation. >>>>>> I didn't know about this. >>>>>> >>>>>> So it seems like vm.gc=="null" means not specifying vm option. >>>>>> >>>>>>> >>>>>>> This is for: >>>>>>> TestG1ConcMarkStepDurationMillis.java (G1) >>>>>>> TestObjectTenuringFlags.java (Parallel) >>>>>>> TestInitialTenuringThreshold.java (Parallel) >>>>>>> TestG1HeapRegionSize.java (G1) >>>>>> Okay, I will add these tags at next webrev. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> - Derek >>>>>>> >>>>>>> On 8/24/15 5:33 PM, sangheon.kim wrote: >>>>>>>> Hi Kim, >>>>>>>> >>>>>>>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>>>>>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim >>>>>>>>> wrote: >>>>>>>>>> Hi Kim, >>>>>>>>>> >>>>>>>>>> Here's webrev.03 which includes your comment for >>>>>>>>>> MarkStackSize constraint function. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>>>>>>> >>>>>>>>>> And all your comments will be managed by >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>>>>>>> If the value of MarkStackSizeMax were changed later, there's >>>>>>>>> nothing >>>>>>>>> to verify MarkStackSize is still smaller. [This is related to my >>>>>>>>> earlier comment about constraints between options being tested >>>>>>>>> twice >>>>>>>>> and failures reported twice.] Do we care in this case? >>>>>>>> If your concern is something like >>>>>>>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>>>>>>> Yes, in this case the order is important as ranges and >>>>>>>> constraint functions are verified by its order. >>>>>>>> MarkStackSizeMax will be verified first(its range) and >>>>>>>> MarkStackSize will be compared with verified MarkStackSizeMax. >>>>>>>> >>>>>>>> And as I said your original concern is current limitation. >>>>>>>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid >>>>>>>> values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>>>>>>> they will print out 2 failure messages. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>>> >>>>>>>>> Other than that, looks good. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From derek.white at oracle.com Fri Aug 28 20:41:25 2015 From: derek.white at oracle.com (Derek White) Date: Fri, 28 Aug 2015 16:41:25 -0400 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55E099EF.8050807@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE22CE.7080600@oracle.com> <55DE2682.8020209@oracle.com> <55DE3612.80101@oracle.com> <55DE3E11.4010505@oracle.com> <55E00340.7020509@oracle.com> <8F2549AA-F0EC-4D15-8862-B10913DBC11F@oracle.com> <55E099EF.8050807@oracle.com> Message-ID: <55E0C775.7000208@oracle.com> Hi Sangheon, Kim, On 8/28/15 1:27 PM, sangheon.kim wrote: > Hi Kim, > > On 08/28/2015 09:50 AM, Kim Barrett wrote: >> On Aug 28, 2015, at 2:44 AM, sangheon.kim >> wrote: >> >>> 1. @requires vm.gc==xx for 4 test cases. (Derek) >> Is this actually needed? I'm not sure how the process builder works. >> Does it use any options from the calling process? This is an FYI - not a stopper. The main issue is that there's a disconnect between the jtreg framework, including the @requires mechanism, and most tests that use ProcessTools. Adding "@requires vm.gc=" doesn't totally fix the problem, but it ties the two together. If you don't do @requires, then this situation can happen: Due to jtreg argument roulette in nightlies, jtreg will run TestObjectTenuringFlags (which is a parallel-only test), while perhaps specifying |-XX:+UseG1GC and/or ||-||/XX/:+UseConcMarkSweepGC|to the outer level test. But there's no point running the outer test framework four ways (default, g1, cms, and parallel) when the real inner test always gets run with parallel GC. You just ran the same test 4 times. This is not directly harmful, but it's unnecessary and makes jtreg nightly runs longer. It's also indirectly harmful because when a failure occurs it's very easy for bug triage or the initial bug handler to get confused and think it's a G1 or CMS bug (because that's at the top-level of the error report says). Yes, this has happened to me! > If you are asking about any options are passed via @run tag, NO these > 4 tests don't use them. > e.g. > @run main/othervm -XX:xxxxx > > I added them as ProcessTools.createJavaProcessBuilder() takes specific > GC mode options. > Maybe I am misunderstanding the tag. > > Anyone can give clear advice for this? Derek? > >> If not, then I >> don't think these new @requires are needed. >> >> Hm, I see lots of G1 tests that use the process builder and don't have >> @requires lines, which argues this block of changes is not needed. > Right. And if all the other tests jumped off a bridge would you do it too? :-) In short, I don't think the change is strictly necessary, but I think it's a good idea that we should start using in all of our GC-specific tests that go through ProcessTools. I'm fine with or without this change. Maybe I should bring it up in the SQE talk at the offsite to get consensus. - Derek From sangheon.kim at oracle.com Fri Aug 28 22:23:37 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Fri, 28 Aug 2015 15:23:37 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55E0C775.7000208@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE22CE.7080600@oracle.com> <55DE2682.8020209@oracle.com> <55DE3612.80101@oracle.com> <55DE3E11.4010505@oracle.com> <55E00340.7020509@oracle.com> <8F2549AA-F0EC-4D15-8862-B10913DBC11F@oracle.com> <55E099EF.8050807@oracle.com> <55E0C775.7000208@oracle.com> Message-ID: <55E0DF69.50907@oracle.com> Hi Derek, Thank you for the kind explanation! For me adding these tags would be better as these will reduce testing time. Kim, may I ask your opinion? Thanks, Sangheon On 08/28/2015 01:41 PM, Derek White wrote: > Hi Sangheon, Kim, > > On 8/28/15 1:27 PM, sangheon.kim wrote: >> Hi Kim, >> >> On 08/28/2015 09:50 AM, Kim Barrett wrote: >>> On Aug 28, 2015, at 2:44 AM, sangheon.kim >>> wrote: >>> >>>> 1. @requires vm.gc==xx for 4 test cases. (Derek) >>> Is this actually needed? I'm not sure how the process builder works. >>> Does it use any options from the calling process? > This is an FYI - not a stopper. > > The main issue is that there's a disconnect between the jtreg > framework, including the @requires mechanism, and most tests that use > ProcessTools. > > Adding "@requires vm.gc=" doesn't totally fix the problem, but it ties > the two together. If you don't do @requires, then this situation can > happen: > > Due to jtreg argument roulette in nightlies, jtreg will run > TestObjectTenuringFlags (which is a parallel-only test), while perhaps > specifying |-XX:+UseG1GC and/or ||-||/XX/:+UseConcMarkSweepGC|to the > outer level test. But there's no point running the outer test > framework four ways (default, g1, cms, and parallel) when the real > inner test always gets run with parallel GC. You just ran the same > test 4 times. This is not directly harmful, but it's unnecessary and > makes jtreg nightly runs longer. > > It's also indirectly harmful because when a failure occurs it's very > easy for bug triage or the initial bug handler to get confused and > think it's a G1 or CMS bug (because that's at the top-level of the > error report says). Yes, this has happened to me! > >> If you are asking about any options are passed via @run tag, NO these >> 4 tests don't use them. >> e.g. >> @run main/othervm -XX:xxxxx >> >> I added them as ProcessTools.createJavaProcessBuilder() takes >> specific GC mode options. >> Maybe I am misunderstanding the tag. >> >> Anyone can give clear advice for this? Derek? >> >>> If not, then I >>> don't think these new @requires are needed. >>> >>> Hm, I see lots of G1 tests that use the process builder and don't have >>> @requires lines, which argues this block of changes is not needed. >> Right. > And if all the other tests jumped off a bridge would you do it too? > :-) In short, I don't think the change is strictly necessary, but I > think it's a good idea that we should start using in all of our > GC-specific tests that go through ProcessTools. > > I'm fine with or without this change. Maybe I should bring it up in > the SQE talk at the offsite to get consensus. > > - Derek From david.holmes at oracle.com Mon Aug 31 04:12:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 Aug 2015 14:12:51 +1000 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55DF86C8.3030200@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> <55B1119D.4030802@oracle.com> <55C41C20.90208@oracle.com> <55C83C5C.60702@oracle.com> <55C8D456.9030006@oracle.com> <5A08C1CB-58F9-4193-802F-767EE11F4D2B@oracle.com> <55CA4E0E.2070503@oracle.com> <55DB540A.4010804@oracle.com> <55DCE602.3040801@oracle.com> <55DE9846.8050008@oracle.com> <55DF86C8.3030200@oracle.com> Message-ID: <55E3D443.5020708@oracle.com> Hi Derek, Looking good - thanks for the persistence! One minor comment in arguments.cpp: 327 { "not deprecated or obsolete", JDK_Version::undefined(), JDK_Version::jdk(9), JDK_Version::undefined() }, That appears to be obsolete. Did you mean: { "not deprecated or obsolete", JDK_Version::undefined(), JDK_Version::undefined(), JDK_Version::jdk(9) }, ? Thanks, David On 28/08/2015 7:53 AM, Derek White wrote: > Hi David, > > Comments inline... > > On 8/27/15 12:55 AM, David Holmes wrote: >> On 26/08/2015 8:02 AM, Derek White wrote: >>> Thanks Karen! >>> >>> If I don't get any other feedback, can I get you to sponsor the change >>> for me? After folding in your fixes... >> >> I need to see those fixes first as I got quite confused trying to >> reconcile the code with the documentation. > OK, I've integrated Karen's final documentation feedback. > >> I'm unclear why is_obsolete doesn't care about EXPIRED but >> is_deprecated does? > Because the caller of is_obsolete doesn't care about EXPIRED but the > caller of is_deprecated does :-) > > In the first case, Arguments::process_argument has already tried > processing the argument as a normal, aliased, or deprecated flag, and > failed. Right before it starts whining about illegal flags it checks to > see if it's obsolete, and if so prints the warning and continues on to > the next flag. If the flag isn't obsolete then it must be non-existent. > But process_argument treats both cases the same (it's in the definition > of EXPIRED). In any case, that was the contract for the original > is_newly_obsolete() method. > > In the "is_deprecated" case, the caller (parse_argument) is in the > middle of handling a real-life global flag, but it needs to decide if > should print a deprecation warning, or treat it as a normal flag, or > note that the flag is now obsolete or expired, in which case it has to > bail out of parse_argument. So parse_argument needs to know three states. >> Also you often state something like "fits into the range specified" >> but it is unclear what range you are referring to. > > I simplified both the code and documentation you mentioned. The > implementations had gotten "overly factored". I hope you find the new > code and documentation clearer. > > I have a JPRT build out running, but are the new webrevs: > > http://cr.openjdk.java.net/~drwhite/8066821/webrev.09 > http://cr.openjdk.java.net/~drwhite/8066821/webrev.8.v.9 > http://cr.openjdk.java.net/~drwhite/8066821/webrev.7.v.9 > > Thanks for your comments! > > - Derek >> >> Thanks, >> David >> >>> - Derek >>> >>> On 8/25/15 2:05 PM, Karen Kinnear wrote: >>>> Derek, >>>> >>>> Many thanks for the latest changes. And thank you for the >>>> verify_special_jvm_flags -- that will remind us to >>>> clean up the flags when the version number changes. So the expired_in >>>> information is for internal use only - we >>>> don't print that information for users, we simply tell them "in a >>>> future release". >>>> >>>> Looks good. No need for my further code review. >>>> >>>> Minor comments: >>>> 1. arguments.hpp >>>> line 421 "In the case" -> "In this case" >>>> >>>> 2. arguments.cpp comments >>>> >>>> I love the high level comments - could you possibly update them? >>>> - e.g. they still talk about the deprecated_jvm_flags and >>>> obsolete_jvm_flags tables. >>>> - e.g. expired and obsolete options should have their global >>>> variable definitions and >>>> related implementations removed ... >>>> >>>> comment line 2119 - extra spaces at the front? (or webrev artifact?) >>>> >>>> thanks very much, >>>> Karen >>>> >>>> >>>> >>>> >>>> On Aug 24, 2015, at 1:27 PM, Derek White wrote: >>>> >>>>> RFR: >>>>> >>>>> This version incorporates Dave and Karen's suggestions to >>>>> automatically handle deprecated-> obsolete transitions. This is >>>>> implemented with a unified table of deprecated and obsolete options >>>>> ("special_jvm_flags"). >>>>> >>>>> Karen also suggested (offline) that it would be good to verify that >>>>> obsolete and expired options no longer have a "globals" variable >>>>> defined. This revision adds debug checking of the special_jvm_flags >>>>> table to check a bunch of constraints, such as deprecated version >>>>> must be < obsolete version < expired version, and checks for >>>>> duplicate table entries as well as looking for left-over "globals" >>>>> variables. >>>>> >>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.08 >>>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>>> >>>>> I also have a webrev of webrev.07 vs. webrev.08: >>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.7.v.8 >>>>> >>>>> Thanks for looking! >>>>> >>>>> - Derek >>>>> >>>>> On 8/11/15 3:33 PM, Derek White wrote: >>>>>> Hi Karen, >>>>>> >>>>>> As much as I want to get this RFE over and out, I see your and David >>>>>> H's point :-) >>>>>> >>>>>> I'll spin another rev... >>>>>> >>>>>> - Derek >>>>>> >>>>>> On 8/10/15 6:07 PM, Karen Kinnear wrote: >>>>>>> Derek, >>>>>>> >>>>>>> Thank you for all of your work on this and responses to suggestions. >>>>>>> >>>>>>> I had a couple of questions/comments: >>>>>>> >>>>>>> I appreciate that you have created mechanisms to allow: >>>>>>> 1. 2 step obsolete: obsolete_jvm_flags >>>>>>> - step 1: obsolete: warn and ignore >>>>>>> - step 2: expire >>>>>>> - and I expect we will use this for most -XX flags, especially >>>>>>> develop flags >>>>>>> >>>>>>> 2. 2 step deprecate: deprecated_jvm_flags >>>>>>> - step 1: deprecate: warn and handle >>>>>>> - step 2: expire >>>>>>> >>>>>>> I see this approach as useful for aliasing and for a few other >>>>>>> flags, but not >>>>>>> the common path. >>>>>>> >>>>>>> My concerns: >>>>>>> >>>>>>> With my understanding of how this is set up today, for the flags >>>>>>> that are most exposed to >>>>>>> customers, which would want the 3 step deprecation, it would be too >>>>>>> easy for an engineer >>>>>>> to add the flag to the deprecated_jvm_flags and forget to add it to >>>>>>> the obsolete_jvm_flags, >>>>>>> as the comments under deprecated_jvm_flags suggest. And we don't >>>>>>> want folks to have >>>>>>> to go back and do a second step later for flags if they could do it >>>>>>> all at once. >>>>>>> >>>>>>> I think it would be confusing to add a flag to both >>>>>>> deprecated_jvm_flags and obsolete_jvm_flags >>>>>>> at the same time, since then the expiration release is not clear. >>>>>>> >>>>>>> 3. For product non-XX, commercial and common -XX flags what I would >>>>>>> like to see is >>>>>>> a three-step table which I would have called deprecated_jvm_flags, >>>>>>> which did >>>>>>> - step 1: deprecate: warn and handle >>>>>>> - step 2: obsolete: warn and ignore >>>>>>> - step 3: expire: unrecognized error >>>>>>> >>>>>>> Would you be willing to add a table like that which is the >>>>>>> recommended approach >>>>>>> for external supported flags? >>>>>>> >>>>>>> So one way to do this would be to change the current >>>>>>> deprecated_jvm_flags to have >>>>>>> three fields, so that the usual path would be to have three >>>>>>> releases listed, and >>>>>>> for aliased flags leave the middle field with the undefined version. >>>>>>> >>>>>>> Another approach would be to have the three fields and have it >>>>>>> used by >>>>>>> all three approaches, just fill in the steps that are appropriate. >>>>>>> >>>>>>> minor comment: >>>>>>> >>>>>>> >>>>>>> 1. arguments.hpp >>>>>>> Could you possibly change the comments from "and has expired >>>>>>> (should be ignored)" to >>>>>>> "and has expired (unrecognized error)" >>>>>>> >>>>>>> unless what you mean really is should be ignored, which is not the >>>>>>> same expired. >>>>>>> >>>>>>> thanks, >>>>>>> Karen >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Aug 10, 2015, at 12:41 PM, Derek White wrote: >>>>>>> >>>>>>>> Thanks David! >>>>>>>> >>>>>>>> - Derek >>>>>>>> >>>>>>>> On 8/10/15 1:53 AM, David Holmes wrote: >>>>>>>>> Hi Derek, >>>>>>>>> >>>>>>>>> I don't have any further comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 7/08/2015 12:46 PM, Derek White wrote: >>>>>>>>>> Another RFR. >>>>>>>>>> >>>>>>>>>> I've updated based on David and Kim's last comments. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/ >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>>>>>>>> >>>>>>>>>> I also have a webrev of webrev.06 vs. webrev.07: >>>>>>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/ >>>>>>>>>> >>>>>>>>>> [This webrev is confused about CommandLineOptionTest.java. I >>>>>>>>>> double-checked with a recursive diff and the only differences >>>>>>>>>> are in >>>>>>>>>> arguments.cpp and arguments.hpp.] >>>>>>>>>> >>>>>>>>>> Thanks for looking! >>>>>>>>>> >>>>>>>>>> - Derek >>>>>>>>>> .... >>> > From gerard.ziemski at oracle.com Mon Aug 31 16:19:51 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Mon, 31 Aug 2015 11:19:51 -0500 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55E00340.7020509@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE22CE.7080600@oracle.com> <55DE2682.8020209@oracle.com> <55DE3612.80101@oracle.com> <55DE3E11.4010505@oracle.com> <55E00340.7020509@oracle.com> Message-ID: <55E47EA7.3030105@oracle.com> hi Sangheon, Looks good. cheers On 08/28/2015 01:44 AM, sangheon.kim wrote: > Hi Jon, Gerard and Derek, > > Here's the new webrev which includes: > 1. @requires vm.gc==xx for 4 test cases. (Derek) > 2. Change INITIAL_RANGES_SIZE and INITIAL_CONSTRAINTS_SIZE to current actual size. (Gerard) > 3. Range of G1UpdateBufferSize is 'NOT_LP64(32*M) LP64_ONLY(1*G)'. (Jon) > 4. 'amount' to 'count' at G1YoungSurvRateNumRegionsSummaryConstraintFunc. (Jon) > 5. Add more explanation for CheckMaxHeapSizeAndSoftRefLRUPolicyMSPerMB. (Jon) > > http://cr.openjdk.java.net/~sangheki/8078555/webrev.04 > http://cr.openjdk.java.net/~sangheki/8078555/webrev.04_to_03 > > Thanks, > Sangheon > > > On 08/26/2015 03:30 PM, sangheon.kim wrote: >> >> >> On 08/26/2015 02:56 PM, Jon Masamitsu wrote: >>> >>> >>> On 8/26/2015 1:50 PM, sangheon.kim wrote: >>>> Hi Jon, >>>> >>>> On 08/26/2015 01:34 PM, Jon Masamitsu wrote: >>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03/src/share/vm/gc/g1/g1_globals.hpp.frames.html >>>>> >>>>> How was the 1*G maximum chosen? >>>>> >>>>> 114 product(size_t, G1UpdateBufferSize, 256, \ >>>>> 115 "Size of an update buffer") \ >>>>> 116 range(1, 1*G) >>>>> >>>>> >>>>> Maybe this was already discussed? >>>> You have eagles eye! :) >>>> Personally I asked to Thomas and his suggestion was 'I think something in the MB range should be "enough" '. >>>> >>>> I know that 1G is quite different from MB range but I wanted to find not making problem range. >>>> One point that would make problem is 'G1CollectedHeap::pending_card_num()'. >>>> '(buffer_size * buffer_num + extra_cards)' should not overflow and I think 1G would be safe enough. >>> >>> 1G seems too large on a 32bit system. I don't know how large buffer_num >>> can get but can image it can get large in some instances. >>> >>> Having said that this is not necessarily something that can be fixed at >>> flag validation time. This may be one of those cases where the calculated >>> numbers are too dynamic to catch early. If you can make the check >>> different on a 32bit system, 32M might be a better number on a >>> 32bit system. Leave it 1G on a 64bit system. >> Okay, I will change as you mentioned. >> range(1, NOT_LP64(32*M) LP64_ONLY(1*G)) >> >> This will be included at next webrev. >> >> Thanks, >> Sangheon >> >> >>> >>> Jon >>> >>>> But I know that it is too large as a buffer size. :( >>>> Any suggestion for this? >>>> >>>> Sangheon >>>> >>>> >>>>> >>>>> Jon >>>>> >>>>> On 8/26/2015 11:51 AM, sangheon.kim wrote: >>>>>> Hi Derek, >>>>>> >>>>>> Thank you for looking at this! >>>>>> >>>>>> On 08/26/2015 10:59 AM, Derek White wrote: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> I haven't reviewed the actual ranges and constraints yet, but one thing you might want to consider: >>>>>>> >>>>>>> For the test cases, you may want synchronize the GC specified to ProcessBuilder with the "@requires gc=" tags. >>>>>>> This prevents the test harness from running G1 tests when the test harness is trying to run CMS test, etc, and >>>>>>> also avoids potential confusing test failures. >>>>>>> >>>>>>> @requires vm.gc=="G1" | vm.gc=="null" >>>>>>> (or specify Parallel GC as needed). >>>>>> Thank you for the explanation. >>>>>> I didn't know about this. >>>>>> >>>>>> So it seems like vm.gc=="null" means not specifying vm option. >>>>>> >>>>>>> >>>>>>> This is for: >>>>>>> TestG1ConcMarkStepDurationMillis.java (G1) >>>>>>> TestObjectTenuringFlags.java (Parallel) >>>>>>> TestInitialTenuringThreshold.java (Parallel) >>>>>>> TestG1HeapRegionSize.java (G1) >>>>>> Okay, I will add these tags at next webrev. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> - Derek >>>>>>> >>>>>>> On 8/24/15 5:33 PM, sangheon.kim wrote: >>>>>>>> Hi Kim, >>>>>>>> >>>>>>>> On 08/24/2015 02:16 PM, Kim Barrett wrote: >>>>>>>>> On Aug 24, 2015, at 3:06 PM, sangheon.kim wrote: >>>>>>>>>> Hi Kim, >>>>>>>>>> >>>>>>>>>> Here's webrev.03 which includes your comment for MarkStackSize constraint function. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03 >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8078555/webrev.03_to_02/ >>>>>>>>>> >>>>>>>>>> And all your comments will be managed by https://bugs.openjdk.java.net/browse/JDK-8134348 . >>>>>>>>> If the value of MarkStackSizeMax were changed later, there's nothing >>>>>>>>> to verify MarkStackSize is still smaller. [This is related to my >>>>>>>>> earlier comment about constraints between options being tested twice >>>>>>>>> and failures reported twice.] Do we care in this case? >>>>>>>> If your concern is something like >>>>>>>> -XX:MarkStackSize=128 -XX:MarkStackSizeMax=100. >>>>>>>> Yes, in this case the order is important as ranges and constraint functions are verified by its order. >>>>>>>> MarkStackSizeMax will be verified first(its range) and MarkStackSize will be compared with verified >>>>>>>> MarkStackSizeMax. >>>>>>>> >>>>>>>> And as I said your original concern is current limitation. >>>>>>>> If we set CMSOldPLABMin and CMSOldPLABMax together with invalid values (e.g. CMSOldPLABMin=100, CMSOldPLABMax=50), >>>>>>>> they will print out 2 failure messages. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>>> >>>>>>>>> Other than that, looks good. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > > From kim.barrett at oracle.com Mon Aug 31 18:05:01 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 31 Aug 2015 14:05:01 -0400 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <55E0C775.7000208@oracle.com> References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE22CE.7080600@oracle.com> <55DE2682.8020209@oracle.com> <55DE3612.80101@oracle.com> <55DE3E11.4010505@oracle.com> <55E00340.7020509@oracle.com> <8F2549AA-F0EC-4D15-8862-B10913DBC11F@oracle.com> <55E099EF.8050807@oracle.com> <55E0C775.7000208@oracle.com> Message-ID: On Aug 28, 2015, at 4:41 PM, Derek White wrote: > > The main issue is that there's a disconnect between the jtreg framework, including the @requires mechanism, and most tests that use ProcessTools. > > Adding "@requires vm.gc=" doesn't totally fix the problem, but it ties the two together. If you don't do @requires, then this situation can happen: > > Due to jtreg argument roulette in nightlies, jtreg will run TestObjectTenuringFlags (which is a parallel-only test), while perhaps specifying |-XX:+UseG1GC and/or ||-||/XX/:+UseConcMarkSweepGC|to the outer level test. But there's no point running the outer test framework four ways (default, g1, cms, and parallel) when the real inner test always gets run with parallel GC. You just ran the same test 4 times. This is not directly harmful, but it's unnecessary and makes jtreg nightly runs longer. Derek - thanks for the explanation. Given how intermittent some of our bugs can be, this might not even be strictly harmful. But I see your point. > It's also indirectly harmful because when a failure occurs it's very easy for bug triage or the initial bug handler to get confused and think it's a G1 or CMS bug (because that's at the top-level of the error report says). Yes, this has happened to me! Ouch! Yes, that's a good argument for this kind of change. > I don't think the change is strictly necessary, but I think it's a good idea that we should start using in all of our GC-specific tests that go through ProcessTools. > > I'm fine with or without this change. Maybe I should bring it up in the SQE talk at the offsite to get consensus. Looks like you added this issue to the offsite agenda. I have a mild preference for removing this part of the changes, to be consistent with what seems to be the status quo. (But note that there are a few existing counterexamples.) That preference is not so strong that I would object to going ahead with the changes as is. I'll leave it up to Sangheon, and I don't need a new webrev if he backs out the new @requires. Looks good. From derek.white at oracle.com Mon Aug 31 18:29:09 2015 From: derek.white at oracle.com (Derek White) Date: Mon, 31 Aug 2015 14:29:09 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55E3D443.5020708@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> <55B1119D.4030802@oracle.com> <55C41C20.90208@oracle.com> <55C83C5C.60702@oracle.com> <55C8D456.9030006@oracle.com> <5A08C1CB-58F9-4193-802F-767EE11F4D2B@oracle.com> <55CA4E0E.2070503@oracle.com> <55DB540A.4010804@oracle.com> <55DCE602.3040801@oracle.com> <55DE9846.8050008@oracle.com> <55DF86C8.3030200@oracle.com> <55E3D443.5020708@oracle.com> Message-ID: <55E49CF5.3080200@oracle.com> Hi David, Thanks for the comments. On 8/31/15 12:12 AM, David Holmes wrote: > Hi Derek, > > Looking good - thanks for the persistence! > > One minor comment in arguments.cpp: > > 327 { "not deprecated or obsolete", JDK_Version::undefined(), > JDK_Version::jdk(9), JDK_Version::undefined() }, > > That appears to be obsolete. Did you mean: > > { "not deprecated or obsolete", JDK_Version::undefined(), > JDK_Version::undefined(), JDK_Version::jdk(9) }, Yes, that was wrong. I fixed this, retested and verified all expected errors were printed. I also moved the test data to the end of the table to keep the import stuff first. I'm re-running jrprt. Would you like another webrev? - Derek > > Thanks, > David > > > > On 28/08/2015 7:53 AM, Derek White wrote: >> Hi David, >> >> Comments inline... >> >> On 8/27/15 12:55 AM, David Holmes wrote: >>> On 26/08/2015 8:02 AM, Derek White wrote: >>>> Thanks Karen! >>>> >>>> If I don't get any other feedback, can I get you to sponsor the change >>>> for me? After folding in your fixes... >>> >>> I need to see those fixes first as I got quite confused trying to >>> reconcile the code with the documentation. >> OK, I've integrated Karen's final documentation feedback. >> >>> I'm unclear why is_obsolete doesn't care about EXPIRED but >>> is_deprecated does? >> Because the caller of is_obsolete doesn't care about EXPIRED but the >> caller of is_deprecated does :-) >> >> In the first case, Arguments::process_argument has already tried >> processing the argument as a normal, aliased, or deprecated flag, and >> failed. Right before it starts whining about illegal flags it checks to >> see if it's obsolete, and if so prints the warning and continues on to >> the next flag. If the flag isn't obsolete then it must be non-existent. >> But process_argument treats both cases the same (it's in the definition >> of EXPIRED). In any case, that was the contract for the original >> is_newly_obsolete() method. >> >> In the "is_deprecated" case, the caller (parse_argument) is in the >> middle of handling a real-life global flag, but it needs to decide if >> should print a deprecation warning, or treat it as a normal flag, or >> note that the flag is now obsolete or expired, in which case it has to >> bail out of parse_argument. So parse_argument needs to know three >> states. >>> Also you often state something like "fits into the range specified" >>> but it is unclear what range you are referring to. >> >> I simplified both the code and documentation you mentioned. The >> implementations had gotten "overly factored". I hope you find the new >> code and documentation clearer. >> >> I have a JPRT build out running, but are the new webrevs: >> >> http://cr.openjdk.java.net/~drwhite/8066821/webrev.09 >> http://cr.openjdk.java.net/~drwhite/8066821/webrev.8.v.9 >> http://cr.openjdk.java.net/~drwhite/8066821/webrev.7.v.9 >> >> Thanks for your comments! >> >> - Derek >>> >>> Thanks, >>> David >>> >>>> - Derek >>>> >>>> On 8/25/15 2:05 PM, Karen Kinnear wrote: >>>>> Derek, >>>>> >>>>> Many thanks for the latest changes. And thank you for the >>>>> verify_special_jvm_flags -- that will remind us to >>>>> clean up the flags when the version number changes. So the expired_in >>>>> information is for internal use only - we >>>>> don't print that information for users, we simply tell them "in a >>>>> future release". >>>>> >>>>> Looks good. No need for my further code review. >>>>> >>>>> Minor comments: >>>>> 1. arguments.hpp >>>>> line 421 "In the case" -> "In this case" >>>>> >>>>> 2. arguments.cpp comments >>>>> >>>>> I love the high level comments - could you possibly update them? >>>>> - e.g. they still talk about the deprecated_jvm_flags and >>>>> obsolete_jvm_flags tables. >>>>> - e.g. expired and obsolete options should have their global >>>>> variable definitions and >>>>> related implementations removed ... >>>>> >>>>> comment line 2119 - extra spaces at the front? (or webrev artifact?) >>>>> >>>>> thanks very much, >>>>> Karen >>>>> >>>>> >>>>> >>>>> >>>>> On Aug 24, 2015, at 1:27 PM, Derek White wrote: >>>>> >>>>>> RFR: >>>>>> >>>>>> This version incorporates Dave and Karen's suggestions to >>>>>> automatically handle deprecated-> obsolete transitions. This is >>>>>> implemented with a unified table of deprecated and obsolete options >>>>>> ("special_jvm_flags"). >>>>>> >>>>>> Karen also suggested (offline) that it would be good to verify that >>>>>> obsolete and expired options no longer have a "globals" variable >>>>>> defined. This revision adds debug checking of the special_jvm_flags >>>>>> table to check a bunch of constraints, such as deprecated version >>>>>> must be < obsolete version < expired version, and checks for >>>>>> duplicate table entries as well as looking for left-over "globals" >>>>>> variables. >>>>>> >>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.08 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>>>> >>>>>> I also have a webrev of webrev.07 vs. webrev.08: >>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.7.v.8 >>>>>> >>>>>> Thanks for looking! >>>>>> >>>>>> - Derek >>>>>> >>>>>> On 8/11/15 3:33 PM, Derek White wrote: >>>>>>> Hi Karen, >>>>>>> >>>>>>> As much as I want to get this RFE over and out, I see your and >>>>>>> David >>>>>>> H's point :-) >>>>>>> >>>>>>> I'll spin another rev... >>>>>>> >>>>>>> - Derek >>>>>>> >>>>>>> On 8/10/15 6:07 PM, Karen Kinnear wrote: >>>>>>>> Derek, >>>>>>>> >>>>>>>> Thank you for all of your work on this and responses to >>>>>>>> suggestions. >>>>>>>> >>>>>>>> I had a couple of questions/comments: >>>>>>>> >>>>>>>> I appreciate that you have created mechanisms to allow: >>>>>>>> 1. 2 step obsolete: obsolete_jvm_flags >>>>>>>> - step 1: obsolete: warn and ignore >>>>>>>> - step 2: expire >>>>>>>> - and I expect we will use this for most -XX flags, >>>>>>>> especially >>>>>>>> develop flags >>>>>>>> >>>>>>>> 2. 2 step deprecate: deprecated_jvm_flags >>>>>>>> - step 1: deprecate: warn and handle >>>>>>>> - step 2: expire >>>>>>>> >>>>>>>> I see this approach as useful for aliasing and for a few other >>>>>>>> flags, but not >>>>>>>> the common path. >>>>>>>> >>>>>>>> My concerns: >>>>>>>> >>>>>>>> With my understanding of how this is set up today, for the flags >>>>>>>> that are most exposed to >>>>>>>> customers, which would want the 3 step deprecation, it would be >>>>>>>> too >>>>>>>> easy for an engineer >>>>>>>> to add the flag to the deprecated_jvm_flags and forget to add >>>>>>>> it to >>>>>>>> the obsolete_jvm_flags, >>>>>>>> as the comments under deprecated_jvm_flags suggest. And we don't >>>>>>>> want folks to have >>>>>>>> to go back and do a second step later for flags if they could >>>>>>>> do it >>>>>>>> all at once. >>>>>>>> >>>>>>>> I think it would be confusing to add a flag to both >>>>>>>> deprecated_jvm_flags and obsolete_jvm_flags >>>>>>>> at the same time, since then the expiration release is not clear. >>>>>>>> >>>>>>>> 3. For product non-XX, commercial and common -XX flags what I >>>>>>>> would >>>>>>>> like to see is >>>>>>>> a three-step table which I would have called deprecated_jvm_flags, >>>>>>>> which did >>>>>>>> - step 1: deprecate: warn and handle >>>>>>>> - step 2: obsolete: warn and ignore >>>>>>>> - step 3: expire: unrecognized error >>>>>>>> >>>>>>>> Would you be willing to add a table like that which is the >>>>>>>> recommended approach >>>>>>>> for external supported flags? >>>>>>>> >>>>>>>> So one way to do this would be to change the current >>>>>>>> deprecated_jvm_flags to have >>>>>>>> three fields, so that the usual path would be to have three >>>>>>>> releases listed, and >>>>>>>> for aliased flags leave the middle field with the undefined >>>>>>>> version. >>>>>>>> >>>>>>>> Another approach would be to have the three fields and have it >>>>>>>> used by >>>>>>>> all three approaches, just fill in the steps that are appropriate. >>>>>>>> >>>>>>>> minor comment: >>>>>>>> >>>>>>>> >>>>>>>> 1. arguments.hpp >>>>>>>> Could you possibly change the comments from "and has expired >>>>>>>> (should be ignored)" to >>>>>>>> "and has expired (unrecognized error)" >>>>>>>> >>>>>>>> unless what you mean really is should be ignored, which is not the >>>>>>>> same expired. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Karen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Aug 10, 2015, at 12:41 PM, Derek White wrote: >>>>>>>> >>>>>>>>> Thanks David! >>>>>>>>> >>>>>>>>> - Derek >>>>>>>>> >>>>>>>>> On 8/10/15 1:53 AM, David Holmes wrote: >>>>>>>>>> Hi Derek, >>>>>>>>>> >>>>>>>>>> I don't have any further comments. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 7/08/2015 12:46 PM, Derek White wrote: >>>>>>>>>>> Another RFR. >>>>>>>>>>> >>>>>>>>>>> I've updated based on David and Kim's last comments. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/ >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>>>>>>>>>> >>>>>>>>>>> I also have a webrev of webrev.06 vs. webrev.07: >>>>>>>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/ >>>>>>>>>>> >>>>>>>>>>> [This webrev is confused about CommandLineOptionTest.java. I >>>>>>>>>>> double-checked with a recursive diff and the only differences >>>>>>>>>>> are in >>>>>>>>>>> arguments.cpp and arguments.hpp.] >>>>>>>>>>> >>>>>>>>>>> Thanks for looking! >>>>>>>>>>> >>>>>>>>>>> - Derek >>>>>>>>>>> .... >>>> >> From sangheon.kim at oracle.com Mon Aug 31 18:36:28 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 31 Aug 2015 11:36:28 -0700 Subject: RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: References: <55D40546.2060907@oracle.com> <27F3E65F-F871-425F-94D5-CF5CC72A7FD8@oracle.com> <55D509FC.3040307@oracle.com> <55D57435.6050604@oracle.com> <55D62313.2090306@oracle.com> <55D6C5EC.9070202@oracle.com> <0A980270-EEC7-42A0-9464-8B23157AD991@oracle.com> <55DB39EE.9050102@oracle.com> <58086AD6-17EA-4016-BAF1-EBB262C950D3@oracle.com> <55DB6B27.40704@oracle.com> <55DB8DAB.6030501@oracle.com> <55DDFE85.3080904@oracle.com> <55DE0A9A.5030806@oracle.com> <55DE22CE.7080600@oracle.com> <55DE2682.8020209@oracle.com> <55DE3612.80101@oracle.com> <55DE3E11.4010505@oracle.com> <55E00340.7020509@oracle.com> <8F2549AA-F0EC-4D15-8862-B10913DBC11F@oracle.com> <55E099EF.8050807@oracle.com> <55E0C775.7000208@oracle.com> Message-ID: <55E49EAC.7060003@oracle.com> Hi Kim, On 08/31/2015 11:05 AM, Kim Barrett wrote: > On Aug 28, 2015, at 4:41 PM, Derek White wrote: >> The main issue is that there's a disconnect between the jtreg framework, including the @requires mechanism, and most tests that use ProcessTools. >> >> Adding "@requires vm.gc=" doesn't totally fix the problem, but it ties the two together. If you don't do @requires, then this situation can happen: >> >> Due to jtreg argument roulette in nightlies, jtreg will run TestObjectTenuringFlags (which is a parallel-only test), while perhaps specifying |-XX:+UseG1GC and/or ||-||/XX/:+UseConcMarkSweepGC|to the outer level test. But there's no point running the outer test framework four ways (default, g1, cms, and parallel) when the real inner test always gets run with parallel GC. You just ran the same test 4 times. This is not directly harmful, but it's unnecessary and makes jtreg nightly runs longer. > Derek - thanks for the explanation. > > Given how intermittent some of our bugs can be, this might not even be > strictly harmful. But I see your point. > >> It's also indirectly harmful because when a failure occurs it's very easy for bug triage or the initial bug handler to get confused and think it's a G1 or CMS bug (because that's at the top-level of the error report says). Yes, this has happened to me! > Ouch! Yes, that's a good argument for this kind of change. > >> I don't think the change is strictly necessary, but I think it's a good idea that we should start using in all of our GC-specific tests that go through ProcessTools. >> >> I'm fine with or without this change. Maybe I should bring it up in the SQE talk at the offsite to get consensus. > Looks like you added this issue to the offsite agenda. > > I have a mild preference for removing this part of the changes, to be > consistent with what seems to be the status quo. (But note that there > are a few existing counterexamples.) That preference is not so strong > that I would object to going ahead with the changes as is. I'll leave > it up to Sangheon, and I don't need a new webrev if he backs out the > new @requires. Let me include @requires. Thanks, Sangheon > > Looks good. >