From vladimir.kozlov at oracle.com Tue Dec 1 00:53:47 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 Nov 2015 16:53:47 -0800 Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings In-Reply-To: <5656E2C6.1090409@redhat.com> References: <564DB8FF.2080103@redhat.com> <564DE5EC.8040901@oracle.com> <564DE722.3050804@redhat.com> <564DFD47.6010807@oracle.com> <564E0425.4010302@redhat.com> <564E06F1.2080900@oracle.com> <564E0775.6030008@oracle.com> <5656E2C6.1090409@redhat.com> Message-ID: <565CEF9B.4080809@oracle.com> Good. Thanks, Vladimir On 11/26/15 2:45 AM, Andrew Haley wrote: > Here is a reduced webrev, suitable for just the machine-dependent > parts of the fix: > > http://cr.openjdk.java.net/~aph/8143219-2/hotspot.changeset > > All it does is adjust the lengths for string_compare and string_equals. > > Andrew. > From sangheon.kim at oracle.com Tue Dec 1 01:33:41 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 30 Nov 2015 17:33:41 -0800 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <565CDEA5.10603@oracle.com> References: <564F8ADB.9090008@oracle.com> <5654747A.3000908@oracle.com> <56547635.9060808@oracle.com> <56563D89.5090902@oracle.com> <565CD030.50507@oracle.com> <565CDEA5.10603@oracle.com> Message-ID: <565CF8F5.9040504@oracle.com> Hi Gerard again, On 11/30/2015 03:41 PM, sangheon.kim wrote: > Hi Gerard, > > Thank you for reviewing this! > I was waiting your review. > > On 11/30/2015 02:39 PM, gerard ziemski wrote: >> hi Sangheon, >> >> I found a few issues: >> >> ------------- >> #1 An already existing issue, but there are many candidate flags that >> could have their types changed to "size_t", that currently are >> defined as some other type (usually uintx) ex: >> ParGCDesiredObjsFromOverflowList, CMSOldPLABReactivityFactor > Right. > There are some other cases like you mentioned. > Let me address this issue separately. > >> >> >> ------------- >> #2 Why isn't the range here "range(min_intx, max_intx)" ? >> >> src/share/vm/runtime/globals.hpp lines: >> 1985 manageable(intx, CMSWaitDuration, >> 2000, \ >> 1986 "Time in milliseconds that CMS thread waits for young >> GC") \ >> 1987 range(min_jint, >> max_jint) \ > As I shortly explained my RFR, this value is used to set a function > which has an input parameter of 'long' type. > And I think it would be a good reason to narrow its range. > >> >> >> ------------- >> #3 The min in the range must not be 0, because we use it as denominator: >> >> size_t survivor_size = size / InitialSurvivorRatio; >> >> so the range should be range(1, max_uintx) ? > When we reach to that line, InitialSurvivorRatio will be changed to > '3' for min by line 58. generationSizer.cpp > GenerationSizer::initialize_flags() { > .. > if (InitialSurvivorRatio < 3) { > .. > } > >> >> Lines: >> src/share/vm/runtime/globals.hpp lines: >> 2347 "Initial ratio of young generation/survivor space >> size") \ >> 2348 range(0, >> max_uintx) \ >> >> >> ------------- >> #4 The min in the range must not be 0, because we do: >> >> if (_cur_file_num > NumberOfGCLogFiles - 1) _cur_file_num = 0; >> >> so the range should be range(1, max_uintx) ? > NumberOfGCLogFiles==0 is default value for disabling rotation. > And before reaching that line, we already filtered NumberOfGCLogFiles > <= 1 cases. > >> >> src/share/vm/runtime/globals.hpp lines: >> 2599 product(uintx, NumberOfGCLogFiles, >> 0, \ >> 2600 "Number of gclog files in rotation >> " \ >> 2601 "(default: 0, no >> rotation)") \ >> 2602 range(0, >> max_uintx) \ >> >> >> ------------- >> #5 TLABRefillWasteFraction should have a constraint moved from >> Arguments::check_vm_args_consistency to >> src/share/vm/runtime/commandLineFlagConstraintsGC ? >> >> // Check the consistency of vm_init_args >> bool Arguments::check_vm_args_consistency() { >> // Method for adding checks for flag consistency. >> // The intent is to warn the user of all possible conflicts, >> // before returning an error. >> // Note: Needs platform-dependent factoring. >> bool status = true; >> >> if (TLABRefillWasteFraction == 0) { >> jio_fprintf(defaultStream::error_stream(), >> "TLABRefillWasteFraction should be a denominator, " >> "not " SIZE_FORMAT "\n", >> TLABRefillWasteFraction); >> status = false; >> } > Right. We have more cases including this. > David Lindholm filed a CR for moving JDK-8133649. > >> >> src/share/vm/runtime/globals.hpp lines: >> 3419 product(uintx, TLABRefillWasteFraction, >> 64, \ >> 3420 "Maximum TLAB waste at a refill (internal >> fragmentation)") \ >> 3421 range(1, >> max_juint) \ >> >> >> ------------- >> #6 We multiply NewSizeThreadIncrease later, like >> >> size_t thread_increase_size = threads_count * NewSizeThreadIncrease; >> >> so the range's max needs to be smaller than max_uintx by some large >> enough constant (MAX thread count?) > You are right. > We don't have any problem without constraint function but it would be > better to have one. > I will post next webrev soon with this constraint function. Looking at the code again, it is hard to add constraint function for this flag. When we run the constraint function('threads_count' is zero at this time), we don't know how many non-daemon threads will be running. i.e. 'size_t thread_increase_size = threads_count * NewSizeThreadIncrease; ' is executed after GC is happened and the flag validation is occurred much earlier. And as we are using both MIN/MAX macro, I think there will be no value range problem with this flag. What do you think about this? Thanks, Sangheon > > Thanks, > Sangheon > > >> >> src/share/vm/runtime/globals.hpp lines: >> 3437 product_pd(size_t, >> NewSizeThreadIncrease, \ >> 3438 "Additional size added to desired new generation size >> per " \ >> 3439 "non-daemon thread (in >> bytes)") \ >> 3440 range(0, >> max_uintx) \ >> >> >> cheers >> >> On 11/25/2015 05:00 PM, sangheon.kim wrote: >>> Hi all, >>> >>> Here's updated webrev which reflects changes by "JDK-8143038: >>> [TESTBUG] TestOptionsWithRanges: allow excluding only a >>> subset of tested values specified for a flag". >>> >>> The only updated file is >>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java. >>> Changed from "allOptionsAsMap.remove("flag name")" to >>> "excludeTestMaxRange("flag name")". >>> >>> FYI, JDK-8143038 introduced separated exclude methods of >>> "excludeTest, excludeTestMaxRange and excludeTestMinRange". >>> >>> webrev: >>> http://cr.openjdk.java.net/~sangheki/8142341/webrev.01/ >>> http://cr.openjdk.java.net/~sangheki/8142341/webrev.01_to_00/ >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 11/24/2015 06:37 AM, sangheon.kim wrote: >>>> Hi Dmitry, >>>> >>>> Thank you for the review! >>>> Sure I will update my patch related to your enhancement. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote: >>>>> Hi Sangheon, >>>>> >>>>> Looks good to me! Thank you for fixing that. I hope that >>>>> enhancement will be pushed today(currently in JPRT queue), >>>>> so please update your patch after that! >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>>> On 21.11.2015 0:04, sangheon.kim wrote: >>>>>> Hi all, >>>>>> >>>>>> Could I have a couple of reviews for this change to add explicit >>>>>> 'range' for flags? >>>>>> >>>>>> Previously, we added 'range' when it is needed to avoid >>>>>> assert/crash but now explicit 'range' are needed for all flags. >>>>>> All flags should have 'range' or 'constraint' at least. >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8142341 >>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8142341/webrev.00 >>>>>> Testing: JPRT, RBT >>>>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>>> --add-tonga-keyword quick), >>>>>> hotspot/test/runtime/CommandLine for embedded >>>>>> >>>>>> * Summary >>>>>> 1. Added 3 new constraint functions. >>>>>> 1) HeapBaseMinAddress: Added to avoid an overflow after align >>>>>> up and this flag makes hang up without constraint >>>>>> function. (newly added as a part of GC work) >>>>>> 2) TLABWasteIncrement: Without this constraint function we >>>>>> don't have problems (even many GCs happen). But added >>>>>> to avoid an overflow at >>>>>> ThreadLocalAllocBuffer::record_slow_allocation(). There are also >>>>>> separate CR for this >>>>>> overflow ( JDK-8143352 ). >>>>>> 3) NUMAInterleaveGranularity: Added to avoid an overflow after >>>>>> align up. >>>>>> >>>>>> 2. Some flags have narrower range than their type. >>>>>> 1) Here's the reason why some flags should have different >>>>>> range. (same order from globals.hpp) >>>>>> {flag type} {flag name}: (range), {comment} >>>>>> size_t NUMAInterleaveGranularity: >>>>>> (os::vm_allocation_granularity(), max_uintx), there is a comment at >>>>>> numa_interleaving_init() that this flag should be larger than >>>>>> vm_allocation_granularity(). >>>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero >>>>>> as used for multiplication >>>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function >>>>>> which has 'unsigned int' type input parameter. >>>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function >>>>>> which has 'unsigned int' type input parameter. >>>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a >>>>>> function which has 'long' type input parameter. >>>>>> uintx PausePadding: (0, max_juint), used to set a function which >>>>>> has 'unsigned int' type input parameter. >>>>>> uintx PromotedPadding: (0, max_juint), used to set a function >>>>>> which has 'unsigned int' type input parameter. >>>>>> uintx SurvivorPadding: (0, max_juint), used to set a function >>>>>> which has 'unsigned int' type input parameter. >>>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this >>>>>> flag is divided by 100 I assume this is percentage. >>>>>> uintx GCTimeRatio: (0, max_juint), used to set a function which >>>>>> has 'unsigned int' type input parameter. >>>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint) >>>>>> intx PrefetchScanIntervalInBytes: (-1, max_jint) >>>>>> intx PrefetchFieldsAhead: (-1, max_jint), I think these 3 >>>>>> Prefetch* flags should have same upper limit and looking >>>>>> at their related codes 'max_jint' seems appropriate ( no problem >>>>>> with 'max_jint' during testing). However, as >>>>>> Prefetch::read/write() needs 'intx', 'intx' also seems good but >>>>>> we have to fix some codes (maybe including generated >>>>>> codes). >>>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function >>>>>> which has 'unsigned int' type input parameter. >>>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint >>>>>> variable and used 'for loop' which has uint >>>>>> increment. i.e. for (uint i=0; i>>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at >>>>>> 'increment for loop()' as max value and the increment >>>>>> is uint. >>>>>> uintx CMSYieldSleepCount: (0, max_juint), used at 'increment for >>>>>> loop()' as max value and the increment is uint. >>>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return >>>>>> value of uint type function and for division. i.e. >>>>>> uint GCTLABConfiguration::tlab_refill_waste_limit()() { return >>>>>> TLABRefillWasteFraction; } >>>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int) >>>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we >>>>>> only use " if (a !=0, >0, >1)". >>>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we >>>>>> only use " if (a !=0, >0, >1)". >>>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only >>>>>> use " if (a !=0, >0)". >>>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to >>>>>> 'unsigned int' >>>>>> >>>>>> (g1_globals.hpp) >>>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set >>>>>> (int) type variable. >>>>>> >>>>>> 3. Excluded flags from TestOptionsWithRanges.java >>>>>> 1) Memory and thread related flags: tests for these flags will >>>>>> consume too many resources from the system. >>>>>> 2) VMThreadStackSize: range work for this flag is not included in >>>>>> this patch but I faced OOME several times, so >>>>>> excluded. >>>>>> >>>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] >>>>>> TestOptionsWithRanges: allow excluding only a subset of >>>>>> tested values specified for a flag) next time. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> > From gil at azul.com Tue Dec 1 02:58:16 2015 From: gil at azul.com (Gil Tene) Date: Tue, 1 Dec 2015 02:58:16 +0000 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> <562BC968.70603@cs.oswego.edu> <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> Message-ID: <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> Update: After some significant back-and-forth between Doug and I on naming and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have what we think is a good spec and name selection for this thing. We're proposing to add a new static method to the Runtime class: class Runtime { /... /** * Method signifying that the caller is momentarily unable to * progress until the occurrence of one or more actions of one or * more other activities. When invoked within each iteration, this * method typically improves performance of spin wait loop * constructions. */ public static void onSpinWait() {}; } See updated details, including a link to the updated JEP draft, as well as links to working prototype implementations, webrevs against OpenJDK9b94, and example here: https://github.com/giltene/GilExamples/tree/master/SpinWaitTest . All names have changed to reflect the new naming (onSpinWait, -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.). As an interesting stat, the total changes in the WebRevs amount to 78 added lines (across 14 files) , and 0 lines removed or changed. Hopefully a good indication of relatively low footprint and risk. ? Gil. From kim.barrett at oracle.com Tue Dec 1 03:04:56 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 Nov 2015 22:04:56 -0500 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <56566A62.4030902@oracle.com> References: <565631DC.1010800@oracle.com> <56563B4D.3030301@oracle.com> <56566A62.4030902@oracle.com> Message-ID: On Nov 25, 2015, at 9:11 PM, David Holmes wrote: > > We already have VM_Version::early_initialize() that can/should be used for this if possible. VM_Version::early_initialize doesn?t work for this, because determine_features (sparc) examines some command-line arguments, and those aren't parsed until a later stage of Threads::create_vm. Specifically, determine_features (sparc) is presently looking at two CLAs: UseV8InstrsOnly (develop) and UseNiagaraInstrs (product). I suspect UseV8InstrsOnly has served its purpose and could be purged. But calling determine_features before argument parsing would unintentionally ignore UseNiagaraInstrs. Calling determine_features from os::init_before_ergo doesn't have this problem. [I missed this in my review of Jon?s original change to use early_initialize.] From asmundak at google.com Tue Dec 1 03:31:03 2015 From: asmundak at google.com (Alexander Smundak) Date: Mon, 30 Nov 2015 19:31:03 -0800 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <565C4477.4090708@oracle.com> References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> Message-ID: > On 2015-11-30 05:23, David Holmes wrote: >>.. >> At the top level if we see ppc64le then we set VAR_CPU to ppc64le instead >> of ppc64. However, once we get into hotspot build we want ARCH to be ppc64 >> again (in hotspot-spec.gmk.in) - why is that? >> >> Inside hotpot we want: >> >> SRCARCH := ppc >> BUILDARCH := ppc64 >> LIBARCH := ppc64le >> >> right? So can ARCH not be ppc64le from the top-level and then we adjust >> SRCARCH and BUILDARCH? And avoid the top-level changes to ARCH. The new revision does that: http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03 http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03 http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03/ common/autoconf/hotspot-spec.gmk.in has been left alone, and hotspot/make/defs.make sets BUILDARCH and LIBARCH (BUILDARCH should be the same for ppc64 and ppc64le because the file linux/makefiels/$)BUILDARCH).make is pulled in by vm.make) I have also reduced the changeset for hotspot by making sun.jvm.hotspot.utilities.PlatformInfo.getCPU() return "ppc64" both when "os.arch" propertie's value is "ppc64" and "ppc64le". >> >> agent/src/os/linux/LinuxDebuggerLocal.c >> agent/src/os/linux/libproc.h >> >> Is it not the case that ppc64le -> ppc64, so that we can avoid "if >> defined(ppc64) | defined(ppc64le) ? I would hope that the only places in the >> sources where you need to check for ppc64le is where that code differs from >> the ppc64 code. This is defined as -D$(OPENJDK_TARGET_CPU_LEGACY), but the same variable is used in the generated hotspot-spec.gmk file, so I decided it's easier to fix the SA code. >> src/share/vm/runtime/vm_version.cpp >> >> I think this messy code block relates to builds where CPU is not set - >> which should never be the case these days. Maybe just put in a check "ifndef >> CPU -> error" ? > > I agree. There might be a case for handling zero, though. If I remember > correctly the hotspot build might not set CPU, or set it incorrectly, when > building zero. (Then again, zero is a strange beast, a mix between a variant > and a platform...) I have listed platform-specific options for building Hotspot above, but here's the full command line to build vm_version.o for ppc64le: /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/hotspot/src/share/vm/prims -I/hotspot/src/share/vm -I/hotspot/src/share/vm/precompiled -I/hotspot/src/cpu/ppc/vm -I/hotspot/src/os_cpu/linux_ppc/vm -I/hotspot/src/os/linux/vm -I/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_BUILD_USER="\"asmundak\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DHOTSPOT_RELEASE_VERSION="\"1.9.0-internal-asmundak_2015_11_26_17_11-b00\"" -DJRE_RELEASE_VERSION="\"1.9.0-internal-asmundak_2015_11_26_17_11-b00\"" -DJDK_MAJOR_VERSION="\"1\"" -DJDK_MINOR_VERSION="\"9\"" -DJDK_MICRO_VERSION="\"0\"" -DJDK_BUILD_NUMBER="\"b00\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DINCLUDE_JVMCI=0 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual -Wtype-limits -Wno-format-zero-length -Wuninitialized -c -MMD -MP -MF ../generated/dependencies/vm_version.o.d -fpch-deps -o vm_version.o /hotspot/src/share/vm/runtime/vm_version.cpp (I have replaced the actual path to the source tree with ) Preprocessor variable 'CPU' is not defined on the command line, and if I add #error CPU is not defined right after #fndef CPU on line 193 in vm_version.cpp, it will fail to compile at least on Linux ppc64le and Linux x86_64. > I also think something's very weird here. OPENJDK_TARGET_CPU_ARCH is defined > to ppc for both ppc64 and the new ppc64le platform, that it, it explicitely > excludes address size. I think it's reasonable that it excludes endianness > as well, but we have not really had to make that discussion before. In any > case, it should not contain "64", otherwise the value will be "ppc" for > ppc64 and "ppc64le" for ppc64le, and that's just plain wrong. With the proposed patches the generated spec.gmk will contain OPENJDK_TARGET_CPU_OSARCH:=ppc64le when building JDK for the little endian and ppc64 for the big endian. "os.arch" property is set from ARCHPROPNAME preprocessor variable, whose value is $(OPENJDK_TARGET_CPU_ARCH). Did I misunderstand something? From jamsheed.c.m at oracle.com Tue Dec 1 03:47:47 2015 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 1 Dec 2015 09:17:47 +0530 Subject: Removing -XX option Use486InstrsOnly from hotspot. Message-ID: <565D1863.1020608@oracle.com> Hi All, I am planning to remove command line option -XX:+/-Use486InstrsOnly from Hotspot. This flag is too old to be maintained in Hotspot any longer. Let me know if someone is still using this flag? (flag removal decision is triggered by the bug 6808665) Best Regards, Jamsheed From david.holmes at oracle.com Tue Dec 1 05:24:35 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2015 15:24:35 +1000 Subject: Fwd: Re: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <565C80B9.5070202@oracle.com> References: <565631DC.1010800@oracle.com> <56563B4D.3030301@oracle.com> <56566A62.4030902@oracle.com> <565C80B9.5070202@oracle.com> Message-ID: <565D2F13.3080504@oracle.com> Hi Jon, On 1/12/2015 3:00 AM, Jon Masamitsu wrote: > On 11/25/2015 06:11 PM, David Holmes wrote: >> Hi Jon, >> >> We already have VM_Version::early_initialize() that can/should be used >> for this if possible. > > David, > > Thanks for looking at this. I tried to use early_initialize() but found > that I needed to add empty early_initialize() methods for nearly > all the platforms. The code I wanted to move was in os_solaris.cpp > (from the os_init() to the early_initialize()), which made me add an > early_initialize() for solaris x86 which seemed to require I add > an early_initialize() to vm_version_x86.hpp which lead me to > add empty early_initialize() for all the x86 platforms. Yes it does work that way. VM_Version is defined in cpu specific headers, then implemented by os_cpu specific .cpp files. So if you want an os specific early_initialize it will have to be applied to all cpu/os combinations for which your os has a given cpu implementation. But you've added your own VM_Version function in a similar way, so how is this working out any differently ?? (Note your change would also impact a linux/sparc port). David ----- > > http://cr.openjdk.java.net/~jmasa/8133023/webrev.01/ > > Jon >> >> Thanks, >> David >> >> On 26/11/2015 8:50 AM, Jon Masamitsu wrote: >>> Widening the review request. This fixed changed the order >>> of some VM initialization for solaris-sparc with hopefully >>> the minimum change for other platforms. >>> >>> Thanks. >>> >>> Jon >>> >>> -------- Forwarded Message -------- >>> Subject: Re: Request for Review (s) - 8133023: ParallelGCThreads is >>> not calculated correctly >>> Date: Wed, 25 Nov 2015 14:10:36 -0800 >>> From: Jon Masamitsu >>> Organization: Oracle Corporation >>> To: hotspot-gc-dev at openjdk.java.net >>> >>> >>> >>> I have a new fix for this bug. My previous fix broke solaris-x86 (I >>> had not defined an early_initialize() for x86). This fix is slightly >>> smaller and has the virtue of moving the required initialization >>> closer to where it is used. >>> >>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.03/index.html >>> >>> Testing: JPRT build on all platforms, checked by hand that the correct >>> number >>> of GC worker threads are created on later Niagara platforms. >>> >>> Thanks. >>> >>> Jon >>> >>> On 11/12/2015 1:31 PM, Jon Masamitsu wrote: >>>> GC calls VM_Version::calc_parallel_worker_threads() to determine >>>> the number of GC threads to create. On Sparc it checks for newer >>>> Niagara hardware to decide the proper scaling of the GC threads with >>>> the hardware threads. calc_parallel_worker_threads() was being called >>>> before enough information was gathered to determine the Sparc hardware. >>>> >>>> Moved the gathering of information needed to earlier in the JVM >>>> initialization. >>>> >>>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.00/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8133023 >>>> >>>> Thanks. >>>> >>>> Jon >>> >>> >>> > From david.holmes at oracle.com Tue Dec 1 06:14:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2015 16:14:26 +1000 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: References: <565631DC.1010800@oracle.com> <56563B4D.3030301@oracle.com> <56566A62.4030902@oracle.com> Message-ID: <565D3AC2.307@oracle.com> On 1/12/2015 1:04 PM, Kim Barrett wrote: > On Nov 25, 2015, at 9:11 PM, David Holmes wrote: >> >> We already have VM_Version::early_initialize() that can/should be used for this if possible. > > VM_Version::early_initialize doesn?t work for this, because > determine_features (sparc) examines some command-line arguments, and > those aren't parsed until a later stage of Threads::create_vm. > > Specifically, determine_features (sparc) is presently looking at two > CLAs: UseV8InstrsOnly (develop) and UseNiagaraInstrs (product). I > suspect UseV8InstrsOnly has served its purpose and could be purged. > But calling determine_features before argument parsing would > unintentionally ignore UseNiagaraInstrs. > > Calling determine_features from os::init_before_ergo doesn't have this problem. > > [I missed this in my review of Jon?s original change to use early_initialize.] Thanks Kim. Still makes me wonder if it isn't something else that is in the wrong place - the initialization dance is very tricky and I hate to see yet-another-vm-version-init function added. Makes me wonder whether determine_features should only look at what the hardware provides, and then after argument processing is complete (or appropriate portion thereof) we update the features that should actually be used? - but that ship sailed long ago. David > From david.holmes at oracle.com Tue Dec 1 06:38:45 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2015 16:38:45 +1000 Subject: Removing -XX option Use486InstrsOnly from hotspot. In-Reply-To: <565D1863.1020608@oracle.com> References: <565D1863.1020608@oracle.com> Message-ID: <565D4075.2080400@oracle.com> Hi Jamsheed, On 1/12/2015 1:47 PM, Jamsheed C m wrote: > Hi All, > > I am planning to remove command line option -XX:+/-Use486InstrsOnly from > Hotspot. > > This flag is too old to be maintained in Hotspot any longer. Let me know > if someone is still using this flag? This flag is completely obsolete. It's only use is in determining cpu information inside VM_Version::get_processor_features; and as per the bug report enabling it on a fastdebug build fails an assertion - so you can be assured we are not using this in any testing. And of course 486 has not been supported for a long time. :) But thanks for checking. Cheers, David > (flag removal decision is triggered by the bug 6808665) > > Best Regards, > Jamsheed > > From jamsheed.c.m at oracle.com Tue Dec 1 07:41:50 2015 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 1 Dec 2015 13:11:50 +0530 Subject: Removing -XX option Use486InstrsOnly from hotspot. In-Reply-To: <565D4075.2080400@oracle.com> References: <565D1863.1020608@oracle.com> <565D4075.2080400@oracle.com> Message-ID: <565D4F3E.1040601@oracle.com> Hi David, On 12/1/2015 12:08 PM, David Holmes wrote: > Hi Jamsheed, > > On 1/12/2015 1:47 PM, Jamsheed C m wrote: >> Hi All, >> >> I am planning to remove command line option -XX:+/-Use486InstrsOnly from >> Hotspot. >> >> This flag is too old to be maintained in Hotspot any longer. Let me know >> if someone is still using this flag? > > This flag is completely obsolete. It's only use is in determining cpu > information inside VM_Version::get_processor_features; and as per the > bug report enabling it on a fastdebug build fails an assertion - so > you can be assured we are not using this in any testing. And of course > 486 has not been supported for a long time. :) > yes, that is right. > But thanks for checking. Sure. Best Regards, Jamsheed > > Cheers, > David > >> (flag removal decision is triggered by the bug 6808665) >> >> Best Regards, >> Jamsheed >> >> From erik.joelsson at oracle.com Tue Dec 1 08:01:22 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 1 Dec 2015 09:01:22 +0100 Subject: RFR: JDK-8142333: Build failure in debugInfoRec.cpp with SS12u4 In-Reply-To: <565CBA46.3030905@oracle.com> References: <56557936.3070109@oracle.com> <5655CA09.6020001@oracle.com> <56583C2C.6040508@oracle.com> <565C836E.7040108@oracle.com> <565CBA46.3030905@oracle.com> Message-ID: <565D53D2.3070600@oracle.com> Thanks for reviews and getting this resolved! /Erik On 2015-11-30 22:06, Vladimir Kozlov wrote: > Looks fine to me too. I can push the fix into hs-comp for you, if you > want. Or it should be hs-rt? > > Thanks, > Vladimir > > On 11/30/15 9:12 AM, Coleen Phillimore wrote: >> >> This change seems fine (if you haven't already pushed) and seems >> better than my making the only the compare function >> public. I think the compiler complained because the compare function >> here: >> >> 284 DIR_Chunk* match = >> _all_chunks->insert_sorted(ns); >> >> >> Wasn't in the scope of the DebugInformationRecorder function. Which >> is probably a bug in the Solaris C++ compiler that >> you should file, since none of the other compilers complain. >> >> Coleen >> >> >> On 11/27/15 6:19 AM, Erik Joelsson wrote: >>> You were correct, it didn't work when I built with "make >>> INCLUDE_JMVCI=false". Here is a new webrev where that part is >>> fixed: >>> >>> http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/ >>> >>> (I accidentally overwrote the old one) >>> >>> It changes the other accesses to _offset to offset(). >>> >>> Regarding why the patch works, Tom, could you please fill in here? >>> >>> /Erik >>> >>> On 2015-11-25 15:47, Coleen Phillimore wrote: >>>> >>>> I don't think this change will compile with INCLUDE_JVMCI off either. >>>> Coleen >>>> >>>> On 11/25/15 4:02 AM, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> The following new build failure has appeared in the hotspot build >>>>> when using the proposed new compiler version on >>>>> Solaris, SS12u4. >>>>> >>>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", >>>>> line 281: Error: static >>>>> DIR_Chunk::compare(DIR_Chunk*const&, DIR_Chunk*const&) is not >>>>> accessible from >>>>> GrowableArray::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&). >>>>> >>>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", >>>>> line 281: Where: While instantiating >>>>> "GrowableArray::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&)". >>>>> >>>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", >>>>> line 281: Where: Instantiated from >>>>> non-template code. >>>>> >>>>> Tom Rodriguez provided a patch and I have verified that it solves >>>>> the issue. Since this is blocking us upgrading >>>>> compilers on Solaris, I am taking the liberty of posting it for >>>>> review so we may get this resolved quickly. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142333 >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/ >>>>> >>>>> /Erik >>>> >>> >> From staffan.larsen at oracle.com Tue Dec 1 09:22:48 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Dec 2015 10:22:48 +0100 Subject: RFR : 8132961 : JEP 279 Improve Test-Failure Troubleshooting In-Reply-To: <2D3984B6-91DE-451F-A814-FD5E30237CE1@oracle.com> References: <2D3984B6-91DE-451F-A814-FD5E30237CE1@oracle.com> Message-ID: <7F734C89-75CE-462D-B73D-11CFEC42B30F@oracle.com> Looks good and sorry for the delay. Thanks, /Staffan > On 24 nov. 2015, at 20:13, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/ >> 3579 lines changed: 3579 ins; 0 del; 0 mod; 0 unchg > > Hi, > > Could you please review the webrev[0] for JEP 279[1]? > > The scope of the JEP is an implementation of a library which uses jtreg timeout handler and observer extension points to collect information about environment in case of test failures (including timeouts) and about test processes in case of timeouts. This data is then presented together with the test failure to simplify analysis. > > To make it easier to specify which tools should be run by the library on which platform when a test failure or timeout occurs, we use properties files to configure the library. Each platform family uses its own property file (named .properties) and common.properties, which contains platform independent tools, such as jps. Using property files allows to easily extend the tools that are used to collect information on test failure or timeout in the future. See the JEP for a more thorough overview of the collected data. Currently, we are using the following tools: > - on all platforms[3]: jps, jstack, jmap, jinfo, jcmd > - on linux[4]: ps, pmap, lsof, lslocks, gdb, gcore, id, who, last, df, env, dmesg, sysctl, top, free, vmstat, netstat > - on solaris[5]: pgrep, pmap, pfiles, pstack, gcore, id, who, last, df, env, dmesg, prtconf, sysdef, swap, ps, top, vmstat, pagesize, netstat > - on mac[6]: pgrep, vmmap, heap, leaks, spindump, lldb, gcore, id, who, last, df, env, dmesg, sysctl, ps, top, vm_stat, netstat > - on windows[7]: wmic, pmap, handle, cdb, id, who, last, df, env, powershell, tasklist, ps, top, free, vmstat, openfiles, netstat > > More information can be found in the JEP[1] and README[2]. > > The library integration into makefiles will be done later as the fix for JDK-8132962[8]. > > [0] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/ > [1] https://bugs.openjdk.java.net/browse/JDK-8075621 > [2] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/README.html > [3] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/common.properties.html > [4] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/linux.properties.html > [5] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/solaris.properties.html > [6] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/mac.properties.html > [7] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/windows.properties.html > [8] https://bugs.openjdk.java.net/browse/JDK-8132962 > > Thanks, > ? Igor From thomas.stuefe at gmail.com Tue Dec 1 09:41:40 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 1 Dec 2015 10:41:40 +0100 Subject: RFR: 8132510: Replace ThreadLocalStorage with compiler/language-based thread-local variables In-Reply-To: <565644E8.2050809@oracle.com> References: <5652BA32.8090207@oracle.com> <565644E8.2050809@oracle.com> Message-ID: Hi David, On Thu, Nov 26, 2015 at 12:31 AM, David Holmes wrote: > Hi Thomas, > > Thanks for reviewing. > > On 26/11/2015 1:20 AM, Thomas St?fe wrote: > >> Hi David, >> >> I looked over your latest version at >> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8 >> >> This all looks nice and builds on AIX. I am currently running some jtreg >> tests. >> > > Thanks. Please let me know if any issues surface. Sorry for the delay. AIX tests went through without any issues related to your change. Our machines are terribly slow, so all I could do was hotspot/runtime though. But even if issues surface, we can easily backpaddle later to pthread tls. Kind Regards, Thomas > I will need to resubmit my own tests after latest changes. > > Some small remarks: >> >> ------------ >> >> would it be possible to add a configure option (e.g. >> --enable-compiler-based-tls)? On AIX, disabling compiler level tls also >> makes the -qtls compiler option unnecessary, so it affects the makefile. >> >> Not really important, just would be quite comfortable. >> > > It's possible to file a RFE for this. To be honest I didn't see this as > some kind of user-defined choice that would need to be configured. The > intent is that platforms which can't support compiler level TLS simply > hardwire the flag in their platform specific makefile. > > ------------ >> >> >> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/os/windows/vm/os_windows.cpp.udiff.html >> >> @@ -5175,11 +5159,11 @@ >> - JavaThread* thread = (JavaThread*)(Thread::current()); >> + Thread* thread = Thread::current(); >> assert(thread->is_Java_thread(), "Must be JavaThread"); >> JavaThread *jt = (JavaThread *)thread; >> >> may be simplified to use your new >> >> JavaThread* thread = JavaThread::current(); >> > > Indeed it can. Fixed. And changed jt to thread in the following code. > > ------------ >> >> >> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/share/vm/runtime/thread.cpp.udiff.html >> >> in >> >> Thread::clear_thread_current() >> >> we could also add a >> >> assert(Thread::current() == ThreadLocalStorage::thread(), "TLS >> mismatch!"); >> >> to catch a case where library tls slot content changed during lifetime >> of thread. >> > > Fixed. > > ---- >> >> JavaThread* JavaThread::active() { >> - Thread* thread = ThreadLocalStorage::thread(); >> + Thread* thread = Thread::current(); >> assert(thread != NULL, "just checking"); >> >> the assert is unnecessary. >> > > Fixed. > >> >> ----- >> >> >> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/share/vm/runtime/thread.hpp.udiff.html >> >> // Inline implementation of JavaThread::current >> inline JavaThread* JavaThread::current() { >> - Thread* thread = ThreadLocalStorage::thread(); >> + Thread* thread = Thread::current(); >> assert(thread != NULL && thread->is_Java_thread(), "just checking"); >> return (JavaThread*)thread; >> } >> >> asserting thread != NULL is unnecessary. >> > > Fixed > >> ----- >> >> >> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/share/vm/utilities/globalDefinitions_gcc.hpp.udiff.html >> >> (and corresponding globalDefinitions_.. files) >> >> +#define THREAD_LOCAL_DECL __thread >> >> could be surrounded by #ifndef USE_LIBRARY_BASED_TLS_ONLY >> > > Okay - changed. > > Updated webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v9/ > > Thanks, > David > ----- > > ----- >> >> Kind Regards, Thomas >> >> >> >> >> >> >> >> >> On Mon, Nov 23, 2015 at 8:03 AM, David Holmes > > wrote: >> >> After all the preliminary discussions here are final proposed changes: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8132510 >> >> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/ >> >> A simple (in principle) but wide-ranging change which should appeal >> to our Code Deletion Engineer's. We implement Thread::current() >> using a compiler/language-based thread-local variable eg: >> >> static __thread Thread *_thr_current; >> >> inline Thread* Thread::current() { >> return _thr_current; >> } >> >> with an appropriate setter of course. By doing this we can >> completely remove the os_cpu-specific ThreadLocalStorage >> implementations, and the associated os::thread_local_storage* calls. >> >> As __thread is not async-signal-safe (either in theory or practice) >> we need a fallback library-based solution as used today. For this we >> use a very simple ThreadLocalStorage class and an implementation >> thereof for POSIX (covers AIX, BSD, Linux, OSX and Solaris) using >> pthread_get/setspecific; and one for Windows using its TLS library. >> While these library routines are not guaranteed async-signal-safe, >> they seem to be in practice and are what we have been using all along. >> >> We also allow for use of only the library-based TLS for platforms >> where compiler-based thread locals are not supported (as will be >> needed in the Mobile project). This is enabled at build time by >> defining USE_LIBRARY_BASED_TLS_ONLY. >> >> Thanks to Andrew Haley for providing the Aarch64 code; and for >> Thomas Stuefe for testing PPC and AIX. >> >> Testing: >> - JPRT (core platforms) >> - Jtreg tests (linux & solaris) >> - vm.runtime (core platforms) >> >> Performance: >> - still TBD - this is proving to be extremely difficult. If anyone >> has any simple to run microbenchmarks to suggest I'd give them a try >> as a sanity check. But I lack access to hardware for running serious >> benchmarking. >> >> Footprint: >> - varies by platform and the VM (server, client, minimal) >> - worst-case: ~1% increase for server VM and minimal VM >> - best-case: 0.4% decrease for client VM >> >> Thanks, >> David >> >> >> From sgehwolf at redhat.com Tue Dec 1 10:17:09 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Dec 2015 11:17:09 +0100 Subject: [PING] RFR 6425769: jmx remote bind address In-Reply-To: <1447061525.3551.3.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> Message-ID: <1448965029.4309.10.camel@redhat.com> On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > Hi, > > > > Updated webrev with jtreg test in Java: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > bug:?https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > I believe this updated webrev addresses all concerns and > > incorporates > > suggestions brought up by Jaroslav and Daniel. > > > > I'm still looking for a sponsor and a hotspot/servicability-dev > > reviewer. Could somebody maintaining javax.rmi.ssl have a look at > > this > > as well? Thank you! > > Ping? Friendly reminder that I still need reviewers and a sponsor for > this. Anyone? > Thanks, > Severin > > > Cheers, > > Severin > > > > On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote: > > > On 2.11.2015 19:06, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Thanks Jaroslav and Daniel for the reviews! Comments inline. > > > > > > > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > > > > > Hi, > > > > > > > > > > On 2.11.2015 16:19, Daniel Fuchs wrote: > > > > > > Hi Severin, > > > > > > > > > > > > Adding serviceability-dev at openjdk.java.net into the loop - > > > > > > that's > > > > > > a better alias than hotspot-dev for this kind of changes - > > > > > > maybe > > > > > > someone from serviceability-dev will offer to sponsor :-) > > > > > > > > > > > > I will let serviceability team members comment on the > > > > > > hotspot > > > > > > changes. > > > > > > > > > > > > ConnectorBootstrap.java > > > > > > > > > > > > I have one suggestion and one concern: > > > > > > > > > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket > > > > > > Factory) > > > > > > and > > > > > > ssf??(Server Socket Factory) variables rather than > > > > > > introduce > > > > > > the > > > > > > two > > > > > > new variables rmiServerSocketFactory and > > > > > > rmiClientSocketFactory. > > > > > > You might want to create a new boolean 'useSocketFactory' > > > > > > variable, > > > > > > if that makes the code more readable. > > > > > > > > > > > > Concern: If I understand correctly how RMI socket factories > > > > > > work, > > > > > > the client socket factory will be serialized and sent to > > > > > > the > > > > > > client > > > > > > side. This is problematic for interoperability, as the > > > > > > class > > > > > > may > > > > > > not > > > > > > present in the remote client - if the remote client is e.g. > > > > > > jdk > > > > > > 8. > > > > > > > > > > > > As far as I can see, your new DefaultClientSocketFactory > > > > > > doesn't do > > > > > > anything useful - so I would suggest to simply get rid of > > > > > > it, > > > > > > and > > > > > > only > > > > > > set the Server Socket Factory when SSL is not involved. > > > > > > > > Thanks. Fixed in updated webrev. > > > > > > > > > > Tests: > > > > > > > > > > > > Concerning the tests - we're trying to get rid of shell > > > > > > scripts > > > > > > rather than introducing new ones :-) > > > > > > Could the test be rewritten in pure java using the Process > > > > > > API? > > > > > > > > > > > > I believe there's even a test library that will let you do > > > > > > that > > > > > > easily jdk/test/lib/testlibrary/jdk/testlibrary/ > > > > > > (see ProcessTools.java) > > > > > > > > It'll take me a bit to rewrite the test in pure Java, but > > > > should > > > > be > > > > fine. This is not yet fixed in the updated webrev. > > > > > > > > > > Other: > > > > > > > > > > > > Also - I believe the new option should be documented in: > > > > > > src/java.management/share/conf/management.properties > > > > > > > > Docs have been updated > > > > in src/java.management/share/conf/management.properties. > > > > > > > > > I share Daniel's concerns. Also, the part of the changeset is > > > > > related > > > > > to javax.rmi.ssl - someone maintaining this library should > > > > > also > > > > > comment here. > > > > > > > > > > Also, the change is introducing new API (system property) and > > > > > changing the existing one (adding SslRmiServerSocketFactory > > > > > public > > > > > constructors) so compatibility review process will have to be > > > > > involved. > > > > > > > > OK. What exactly is there for me to do? I'm not familiar with > > > > this > > > > process. Note that the intent would be to get this backported > > > > to > > > > JDK 8. > > > Not much for you. But for the potential Oracle sponsor this means > > > she > > > will have to remember to go through some extra hoops before > > > integrating your patch. > > > > I see. Thanks for clarifying it. > > > > > -JB- > > > > > > > > > > > New webrev at: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ > > > > > > > > Thanks, > > > > Severin > > > > > > > > > -JB- > > > > > > > > > > > > best regards, > > > > > > > > > > > > -- daniel > > > > > > > > > > > > On 02/11/15 11:38, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Here is a patch addressing JDK-6425769. The issue is that > > > > > > > the > > > > > > > JMX > > > > > > > agent > > > > > > > binds to the wildcard address by default, preventing > > > > > > > users > > > > > > > to > > > > > > > use > > > > > > > system properties for JMX agents on multi-homed hosts. > > > > > > > Given > > > > > > > a > > > > > > > host > > > > > > > with local network interfaces, 192.168.0.1 and > > > > > > > 192.168.0.2 > > > > > > > say, > > > > > > > it's > > > > > > > impossible to start two JMX agents binding to fixed ports > > > > > > > but > > > > > > > to > > > > > > > different network interfaces, 192.168.0.1:{9111,9112} and > > > > > > > 192.168.0.2:{9111,9112} say. > > > > > > > > > > > > > > The JDK would bind to all local interfaces by default. In > > > > > > > the > > > > > > > above > > > > > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is > > > > > > > that > > > > > > > the > > > > > > > second > > > > > > > Java process would get a "Connection refused" error > > > > > > > because > > > > > > > another > > > > > > > process has already been bound to the specified JMX/RMI > > > > > > > port > > > > > > > pairs. > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > > > > 64 > > > > > > > 25 > > > > > > > 769/ > > > > > > > 00/ > > > > > > > > > > > > > > Testing done: > > > > > > > jdk_jmx and jdk_management tests all pass after this > > > > > > > change > > > > > > > (no > > > > > > > regressions). There is also a new JTREG test which fails > > > > > > > prior > > > > > > > this > > > > > > > change and passes after. Updates to the diagnostic > > > > > > > command > > > > > > > have > > > > > > > been > > > > > > > tested manually. > > > > > > > > > > > > > > I understand that, if approved, the JDK and hotspot > > > > > > > changes > > > > > > > should get > > > > > > > pushed together? Hotspot changes are fairly trivial since > > > > > > > it's > > > > > > > only a > > > > > > > doc-update for the new JDK property in the relevant > > > > > > > diagnostic > > > > > > > command. > > > > > > > > > > > > > > Could someone please review and sponsor this change? > > > > > > > Please > > > > > > > let > > > > > > > me know > > > > > > > if there are questions. > > > > > > > > > > > > > > Thanks, > > > > > > > Severin > > > > > > > > > > > > > > > > > > > > > > > > > > > > From paul.sandoz at oracle.com Tue Dec 1 10:36:45 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Dec 2015 11:36:45 +0100 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> <562BC968.70603@cs.oswego.edu> <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> Message-ID: <87110734-3922-434C-B2D7-11F9AD0A5D0E@oracle.com> > On 1 Dec 2015, at 03:58, Gil Tene wrote: > > Update: After some significant back-and-forth between Doug and I on naming and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have what we think is a good spec and name selection for this thing. We're proposing to add a new static method to the Runtime class: > > class Runtime { /... > /** > * Method signifying that the caller is momentarily unable to > * progress until the occurrence of one or more actions of one or > * more other activities. When invoked within each iteration, this > * method typically improves performance of spin wait loop > * constructions. > */ > public static void onSpinWait() {}; > } > Short and sweet. I like it. I think it would be useful to add an @apiNote with explanatory text similar to that in the motivation section of the JEP. If you like I can help guide this through the JEP process. > See updated details, including a link to the updated JEP draft, as well as links to working prototype implementations, webrevs against OpenJDK9b94, and example here: https://github.com/giltene/GilExamples/tree/master/SpinWaitTest . All names have changed to reflect the new naming (onSpinWait, -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.). > > As an interesting stat, the total changes in the WebRevs amount to 78 added lines (across 14 files) , and 0 lines removed or changed. Hopefully a good indication of relatively low footprint and risk. > I agree, the JDK and hotspot patches (for x86 support) are quite small. Paul. From jaroslav.bachorik at oracle.com Tue Dec 1 11:33:38 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 1 Dec 2015 12:33:38 +0100 Subject: [PING] RFR 6425769: jmx remote bind address In-Reply-To: <1448965029.4309.10.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> Message-ID: <565D8592.6020701@oracle.com> On 1.12.2015 11:17, Severin Gehwolf wrote: > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: >> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: >>> Hi, >>> >>> Updated webrev with jtreg test in Java: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-6425769 >>> >>> I believe this updated webrev addresses all concerns and >>> incorporates >>> suggestions brought up by Jaroslav and Daniel. >>> >>> I'm still looking for a sponsor and a hotspot/servicability-dev >>> reviewer. Could somebody maintaining javax.rmi.ssl have a look at >>> this >>> as well? Thank you! >> >> Ping? Friendly reminder that I still need reviewers and a sponsor for >> this. > > Anyone? I'm sorry for not spotting this earlier: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/jdk/src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java.sdiff.html * L442 - the log would contain 'com.sun.management.jmxremote.host = null' if host is not specified; might be better not to print this out at all Other than that the change looks good to me. If no one else is volunteering I may sponsor this change. Cheers, -JB- > >> Thanks, >> Severin >> >>> Cheers, >>> Severin >>> >>> On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote: >>>> On 2.11.2015 19:06, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Thanks Jaroslav and Daniel for the reviews! Comments inline. >>>>> >>>>> On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: >>>>>> Hi, >>>>>> >>>>>> On 2.11.2015 16:19, Daniel Fuchs wrote: >>>>>>> Hi Severin, >>>>>>> >>>>>>> Adding serviceability-dev at openjdk.java.net into the loop - >>>>>>> that's >>>>>>> a better alias than hotspot-dev for this kind of changes - >>>>>>> maybe >>>>>>> someone from serviceability-dev will offer to sponsor :-) >>>>>>> >>>>>>> I will let serviceability team members comment on the >>>>>>> hotspot >>>>>>> changes. >>>>>>> >>>>>>> ConnectorBootstrap.java >>>>>>> >>>>>>> I have one suggestion and one concern: >>>>>>> >>>>>>> Suggestion: I would suggest to reuse 'csf' (Client Socket >>>>>>> Factory) >>>>>>> and >>>>>>> ssf (Server Socket Factory) variables rather than >>>>>>> introduce >>>>>>> the >>>>>>> two >>>>>>> new variables rmiServerSocketFactory and >>>>>>> rmiClientSocketFactory. >>>>>>> You might want to create a new boolean 'useSocketFactory' >>>>>>> variable, >>>>>>> if that makes the code more readable. >>>>>>> >>>>>>> Concern: If I understand correctly how RMI socket factories >>>>>>> work, >>>>>>> the client socket factory will be serialized and sent to >>>>>>> the >>>>>>> client >>>>>>> side. This is problematic for interoperability, as the >>>>>>> class >>>>>>> may >>>>>>> not >>>>>>> present in the remote client - if the remote client is e.g. >>>>>>> jdk >>>>>>> 8. >>>>>>> >>>>>>> As far as I can see, your new DefaultClientSocketFactory >>>>>>> doesn't do >>>>>>> anything useful - so I would suggest to simply get rid of >>>>>>> it, >>>>>>> and >>>>>>> only >>>>>>> set the Server Socket Factory when SSL is not involved. >>>>> >>>>> Thanks. Fixed in updated webrev. >>>>> >>>>>>> Tests: >>>>>>> >>>>>>> Concerning the tests - we're trying to get rid of shell >>>>>>> scripts >>>>>>> rather than introducing new ones :-) >>>>>>> Could the test be rewritten in pure java using the Process >>>>>>> API? >>>>>>> >>>>>>> I believe there's even a test library that will let you do >>>>>>> that >>>>>>> easily jdk/test/lib/testlibrary/jdk/testlibrary/ >>>>>>> (see ProcessTools.java) >>>>> >>>>> It'll take me a bit to rewrite the test in pure Java, but >>>>> should >>>>> be >>>>> fine. This is not yet fixed in the updated webrev. >>>>> >>>>>>> Other: >>>>>>> >>>>>>> Also - I believe the new option should be documented in: >>>>>>> src/java.management/share/conf/management.properties >>>>> >>>>> Docs have been updated >>>>> in src/java.management/share/conf/management.properties. >>>>> >>>>>> I share Daniel's concerns. Also, the part of the changeset is >>>>>> related >>>>>> to javax.rmi.ssl - someone maintaining this library should >>>>>> also >>>>>> comment here. >>>>>> >>>>>> Also, the change is introducing new API (system property) and >>>>>> changing the existing one (adding SslRmiServerSocketFactory >>>>>> public >>>>>> constructors) so compatibility review process will have to be >>>>>> involved. >>>>> >>>>> OK. What exactly is there for me to do? I'm not familiar with >>>>> this >>>>> process. Note that the intent would be to get this backported >>>>> to >>>>> JDK 8. >>>> Not much for you. But for the potential Oracle sponsor this means >>>> she >>>> will have to remember to go through some extra hoops before >>>> integrating your patch. >>> >>> I see. Thanks for clarifying it. >>> >>>> -JB- >>>> >>>>> >>>>> New webrev at: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>>> -JB- >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>> On 02/11/15 11:38, Severin Gehwolf wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Here is a patch addressing JDK-6425769. The issue is that >>>>>>>> the >>>>>>>> JMX >>>>>>>> agent >>>>>>>> binds to the wildcard address by default, preventing >>>>>>>> users >>>>>>>> to >>>>>>>> use >>>>>>>> system properties for JMX agents on multi-homed hosts. >>>>>>>> Given >>>>>>>> a >>>>>>>> host >>>>>>>> with local network interfaces, 192.168.0.1 and >>>>>>>> 192.168.0.2 >>>>>>>> say, >>>>>>>> it's >>>>>>>> impossible to start two JMX agents binding to fixed ports >>>>>>>> but >>>>>>>> to >>>>>>>> different network interfaces, 192.168.0.1:{9111,9112} and >>>>>>>> 192.168.0.2:{9111,9112} say. >>>>>>>> >>>>>>>> The JDK would bind to all local interfaces by default. In >>>>>>>> the >>>>>>>> above >>>>>>>> example to 192.168.0.1 *and* 192.168.0.2. The effect is >>>>>>>> that >>>>>>>> the >>>>>>>> second >>>>>>>> Java process would get a "Connection refused" error >>>>>>>> because >>>>>>>> another >>>>>>>> process has already been bound to the specified JMX/RMI >>>>>>>> port >>>>>>>> pairs. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 >>>>>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- >>>>>>>> 64 >>>>>>>> 25 >>>>>>>> 769/ >>>>>>>> 00/ >>>>>>>> >>>>>>>> Testing done: >>>>>>>> jdk_jmx and jdk_management tests all pass after this >>>>>>>> change >>>>>>>> (no >>>>>>>> regressions). There is also a new JTREG test which fails >>>>>>>> prior >>>>>>>> this >>>>>>>> change and passes after. Updates to the diagnostic >>>>>>>> command >>>>>>>> have >>>>>>>> been >>>>>>>> tested manually. >>>>>>>> >>>>>>>> I understand that, if approved, the JDK and hotspot >>>>>>>> changes >>>>>>>> should get >>>>>>>> pushed together? Hotspot changes are fairly trivial since >>>>>>>> it's >>>>>>>> only a >>>>>>>> doc-update for the new JDK property in the relevant >>>>>>>> diagnostic >>>>>>>> command. >>>>>>>> >>>>>>>> Could someone please review and sponsor this change? >>>>>>>> Please >>>>>>>> let >>>>>>>> me know >>>>>>>> if there are questions. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Severin >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From vitalyd at gmail.com Tue Dec 1 12:16:24 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 1 Dec 2015 07:16:24 -0500 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> <562BC968.70603@cs.oswego.edu> <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> Message-ID: Minor quibble, but why the "on" prefix in the name? Maybe just me, but onXYX is typically used for event notification style APIs. Also, the "wait" part seems inappropriate as the method itself isn't doing any waiting. What was wrong with the original spinLoopHint name? Or cpuRelax()? sent from my phone On Nov 30, 2015 9:59 PM, "Gil Tene" wrote: > Update: After some significant back-and-forth between Doug and I on naming > and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have > what we think is a good spec and name selection for this thing. We're > proposing to add a new static method to the Runtime class: > > class Runtime { /... > /** > * Method signifying that the caller is momentarily unable to > * progress until the occurrence of one or more actions of one or > * more other activities. When invoked within each iteration, this > * method typically improves performance of spin wait loop > * constructions. > */ > public static void onSpinWait() {}; > } > > See updated details, including a link to the updated JEP draft, as well as > links to working prototype implementations, webrevs against OpenJDK9b94, > and example here: > https://github.com/giltene/GilExamples/tree/master/SpinWaitTest < > https://github.com/giltene/GilExamples/tree/master/SpinWaitTest> . All > names have changed to reflect the new naming (onSpinWait, > -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.). > > As an interesting stat, the total changes in the WebRevs amount to 78 > added lines (across 14 files) , and 0 lines removed or changed. Hopefully a > good indication of relatively low footprint and risk. > > ? Gil. > > > > > > From dl at cs.oswego.edu Tue Dec 1 12:43:41 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 1 Dec 2015 07:43:41 -0500 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <87110734-3922-434C-B2D7-11F9AD0A5D0E@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> <562BC968.70603@cs.oswego.edu> <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> <87110734-3922-434C-B2D7-11F9AD0A5D0E@oracle.com> Message-ID: <565D95FD.3000906@cs.oswego.edu> On 12/01/2015 05:36 AM, Paul Sandoz wrote: > >> On 1 Dec 2015, at 03:58, Gil Tene wrote: >> >> class Runtime { /... >> /** >> * Method signifying that the caller is momentarily unable to >> * progress until the occurrence of one or more actions of one or >> * more other activities. When invoked within each iteration, this >> * method typically improves performance of spin wait loop >> * constructions. >> */ >> public static void onSpinWait() {}; >> } >> > > Short and sweet. I like it. I think it would be useful to add an @apiNote with explanatory text similar to that in the motivation section of the JEP. > Or maybe not. Recent experience suggests that it is hard to add a brief explanatory note or usage guidance without saying something confusing or wrong wrt usages focussing on latency, throughput, or power -- these effects may vary across processors with different instructions (possibly just no-op) used to implement it. Not a lot, but this accounts for the bland wording of "typically improves performance". -Doug From sgehwolf at redhat.com Tue Dec 1 13:19:05 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Dec 2015 14:19:05 +0100 Subject: [PING] RFR 6425769: jmx remote bind address In-Reply-To: <565D8592.6020701@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> Message-ID: <1448975945.4309.16.camel@redhat.com> Hi Jaroslav, On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > On 1.12.2015 11:17, Severin Gehwolf wrote: > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Updated webrev with jtreg test in Java: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > > I believe this updated webrev addresses all concerns and > > > > incorporates > > > > suggestions brought up by Jaroslav and Daniel. > > > > > > > > I'm still looking for a sponsor and a hotspot/servicability-dev > > > > reviewer. Could somebody maintaining javax.rmi.ssl have a look at > > > > this > > > > as well? Thank you! > > > > > > Ping? Friendly reminder that I still need reviewers and a sponsor for > > > this. > > > > Anyone? > > I'm sorry for not spotting this earlier: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/jdk/src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java.sdiff.html > * L442 - the log would contain 'com.sun.management.jmxremote.host =? > null' if host is not specified; might be better not to print this out at all Updated webrev which does not print 'com.sun.management.jmxremote.host = null' if unset: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ > Other than that the change looks good to me. If no one else is > volunteering I may sponsor this change. Thank you! Cheers, Severin > Cheers, > > -JB- From daniel.daugherty at oracle.com Tue Dec 1 14:28:36 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 1 Dec 2015 07:28:36 -0700 Subject: RFR: 8132510: Replace ThreadLocalStorage with compiler/language-based thread-local variables In-Reply-To: <565805A1.9080803@oracle.com> References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com> <56530618.2020202@oracle.com> <565318A8.8050003@oracle.com> <56538862.5010609@oracle.com> <56557DCD.9050907@oracle.com> <5655B349.9070700@oracle.com> <5655CB39.3030007@oracle.com> <56563BA0.1010307@oracle.com> <56563F61.4030008@oracle.com> <5656497E.2050208@oracle.com> <565805A1.9080803@oracle.com> Message-ID: <565DAE94.7060506@oracle.com> > http://cr.openjdk.java.net/~dholmes/8132510/webrev.v10 Rereviewed by comparing this webrev's patch with the patch from webrev.v8. Thumbs up. Dan On 11/27/15 12:26 AM, David Holmes wrote: > Hi Thomas, > > On 26/11/2015 7:56 PM, Thomas St?fe wrote: >> >> On Thu, Nov 26, 2015 at 12:51 AM, David Holmes > > wrote: >> >> On 26/11/2015 9:08 AM, Daniel D. Daugherty wrote: >> >> If I understand the problem... :-) >> >> The Win-X64 ABI requires that some extra space be allocated on >> the stack in the caller for "homing" four registers... >> >> This code uses MacroAssembler::call() which is a lower level >> call() function that assumes you know the ABI... >> >> 9765 void MacroAssembler::get_thread(Register thread) { >> >> 9784 call(RuntimeAddress(CAST_FROM_FN_PTR(address, >> Thread::current))); >> >> So the failing here was nothing to do with register saving per-se, >> nor the alignment code, but "simply" not also saving the extra space >> prior to the call! >> >> Yes. These 32 byte are a scratch area for the callee, which may be used >> for parameter registers or anything else. We may just have been lucky so >> far that TlsGetValue() did not use this area. As Bertrand already said, >> now we call Thread::current(), which does magic tls accesses under the >> hood, so this must be tested again. > > Right. All testing so far has been successful but ... > >> However I think that a simple addition to your current fix could simply >> be subtracting 32 from rsp before the call: >> >> subq(rsp, 32) >> call(RuntimeAddress(CAST_FROM_FN_PTR(address, Thread::current))); >> addq(rsp, 32) > > ... I decided to do what was previously suggested and use: > > call_VM_leaf_base(CAST_FROM_FN_PTR(address, Thread::current), 0); > > as it takes care of everything (stack alignment if needed and > preserving space for the register args on win64). > >> Also, we could probably skip saving/restoring rdi and rsi on Windows: > > Maybe - but we don't seem to consider that anywhere else ie: > > void MacroAssembler::push_callee_saved_registers() { > push(rsi); > push(rdi); > push(rdx); > push(rcx); > } > > so I don't want to be the trail-blazer here. :) > > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/8132510/webrev.v10 > > Only change to macroAssembler_x86.cpp. Re-tested on Windows 32-bit and > 64-bit. > > Thanks, > David > >> https://msdn.microsoft.com/en-us/library/6t169e9c.aspx >> >> "The registers RAX, RCX, RDX, R8, R9, R10, R11 are considered volatile >> and must be considered destroyed on function calls (unless otherwise >> safety-provable by analysis such as whole program optimization). The >> registers RBX, RBP, RDI, RSI, RSP, R12, R13, R14, and R15 are considered >> nonvolatile and must be saved and restored by a function that uses >> them." > > > >> Best Regards, Thomas >> >> >> If you switch to MacroAssembler::call_VM_leaf_base() it handles >> more of the gory details for you than MacroAssembler::call(): >> >> >> Wow! Not exactly a clearly-defined name for this. AFAICS there's >> nothing VM or leaf specific about this. Also the MacroAssembler is >> supposed to be a platform-agnostic higher-level abstraction that is >> easy to use - but in this case every use of the plain call on >> Windows-x64 is potentially broken if the programmer was not aware of >> this ABI constraint which only applies to Windows (and we're in >> OS-neutral files!). >> >> This seems fundamentally broken to me. >> >> Thanks for the info. >> >> David >> >> >> src/cpu/x86/vm/macroAssembler_x86.cpp: >> >> 524 void MacroAssembler::call_VM_leaf_base(address >> entry_point, int >> num_args >> ) { >> 525 Label L, E; >> 526 >> 527 #ifdef _WIN64 >> 528 // Windows always allocates space for it's >> register args >> 529 assert(num_args <= 4, "only register arguments >> supported"); >> 530 subq(rsp, frame::arg_reg_save_area_bytes); >> 531 #endif >> 532 >> 533 // Align stack if necessary >> 534 testl(rsp, 15); >> 535 jcc(Assembler::zero, L); >> 536 >> 537 subq(rsp, 8); >> 538 { >> 539 call(RuntimeAddress(entry_point)); >> 540 } >> >> So call_VM_leaf_base() allocates the "homing" space for register >> args for Win-X64 on L530 and it handles any stack alignment >> before >> calling MacroAssembler::call(). >> >> So if you switch to call_VM_leaf_base() you can drop >> the stack alignment code: >> >> 9777 // ensure stack alignment >> 9778 mov(r10, rsp); >> 9779 andq(rsp, -16); >> 9780 push(r10); >> >> and just switch to: >> >> 9777 push(rsp); >> >> And you won't be exposed to potential saved register >> overwrite by the "homing" of any registers in the call >> Thread::current(). >> >> I _think_ I have that all correct... :-) >> >> Dan >> >> >> On 11/25/15 3:52 PM, David Holmes wrote: >> >> On 26/11/2015 2:53 AM, Thomas St?fe wrote: >> >> I created a bug to track this: >> >> https://bugs.openjdk.java.net/browse/JDK-8144059 >> >> >> Thanks. I admit I still don't really grok the exact problem >> here. It >> is the alignment code that is the problem right? >> >> 79 mov(r10, rsp); >> 80 andq(rsp, -16); >> 81 push(r10); >> >> ? >> >> Thanks, >> David >> >> Because Davids change is not submitted yet, the bug >> refers to the old >> coding, but stays relevant also after this fix. >> >> Kind Regards, Thomas >> >> On Wed, Nov 25, 2015 at 3:52 PM, Daniel D. Daugherty >> > >> > >> >> wrote: >> >> On 11/25/15 6:10 AM, David Holmes wrote: >> >> On 25/11/2015 8:46 PM, Thomas St?fe wrote: >> >> >> On Wed, Nov 25, 2015 at 10:22 AM, Bertrand >> Delsart >> > >> > > >> > >> > >>> wrote: >> >> Good finding Thomas, >> >> On 25/11/2015 09:40, Thomas St?fe >> wrote: >> >> Hi David, Bertrand, >> >> about >> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html >> >> >> I am not sure this is correct for >> Windows x64. >> >> >> Unless I'm misreading it, the new code >> looks a lot like >> the old one >> (including the alignement part). Hence >> this does not >> look like a >> regression caused by David's change. >> >> >> Yes, this seems like an old bug. >> >> I also see that this is fixed in our >> codebase since 2010, >> exactly the >> way you propose (with MacroAssembler >> ::call_VM_leaf_base >> >> >> ). >> >> >> So, it is already used since five years. I >> would propose >> opening a >> separate bug for this one and we contribute >> our fix. >> >> >> That sounds good to me too. I also suspect >> additional code will >> need to be checked as this stack alignment is >> performed in a few >> places in ./cpu/x86/vm/macroAssembler_x86.cpp >> with no OS >> specific differences being considered. >> >> >> Looks like MacroAssembler::call_VM_leaf_base() does >> the "right >> thing" >> for stack alignment in the X64 case. Perhaps we >> need to audit both >> stack alignment _and_ uses of >> MacroAssembler::call() just to make >> sure... >> >> Did I mention that all the assembly code stuff >> gives me a >> headache? :-) >> >> Dan >> >> >> >> >> Thanks, >> David >> >> Regards, Thomas >> >> >> https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx >> >> windows x64 Abi requires the >> register parameter >> area right above the >> return address on the stack. It >> is not >> guaranteed to be >> preserved during >> the function call: >> >> "Even if the called function has >> fewer than 4 >> parameters, these >> 4 stack >> locations are effectively owned by >> the called >> function, and may >> be used >> by the called function for other >> purposes besides >> saving parameter >> register values. Thus the caller >> may not save >> information in >> this region >> of stack across a function call." >> >> So, restoring parameters from it >> may not work if >> Thread::current() uses >> this area for any reason. In this >> case, r9, rsp, >> r10, r11 may be >> overwritten by the callee. >> >> I also think Windows x64 ABI is >> different enough >> from Linux that >> this >> function could live somewhere in >> _. >> >> >> This is a valid point. However, note >> that this is >> similar to the >> issue we have for instance in 'shared' >> MacroAssembler::call_VM_leaf_base, >> which was not put in >> _ >> files. >> >> In fact, the right fix may be to use >> call_VM_leaf >> instead of call :-) >> >> (alternatively we could use "#ifdef >> _WIN64" or check >> "frame::arg_reg_save_area_bytes != 0", >> which may be >> even cleaner and >> more portable) >> >> All these solutions are fine for me. >> >> >> Since we are near to feature freeze, >> this should >> probably be done in >> a separate CR (unless David has enough >> time to test >> it). >> >> Regards, >> >> Bertrand. >> >> >> Kind Regards, Thomas >> >> >> >> >> On Mon, Nov 23, 2015 at 10:42 PM, >> David Holmes >> > >> > > >> > >> > >> >> > >> > > >> > >> > >>>> wrote: >> >> On 23/11/2015 11:46 PM, >> Bertrand Delsart >> wrote: >> >> On 23/11/2015 13:27, >> David Holmes wrote: >> >> Hi Bertrand, >> >> On 23/11/2015 8:14 >> PM, Bertrand >> Delsart wrote: >> >> Hi David, >> >> Overall looks >> good. >> Thanks for the >> #ifndef >> USE_LIBRARY_BASED_TLS_ONLY :-) >> >> One doubt, in >> case this has not >> been discussed >> before. >> >> I'm still >> catching up on x86_64 >> (after years of ARM >> assembly :-)) >> but it >> seems that there >> are some stack >> alignment >> constraints on >> runtime calls, >> at least for some >> x86_64 ABIs. >> >> Some of the x86 >> MacroAssembler::get_thread >> implementations >> had code to >> align the stack >> before calling >> pthread_getspecific. See >> for instance >> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html >> >> >> >> >> Sorry I'm not that >> familiar with the >> MacroAssembler >> - is it >> this odd >> fragment: >> >> - push(r10); >> - // XXX >> - mov(r10, rsp); >> - andq(rsp, -16); >> - push(r10); >> >> I'm not at all clear >> what that is >> doing - and if it >> somehow >> changes the >> alignment wouldn't >> something need to >> be fixed up when >> popping the >> previous values ?? >> >> To be honest I'm not >> even sure what an >> "unaligned >> stack" means. >> >> >> On some platforms, SP may >> have to be >> aligned on a 16 bytes >> boundary when >> calling another method. >> >> >> Okay - that seems to be an >> x64 ABI requirement >> based on >> other code >> in MacroAssembler. The reason >> it is missing in >> the Solaris >> code is >> because I already removed it >> in the earlier >> changes that >> were done >> on Solaris: >> >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10 >> >> and nobody picked it up. :( >> >> That said, the absence of >> this code has not >> caused any >> problems so >> presumably we are normally >> aligned. >> >> After having pushed what >> needed to be >> saved, the code above >> rounds SP >> down and saves the old >> value. It will then >> also push >> r11, which >> results >> in the expected >> alignment. >> >> The conterpart, after the >> VM call, is the: >> pop(r11); >> pop(rsp); >> >> >> I had assumed this extra >> manipulation was >> related to >> pushing the arg >> for the call. >> >> This alignment is >> no longer >> performed in the new >> (shared) >> implementation >> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html >> >> >> >> >> >> Now, Solaris was >> not performing >> the alignment and >> Windows has a >> separate >> path for x86_64. >> Did we really >> need the >> alignment for >> linux x86_64 and >> bsd_x86_64 ? >> Might it be needed >> for other ports ? >> >> IMHO, it might be >> safer to align >> the stack by >> default, >> knowing it should >> not be expensive >> since we call >> get_thread >> rarely for >> x86_64 (result is >> cached in r15). >> I'll let you see >> whether it is >> worth >> adding an >> ifdef so >> as to explicitly >> deactivate the >> alignment on >> some platforms >> (solaris_x86_64 ?) >> >> >> I don't have enough >> knowledge to even >> begin to >> comment on >> this. I will >> have to rely on our >> x86_64 >> macroassembler experts >> to explain >> the old >> code and what the >> requirements are. >> >> >> OK. This means that the >> alignment was not >> removed >> purposefully. >> >> In that case, you must >> either keep the per >> platform >> code x86_64 >> (since >> it was not identical for >> all platforms) or >> use the safest >> version, with >> the additional >> >> // XXX >> mov(r10, rsp); >> andq(rsp, -16); >> push(r10); >> >> before the push(r11) and >> with the >> >> pop(rsp); >> >> after the pop(r11). It >> should work on all >> x86_64 platforms. >> >> >> Right, I will add this back >> to the code - and >> replace the >> meaningless // XXX with an >> actual comment! >> >> Many thanks, >> David >> ----- >> >> >> FYI, there is another way >> to do the >> alignment, based on >> the fact >> that >> we are at least aligned >> on 8 bytes (see >> MacroAssembler::call_VM_leaf_base). I >> assume that this >> second >> version is >> more efficient >> (particularly thanks to >> specilative >> branches) but it >> might be safer/simpler to >> continue using >> andq in >> get_thread. >> >> Bertrand. >> >> >> Thanks, >> David >> >> Regards, >> >> Bertrand. >> >> >> >> On 23/11/2015 >> 08:03, David Holmes >> wrote: >> >> After all the >> preliminary >> discussions here >> are final >> proposed changes: >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8132510 >> >> Open webrev: >> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/ >> >> A simple (in >> principle) but >> wide-ranging change >> which should >> appeal to >> our Code >> Deletion Engineer's. >> We implement >> >> Thread::current() using a >> compiler/language-based >> thread-local >> variable eg: >> >> static >> __thread Thread >> *_thr_current; >> >> inline Thread* >> Thread::current() { >> return >> _thr_current; >> } >> >> with an >> appropriate setter of >> course. By >> doing this >> we can >> completely >> remove the >> os_cpu-specific >> ThreadLocalStorage >> >> implementations, and the >> associated >> os::thread_local_storage* calls. >> >> As __thread >> is not >> async-signal-safe (either in >> theory or >> practice) we >> need a >> fallback library-based >> solution as used >> today. For >> this we use a >> very simple >> ThreadLocalStorage >> class and an >> >> implementation thereof for >> POSIX (covers >> AIX, BSD, Linux, >> OSX and >> Solaris) using >> pthread_get/setspecific; and >> one for >> Windows using >> its TLS >> library. >> While these >> library routines >> are not guaranteed >> >> async-signal-safe, they >> seem to be in >> practice and are >> what we have >> been >> using all >> along. >> >> We also allow >> for use of >> only the >> library-based TLS >> for platforms >> where >> >> compiler-based thread locals >> are not >> supported (as >> will be >> needed in >> the >> Mobile >> project). This is >> enabled at build >> time by >> defining >> USE_LIBRARY_BASED_TLS_ONLY. >> >> Thanks to >> Andrew Haley for >> providing the >> Aarch64 >> code; and for >> Thomas >> Stuefe for >> testing PPC and >> AIX. >> >> Testing: >> - JPRT >> (core platforms) >> - Jtreg >> tests (linux & >> solaris) >> - >> vm.runtime (core >> platforms) >> >> Performance: >> - still >> TBD - this is >> proving to be >> extremely >> difficult. If >> anyone >> has >> any simple >> to run >> microbenchmarks to >> suggest I'd >> give them a >> try as a >> sanity check. >> But I lack >> access to hardware for >> running serious >> benchmarking. >> >> Footprint: >> - varies by >> platform and the >> VM (server, >> client, >> minimal) >> - worst-case: >> ~1% increase for >> server VM >> and minimal VM >> - best-case: >> 0.4% decrease >> for client VM >> >> Thanks, >> David >> >> >> >> >> >> >> >> >> -- >> Bertrand Delsart, >> Grenoble >> Engineering Center >> Oracle, 180 av. de l'Europe, >> ZIRST de >> Montbonnot >> 38330 Montbonnot Saint Martin, FRANCE >> bertrand.delsart at oracle.com >> >> > > >> > >> > >> >> Phone : +33 4 76 18 81 23 >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> NOTICE: This email message is for the >> sole use of the >> intended >> recipient(s) and may contain >> confidential and >> privileged >> information. Any unauthorized >> review, use, >> disclosure or >> distribution is prohibited. If you are >> not the intended >> recipient, >> please contact the sender by reply >> email and destroy >> all copies of >> the original message. >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> >> >> >> From frederic.parain at oracle.com Tue Dec 1 16:21:47 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 1 Dec 2015 17:21:47 +0100 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <56548F9B.1000507@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <56548F9B.1000507@oracle.com> Message-ID: <565DC91B.9060206@oracle.com> Hi Dan, Thank you for your detailed review. My answers are in-lined below. New webrev: http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/ On 24/11/2015 17:26, Daniel D. Daugherty wrote: > > src/cpu/sparc/vm/frame_sparc.cpp > (old) L635: if (fp() - sp() > 1024 + > m->max_stack()*Interpreter::stackElementSize) { > (new) L635: if (fp() - unextended_sp() > 1024 + > m->max_stack()*Interpreter::stackElementSize) { > This looks like a bug fix independent of this fix. Correct, this is the SPARC version of JDK-8068655. > src/share/vm/runtime/thread.hpp > L953: intptr_t* _reserved_stack_activation; > L1382: intptr_t* reserved_stack_activation() const { return > _reserved_stack_activation; } > L1383: void set_reserved_stack_activation(intptr_t* addr) { > > I was expecting this type to be 'address' instead of 'intptr_t*'. > > Update: I've gone back through the changes and I still don't > see a reason that this is 'intptr_t*'. The _reserved_stack_activation has been declared as an 'intptr_t*' just to be consistent with the _sp and _fp fields of the frame class. However, this is not really a requirement, the content stored at the _reserved_stack_activation address is never read. This address is just a "marker" on the stack to quickly check if the thread has exited the annotated code section or not. I've change the type to address, there's slightly less casts, and it doesn't impact the ReservedStackArea logic. Note: I've removed all further comments about _reserved_stack_activation type in order to improve the e-mail readability. > L1341: { return stack_yellow_zone_base();} > '{' should be at the end of the previous line. > Missing space after ';'. Fixed > L1343: { return StackReservedPages * os::vm_page_size(); } > '{' should be at the end of the previous line. Fixed > src/share/vm/runtime/thread.cpp > L2543: // The base notation is from the stacks point of view, > growing downward. > L2565: // The base notation is from the stacks point of view, > growing downward. > Typo: "stacks point of view" -> "stack's point of view" Fixed > L2552: } else { > L2553: warning("Attempt to guard stack reserved zone failed."); > L2554: } > L2555: enable_register_stack_guard(); > > Should enable_register_stack_guard() be called when we issued > the warning on L2553? > > L2571: } else { > L2572: warning("Attempt to unguard stack reserved zone failed."); > L2573: } > L2574: disable_register_stack_guard(); > > Should disable_register_stack_guard() be called when we issued > the warning on L2572? enable_register_stack_guard() and disable_register_stack_guard() are relics of the Itanium code (Itanium had a very different stack management). These methods are currently empty on all OpenJDK and Oracle platforms. May be another clean up opportunity here. Regarding the placement of the calls, I followed the same pattern as the other red/yellow pages management functions. > src/share/vm/runtime/sharedRuntime.cpp > > L784: java_lang_Throwable::set_message(exception_oop, > L785: Universe::delayed_stack_overflow_error_message()); > Wrong indent; this should line up under the 'e' after the '('. Fixed > L2976: if (fr.is_interpreted_frame()) { > L2978: prv_fr = fr; > L2982: prv_fr = fr; > This line is in both branches of the if-statement on L2976. > Is there a reason not to save prv_fr before L2976? No particular reason, fixed. > L2996 continue; > Wrong indent; needs one more space. Fixed > L2958: frame activation; > L3013: return activation; > The return on L3013 can return a default constructed 'frame'. > Is that default safe to return here? Yes, the caller performs a check before using the returned frame: if (activation.sp() != NULL) { ... > > src/os/bsd/vm/os_bsd.hpp > L109: static bool get_frame_at_stack_banging_point(JavaThread* > thread, ucontext_t* uc, frame* fr); > Wrong indent; needs one less space. Fixed > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > L322: // For Forte Analyzer AsyncGetCallTrace profiling support - > thread > L323: // is currently interrupted by SIGPROF. > Now fetch_frame_from_ucontext() is also used for stack overflow > signal handling. Fixed > L379: assert(fr->safe_for_sender(thread), "Safety check"); > L380: if (!fr->is_first_java_frame()) { > L381: *fr = fr->java_sender(); > The assert() on L379 should be before the java_sender() > call on L381. Fixed > src/os/linux/vm/os_linux.cpp > L1902: jt->stack_guards_enabled()) { // No pending > stack overflow exceptions > This line's comment used to align with the previous line's comment. > Can you move the previous line's comment to align with this one? Done. > src/os_cpu/linux_x86/vm/os_linux_x86.cpp > L135: // For Forte Analyzer AsyncGetCallTrace profiling support - > thread > L136: // is currently interrupted by SIGPROF. > Now fetch_frame_from_ucontext() is also used for stack overflow > signal handling. Fixed > L192: assert(fr->safe_for_sender(thread), "Safety check"); > L193: if (!fr->is_first_java_frame()) { > L194: *fr = fr->java_sender(); > The assert() on L192 should be before the java_sender() > call on L194. Fixed > src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp > L209: // For Forte Analyzer AsyncGetCallTrace profiling support - > thread > L210: // is currently interrupted by SIGPROF. > Now fetch_frame_from_ucontext() is also used for stack overflow > signal handling. Fixed > L265: assert(fr->safe_for_sender(thread), "Safety check"); > L266: if (!fr->is_first_java_frame()) { > L267: *fr = fr->java_sender(); > The assert() on L265 should be before the java_sender() > call on L267. Fixed > L279: //assert(fr->safe_for_sender(thread), "Safety check"); > Delete this line; you copied it to L282. Done > L287 return true; > Should this assert be added above this line? > assert(fr->is_java_frame(), "Safety check"); Yes, this assert exists on other platforms, and there's no reason to omit it on Solaris/SPARC > src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp > L195: // For Forte Analyzer AsyncGetCallTrace profiling support - > thread > L196: // is currently interrupted by SIGPROF. > Now fetch_frame_from_ucontext() is also used for stack overflow > signal handling. Fixed > L253: assert(fr->safe_for_sender(thread), "Safety check"); > L254: if (!fr->is_first_java_frame()) { > L255: *fr = fr->java_sender(); > The assert() on L253 should be before the java_sender() > call on L255. Fixed > L273: *fr = fr->java_sender(); > Wrong indent; one too many spaces. Fixed > src/os/windows/vm/os_windows.cpp > L2364: assert(fr->safe_for_sender(thread), "Safety check"); > L2365: if (!fr->is_first_java_frame()) { > L2366: *fr = fr->java_sender(); > The assert() on L2364 should be before the java_sender() > call on L2366. Fixed > L2387: return true; > Should this assert be added above this line? > assert(fr->is_java_frame(), "Safety check"); Certainly, fixed. > src/share/vm/oops/method.hpp > (old) L87: u1 _flags; > (new) L88: u2 _flags; > Ouch - just needed one more bit... The initial implementation of the reserved stack area used the last bit, but unfortunately, someone else steal it before I could push my code :-( So I had to extend the flags field > L834: return (_flags & _reserved_stack_access) != 0; > Wrong indent; two fewer spaces. Fixed > src/share/vm/runtime/globals.hpp > L3549: range(MIN_STACK_RESERVED_PAGES, > (DEFAULT_STACK_RESERVED_PAGES+10))\ > Wrong indent; should line up below the double quote in > the previous line. Fixed > src/share/vm/interpreter/interpreterRuntime.cpp > L328 IRT_ENTRY(void, > InterpreterRuntime::throw_delayed_StackOverflowError(JavaThread* thread)) > > The regular throw_StackOverflowError() increments > a counter: > > L313: Atomic::inc(&Exceptions::_stack_overflow_errors); > > Should this function increment the same counter or > a different counter? Good catch! I've added the counter increment to the method throw_delayed_StackOverflowError(). I don't see a strong rational to create a new counter for delayed stack overflows, so it increments the same counter as throw_StackOverflowError(). > > src/cpu/sparc/vm/macroAssembler_sparc.hpp > L1423: // Check for reserved stack access in method being exited > (for the compilers) > The X86 version says "for JIT compilers". I prefer "JIT". Fixed > src/cpu/x86/vm/macroAssembler_x86.hpp > L643: // Check for reserved stack access in method being exited > (for JIT compilers) > The SPARC version says "for the compilers". Fixed > src/share/vm/ci/ciMethod.cpp > L95: _has_reserved_stack_access = > h_m()->has_reserved_stack_access(); > Wrong indent; should be only one space before '='. Fixed > src/share/vm/c1/c1_GraphBuilder.cpp > L3323: if(callee->has_reserved_stack_access()) { > L3336: if(callee->has_reserved_stack_access()) { > L3356: if(callee->has_reserved_stack_access()) { > Missing space between 'if' and '('. All fixed. > src/cpu/x86/vm/x86_32.ad > L737: size += 64; // added to support ReservedStackAccess > Usually I hate literals like this, but this function has > them in spades. :-( I agree but I didn't find a better solution. > src/cpu/x86/vm/x86_64.ad > L960: MacroAssembler _masm(&cbuf); > L965: MacroAssembler _masm(&cbuf); > > I think you can delete the _masm on L965. Right, removed. > src/share/vm/opto/compile.cpp > L675: _has_reserved_stack_access(target->has_reserved_stack_access()) { > Wrong indent; should be a single space between ')' and '{'. Fixed > test/runtime/ReservedStack/ReservedStackTest.java > L26: * @run main/othervm -XX:-Inline > -XX:CompileCommand=exclude,java/util/concurrent/locks/AbstractOwnableSynchronizer,setExclusiveOwnerThread > ReservedStackTest > > Should the comma before 'setExclusiveOwnerThread' be a period? > Perhaps both formats work... Both formats work, but I changed it to be a period, it's cleaner. > L47: * else > Wrong indent; needs one more space before 'else'. > > L52: * successfully update the status of the lock but he method > Typo: 'update the' -> 'updates the' > Typo: 'he method' -> 'the method' > > L60: * first StackOverflowError is thrown, the Error is catched > Typo: 'is catched' -> 'is caught' > > L61: * and a few dozens frames are exited. Now the thread has > Typo: 'a few dozens frames' -> 'a few dozen frames' > > L66: * of its invocation, tries to acquire the next lock > Typo: 'its invocation' -> 'its invocations' > > L81: * stack to prevent false sharing. The test is using this > Perhaps 'The test is using this' > -> 'The test relies on this' > > to better match wording on L225-6. > > L82: * to have different stack alignments and hit the targeted > Grammar: 'and hit' -> 'when it hits' > > L102: * exploit the property that interpreter frames are (much) > Typo: 'exploit' -> 'exploits' > Delete extra space after 'the'. > > L123: //LOCK_ARRAY_SIZE value > Add a space after '//'. > > L188: @jdk.internal.vm.annotation.ReservedStackAccess > This isn't privileged code and -XX:-RestrictReservedStack > isn't specified so what does this do? It checks that by default the annotation is ignored for non-privileged code, in case it is not ignored, the test would fail. > > L201: System.exit(-1); > Wrong indent; needs two more spaces. All fixed. Thank you very much! Fred >> >> On 20/11/2015 19:44, Karen Kinnear wrote: >>> Frederic, >>> >>> Code review for web revs you sent out. >>> Code looks good. I am not as familiar with the compiler code. >>> >>> I realize you need to check in at least a subset of the >>> java.util.concurrent changes for >>> the test to work, so maybe I should not have asked Doug about his >>> preference there. >>> Sorry. >>> >>> I am impressed you found a way to make a reproducible test! >>> >>> Comments/questions: >>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >> >> Fixed >> >>> 2. IIRC, due to another bug with windows handling of our guard pages, >>> this >>> is disabled for Windows. Would it be worth putting a comment in the >>> bug , 8067946, that once this is fixed, the reserved stack logic on >>> windows >>> will need testing before enabling? >> >> More than testing, the implementation would have to be completed on >> Windows. I've added a comment to JDK-8067946. >> >>> 3. In get_frame_at_stack_banging_point on Linux, BSD and solaris_x86 if >>> this is in interpreter code, you explicitly return the Java sender >>> of the current frame. I was expecting to see that on Solaris_sparc >>> and Windows >>> as well? I do see the assertion in caller that you do have a java frame. >> >> It doesn't make sense to check the current frame (no bytecode has been >> executed yet, so risk of partially executed critical section). I did the >> change but not for all platforms. This is now fixed for Solaris_SPARC >> and Windows too. >> >>> 4. test line 83 ?writtent? -> ?written? >> >> Fixed >> >>> 5. I like the way you set up the preallocated exception and then set >>> the message - we may >>> try that for default methods in future. >>> >>> 6. I had a memory that you had found a bug in safe_for_sender - did >>> you already check that in? >> >> I've fixed x86 platforms in JDK-8068655. >> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >> I had hoped it would have been silently accepted :-) >> >> >>> 7. I see the change in trace.xml, and I see an include added to >>> SharedRuntime.cpp, >>> but I didn?t see where it was used - did I just miss it? >> >> trace.xml changes define a new event. >> This event is created at sharedRuntime.cpp::3006 and it is used >> in the next 3 lines. >> >> Thanks, >> >> Fred >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From jaroslav.bachorik at oracle.com Tue Dec 1 17:47:38 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 1 Dec 2015 18:47:38 +0100 Subject: RFR 8141526: Allow to collect stdout/stderr from the FinalizationRunner even before the process returns In-Reply-To: <565C269F.1050206@oracle.com> References: <563CD13B.8040800@oracle.com> <56562D60.80306@oracle.com> <565C269F.1050206@oracle.com> Message-ID: <565DDD3A.8000406@oracle.com> On 30.11.2015 11:36, Jaroslav Bachorik wrote: > On 25.11.2015 22:51, Dmitry Samersoff wrote: >> Jaroslav, >> >> Looks good for me. > > Thanks! Could I have someone from outside of svc to take a look at this > as well? The change needs to augment the hotspot test library with some > features from the jdk hotspot library. And in order not to duplicate the > code it consolidate these library classes into the shared library. Last call - if I am not hearing any objections I am going to integrate this patch tomorrow. Regards, -JB- > > >> >> PS: I found a bug in canPtraceAttachLinux not related to your changes - >> it's probably my mistake: >> >> 181 if (userName.equals("root")) { >> 182 return true; >> 183 } >> >> shouldn't be there. >> >> Could you file a separate CR and assign it to me? > > Will do. > > -JB- > >> >> -Dmitry >> >> On 2015-11-06 19:11, Jaroslav Bachorik wrote: >>> [wider audience included] >>> >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8141526 >>> Webrev: >>> top> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00 >>> hotspot> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/hotspot >>> jdk> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/jdk >>> >>> After the fix for https://bugs.openjdk.java.net/browse/JDK-8135188 we >>> are not able to get the debug info about the run of the launcher >>> FinalizationRunner application in case it gets stuck and harness times >>> out. This is because the stdout/err of the application started via >>> ProcessTools.executeProcess() is collected only after the application >>> has exited. >>> >>> The solution is to use ProcessTools.startProcess() and consume the >>> application stdout/err in a streaming mode. Because this method has only >>> been available in the 'jdk' version of ProcessTools and not in the >>> 'hotspot' one I decided to merge both of those versions and place the >>> merged version into the shared location 'test/lib/share/classes/'. >>> During this I decided to change the package for the shared ProcessTools >>> class to be 'jdk.test.lib.process' to be more in line with the way this >>> shared library is structured. I had to move few other lib classes >>> required by ProcessTools to the shared lib as well. All the moved lib >>> classes have been marked as deprecated in their original location. >>> >>> >>> Thanks, >>> >>> -JB- >>> >> >> > From gerard.ziemski at oracle.com Tue Dec 1 17:49:04 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Tue, 1 Dec 2015 11:49:04 -0600 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <565CF8F5.9040504@oracle.com> References: <564F8ADB.9090008@oracle.com> <5654747A.3000908@oracle.com> <56547635.9060808@oracle.com> <56563D89.5090902@oracle.com> <565CD030.50507@oracle.com> <565CDEA5.10603@oracle.com> <565CF8F5.9040504@oracle.com> Message-ID: <565DDD90.1010506@oracle.com> On 11/30/2015 07:33 PM, sangheon.kim wrote: >> >>> >>> src/share/vm/runtime/globals.hpp lines: >>> 3419 product(uintx, TLABRefillWasteFraction, 64, \ >>> 3420 "Maximum TLAB waste at a refill (internal fragmentation)") \ >>> 3421 range(1, max_juint) \ >>> >>> >>> ------------- >>> #6 We multiply NewSizeThreadIncrease later, like >>> >>> size_t thread_increase_size = threads_count * NewSizeThreadIncrease; >>> >>> so the range's max needs to be smaller than max_uintx by some large enough constant (MAX thread count?) >> You are right. >> We don't have any problem without constraint function but it would be better to have one. >> I will post next webrev soon with this constraint function. > Looking at the code again, it is hard to add constraint function for this flag. > When we run the constraint function('threads_count' is zero at this time), we don't know how many non-daemon threads > will be running. > i.e. 'size_t thread_increase_size = threads_count * NewSizeThreadIncrease; ' is executed after GC is happened and the > flag validation is occurred much earlier. > And as we are using both MIN/MAX macro, I think there will be no value range problem with this flag. > What do you think about this? Our SQE testing framework for ranges will use the MAX value from the range guranteed, so our testing will hit this for sure. Should we perhaps then at least define the range as (1, max_juint/2048) or some other reasonable value instead of 2048? cheers From jaroslav.bachorik at oracle.com Tue Dec 1 17:51:32 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 1 Dec 2015 18:51:32 +0100 Subject: RFR 8141526: Allow to collect stdout/stderr from the FinalizationRunner even before the process returns In-Reply-To: <565C269F.1050206@oracle.com> References: <563CD13B.8040800@oracle.com> <56562D60.80306@oracle.com> <565C269F.1050206@oracle.com> Message-ID: <565DDE24.1030902@oracle.com> On 30.11.2015 11:36, Jaroslav Bachorik wrote: > On 25.11.2015 22:51, Dmitry Samersoff wrote: >> Jaroslav, >> >> Looks good for me. > > Thanks! Could I have someone from outside of svc to take a look at this > as well? The change needs to augment the hotspot test library with some > features from the jdk hotspot library. And in order not to duplicate the > code it consolidate these library classes into the shared library. Last call - if I am not hearing any objections I am going to integrate this patch tomorrow. Regards, -JB- > > >> >> PS: I found a bug in canPtraceAttachLinux not related to your changes - >> it's probably my mistake: >> >> 181 if (userName.equals("root")) { >> 182 return true; >> 183 } >> >> shouldn't be there. >> >> Could you file a separate CR and assign it to me? > > Will do. > > -JB- > >> >> -Dmitry >> >> On 2015-11-06 19:11, Jaroslav Bachorik wrote: >>> [wider audience included] >>> >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8141526 >>> Webrev: >>> top> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00 >>> hotspot> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/hotspot >>> jdk> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/jdk >>> >>> After the fix for https://bugs.openjdk.java.net/browse/JDK-8135188 we >>> are not able to get the debug info about the run of the launcher >>> FinalizationRunner application in case it gets stuck and harness times >>> out. This is because the stdout/err of the application started via >>> ProcessTools.executeProcess() is collected only after the application >>> has exited. >>> >>> The solution is to use ProcessTools.startProcess() and consume the >>> application stdout/err in a streaming mode. Because this method has only >>> been available in the 'jdk' version of ProcessTools and not in the >>> 'hotspot' one I decided to merge both of those versions and place the >>> merged version into the shared location 'test/lib/share/classes/'. >>> During this I decided to change the package for the shared ProcessTools >>> class to be 'jdk.test.lib.process' to be more in line with the way this >>> shared library is structured. I had to move few other lib classes >>> required by ProcessTools to the shared lib as well. All the moved lib >>> classes have been marked as deprecated in their original location. >>> >>> >>> Thanks, >>> >>> -JB- >>> >> >> > From viktor.klang at gmail.com Tue Dec 1 12:47:43 2015 From: viktor.klang at gmail.com (Viktor Klang) Date: Tue, 1 Dec 2015 13:47:43 +0100 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> <562BC968.70603@cs.oswego.edu> <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> Message-ID: While we are painting the bikeshed, what about `powerNap()` On Tue, Dec 1, 2015 at 1:16 PM, Vitaly Davidovich wrote: > Minor quibble, but why the "on" prefix in the name? Maybe just me, but > onXYX is typically used for event notification style APIs. > > Also, the "wait" part seems inappropriate as the method itself isn't doing > any waiting. What was wrong with the original spinLoopHint name? Or > cpuRelax()? > > sent from my phone > On Nov 30, 2015 9:59 PM, "Gil Tene" wrote: > >> Update: After some significant back-and-forth between Doug and I on >> naming and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we >> have what we think is a good spec and name selection for this thing. We're >> proposing to add a new static method to the Runtime class: >> >> class Runtime { /... >> /** >> * Method signifying that the caller is momentarily unable to >> * progress until the occurrence of one or more actions of one or >> * more other activities. When invoked within each iteration, this >> * method typically improves performance of spin wait loop >> * constructions. >> */ >> public static void onSpinWait() {}; >> } >> >> See updated details, including a link to the updated JEP draft, as well >> as links to working prototype implementations, webrevs against OpenJDK9b94, >> and example here: >> https://github.com/giltene/GilExamples/tree/master/SpinWaitTest < >> https://github.com/giltene/GilExamples/tree/master/SpinWaitTest> . All >> names have changed to reflect the new naming (onSpinWait, >> -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.). >> >> As an interesting stat, the total changes in the WebRevs amount to 78 >> added lines (across 14 files) , and 0 lines removed or changed. Hopefully a >> good indication of relatively low footprint and risk. >> >> ? Gil. >> >> >> >> >> >> > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > -- Cheers, ? From jon.masamitsu at oracle.com Tue Dec 1 18:11:15 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 1 Dec 2015 10:11:15 -0800 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <565D3AC2.307@oracle.com> References: <565631DC.1010800@oracle.com> <56563B4D.3030301@oracle.com> <56566A62.4030902@oracle.com> <565D3AC2.307@oracle.com> Message-ID: <565DE2C3.4020900@oracle.com> David, Thanks again for looking at this. Given the points that Kim made, are you OK with this implementation? The initialization is fragile and I hoped to fix it with the least risk of collateral damage. But I can look at it again if you can suggest what to look for. I don't claim to know why things are the way they are. And I'm going to add the needed empty definitions for aarch64, ppc, and zero (Kim encouraged me to do that). I intended to leave the linux/sparc alone for now. I don't think I have a build to test changes yet. Jon On 11/30/2015 10:14 PM, David Holmes wrote: > On 1/12/2015 1:04 PM, Kim Barrett wrote: >> On Nov 25, 2015, at 9:11 PM, David Holmes >> wrote: >>> >>> We already have VM_Version::early_initialize() that can/should be >>> used for this if possible. >> >> VM_Version::early_initialize doesn?t work for this, because >> determine_features (sparc) examines some command-line arguments, and >> those aren't parsed until a later stage of Threads::create_vm. >> >> Specifically, determine_features (sparc) is presently looking at two >> CLAs: UseV8InstrsOnly (develop) and UseNiagaraInstrs (product). I >> suspect UseV8InstrsOnly has served its purpose and could be purged. >> But calling determine_features before argument parsing would >> unintentionally ignore UseNiagaraInstrs. >> >> Calling determine_features from os::init_before_ergo doesn't have >> this problem. >> >> [I missed this in my review of Jon?s original change to use >> early_initialize.] > > Thanks Kim. Still makes me wonder if it isn't something else that is > in the wrong place - the initialization dance is very tricky and I > hate to see yet-another-vm-version-init function added. Makes me > wonder whether determine_features should only look at what the > hardware provides, and then after argument processing is complete (or > appropriate portion thereof) we update the features that should > actually be used? - but that ship sailed long ago. > > David > >> From tom.benson at oracle.com Tue Dec 1 18:51:25 2015 From: tom.benson at oracle.com (Tom Benson) Date: Tue, 1 Dec 2015 13:51:25 -0500 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <565CE0FB.8000303@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> Message-ID: <565DEC2D.3010308@oracle.com> Hi Sangheon, On 11/30/2015 6:51 PM, sangheon.kim wrote: > Hi Tom, > > Thank you for reviewing this! > > On 11/30/2015 02:46 PM, Tom Benson wrote: >> Hi Sangheon, >> >> I think there's a problem with using the same routine to check >> HeapBaseMinAddress as is used for checking heap size in >> commandLineFlagConstraintsGC.cpp. I tried running this, to make sure >> I understood what it was trying to do. When I specified something too >> large for HeapBaseMinAddress, the check reported that the value must >> be greater than or equal to maximum value N. > Sorry Tom, I can't understand. > Currently we print the error message if its value is too large like, > "must be less than or equal to aligned maximum value (xxx)". > Do you mean it should be 'address' instead of 'value'? What I meant was that I got an internal error when I used the value the message recommended, so perhaps the value should be further constrained. > I thought it is okay. > >> Re-running with that (still huge) value, I get a fatal internal error >> out of virtualspace.cpp. (In the debug version, an assertion in >> universe.cpp triggers before reaching this point). EG: > I am trying to reproduce this assert but I can't. Do you have more > information to reproduce this? > I did -version and running GCOld to trigger GC. > > java -XX:HeapBaseMinAddress=18446744073642442752 -version > java -XX:HeapBaseMinAddress=18446744073642442752 GCOld 20 200 10 100 5000 > You probably didn't hit the problem because you're running on a smaller memory system than I am. On the system I'm on, the (computed) max heap size is 32G. And if you specify an Xmx, you don't go through the code path that causes it. Here's the root of the problem. In Arguments::set_heap_size(), we have this code: if (FLAG_IS_DEFAULT(MaxHeapSize)) { . . . if (UseCompressedOops) { // Limit the heap size to the maximum possible when using compressed oops julong max_coop_heap = (julong)max_heap_for_compressed_oops(); . . . if (HeapBaseMinAddress + MaxHeapSize < max_coop_heap) { <======== *** PROBLEM IS HERE *** // Heap should be above HeapBaseMinAddress to get zero based compressed oops // but it should be not less than default MaxHeapSize. max_coop_heap -= HeapBaseMinAddress; } reasonable_max = MIN2(reasonable_max, max_coop_heap); } HeapBaseMinAddress is 64-bit unsigned, and in this case is 0xfffffffffc000000 (the 18446744073642442752 from the command line). MaxHeapSize is 0x7CCCCC8 and max_coop_heap is 0x7FE000000. The addition of HeapBaseMinAddress and MaxHeapSize overflows to 0x3ccccc8. Since this is less than 0x7FE000000, we subtract the 0xfffffffffc000000 from max_coop_heap, getting the result 0x802000000. reasonable_max is 0x800000000, so it stays at that value after the MIN2, rather than being reduced as it should be. Changing the conditional to also check for overflow avoids the problem. But of course you don't get the requested HeapBaseMinAddress anyway, since it's too high. So another approach would be to change your constraint to ensure that (HeapBaseMinAddress plus MaxHeapSize) won't overflow. I don't think there's any point in allowing a HeapBaseMinAddress so high that it would. Tom > Thanks, > Sangheon > > >> >> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=0xffffffffffffffff -version >> HeapBaseMinAddress (18446744073709551615) must be less than or equal >> to aligned maximum value (18446744073642442752) >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=18446744073642442752 >> -version >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (virtualspace.cpp:456), pid=10359, tid=10360 >> # guarantee(size + noaccess_prefix_size(alignment) <= >> OopEncodingHeapMax) failed: can not allocate compressed oop heap for >> this size >> # >> >> Perhaps you should check only the alignment in the constraint code, >> without checking the range, because I'm not sure you have the final >> heap size at that point. Then maybe the heap reservation code should >> report this as a non-internal error, at the point where the assertion >> occurs, if the user specified a base address. >> >> There's also an extraneous single quote in >> commandLineFlagConstraintsGC.cpp in the comment at line 510. >> >> Tom >> >> >> Date: Tue, 24 Nov 2015 06:37:41 -0800 >> From: "sangheon.kim" >> To: Dmitry Dmitriev, >> "hotspot-dev at openjdk.java.net Developers" >> >> Subject: Re: RFR(S): 8142341: GC: current flags need ranges to be >> implemented >> Message-ID:<56547635.9060808 at oracle.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> Hi Dmitry, >> >> Thank you for the review! >> Sure I will update my patch related to your enhancement. >> >> Thanks, >> Sangheon >> >> >> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote: >> >>> Hi Sangheon, >>> >>> Looks good to me! Thank you for fixing that. I hope that enhancement >>> will be pushed today(currently in JPRT queue), so please update your >>> patch after that! >>> >>> Thanks, >>> Dmitry >>> >>> On 21.11.2015 0:04, sangheon.kim wrote: >>>> Hi all, >>>> >>>> Could I have a couple of reviews for this change to add explicit >>>> 'range' for flags? >>>> >>>> Previously, we added 'range' when it is needed to avoid assert/crash >>>> but now explicit 'range' are needed for all flags. >>>> All flags should have 'range' or 'constraint' at least. >>>> >>>> CR:https://bugs.openjdk.java.net/browse/JDK-8142341 >>>> Webrev:http://cr.openjdk.java.net/~sangheki/8142341/webrev.00 >>>> Testing: JPRT, RBT >>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for >>>> embedded >>>> >>>> * Summary >>>> 1. Added 3 new constraint functions. >>>> 1) HeapBaseMinAddress: Added to avoid an overflow after align up >>>> and this flag makes hang up without constraint function. (newly added >>>> as a part of GC work) >>>> 2) TLABWasteIncrement: Without this constraint function we don't >>>> have problems (even many GCs happen). But added to avoid an overflow >>>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are also >>>> separate CR for this overflow ( JDK-8143352 ). >>>> 3) NUMAInterleaveGranularity: Added to avoid an overflow after >>>> align up. >>>> >>>> 2. Some flags have narrower range than their type. >>>> 1) Here's the reason why some flags should have different range. >>>> (same order from globals.hpp) >>>> {flag type} {flag name}: (range), {comment} >>>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), >>>> max_uintx), there is a comment at numa_interleaving_init() that this >>>> flag should be larger than vm_allocation_granularity(). >>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as >>>> used for multiplication >>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which >>>> has 'unsigned int' type input parameter. >>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function which >>>> has 'unsigned int' type input parameter. >>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function >>>> which has 'long' type input parameter. >>>> uintx PausePadding: (0, max_juint), used to set a function which has >>>> 'unsigned int' type input parameter. >>>> uintx PromotedPadding: (0, max_juint), used to set a function which >>>> has 'unsigned int' type input parameter. >>>> uintx SurvivorPadding: (0, max_juint), used to set a function which >>>> has 'unsigned int' type input parameter. >>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag >>>> is divided by 100 I assume this is percentage. >>>> uintx GCTimeRatio: (0, max_juint), used to set a function which has >>>> 'unsigned int' type input parameter. >>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint) >>>> intx PrefetchScanIntervalInBytes: (-1, max_jint) >>>> intx PrefetchFieldsAhead: (-1, max_jint), I think these 3 Prefetch* >>>> flags should have same upper limit and looking at their related codes >>>> 'max_jint' seems appropriate ( no problem with 'max_jint' during >>>> testing). However, as Prefetch::read/write() needs 'intx', 'intx' >>>> also seems good but we have to fix some codes (maybe including >>>> generated codes). >>>> uintx CPUForCMSThread: (0, max_juint), used to set a function which >>>> has 'unsigned int' type input parameter. >>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint >>>> variable and used 'for loop' which has uint increment. i.e. for (uint >>>> i=0; i>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at >>>> 'increment for loop()' as max value and the increment is uint. >>>> uintx CMSYieldSleepCount: (0, max_juint), used at 'increment for >>>> loop()' as max value and the increment is uint. >>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return value >>>> of uint type function and for division. i.e. uint >>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return >>>> TLABRefillWasteFraction; } >>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int) >>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we only >>>> use " if (a !=0, >0, >1)". >>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we only >>>> use " if (a !=0, >0, >1)". >>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only use >>>> " if (a !=0, >0)". >>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned >>>> int' >>>> >>>> (g1_globals.hpp) >>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int) >>>> type variable. >>>> >>>> 3. Excluded flags from TestOptionsWithRanges.java >>>> 1) Memory and thread related flags: tests for these flags will >>>> consume too many resources from the system. >>>> 2) VMThreadStackSize: range work for this flag is not included in >>>> this patch but I faced OOME several times, so excluded. >>>> >>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] >>>> TestOptionsWithRanges: allow excluding only a subset of tested values >>>> specified for a flag) next time. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> > From christian.tornqvist at oracle.com Tue Dec 1 19:19:17 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 1 Dec 2015 14:19:17 -0500 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> Message-ID: <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> Hi Paul, Tests in hotspot/test/runtime needs to be jtreg tests. Looking at your tests, I can't see a reason why they can't easily be modified to be jtreg tests instead? (adding the hotspot-dev mail alias) Thanks, Christian -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Paul Sandoz Sent: Tuesday, December 1, 2015 5:28 AM Cc: hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables > On 30 Nov 2015, at 23:33, Paul Sandoz wrote: > > >> On 30 Nov 2015, at 23:05, Christian Tornqvist wrote: >> >> Because jtreg is the test framework that we use, we've been working hard to reduce the number of test frameworks in use. >> > > jtreg comes bundled with testng so what is there to reduce? > Here is an analogy: jtreg is to testng as launcher is to library They are complementary to each other i.e. think of testng as an implicit @library that helps one better organize tests and report errors. ? Would i be correct in stating that the HotSpot runtime team is taking a conservative position and does not want to deal with such a library, contrary to other areas of the JDK? Sorry to push back, but I don?t agree with that position (if correct). I am reluctant to change the tests. Please don?t think that complete pigheadedness on my part :-) I just don?t think it?s the right thing to do. If the HotSpot runtime team will not accept the use of TestNG then I suppose I could unblock by proposing to move the tests to the JDK repo, which I would also be reluctant to do since they caught an issue lying dormant for at least 8 years on certain platforms (not covered by the core testset) that existing hotspot tests never caught. Paul. From kim.barrett at oracle.com Tue Dec 1 19:36:07 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Dec 2015 14:36:07 -0500 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <565D3AC2.307@oracle.com> References: <565631DC.1010800@oracle.com> <56563B4D.3030301@oracle.com> <56566A62.4030902@oracle.com> <565D3AC2.307@oracle.com> Message-ID: <70BF0F68-49A6-4FB3-AA36-AA40D3A36A16@oracle.com> On Dec 1, 2015, at 1:14 AM, David Holmes wrote: > > On 1/12/2015 1:04 PM, Kim Barrett wrote: >> On Nov 25, 2015, at 9:11 PM, David Holmes wrote: >>> >>> We already have VM_Version::early_initialize() that can/should be used for this if possible. >> >> VM_Version::early_initialize doesn?t work for this, because >> determine_features (sparc) examines some command-line arguments, and >> those aren't parsed until a later stage of Threads::create_vm. >> >> Specifically, determine_features (sparc) is presently looking at two >> CLAs: UseV8InstrsOnly (develop) and UseNiagaraInstrs (product). I >> suspect UseV8InstrsOnly has served its purpose and could be purged. >> But calling determine_features before argument parsing would >> unintentionally ignore UseNiagaraInstrs. >> >> Calling determine_features from os::init_before_ergo doesn't have this problem. >> >> [I missed this in my review of Jon?s original change to use early_initialize.] > > Thanks Kim. Still makes me wonder if it isn't something else that is in the wrong place - the initialization dance is very tricky and I hate to see yet-another-vm-version-init function added. Makes me wonder whether determine_features should only look at what the hardware provides, and then after argument processing is complete (or appropriate portion thereof) we update the features that should actually be used? - but that ship sailed long ago. I agree this seems kind of suspect. Large program genesis can be so much fun. I think the suggestion of calling determine_features early and then clobbering the result later should work. I don't much like the modification of the features set far away from it's initialization though. And that would still require the introduction of some platform-specific code into about the same place Jon is proposing, in order to do the feature bashing. Conflating the execution platform with the target platform is a very appealing simplification, which unfortunately starts unraveling with the introduction of things like UseNiagaraInstrs (or AOT or cross compilation, on a much wider scale). A better solution might be to move determine_features early (in early_initialize) and change places that should be dependent on UseNiagaraInstrs but are presently using _features to (more) explicitly depend on UseNiagaraInstrs, rather than expecting _features to be affected by UseNiagaraInstrs. But that's probably at least somewhat hard. Another approach would be move determine_features early (in early_initialize) and to ignore UseNiagaraInstrs and UseV8InstrsOnly. I don't know whether either serves any really useful purpose anymore. UseNiagaraInstrs is a product option though. Other than the last of those (ignore presumably obsolete options), I don't think I like any of the choices better than what Jon is proposing. From coleen.phillimore at oracle.com Tue Dec 1 19:42:00 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 1 Dec 2015 14:42:00 -0500 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> Message-ID: <565DF808.7060806@oracle.com> On 12/1/15 2:19 PM, Christian Tornqvist wrote: > Hi Paul, > > Tests in hotspot/test/runtime needs to be jtreg tests. Looking at your tests, I can't see a reason why they can't easily be modified to be jtreg tests instead? > > (adding the hotspot-dev mail alias) > > Thanks, > Christian > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Paul Sandoz > Sent: Tuesday, December 1, 2015 5:28 AM > Cc: hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables > > > >> On 30 Nov 2015, at 23:33, Paul Sandoz wrote: >> >> >>> On 30 Nov 2015, at 23:05, Christian Tornqvist wrote: >>> >>> Because jtreg is the test framework that we use, we've been working hard to reduce the number of test frameworks in use. >>> >> jtreg comes bundled with testng so what is there to reduce? >> > Here is an analogy: > > jtreg is to testng as launcher is to library > > They are complementary to each other i.e. think of testng as an implicit @library that helps one better organize tests and report errors. > > ? > > Would i be correct in stating that the HotSpot runtime team is taking a conservative position and does not want to deal with such a library, contrary to other areas of the JDK? Yes. That is correct. We don't need more frameworks that hinder getting to the java command line for the class file. It's time consuming enough with jtreg. > > Sorry to push back, but I don?t agree with that position (if correct). I am reluctant to change the tests. Please don?t think that complete pigheadedness on my part :-) I just don?t think it?s the right thing to do. > > If the HotSpot runtime team will not accept the use of TestNG then I suppose I could unblock by proposing to move the tests to the JDK repo, which I would also be reluctant to do since they caught an issue lying dormant for at least 8 years on certain platforms (not covered by the core testset) that existing hotspot tests never caught. Can you repost the whole webrev to hotspot-dev ? I didn't see the original to see why these tests require the testng framework and cannot be written as simple regression tests. If they have to be very complex, maybe they belong in a different test directory that has support and tolerance for this complexity. Maybe you can write a small regression test for the hotspot/test/runtime test and put the rest somewhere else. Again, this is in the abstract. I don't have the webrev. Coleen > > Paul. > From tom.benson at oracle.com Tue Dec 1 20:01:16 2015 From: tom.benson at oracle.com (Tom Benson) Date: Tue, 1 Dec 2015 15:01:16 -0500 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <565DEC2D.3010308@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> <565DEC2D.3010308@oracle.com> Message-ID: <565DFC8C.1010007@oracle.com> Hi, I said: > What I meant was that I got an internal error when I used the value the message > recommended, so perhaps the value should be further constrained. Actually what I meant in my *original* reply was that perhaps you shouldn't check the range in the constraint code, and that the code that uses the value should check. But with the new info on where the problem comes from, I think it makes more sense to correct the constraint. Tom On 12/1/2015 1:51 PM, Tom Benson wrote: > Hi Sangheon, > > On 11/30/2015 6:51 PM, sangheon.kim wrote: >> Hi Tom, >> >> Thank you for reviewing this! >> >> On 11/30/2015 02:46 PM, Tom Benson wrote: >>> Hi Sangheon, >>> >>> I think there's a problem with using the same routine to check >>> HeapBaseMinAddress as is used for checking heap size in >>> commandLineFlagConstraintsGC.cpp. I tried running this, to make sure >>> I understood what it was trying to do. When I specified something >>> too large for HeapBaseMinAddress, the check reported that the value >>> must be greater than or equal to maximum value N. >> Sorry Tom, I can't understand. >> Currently we print the error message if its value is too large like, >> "must be less than or equal to aligned maximum value (xxx)". >> Do you mean it should be 'address' instead of 'value'? > > What I meant was that I got an internal error when I used the value > the message recommended, so perhaps the value should be further > constrained. > >> I thought it is okay. >> >>> Re-running with that (still huge) value, I get a fatal internal >>> error out of virtualspace.cpp. (In the debug version, an assertion >>> in universe.cpp triggers before reaching this point). EG: >> I am trying to reproduce this assert but I can't. Do you have more >> information to reproduce this? >> I did -version and running GCOld to trigger GC. >> >> java -XX:HeapBaseMinAddress=18446744073642442752 -version >> java -XX:HeapBaseMinAddress=18446744073642442752 GCOld 20 200 10 100 >> 5000 >> > > You probably didn't hit the problem because you're running on a > smaller memory system than I am. On the system I'm on, the > (computed) max heap size is 32G. And if you specify an Xmx, you > don't go through the code path that causes it. > > Here's the root of the problem. In Arguments::set_heap_size(), we > have this code: > > if (FLAG_IS_DEFAULT(MaxHeapSize)) { > . . . > if (UseCompressedOops) { > // Limit the heap size to the maximum possible when using > compressed oops > julong max_coop_heap = (julong)max_heap_for_compressed_oops(); > . . . > if (HeapBaseMinAddress + MaxHeapSize < max_coop_heap) { > <======== *** PROBLEM IS HERE *** > // Heap should be above HeapBaseMinAddress to get zero based > compressed oops > // but it should be not less than default MaxHeapSize. > max_coop_heap -= HeapBaseMinAddress; > } > reasonable_max = MIN2(reasonable_max, max_coop_heap); > } > > HeapBaseMinAddress is 64-bit unsigned, and in this case is > 0xfffffffffc000000 (the 18446744073642442752 from the command line). > MaxHeapSize is 0x7CCCCC8 and max_coop_heap is 0x7FE000000. The > addition of HeapBaseMinAddress and MaxHeapSize overflows to > 0x3ccccc8. Since this is less than 0x7FE000000, we subtract the > 0xfffffffffc000000 from max_coop_heap, getting the result > 0x802000000. reasonable_max is 0x800000000, so it stays at that > value after the MIN2, rather than being reduced as it should be. > > Changing the conditional to also check for overflow avoids the > problem. But of course you don't get the requested > HeapBaseMinAddress anyway, since it's too high. > > So another approach would be to change your constraint to ensure that > (HeapBaseMinAddress plus MaxHeapSize) won't overflow. I don't think > there's any point in allowing a HeapBaseMinAddress so high that it would. > > Tom > >> Thanks, >> Sangheon >> >> >>> >>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=0xffffffffffffffff >>> -version >>> HeapBaseMinAddress (18446744073709551615) must be less than or equal >>> to aligned maximum value (18446744073642442752) >>> Error: Could not create the Java Virtual Machine. >>> Error: A fatal exception has occurred. Program will exit. >>> >>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=18446744073642442752 >>> -version >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error (virtualspace.cpp:456), pid=10359, tid=10360 >>> # guarantee(size + noaccess_prefix_size(alignment) <= >>> OopEncodingHeapMax) failed: can not allocate compressed oop heap for >>> this size >>> # >>> >>> Perhaps you should check only the alignment in the constraint code, >>> without checking the range, because I'm not sure you have the final >>> heap size at that point. Then maybe the heap reservation code >>> should report this as a non-internal error, at the point where the >>> assertion occurs, if the user specified a base address. >>> >>> There's also an extraneous single quote in >>> commandLineFlagConstraintsGC.cpp in the comment at line 510. >>> >>> Tom >>> >>> >>> Date: Tue, 24 Nov 2015 06:37:41 -0800 >>> From: "sangheon.kim" >>> To: Dmitry Dmitriev, >>> "hotspot-dev at openjdk.java.net Developers" >>> >>> Subject: Re: RFR(S): 8142341: GC: current flags need ranges to be >>> implemented >>> Message-ID:<56547635.9060808 at oracle.com> >>> Content-Type: text/plain; charset=utf-8; format=flowed >>> >>> Hi Dmitry, >>> >>> Thank you for the review! >>> Sure I will update my patch related to your enhancement. >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote: >>> >>>> Hi Sangheon, >>>> >>>> Looks good to me! Thank you for fixing that. I hope that enhancement >>>> will be pushed today(currently in JPRT queue), so please update your >>>> patch after that! >>>> >>>> Thanks, >>>> Dmitry >>>> >>>> On 21.11.2015 0:04, sangheon.kim wrote: >>>>> Hi all, >>>>> >>>>> Could I have a couple of reviews for this change to add explicit >>>>> 'range' for flags? >>>>> >>>>> Previously, we added 'range' when it is needed to avoid assert/crash >>>>> but now explicit 'range' are needed for all flags. >>>>> All flags should have 'range' or 'constraint' at least. >>>>> >>>>> CR:https://bugs.openjdk.java.net/browse/JDK-8142341 >>>>> Webrev:http://cr.openjdk.java.net/~sangheki/8142341/webrev.00 >>>>> Testing: JPRT, RBT >>>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for >>>>> embedded >>>>> >>>>> * Summary >>>>> 1. Added 3 new constraint functions. >>>>> 1) HeapBaseMinAddress: Added to avoid an overflow after align up >>>>> and this flag makes hang up without constraint function. (newly added >>>>> as a part of GC work) >>>>> 2) TLABWasteIncrement: Without this constraint function we don't >>>>> have problems (even many GCs happen). But added to avoid an overflow >>>>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are also >>>>> separate CR for this overflow ( JDK-8143352 ). >>>>> 3) NUMAInterleaveGranularity: Added to avoid an overflow after >>>>> align up. >>>>> >>>>> 2. Some flags have narrower range than their type. >>>>> 1) Here's the reason why some flags should have different range. >>>>> (same order from globals.hpp) >>>>> {flag type} {flag name}: (range), {comment} >>>>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), >>>>> max_uintx), there is a comment at numa_interleaving_init() that this >>>>> flag should be larger than vm_allocation_granularity(). >>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as >>>>> used for multiplication >>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which >>>>> has 'unsigned int' type input parameter. >>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function which >>>>> has 'unsigned int' type input parameter. >>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function >>>>> which has 'long' type input parameter. >>>>> uintx PausePadding: (0, max_juint), used to set a function which has >>>>> 'unsigned int' type input parameter. >>>>> uintx PromotedPadding: (0, max_juint), used to set a function which >>>>> has 'unsigned int' type input parameter. >>>>> uintx SurvivorPadding: (0, max_juint), used to set a function which >>>>> has 'unsigned int' type input parameter. >>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag >>>>> is divided by 100 I assume this is percentage. >>>>> uintx GCTimeRatio: (0, max_juint), used to set a function which has >>>>> 'unsigned int' type input parameter. >>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint) >>>>> intx PrefetchScanIntervalInBytes: (-1, max_jint) >>>>> intx PrefetchFieldsAhead: (-1, max_jint), I think these 3 Prefetch* >>>>> flags should have same upper limit and looking at their related codes >>>>> 'max_jint' seems appropriate ( no problem with 'max_jint' during >>>>> testing). However, as Prefetch::read/write() needs 'intx', 'intx' >>>>> also seems good but we have to fix some codes (maybe including >>>>> generated codes). >>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function which >>>>> has 'unsigned int' type input parameter. >>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint >>>>> variable and used 'for loop' which has uint increment. i.e. for (uint >>>>> i=0; i>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at >>>>> 'increment for loop()' as max value and the increment is uint. >>>>> uintx CMSYieldSleepCount: (0, max_juint), used at 'increment for >>>>> loop()' as max value and the increment is uint. >>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return value >>>>> of uint type function and for division. i.e. uint >>>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return >>>>> TLABRefillWasteFraction; } >>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int) >>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we only >>>>> use " if (a !=0, >0, >1)". >>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we only >>>>> use " if (a !=0, >0, >1)". >>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only use >>>>> " if (a !=0, >0)". >>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned >>>>> int' >>>>> >>>>> (g1_globals.hpp) >>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int) >>>>> type variable. >>>>> >>>>> 3. Excluded flags from TestOptionsWithRanges.java >>>>> 1) Memory and thread related flags: tests for these flags will >>>>> consume too many resources from the system. >>>>> 2) VMThreadStackSize: range work for this flag is not included in >>>>> this patch but I faced OOME several times, so excluded. >>>>> >>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] >>>>> TestOptionsWithRanges: allow excluding only a subset of tested values >>>>> specified for a flag) next time. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>> >> > From mikael.vidstedt at oracle.com Tue Dec 1 21:29:04 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 1 Dec 2015 13:29:04 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: References: Message-ID: <565E1120.2040106@oracle.com> This is as far as I got before I got interrupted: http://cr.openjdk.java.net/~mikael/NioBenchmark.java I haven't had time yet to verify that the benchmark code even measures the right thing, much less figure out why I get the performance impact with my fix. I can see many reasons why that could be the case, but it would be good to know if it's something trivial which can be easily fixed. In general, it sure would be nice to make this code behave and perform without compiler specific annotations, especially given that reliance on unaligned memory accesses and the cast specifically is sketchy at best. Cheers, Mikael On 2015-11-30 10:13, Alexander Smundak wrote: > On Wed, Nov 25, 2015 at 2:52 PM, wrote: >> Have you looked anything at the performance of the generated code? > No. I looked at the emitted code, saw 'MOVQDU' instruction being used > (it was 'MOVQDA' before that resulted in alignment error), and concluded > that the compiler knows what it's doing :-) >> It would be interesting to understand what type of performance you see with >> your patch. > If you have specific benchmark in mind, I am willing to run it. > > Sasha From david.holmes at oracle.com Tue Dec 1 21:54:55 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Dec 2015 07:54:55 +1000 Subject: RFR: 8132510: Replace ThreadLocalStorage with compiler/language-based thread-local variables In-Reply-To: References: <5652BA32.8090207@oracle.com> <565644E8.2050809@oracle.com> Message-ID: <565E172F.3000008@oracle.com> Thanks Thomas. I'll be trying to push this today. David On 1/12/2015 7:41 PM, Thomas St?fe wrote: > Hi David, > > On Thu, Nov 26, 2015 at 12:31 AM, David Holmes > wrote: > > Hi Thomas, > > Thanks for reviewing. > > On 26/11/2015 1:20 AM, Thomas St?fe wrote: > > Hi David, > > I looked over your latest version at > http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8 > > This all looks nice and builds on AIX. I am currently running > some jtreg > tests. > > > Thanks. Please let me know if any issues surface. > > > Sorry for the delay. AIX tests went through without any issues related > to your change. Our machines are terribly slow, so all I could do was > hotspot/runtime though. > > But even if issues surface, we can easily backpaddle later to pthread tls. > > Kind Regards, Thomas > > I will need to resubmit my own tests after latest changes. > > Some small remarks: > > ------------ > > would it be possible to add a configure option (e.g. > --enable-compiler-based-tls)? On AIX, disabling compiler level > tls also > makes the -qtls compiler option unnecessary, so it affects the > makefile. > > Not really important, just would be quite comfortable. > > > It's possible to file a RFE for this. To be honest I didn't see this > as some kind of user-defined choice that would need to be > configured. The intent is that platforms which can't support > compiler level TLS simply hardwire the flag in their platform > specific makefile. > > ------------ > > http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/os/windows/vm/os_windows.cpp.udiff.html > > @@ -5175,11 +5159,11 @@ > - JavaThread* thread = (JavaThread*)(Thread::current()); > + Thread* thread = Thread::current(); > assert(thread->is_Java_thread(), "Must be JavaThread"); > JavaThread *jt = (JavaThread *)thread; > > may be simplified to use your new > > JavaThread* thread = JavaThread::current(); > > > Indeed it can. Fixed. And changed jt to thread in the following code. > > ------------ > > http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/share/vm/runtime/thread.cpp.udiff.html > > in > > Thread::clear_thread_current() > > we could also add a > > assert(Thread::current() == ThreadLocalStorage::thread(), "TLS > mismatch!"); > > to catch a case where library tls slot content changed during > lifetime > of thread. > > > Fixed. > > ---- > > JavaThread* JavaThread::active() { > - Thread* thread = ThreadLocalStorage::thread(); > + Thread* thread = Thread::current(); > assert(thread != NULL, "just checking"); > > the assert is unnecessary. > > > Fixed. > > > ----- > > http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/share/vm/runtime/thread.hpp.udiff.html > > // Inline implementation of JavaThread::current > inline JavaThread* JavaThread::current() { > - Thread* thread = ThreadLocalStorage::thread(); > + Thread* thread = Thread::current(); > assert(thread != NULL && thread->is_Java_thread(), "just > checking"); > return (JavaThread*)thread; > } > > asserting thread != NULL is unnecessary. > > > Fixed > > ----- > > http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/share/vm/utilities/globalDefinitions_gcc.hpp.udiff.html > > (and corresponding globalDefinitions_.. files) > > +#define THREAD_LOCAL_DECL __thread > > could be surrounded by #ifndef USE_LIBRARY_BASED_TLS_ONLY > > > Okay - changed. > > Updated webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v9/ > > Thanks, > David > ----- > > ----- > > Kind Regards, Thomas > > > > > > > > > On Mon, Nov 23, 2015 at 8:03 AM, David Holmes > > >> wrote: > > After all the preliminary discussions here are final > proposed changes: > > bug: https://bugs.openjdk.java.net/browse/JDK-8132510 > > Open webrev: > http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/ > > A simple (in principle) but wide-ranging change which > should appeal > to our Code Deletion Engineer's. We implement Thread::current() > using a compiler/language-based thread-local variable eg: > > static __thread Thread *_thr_current; > > inline Thread* Thread::current() { > return _thr_current; > } > > with an appropriate setter of course. By doing this we can > completely remove the os_cpu-specific ThreadLocalStorage > implementations, and the associated > os::thread_local_storage* calls. > > As __thread is not async-signal-safe (either in theory or > practice) > we need a fallback library-based solution as used today. > For this we > use a very simple ThreadLocalStorage class and an > implementation > thereof for POSIX (covers AIX, BSD, Linux, OSX and Solaris) > using > pthread_get/setspecific; and one for Windows using its TLS > library. > While these library routines are not guaranteed > async-signal-safe, > they seem to be in practice and are what we have been using > all along. > > We also allow for use of only the library-based TLS for > platforms > where compiler-based thread locals are not supported (as > will be > needed in the Mobile project). This is enabled at build time by > defining USE_LIBRARY_BASED_TLS_ONLY. > > Thanks to Andrew Haley for providing the Aarch64 code; and for > Thomas Stuefe for testing PPC and AIX. > > Testing: > - JPRT (core platforms) > - Jtreg tests (linux & solaris) > - vm.runtime (core platforms) > > Performance: > - still TBD - this is proving to be extremely difficult. > If anyone > has any simple to run microbenchmarks to suggest I'd give > them a try > as a sanity check. But I lack access to hardware for > running serious > benchmarking. > > Footprint: > - varies by platform and the VM (server, client, minimal) > - worst-case: ~1% increase for server VM and minimal VM > - best-case: 0.4% decrease for client VM > > Thanks, > David > > > From david.holmes at oracle.com Tue Dec 1 21:55:09 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Dec 2015 07:55:09 +1000 Subject: RFR: 8132510: Replace ThreadLocalStorage with compiler/language-based thread-local variables In-Reply-To: <565DAE94.7060506@oracle.com> References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com> <56530618.2020202@oracle.com> <565318A8.8050003@oracle.com> <56538862.5010609@oracle.com> <56557DCD.9050907@oracle.com> <5655B349.9070700@oracle.com> <5655CB39.3030007@oracle.com> <56563BA0.1010307@oracle.com> <56563F61.4030008@oracle.com> <5656497E.2050208@oracle.com> <565805A1.9080803@oracle.com> <565DAE94.7060506@oracle.com> Message-ID: <565E173D.4020904@oracle.com> Thanks Dan! David On 2/12/2015 12:28 AM, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~dholmes/8132510/webrev.v10 > > Rereviewed by comparing this webrev's patch with the patch from > webrev.v8. > > Thumbs up. > > Dan > > > On 11/27/15 12:26 AM, David Holmes wrote: >> Hi Thomas, >> >> On 26/11/2015 7:56 PM, Thomas St?fe wrote: >>> >>> On Thu, Nov 26, 2015 at 12:51 AM, David Holmes >> > wrote: >>> >>> On 26/11/2015 9:08 AM, Daniel D. Daugherty wrote: >>> >>> If I understand the problem... :-) >>> >>> The Win-X64 ABI requires that some extra space be allocated on >>> the stack in the caller for "homing" four registers... >>> >>> This code uses MacroAssembler::call() which is a lower level >>> call() function that assumes you know the ABI... >>> >>> 9765 void MacroAssembler::get_thread(Register thread) { >>> >>> 9784 call(RuntimeAddress(CAST_FROM_FN_PTR(address, >>> Thread::current))); >>> >>> So the failing here was nothing to do with register saving per-se, >>> nor the alignment code, but "simply" not also saving the extra space >>> prior to the call! >>> >>> Yes. These 32 byte are a scratch area for the callee, which may be used >>> for parameter registers or anything else. We may just have been lucky so >>> far that TlsGetValue() did not use this area. As Bertrand already said, >>> now we call Thread::current(), which does magic tls accesses under the >>> hood, so this must be tested again. >> >> Right. All testing so far has been successful but ... >> >>> However I think that a simple addition to your current fix could simply >>> be subtracting 32 from rsp before the call: >>> >>> subq(rsp, 32) >>> call(RuntimeAddress(CAST_FROM_FN_PTR(address, Thread::current))); >>> addq(rsp, 32) >> >> ... I decided to do what was previously suggested and use: >> >> call_VM_leaf_base(CAST_FROM_FN_PTR(address, Thread::current), 0); >> >> as it takes care of everything (stack alignment if needed and >> preserving space for the register args on win64). >> >>> Also, we could probably skip saving/restoring rdi and rsi on Windows: >> >> Maybe - but we don't seem to consider that anywhere else ie: >> >> void MacroAssembler::push_callee_saved_registers() { >> push(rsi); >> push(rdi); >> push(rdx); >> push(rcx); >> } >> >> so I don't want to be the trail-blazer here. :) >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v10 >> >> Only change to macroAssembler_x86.cpp. Re-tested on Windows 32-bit and >> 64-bit. >> >> Thanks, >> David >> >>> https://msdn.microsoft.com/en-us/library/6t169e9c.aspx >>> >>> "The registers RAX, RCX, RDX, R8, R9, R10, R11 are considered volatile >>> and must be considered destroyed on function calls (unless otherwise >>> safety-provable by analysis such as whole program optimization). The >>> registers RBX, RBP, RDI, RSI, RSP, R12, R13, R14, and R15 are considered >>> nonvolatile and must be saved and restored by a function that uses >>> them." >> >> >> >>> Best Regards, Thomas >>> >>> >>> If you switch to MacroAssembler::call_VM_leaf_base() it handles >>> more of the gory details for you than MacroAssembler::call(): >>> >>> >>> Wow! Not exactly a clearly-defined name for this. AFAICS there's >>> nothing VM or leaf specific about this. Also the MacroAssembler is >>> supposed to be a platform-agnostic higher-level abstraction that is >>> easy to use - but in this case every use of the plain call on >>> Windows-x64 is potentially broken if the programmer was not aware of >>> this ABI constraint which only applies to Windows (and we're in >>> OS-neutral files!). >>> >>> This seems fundamentally broken to me. >>> >>> Thanks for the info. >>> >>> David >>> >>> >>> src/cpu/x86/vm/macroAssembler_x86.cpp: >>> >>> 524 void MacroAssembler::call_VM_leaf_base(address >>> entry_point, int >>> num_args >>> ) { >>> 525 Label L, E; >>> 526 >>> 527 #ifdef _WIN64 >>> 528 // Windows always allocates space for it's >>> register args >>> 529 assert(num_args <= 4, "only register arguments >>> supported"); >>> 530 subq(rsp, frame::arg_reg_save_area_bytes); >>> 531 #endif >>> 532 >>> 533 // Align stack if necessary >>> 534 testl(rsp, 15); >>> 535 jcc(Assembler::zero, L); >>> 536 >>> 537 subq(rsp, 8); >>> 538 { >>> 539 call(RuntimeAddress(entry_point)); >>> 540 } >>> >>> So call_VM_leaf_base() allocates the "homing" space for register >>> args for Win-X64 on L530 and it handles any stack alignment >>> before >>> calling MacroAssembler::call(). >>> >>> So if you switch to call_VM_leaf_base() you can drop >>> the stack alignment code: >>> >>> 9777 // ensure stack alignment >>> 9778 mov(r10, rsp); >>> 9779 andq(rsp, -16); >>> 9780 push(r10); >>> >>> and just switch to: >>> >>> 9777 push(rsp); >>> >>> And you won't be exposed to potential saved register >>> overwrite by the "homing" of any registers in the call >>> Thread::current(). >>> >>> I _think_ I have that all correct... :-) >>> >>> Dan >>> >>> >>> On 11/25/15 3:52 PM, David Holmes wrote: >>> >>> On 26/11/2015 2:53 AM, Thomas St?fe wrote: >>> >>> I created a bug to track this: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8144059 >>> >>> >>> Thanks. I admit I still don't really grok the exact problem >>> here. It >>> is the alignment code that is the problem right? >>> >>> 79 mov(r10, rsp); >>> 80 andq(rsp, -16); >>> 81 push(r10); >>> >>> ? >>> >>> Thanks, >>> David >>> >>> Because Davids change is not submitted yet, the bug >>> refers to the old >>> coding, but stays relevant also after this fix. >>> >>> Kind Regards, Thomas >>> >>> On Wed, Nov 25, 2015 at 3:52 PM, Daniel D. Daugherty >>> >> >>> >> >> >>> wrote: >>> >>> On 11/25/15 6:10 AM, David Holmes wrote: >>> >>> On 25/11/2015 8:46 PM, Thomas St?fe wrote: >>> >>> >>> On Wed, Nov 25, 2015 at 10:22 AM, Bertrand >>> Delsart >>> >> >>> >> > >>> >> >>> >> >>> wrote: >>> >>> Good finding Thomas, >>> >>> On 25/11/2015 09:40, Thomas St?fe >>> wrote: >>> >>> Hi David, Bertrand, >>> >>> about >>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html >>> >>> >>> >>> I am not sure this is correct for >>> Windows x64. >>> >>> >>> Unless I'm misreading it, the new code >>> looks a lot like >>> the old one >>> (including the alignement part). Hence >>> this does not >>> look like a >>> regression caused by David's change. >>> >>> >>> Yes, this seems like an old bug. >>> >>> I also see that this is fixed in our >>> codebase since 2010, >>> exactly the >>> way you propose (with MacroAssembler >>> ::call_VM_leaf_base >>> >>> >>> >>> ). >>> >>> >>> >>> So, it is already used since five years. I >>> would propose >>> opening a >>> separate bug for this one and we contribute >>> our fix. >>> >>> >>> That sounds good to me too. I also suspect >>> additional code will >>> need to be checked as this stack alignment is >>> performed in a few >>> places in ./cpu/x86/vm/macroAssembler_x86.cpp >>> with no OS >>> specific differences being considered. >>> >>> >>> Looks like MacroAssembler::call_VM_leaf_base() does >>> the "right >>> thing" >>> for stack alignment in the X64 case. Perhaps we >>> need to audit both >>> stack alignment _and_ uses of >>> MacroAssembler::call() just to make >>> sure... >>> >>> Did I mention that all the assembly code stuff >>> gives me a >>> headache? :-) >>> >>> Dan >>> >>> >>> >>> >>> Thanks, >>> David >>> >>> Regards, Thomas >>> >>> >>> https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx >>> >>> windows x64 Abi requires the >>> register parameter >>> area right above the >>> return address on the stack. It >>> is not >>> guaranteed to be >>> preserved during >>> the function call: >>> >>> "Even if the called function has >>> fewer than 4 >>> parameters, these >>> 4 stack >>> locations are effectively owned by >>> the called >>> function, and may >>> be used >>> by the called function for other >>> purposes besides >>> saving parameter >>> register values. Thus the caller >>> may not save >>> information in >>> this region >>> of stack across a function call." >>> >>> So, restoring parameters from it >>> may not work if >>> Thread::current() uses >>> this area for any reason. In this >>> case, r9, rsp, >>> r10, r11 may be >>> overwritten by the callee. >>> >>> I also think Windows x64 ABI is >>> different enough >>> from Linux that >>> this >>> function could live somewhere in >>> _. >>> >>> >>> This is a valid point. However, note >>> that this is >>> similar to the >>> issue we have for instance in 'shared' >>> MacroAssembler::call_VM_leaf_base, >>> which was not put in >>> _ >>> files. >>> >>> In fact, the right fix may be to use >>> call_VM_leaf >>> instead of call :-) >>> >>> (alternatively we could use "#ifdef >>> _WIN64" or check >>> "frame::arg_reg_save_area_bytes != 0", >>> which may be >>> even cleaner and >>> more portable) >>> >>> All these solutions are fine for me. >>> >>> >>> Since we are near to feature freeze, >>> this should >>> probably be done in >>> a separate CR (unless David has enough >>> time to test >>> it). >>> >>> Regards, >>> >>> Bertrand. >>> >>> >>> Kind Regards, Thomas >>> >>> >>> >>> >>> On Mon, Nov 23, 2015 at 10:42 PM, >>> David Holmes >>> >> >>> >> > >>> >> >>> >> >> >>> >> >>> >> > >>> >> >>> >> >>>> wrote: >>> >>> On 23/11/2015 11:46 PM, >>> Bertrand Delsart >>> wrote: >>> >>> On 23/11/2015 13:27, >>> David Holmes wrote: >>> >>> Hi Bertrand, >>> >>> On 23/11/2015 8:14 >>> PM, Bertrand >>> Delsart wrote: >>> >>> Hi David, >>> >>> Overall looks >>> good. >>> Thanks for the >>> #ifndef >>> USE_LIBRARY_BASED_TLS_ONLY :-) >>> >>> One doubt, in >>> case this has not >>> been discussed >>> before. >>> >>> I'm still >>> catching up on x86_64 >>> (after years of ARM >>> assembly :-)) >>> but it >>> seems that there >>> are some stack >>> alignment >>> constraints on >>> runtime calls, >>> at least for some >>> x86_64 ABIs. >>> >>> Some of the x86 >>> MacroAssembler::get_thread >>> implementations >>> had code to >>> align the stack >>> before calling >>> pthread_getspecific. See >>> for instance >>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html >>> >>> >>> >>> >>> >>> Sorry I'm not that >>> familiar with the >>> MacroAssembler >>> - is it >>> this odd >>> fragment: >>> >>> - push(r10); >>> - // XXX >>> - mov(r10, rsp); >>> - andq(rsp, -16); >>> - push(r10); >>> >>> I'm not at all clear >>> what that is >>> doing - and if it >>> somehow >>> changes the >>> alignment wouldn't >>> something need to >>> be fixed up when >>> popping the >>> previous values ?? >>> >>> To be honest I'm not >>> even sure what an >>> "unaligned >>> stack" means. >>> >>> >>> On some platforms, SP may >>> have to be >>> aligned on a 16 bytes >>> boundary when >>> calling another method. >>> >>> >>> Okay - that seems to be an >>> x64 ABI requirement >>> based on >>> other code >>> in MacroAssembler. The reason >>> it is missing in >>> the Solaris >>> code is >>> because I already removed it >>> in the earlier >>> changes that >>> were done >>> on Solaris: >>> >>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10 >>> >>> and nobody picked it up. :( >>> >>> That said, the absence of >>> this code has not >>> caused any >>> problems so >>> presumably we are normally >>> aligned. >>> >>> After having pushed what >>> needed to be >>> saved, the code above >>> rounds SP >>> down and saves the old >>> value. It will then >>> also push >>> r11, which >>> results >>> in the expected >>> alignment. >>> >>> The conterpart, after the >>> VM call, is the: >>> pop(r11); >>> pop(rsp); >>> >>> >>> I had assumed this extra >>> manipulation was >>> related to >>> pushing the arg >>> for the call. >>> >>> This alignment is >>> no longer >>> performed in the new >>> (shared) >>> implementation >>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html >>> >>> >>> >>> >>> >>> >>> Now, Solaris was >>> not performing >>> the alignment and >>> Windows has a >>> separate >>> path for x86_64. >>> Did we really >>> need the >>> alignment for >>> linux x86_64 and >>> bsd_x86_64 ? >>> Might it be needed >>> for other ports ? >>> >>> IMHO, it might be >>> safer to align >>> the stack by >>> default, >>> knowing it should >>> not be expensive >>> since we call >>> get_thread >>> rarely for >>> x86_64 (result is >>> cached in r15). >>> I'll let you see >>> whether it is >>> worth >>> adding an >>> ifdef so >>> as to explicitly >>> deactivate the >>> alignment on >>> some platforms >>> (solaris_x86_64 ?) >>> >>> >>> I don't have enough >>> knowledge to even >>> begin to >>> comment on >>> this. I will >>> have to rely on our >>> x86_64 >>> macroassembler experts >>> to explain >>> the old >>> code and what the >>> requirements are. >>> >>> >>> OK. This means that the >>> alignment was not >>> removed >>> purposefully. >>> >>> In that case, you must >>> either keep the per >>> platform >>> code x86_64 >>> (since >>> it was not identical for >>> all platforms) or >>> use the safest >>> version, with >>> the additional >>> >>> // XXX >>> mov(r10, rsp); >>> andq(rsp, -16); >>> push(r10); >>> >>> before the push(r11) and >>> with the >>> >>> pop(rsp); >>> >>> after the pop(r11). It >>> should work on all >>> x86_64 platforms. >>> >>> >>> Right, I will add this back >>> to the code - and >>> replace the >>> meaningless // XXX with an >>> actual comment! >>> >>> Many thanks, >>> David >>> ----- >>> >>> >>> FYI, there is another way >>> to do the >>> alignment, based on >>> the fact >>> that >>> we are at least aligned >>> on 8 bytes (see >>> MacroAssembler::call_VM_leaf_base). I >>> assume that this >>> second >>> version is >>> more efficient >>> (particularly thanks to >>> specilative >>> branches) but it >>> might be safer/simpler to >>> continue using >>> andq in >>> get_thread. >>> >>> Bertrand. >>> >>> >>> Thanks, >>> David >>> >>> Regards, >>> >>> Bertrand. >>> >>> >>> >>> On 23/11/2015 >>> 08:03, David Holmes >>> wrote: >>> >>> After all the >>> preliminary >>> discussions here >>> are final >>> proposed changes: >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-8132510 >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/ >>> >>> A simple (in >>> principle) but >>> wide-ranging change >>> which should >>> appeal to >>> our Code >>> Deletion Engineer's. >>> We implement >>> >>> Thread::current() using a >>> compiler/language-based >>> thread-local >>> variable eg: >>> >>> static >>> __thread Thread >>> *_thr_current; >>> >>> inline Thread* >>> Thread::current() { >>> return >>> _thr_current; >>> } >>> >>> with an >>> appropriate setter of >>> course. By >>> doing this >>> we can >>> completely >>> remove the >>> os_cpu-specific >>> ThreadLocalStorage >>> >>> implementations, and the >>> associated >>> os::thread_local_storage* calls. >>> >>> As __thread >>> is not >>> async-signal-safe (either in >>> theory or >>> practice) we >>> need a >>> fallback library-based >>> solution as used >>> today. For >>> this we use a >>> very simple >>> ThreadLocalStorage >>> class and an >>> >>> implementation thereof for >>> POSIX (covers >>> AIX, BSD, Linux, >>> OSX and >>> Solaris) using >>> pthread_get/setspecific; and >>> one for >>> Windows using >>> its TLS >>> library. >>> While these >>> library routines >>> are not guaranteed >>> >>> async-signal-safe, they >>> seem to be in >>> practice and are >>> what we have >>> been >>> using all >>> along. >>> >>> We also allow >>> for use of >>> only the >>> library-based TLS >>> for platforms >>> where >>> >>> compiler-based thread locals >>> are not >>> supported (as >>> will be >>> needed in >>> the >>> Mobile >>> project). This is >>> enabled at build >>> time by >>> defining >>> USE_LIBRARY_BASED_TLS_ONLY. >>> >>> Thanks to >>> Andrew Haley for >>> providing the >>> Aarch64 >>> code; and for >>> Thomas >>> Stuefe for >>> testing PPC and >>> AIX. >>> >>> Testing: >>> - JPRT >>> (core platforms) >>> - Jtreg >>> tests (linux & >>> solaris) >>> - >>> vm.runtime (core >>> platforms) >>> >>> Performance: >>> - still >>> TBD - this is >>> proving to be >>> extremely >>> difficult. If >>> anyone >>> has >>> any simple >>> to run >>> microbenchmarks to >>> suggest I'd >>> give them a >>> try as a >>> sanity check. >>> But I lack >>> access to hardware for >>> running serious >>> benchmarking. >>> >>> Footprint: >>> - varies by >>> platform and the >>> VM (server, >>> client, >>> minimal) >>> - worst-case: >>> ~1% increase for >>> server VM >>> and minimal VM >>> - best-case: >>> 0.4% decrease >>> for client VM >>> >>> Thanks, >>> David >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Bertrand Delsart, >>> Grenoble >>> Engineering Center >>> Oracle, 180 av. de l'Europe, >>> ZIRST de >>> Montbonnot >>> 38330 Montbonnot Saint Martin, FRANCE >>> bertrand.delsart at oracle.com >>> >>> >> > >>> >> >>> >> >> >>> Phone : +33 4 76 18 81 23 >>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> NOTICE: This email message is for the >>> sole use of the >>> intended >>> recipient(s) and may contain >>> confidential and >>> privileged >>> information. Any unauthorized >>> review, use, >>> disclosure or >>> distribution is prohibited. If you are >>> not the intended >>> recipient, >>> please contact the sender by reply >>> email and destroy >>> all copies of >>> the original message. >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> >>> >>> >>> >>> > From sangheon.kim at oracle.com Tue Dec 1 23:55:46 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Tue, 1 Dec 2015 15:55:46 -0800 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <565DEC2D.3010308@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> <565DEC2D.3010308@oracle.com> Message-ID: <565E3382.7050502@oracle.com> Hi Tom, Thank you for this kind analysis! On 12/01/2015 10:51 AM, Tom Benson wrote: > Hi Sangheon, > > On 11/30/2015 6:51 PM, sangheon.kim wrote: >> Hi Tom, >> >> Thank you for reviewing this! >> >> On 11/30/2015 02:46 PM, Tom Benson wrote: >>> Hi Sangheon, >>> >>> I think there's a problem with using the same routine to check >>> HeapBaseMinAddress as is used for checking heap size in >>> commandLineFlagConstraintsGC.cpp. I tried running this, to make sure >>> I understood what it was trying to do. When I specified something >>> too large for HeapBaseMinAddress, the check reported that the value >>> must be greater than or equal to maximum value N. >> Sorry Tom, I can't understand. >> Currently we print the error message if its value is too large like, >> "must be less than or equal to aligned maximum value (xxx)". >> Do you mean it should be 'address' instead of 'value'? > > What I meant was that I got an internal error when I used the value > the message recommended, so perhaps the value should be further > constrained. I see. > >> I thought it is okay. >> >>> Re-running with that (still huge) value, I get a fatal internal >>> error out of virtualspace.cpp. (In the debug version, an assertion >>> in universe.cpp triggers before reaching this point). EG: >> I am trying to reproduce this assert but I can't. Do you have more >> information to reproduce this? >> I did -version and running GCOld to trigger GC. >> >> java -XX:HeapBaseMinAddress=18446744073642442752 -version >> java -XX:HeapBaseMinAddress=18446744073642442752 GCOld 20 200 10 100 >> 5000 >> > > You probably didn't hit the problem because you're running on a > smaller memory system than I am. On the system I'm on, the > (computed) max heap size is 32G. And if you specify an Xmx, you > don't go through the code path that causes it. Okay, my machine is 32G but when I test on bigger memory machine, I could see the assert. Thank you. > > Here's the root of the problem. In Arguments::set_heap_size(), we > have this code: > > if (FLAG_IS_DEFAULT(MaxHeapSize)) { > . . . > if (UseCompressedOops) { > // Limit the heap size to the maximum possible when using > compressed oops > julong max_coop_heap = (julong)max_heap_for_compressed_oops(); > . . . > if (HeapBaseMinAddress + MaxHeapSize < max_coop_heap) { > <======== *** PROBLEM IS HERE *** > // Heap should be above HeapBaseMinAddress to get zero based > compressed oops > // but it should be not less than default MaxHeapSize. > max_coop_heap -= HeapBaseMinAddress; > } > reasonable_max = MIN2(reasonable_max, max_coop_heap); > } > > HeapBaseMinAddress is 64-bit unsigned, and in this case is > 0xfffffffffc000000 (the 18446744073642442752 from the command line). > MaxHeapSize is 0x7CCCCC8 and max_coop_heap is 0x7FE000000. The > addition of HeapBaseMinAddress and MaxHeapSize overflows to > 0x3ccccc8. Since this is less than 0x7FE000000, we subtract the > 0xfffffffffc000000 from max_coop_heap, getting the result > 0x802000000. reasonable_max is 0x800000000, so it stays at that > value after the MIN2, rather than being reduced as it should be. > > Changing the conditional to also check for overflow avoids the > problem. But of course you don't get the requested > HeapBaseMinAddress anyway, since it's too high. > > So another approach would be to change your constraint to ensure that > (HeapBaseMinAddress plus MaxHeapSize) won't overflow. I don't think > there's any point in allowing a HeapBaseMinAddress so high that it would. Okay, I'm thinking about this. I will post a new webrev after testing. * I also read your other email that fixing constraint function makes sense. ** I already fixed your previous comment of extraneous single quote in commandLineFlagConstraintsGC.cpp at line 510. Thanks, Sangheon > > Tom > >> Thanks, >> Sangheon >> >> >>> >>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=0xffffffffffffffff >>> -version >>> HeapBaseMinAddress (18446744073709551615) must be less than or equal >>> to aligned maximum value (18446744073642442752) >>> Error: Could not create the Java Virtual Machine. >>> Error: A fatal exception has occurred. Program will exit. >>> >>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=18446744073642442752 >>> -version >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error (virtualspace.cpp:456), pid=10359, tid=10360 >>> # guarantee(size + noaccess_prefix_size(alignment) <= >>> OopEncodingHeapMax) failed: can not allocate compressed oop heap for >>> this size >>> # >>> >>> Perhaps you should check only the alignment in the constraint code, >>> without checking the range, because I'm not sure you have the final >>> heap size at that point. Then maybe the heap reservation code >>> should report this as a non-internal error, at the point where the >>> assertion occurs, if the user specified a base address. >>> >>> There's also an extraneous single quote in >>> commandLineFlagConstraintsGC.cpp in the comment at line 510. >>> >>> Tom >>> >>> >>> Date: Tue, 24 Nov 2015 06:37:41 -0800 >>> From: "sangheon.kim" >>> To: Dmitry Dmitriev, >>> "hotspot-dev at openjdk.java.net Developers" >>> >>> Subject: Re: RFR(S): 8142341: GC: current flags need ranges to be >>> implemented >>> Message-ID:<56547635.9060808 at oracle.com> >>> Content-Type: text/plain; charset=utf-8; format=flowed >>> >>> Hi Dmitry, >>> >>> Thank you for the review! >>> Sure I will update my patch related to your enhancement. >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote: >>> >>>> Hi Sangheon, >>>> >>>> Looks good to me! Thank you for fixing that. I hope that enhancement >>>> will be pushed today(currently in JPRT queue), so please update your >>>> patch after that! >>>> >>>> Thanks, >>>> Dmitry >>>> >>>> On 21.11.2015 0:04, sangheon.kim wrote: >>>>> Hi all, >>>>> >>>>> Could I have a couple of reviews for this change to add explicit >>>>> 'range' for flags? >>>>> >>>>> Previously, we added 'range' when it is needed to avoid assert/crash >>>>> but now explicit 'range' are needed for all flags. >>>>> All flags should have 'range' or 'constraint' at least. >>>>> >>>>> CR:https://bugs.openjdk.java.net/browse/JDK-8142341 >>>>> Webrev:http://cr.openjdk.java.net/~sangheki/8142341/webrev.00 >>>>> Testing: JPRT, RBT >>>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for >>>>> embedded >>>>> >>>>> * Summary >>>>> 1. Added 3 new constraint functions. >>>>> 1) HeapBaseMinAddress: Added to avoid an overflow after align up >>>>> and this flag makes hang up without constraint function. (newly added >>>>> as a part of GC work) >>>>> 2) TLABWasteIncrement: Without this constraint function we don't >>>>> have problems (even many GCs happen). But added to avoid an overflow >>>>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are also >>>>> separate CR for this overflow ( JDK-8143352 ). >>>>> 3) NUMAInterleaveGranularity: Added to avoid an overflow after >>>>> align up. >>>>> >>>>> 2. Some flags have narrower range than their type. >>>>> 1) Here's the reason why some flags should have different range. >>>>> (same order from globals.hpp) >>>>> {flag type} {flag name}: (range), {comment} >>>>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), >>>>> max_uintx), there is a comment at numa_interleaving_init() that this >>>>> flag should be larger than vm_allocation_granularity(). >>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as >>>>> used for multiplication >>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which >>>>> has 'unsigned int' type input parameter. >>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function which >>>>> has 'unsigned int' type input parameter. >>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function >>>>> which has 'long' type input parameter. >>>>> uintx PausePadding: (0, max_juint), used to set a function which has >>>>> 'unsigned int' type input parameter. >>>>> uintx PromotedPadding: (0, max_juint), used to set a function which >>>>> has 'unsigned int' type input parameter. >>>>> uintx SurvivorPadding: (0, max_juint), used to set a function which >>>>> has 'unsigned int' type input parameter. >>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag >>>>> is divided by 100 I assume this is percentage. >>>>> uintx GCTimeRatio: (0, max_juint), used to set a function which has >>>>> 'unsigned int' type input parameter. >>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint) >>>>> intx PrefetchScanIntervalInBytes: (-1, max_jint) >>>>> intx PrefetchFieldsAhead: (-1, max_jint), I think these 3 Prefetch* >>>>> flags should have same upper limit and looking at their related codes >>>>> 'max_jint' seems appropriate ( no problem with 'max_jint' during >>>>> testing). However, as Prefetch::read/write() needs 'intx', 'intx' >>>>> also seems good but we have to fix some codes (maybe including >>>>> generated codes). >>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function which >>>>> has 'unsigned int' type input parameter. >>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint >>>>> variable and used 'for loop' which has uint increment. i.e. for (uint >>>>> i=0; i>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at >>>>> 'increment for loop()' as max value and the increment is uint. >>>>> uintx CMSYieldSleepCount: (0, max_juint), used at 'increment for >>>>> loop()' as max value and the increment is uint. >>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return value >>>>> of uint type function and for division. i.e. uint >>>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return >>>>> TLABRefillWasteFraction; } >>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int) >>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we only >>>>> use " if (a !=0, >0, >1)". >>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we only >>>>> use " if (a !=0, >0, >1)". >>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only use >>>>> " if (a !=0, >0)". >>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned >>>>> int' >>>>> >>>>> (g1_globals.hpp) >>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int) >>>>> type variable. >>>>> >>>>> 3. Excluded flags from TestOptionsWithRanges.java >>>>> 1) Memory and thread related flags: tests for these flags will >>>>> consume too many resources from the system. >>>>> 2) VMThreadStackSize: range work for this flag is not included in >>>>> this patch but I faced OOME several times, so excluded. >>>>> >>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] >>>>> TestOptionsWithRanges: allow excluding only a subset of tested values >>>>> specified for a flag) next time. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>> >> > From paul.sandoz at oracle.com Wed Dec 2 08:52:12 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Dec 2015 09:52:12 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> Message-ID: <9C417D00-F022-4CF6-87D3-0AF74CCD7441@oracle.com> Hi Christian, > On 1 Dec 2015, at 20:19, Christian Tornqvist wrote: > > Hi Paul, > > Tests in hotspot/test/runtime needs to be jtreg tests. They are jtreg tests. They are require to be run (re: ?launched") with jtreg see: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/JdkInternalMiscUnsafeAccessTestBoolean.java.html 24 /* 25 * @test 26 * @bug 8143628 27 * @summary Test unsafe access for boolean 28 * @modules java.base/jdk.internal.misc 29 * @run testng/othervm -Diters=100 -Xint JdkInternalMiscUnsafeAccessTestBoolean 30 * @run testng/othervm -Diters=20000 -XX:TieredStopAtLevel=1 JdkInternalMiscUnsafeAccessTestBoolean 31 * @run testng/othervm -Diters=20000 -XX:-TieredCompilation JdkInternalMiscUnsafeAccessTestBoolean 32 * @run testng/othervm -Diters=20000 JdkInternalMiscUnsafeAccessTestBoolean 33 */ That?s the point i was making with: jtreg is to testng as launcher is to library Note the use of the "@modules java.base/jdk.internal.misc?. That?s gonna be important later on. > Looking at your tests, I can't see a reason why they can't easily be modified to be jtreg tests instead? That?s not the point. There is a principle here about what test libraries one can or cannot use with the test in a particular area of a particular repo. At the moment i am not hearing any consistent and solid technical argument as to why testng cannot be used for HotSpot runtime tests. Paul. From paul.sandoz at oracle.com Wed Dec 2 08:54:07 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Dec 2015 09:54:07 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <565DF808.7060806@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <565DF808.7060806@oracle.com> Message-ID: Hi Coleen, > On 1 Dec 2015, at 20:42, Coleen Phillimore wrote: >> >> ? >> >> Would i be correct in stating that the HotSpot runtime team is taking a conservative position and does not want to deal with such a library, contrary to other areas of the JDK? > > Yes. That is correct. We don't need more frameworks that hinder getting to the java command line for the class file. It's time consuming enough with jtreg. So is the real underlying reason is you don?t want to run the tests *locally* with jtreg at all? (Note that jtreg spits out a script that one can use to re-run faster.) At some point later these tests will be even more dependent on jtreg because they have an internal dependency on Unsafe and jtreg will wire up things correctly to bust through the encapsulation, as these are white box tests. >> >> Sorry to push back, but I don?t agree with that position (if correct). I am reluctant to change the tests. Please don?t think that complete pigheadedness on my part :-) I just don?t think it?s the right thing to do. >> >> If the HotSpot runtime team will not accept the use of TestNG then I suppose I could unblock by proposing to move the tests to the JDK repo, which I would also be reluctant to do since they caught an issue lying dormant for at least 8 years on certain platforms (not covered by the core testset) that existing hotspot tests never caught. > > Can you repost the whole webrev to hotspot-dev ? I didn't see the original to see why these tests require the testng framework and cannot be written as simple regression tests. If they have to be very complex, maybe they belong in a different test directory that has support and tolerance for this complexity. Maybe you can write a small regression test for the hotspot/test/runtime test and put the rest somewhere else. Again, this is in the abstract. I don't have the webrev. > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/webrev/ It?s not just about complexity, it?s also about better test code, consistency and reporting. It feels strange to be arguing for the utilisation of a unit test library. Most of the world moved on over 15 years ago :-) and most of the JDK has already moved on. Paul. From volker.simonis at gmail.com Wed Dec 2 10:19:25 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 Dec 2015 11:19:25 +0100 Subject: RFR(L): 8143125: [aix] Further Developments for AIX In-Reply-To: <4295855A5C1DE049A61835A1887419CC41ED242C@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41ED076B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41ED242C@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Thomas, thanks a lot for this nice cleanup. Please find my remaining comments below: libo4.hpp ======= - please update the copyright year - remove the following comments which reference SAP path or bugs 45 // See libo4.h (at //bas2/sapjvm/dev/common/libs/libo4/include) 46 // for details on this API. 59 // See libo4.h (at //bas2/sapjvm/dev/common/libs/libo4/include) 60 // for details on this API. 72 // See also CSN Internal Message 0001182318 2008 73 // 74 // See libo4.h (at //bas2/sapjvm/dev/common/libs/libo4/include) 75 // for details on this API. libo4.cpp ======= - please update the copyright year vmStructs_aix_ppc.hpp ================= - please update the copyright year misc_aix.hpp ========== - "trc" is defined to the empty string and doesn't seemed to be used anywhere: 45 #define trc(fmt, ...) do we still need it? os_aix.cpp ======== - why do we need the following define right in-between the includes: 76 #include "utilities/defaultStream.hpp" 77 #define PV_8_Compat 0x308000 /* Power PC 8 */ 78 #include "utilities/events.hpp" it doesn't seem to be used in os_aix.cpp - you replaced most of the logging with trcVerbose but there are still tow or three places using fprintf and jio_fprintf. Could you please replace them by calls to trcVerbose as well. - I can't see where the kernel thread id is initialized. Shouldn't you call set_kernel_thread_id() from os::create_thread and os::create_attached_thread() ? - in os::commit_memory() are you sure you always have 4K pages: 2342 if (UseExplicitCommit) { 2343 // AIX commits memory on touch. So, touch all pages to be committed. 2344 for (char* p = addr; p < (addr + size); p += SIZE_4K) { 2345 *p = '\0'; 2346 } 2347 } wouldn?t it be better (i.e. potentially faster) to use os::vm_page_size() instead of SIZE_4K ? - it doesn't seem we use '_large_page_size'. We statically initialize it to '0' and later on in os::init() to '-1'. Better remove it and directly return '0' (or '-1') from os::large_page_size(). libperfstat_aix.{cpp, hpp} ================== - please update the copyright year - I want to second Goetz - we really don't need perfstat_cpu_total_t_52. Please remove it from both libperfstat_aix.{cpp, hpp} loadlib_aix.cpp ================== - please update the copyright year misc_aix.{hpp,cpp} ============== - I don't see why we need MiscUtils::describe_errno(). Can you please instead use strerror() to get the error message (as we already do in a lot of other places, e.g. in os_aix.cpp). That said, I realized that strerror() is not thread-safe. So we should probably change it to the POSIX function strerror_r(). But this is not only an AIX problem, so better do that in a follow up change. - the same holds true for MiscUtils::sleep_ms(). Why do we need yet another AIX-specific helper function? Moreover, it is used only once. Can you please instead use usleep() or sleep() directly, depending on how long you want to wait. (Just as a side note: your current implementation of sleep_ms() would sleep for three seconds if called with 1000ms as argument, and it would call usleep() with an argument of 1.000.000 which should be avoided according to your comment (which I couldn't verify in the AIX man-page (see https://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.basetechref/doc/basetrf2/sleep.htm))). So please remove MiscUtils::sleep_ms(). There's no need to provide a new webrev, if you check that the your latest changes will build and run. Thank you and best regards, Volker On Thu, Nov 26, 2015 at 9:29 AM, Lindenmaier, Goetz wrote: > Hi Thomas, > > thanks a lot for doing all these changes. > Looks good now. > > Could you add the change comment to the patch before you > Make a webrev next time? Simplifies sponsoring ;) > > Best regards, > Goetz. > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Mittwoch, 25. November 2015 18:01 > To: Lindenmaier, Goetz > Cc: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers > Subject: Re: RFR(L): 8143125: [aix] Further Developments for AIX > > Hi Goetz, > > new webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8143125-Further/webrev.01/webrev/ > > thank you for reviewing! See remarks inline... > > On Tue, Nov 24, 2015 at 12:38 PM, Lindenmaier, Goetz > wrote: > Hi Thomas, > > I looked at your change. It?s good we get these improvements into > openJDK. But I think we should skip some stuff that's not (yet?) > used there. I'll sponsor the change. Details: > > libperfstat_aix.cpp: > > What do you need > static fun_perfstat_partition_total_t g_fun_perfstat_partition_total = NULL; > static fun_perfstat_wpar_total_t g_fun_perfstat_wpar_total = NULL; > static fun_wpar_getcid_t g_fun_wpar_getcid = NULL; > for? I think they are never used. > > They are now used (for the respective wrapper functions which in turn are used in os_aix.cpp. Sorry for omitting this code. > > libperfstat_aix.cpp:161 > We support AIX 5.3 with xlC12 only. I think we need not add the older > #defines to openJDK. Also, the comment should be adapted and not mention xlc8 etc. > Also, there are datastructures for 5.2 which can be removed. > > Removed the older defines. > I would for now prefer to leave the AIX 5.2 data structures in this file. I am not sure if we could encounter older libperfstat versions on AIX 5.3 too. I plan to rework this coding to get rid of the duplicate structure definitions, but would prefer to do this in a separate patch. > > > Where is this used? > bool libperfstat::get_wparinfo(wparinfo_t* pwi) > Do we need it if it's not used? > > It is now used :) in os_aix.cpp. > > > libperfstat.hpp:835 > I would remove these prototypes commented out. > > I removed them. > > loadlib_aix.cpp > Why do you do these changes? Please revert them. > > I reverted them. > > os_aix.hpp:219 > What's this good for? > get_brk_at_startup() > get_lowest_allocation_above_brk() > > I removed those prototypes. > > os_aix.hpp:259 > What's this good for? > parse_qsyslib_path() > > I removed this prototype. > > os_aix.cpp:410 > Why do you move query_multipage_support()? > > I moved this back to its original position. > > os_aix.inline.hpp:164 > Why do you reverse the order of the functions here? > The old order is the same as in the related files os_linux.inline.hpp etc. > > I reversed the order back to original order. > > Best regards, > Goetz. > > > Kind Regards, Thomas > > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Thomas St?fe >> Sent: Freitag, 20. November 2015 11:49 >> To: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers >> Subject: RFR(L): 8143125: [aix] Further Developments for AIX >> >> Hi all, >> >> please review and sponsor these AIX only changes. Basically, with this >> change we bring the OpenJDK AIX hotspot port up to speed with the >> developments done at SAP in the recent months. >> >> For a more detailled number of changes and fixes, please refer to the bug >> description. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8143125 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8143125- >> Further/webrev.00/webrev/index.html >> >> Kind Regards, Thomas > From dmitry.dmitriev at oracle.com Wed Dec 2 14:22:29 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 2 Dec 2015 17:22:29 +0300 Subject: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework needs to handle VM error codes in some cases In-Reply-To: <56557442.2080408@oracle.com> References: <56557442.2080408@oracle.com> Message-ID: <565EFEA5.9010605@oracle.com> Hello, Please, can I get Review for that fix? Thank you! Dmitry On 25.11.2015 11:41, Dmitry Dmitriev wrote: > Hello, > > Please review this small enhancement to the command line options > validation test framework. This enhancement allow to specify allowed > exit code for flags. This is needed for CDS Shared flags, because in > some cases JVM can exit with error code 2 and this should not be > treated as error. Also, in this fix I refactor code which parse Shared > flags - specify explicit names of the flags in switch statement and > use only one CDS archive file. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8142874 > webrev: http://cr.openjdk.java.net/~ddmitriev/8142874/webrev.01/ > > Testing: tested on all platforms by RBT > > Thanks, > Dmitry From ioi.lam at oracle.com Wed Dec 2 14:30:35 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 02 Dec 2015 06:30:35 -0800 Subject: RFR (S) 8144491 ElfSymbolTable::lookup returns bad value Message-ID: <565F008B.1060405@oracle.com> Please review a small fix: http://cr.openjdk.java.net/~iklam/8144491-ElfSymbolTable-lookup/ Bug: ElfSymbolTable::lookup returns bad value when the lookup has failed https://bugs.openjdk.java.net/browse/JDK-8144491 Summary of fix: I found this when trying to make disassembler.cpp print out more symbolic information for PrintInterpreter. The fix is straight-forward -- if the lookup fails, ElfSymbolTable::lookup should return false. Impact: The only caller to ElfSymbolTable::lookup is ElfFile::decode(), so nothing else would depend on the old (bad) behavior of ElfSymbolTable::lookup. I also took the chance to refactor lookup is ElfFile::decode() to split out two blocks of identical code into a new function, ElfSymbolTable::compare. Tests: JPRT RBT (hotspot/test/:hotspot_all) <-- what other tests should I run? Thanks - Ioi From dl at cs.oswego.edu Wed Dec 2 14:56:24 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 2 Dec 2015 09:56:24 -0500 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <56572F4E.8050603@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu> <56525823.6010506@cs.oswego.edu> <744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com> <56572F4E.8050603@oracle.com> Message-ID: <565F0698.7080600@cs.oswego.edu> Bringing Martin's JEP comment (https://bugs.openjdk.java.net/browse/JDK-8046936) to the lists: Approximately 100% of the cases of StackOverflowError (SOE) we hear about lately on concurrency-interest are due to long chains of CompletableFutures that exist because of the lack of tail-recursion loopification by compilers. I don't think any of these have involved ReentrantLocks, but some hit problems due to lack of finally { ... } cleanup inside Executors upon SOE. In the absence of any of: tail-recursion support, reliable cleanup, or growable stacks, it seems reasonable to choose larger default stack sizes so that these long but finite chains of completions are far less likely to hit SOE. On 32bit systems the 1MB limit is completely defensible. But expanding to say 64MB on 64bit systems would reduce practical encounters with SOE in these kinds of constructions by a factor of 64 or so. Is there any reason not to do this? -Doug From thomas.stuefe at gmail.com Wed Dec 2 15:03:46 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 2 Dec 2015 16:03:46 +0100 Subject: RFR(xs): 8144343: [aix] Stack bottom should be page aligned Message-ID: Hi all, please review this tiny AIX-only fix. Basically, it takes care of the thread stack bottom - and hence the placement of the guard pages - to be always aligned to os::vm_page_size() . bug: https://bugs.openjdk.java.net/browse/JDK-8144343 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8144343-aix-stack-bottom-align/webrev.00/webrev/ Kind Regards, Thomas From aph at redhat.com Wed Dec 2 15:07:26 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 2 Dec 2015 15:07:26 +0000 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <565F0698.7080600@cs.oswego.edu> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu> <56525823.6010506@cs.oswego.edu> <744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com> <56572F4E.8050603@oracle.com> <565F0698.7080600@cs.oswego.edu> Message-ID: <565F092E.2060807@redhat.com> On 12/02/2015 02:56 PM, Doug Lea wrote: > On 32bit systems the 1MB limit is completely defensible. But expanding > to say 64MB on 64bit systems would reduce practical encounters with > SOE in these kinds of constructions by a factor of 64 or so. > Is there any reason not to do this? Some cloud VMs do not over-commit memory. This means they make sure that all of the memory which is allocated really is available. On such systems, pre-allocating 64M would be a Bad Thing. Andrew. From volker.simonis at gmail.com Wed Dec 2 15:32:01 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 Dec 2015 16:32:01 +0100 Subject: RFR(xs): 8144343: [aix] Stack bottom should be page aligned In-Reply-To: References: Message-ID: Hi Thomas, the change looks good. Just some minor comments (regarding the comments :) - what's the meaning of the comment (i.e. the question marks) in line 4348 4348 // high addr --------------------- real base ? at page border ? - you removed the link from line 4342 so please also remove "see also" from line 4350. Thanks, Volker On Wed, Dec 2, 2015 at 4:03 PM, Thomas St?fe wrote: > Hi all, > > please review this tiny AIX-only fix. Basically, it takes care of the > thread stack bottom - and hence the placement of the guard pages - to be > always aligned to os::vm_page_size() . > > bug: https://bugs.openjdk.java.net/browse/JDK-8144343 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8144343-aix-stack-bottom-align/webrev.00/webrev/ > > Kind Regards, Thomas From thomas.stuefe at gmail.com Wed Dec 2 15:49:10 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 2 Dec 2015 16:49:10 +0100 Subject: RFR(xs): 8144343: [aix] Stack bottom should be page aligned In-Reply-To: References: Message-ID: Hi Volker, thank you for the review! I changed the offending comments: http://cr.openjdk.java.net/~stuefe/webrevs/8144343-aix-stack-bottom-align/webrev.01/webrev/ Kind Regards, Thomas On Wed, Dec 2, 2015 at 4:32 PM, Volker Simonis wrote: > Hi Thomas, > > the change looks good. Just some minor comments (regarding the comments :) > > - what's the meaning of the comment (i.e. the question marks) in line 4348 > > 4348 // high addr --------------------- real base ? at page border ? > > - you removed the link from line 4342 so please also remove "see also" > from line 4350. > > Thanks, > Volker > > > > On Wed, Dec 2, 2015 at 4:03 PM, Thomas St?fe > wrote: > > Hi all, > > > > please review this tiny AIX-only fix. Basically, it takes care of the > > thread stack bottom - and hence the placement of the guard pages - to be > > always aligned to os::vm_page_size() . > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8144343 > > webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8144343-aix-stack-bottom-align/webrev.00/webrev/ > > > > Kind Regards, Thomas > From stefan.sarne at oracle.com Wed Dec 2 16:20:42 2015 From: stefan.sarne at oracle.com (=?UTF-8?Q?Stefan_S=c3=a4rne?=) Date: Wed, 2 Dec 2015 17:20:42 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <9C417D00-F022-4CF6-87D3-0AF74CCD7441@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <9C417D00-F022-4CF6-87D3-0AF74CCD7441@oracle.com> Message-ID: <565F1A5A.4040509@oracle.com> Hi Paul, The reason we stick on standard jtreg tests is because it is simpler. For us, a java test is not a unit test, it is an application. :) I agree with you that when writing and debugging java code, I would choose testng over jtreg and run and debug it inside my java IDE. But debugging the VM is instead done with a native debugger and what the framework gives you for java development, becomes a level of indirection in VM land. Just adding the test class as argument to the java launcher where a main method exists is preferred. Cheers, Stefan Den 2015-12-02 kl. 09:52, skrev Paul Sandoz: > Hi Christian, > >> On 1 Dec 2015, at 20:19, Christian Tornqvist >> > > wrote: >> >> Hi Paul, >> >> Tests in hotspot/test/runtime needs to be jtreg tests. > > They are jtreg tests. They are require to be run (re: ?launched") with > jtreg see: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/JdkInternalMiscUnsafeAccessTestBoolean.java.html > > 24 /* > 25 * @test > 26 * @bug 8143628 > 27 * @summary Test unsafe access for boolean > 28 * @modules java.base/jdk.internal.misc > 29 * @run testng/othervm -Diters=100 -Xint JdkInternalMiscUnsafeAccessTestBoolean > 30 * @run testng/othervm -Diters=20000 -XX:TieredStopAtLevel=1 JdkInternalMiscUnsafeAccessTestBoolean > 31 * @run testng/othervm -Diters=20000 -XX:-TieredCompilation JdkInternalMiscUnsafeAccessTestBoolean > 32 * @run testng/othervm -Diters=20000 JdkInternalMiscUnsafeAccessTestBoolean > 33 */ > > That?s the point i was making with: > > jtreg is to testng as launcher is to library > > Note the use of the "@modules java.base/jdk.internal.misc?. That?s > gonna be important later on. > > >> Looking at your tests, I can't see a reason why they can't easily be >> modified to be jtreg tests instead? > > That?s not the point. There is a principle here about what test > libraries one can or cannot use with the test in a particular area of > a particular repo. At the moment i am not hearing any consistent and > solid technical argument as to why testng cannot be used for HotSpot > runtime tests. > > Paul. From stefan.karlsson at oracle.com Wed Dec 2 16:48:16 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 2 Dec 2015 17:48:16 +0100 Subject: RFR (S) 8144491 ElfSymbolTable::lookup returns bad value In-Reply-To: <565F008B.1060405@oracle.com> References: <565F008B.1060405@oracle.com> Message-ID: <565F20D0.2020102@oracle.com> Hi Ioi, On 2015-12-02 15:30, Ioi Lam wrote: > Please review a small fix: > > http://cr.openjdk.java.net/~iklam/8144491-ElfSymbolTable-lookup/ > > Bug: ElfSymbolTable::lookup returns bad value when the lookup has failed > > https://bugs.openjdk.java.net/browse/JDK-8144491 > > Summary of fix: > > I found this when trying to make disassembler.cpp print out more > symbolic > information for PrintInterpreter. > > The fix is straight-forward -- if the lookup fails, > ElfSymbolTable::lookup > should return false. > > Impact: > The only caller to ElfSymbolTable::lookup is ElfFile::decode(), so > nothing > else would depend on the old (bad) behavior of > ElfSymbolTable::lookup. > > I also took the chance to refactor lookup is ElfFile::decode() to > split out > two blocks of identical code into a new function, > ElfSymbolTable::compare. The change looks correct. I would prefer if the refactoring was done as a separate patch, but since this is Runtime code I'll let other reviewers decide on that. Thanks, StefanK > > Tests: > > JPRT > RBT (hotspot/test/:hotspot_all) <-- what other tests should I run? > > Thanks > - Ioi From vladimir.kozlov at oracle.com Wed Dec 2 17:19:22 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 2 Dec 2015 09:19:22 -0800 Subject: RFR(xs): 8144343: [aix] Stack bottom should be page aligned In-Reply-To: References: Message-ID: <565F281A.2050706@oracle.com> Looks good. Thanks, Vladimir On 12/2/15 7:49 AM, Thomas St?fe wrote: > Hi Volker, > > thank you for the review! > > I changed the offending comments: > > http://cr.openjdk.java.net/~stuefe/webrevs/8144343-aix-stack-bottom-align/webrev.01/webrev/ > > Kind Regards, Thomas > > On Wed, Dec 2, 2015 at 4:32 PM, Volker Simonis > wrote: > >> Hi Thomas, >> >> the change looks good. Just some minor comments (regarding the comments :) >> >> - what's the meaning of the comment (i.e. the question marks) in line 4348 >> >> 4348 // high addr --------------------- real base ? at page border ? >> >> - you removed the link from line 4342 so please also remove "see also" >> from line 4350. >> >> Thanks, >> Volker >> >> >> >> On Wed, Dec 2, 2015 at 4:03 PM, Thomas St?fe >> wrote: >>> Hi all, >>> >>> please review this tiny AIX-only fix. Basically, it takes care of the >>> thread stack bottom - and hence the placement of the guard pages - to be >>> always aligned to os::vm_page_size() . >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8144343 >>> webrev: >>> >> http://cr.openjdk.java.net/~stuefe/webrevs/8144343-aix-stack-bottom-align/webrev.00/webrev/ >>> >>> Kind Regards, Thomas >> From daniel.daugherty at oracle.com Wed Dec 2 17:54:19 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 2 Dec 2015 10:54:19 -0700 Subject: RFR (S) 8144491 ElfSymbolTable::lookup returns bad value In-Reply-To: <565F20D0.2020102@oracle.com> References: <565F008B.1060405@oracle.com> <565F20D0.2020102@oracle.com> Message-ID: <565F304B.8040204@oracle.com> On 12/2/15 9:48 AM, Stefan Karlsson wrote: > Hi Ioi, > > On 2015-12-02 15:30, Ioi Lam wrote: >> Please review a small fix: >> >> http://cr.openjdk.java.net/~iklam/8144491-ElfSymbolTable-lookup/ >> >> Bug: ElfSymbolTable::lookup returns bad value when the lookup has failed >> >> https://bugs.openjdk.java.net/browse/JDK-8144491 src/share/vm/utilities/elfSymbolTable.hpp L67: bool compare(const Elf_Sym* sym, address addr, int* stringtableIndex, int* posIndex, int* offset, ElfFuncDescTable* funcDescTable); Should funcDescTable be a 'const'? src/share/vm/utilities/elfSymbolTable.cpp L72: bool ElfSymbolTable::compare(const Elf_Sym* sym, address addr, int* stringtableIndex, int* posIndex, int* offset, ElfFuncDescTable* funcDescTable) { Should funcDescTable be a 'const'? Thumbs up! Don't need to see another webrev if you change the const-ness of funcDescTable More below... >> >> Summary of fix: >> >> I found this when trying to make disassembler.cpp print out more >> symbolic >> information for PrintInterpreter. >> >> The fix is straight-forward -- if the lookup fails, >> ElfSymbolTable::lookup >> should return false. >> >> Impact: >> The only caller to ElfSymbolTable::lookup is ElfFile::decode(), >> so nothing >> else would depend on the old (bad) behavior of >> ElfSymbolTable::lookup. >> >> I also took the chance to refactor lookup is ElfFile::decode() to >> split out >> two blocks of identical code into a new function, >> ElfSymbolTable::compare. > > The change looks correct. I would prefer if the refactoring was done > as a separate patch, but since this is Runtime code I'll let other > reviewers decide on that. For JDK9 we've been been doing both: - product changes plus cleanup changes in the same changeset - cleanup changes in one changeset and product changes in another It really depends on how much the cleanup obscures the product change. I don't think this one is too distracting... > > Thanks, > StefanK >> >> Tests: >> >> JPRT >> RBT (hotspot/test/:hotspot_all) <-- what other tests should I run? Dmitry Samersoff might have an opinion here since he tends to do work on the ELF code... and probably knows what tests hit this code. Dan >> >> Thanks >> - Ioi > From ioi.lam at oracle.com Wed Dec 2 18:18:34 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 02 Dec 2015 10:18:34 -0800 Subject: RFR (S) 8144491 ElfSymbolTable::lookup returns bad value In-Reply-To: <565F304B.8040204@oracle.com> References: <565F008B.1060405@oracle.com> <565F20D0.2020102@oracle.com> <565F304B.8040204@oracle.com> Message-ID: <565F35FA.7020200@oracle.com> Dan & Stafan, thanks for the review! - Ioi On 12/2/15 9:54 AM, Daniel D. Daugherty wrote: > On 12/2/15 9:48 AM, Stefan Karlsson wrote: >> Hi Ioi, >> >> On 2015-12-02 15:30, Ioi Lam wrote: >>> Please review a small fix: >>> >>> http://cr.openjdk.java.net/~iklam/8144491-ElfSymbolTable-lookup/ >>> >>> Bug: ElfSymbolTable::lookup returns bad value when the lookup has >>> failed >>> >>> https://bugs.openjdk.java.net/browse/JDK-8144491 > > src/share/vm/utilities/elfSymbolTable.hpp > L67: bool compare(const Elf_Sym* sym, address addr, int* > stringtableIndex, > int* posIndex, int* offset, ElfFuncDescTable* funcDescTable); > Should funcDescTable be a 'const'? > > > src/share/vm/utilities/elfSymbolTable.cpp > L72: bool ElfSymbolTable::compare(const Elf_Sym* sym, address addr, > int* stringtableIndex, int* posIndex, int* offset, > ElfFuncDescTable* funcDescTable) { > > Should funcDescTable be a 'const'? > > Thumbs up! Don't need to see another webrev if you change the > const-ness of funcDescTable > > More below... > >>> >>> Summary of fix: >>> >>> I found this when trying to make disassembler.cpp print out more >>> symbolic >>> information for PrintInterpreter. >>> >>> The fix is straight-forward -- if the lookup fails, >>> ElfSymbolTable::lookup >>> should return false. >>> >>> Impact: >>> The only caller to ElfSymbolTable::lookup is ElfFile::decode(), >>> so nothing >>> else would depend on the old (bad) behavior of >>> ElfSymbolTable::lookup. >>> >>> I also took the chance to refactor lookup is ElfFile::decode() >>> to split out >>> two blocks of identical code into a new function, >>> ElfSymbolTable::compare. >> >> The change looks correct. I would prefer if the refactoring was done >> as a separate patch, but since this is Runtime code I'll let other >> reviewers decide on that. > > For JDK9 we've been been doing both: > > - product changes plus cleanup changes in the same changeset > - cleanup changes in one changeset and product changes in another > > It really depends on how much the cleanup obscures the product > change. I don't think this one is too distracting... > > >> >> Thanks, >> StefanK >>> >>> Tests: >>> >>> JPRT >>> RBT (hotspot/test/:hotspot_all) <-- what other tests should I run? > > Dmitry Samersoff might have an opinion here since he tends to > do work on the ELF code... and probably knows what tests hit > this code. > > Dan > > > >>> >>> Thanks >>> - Ioi >> > From daniel.daugherty at oracle.com Wed Dec 2 18:22:18 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 2 Dec 2015 11:22:18 -0700 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <565DC91B.9060206@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <56548F9B.1000507@oracle.com> <565DC91B.9060206@oracle.com> Message-ID: <565F36DA.4060004@oracle.com> On 12/1/15 9:21 AM, Frederic Parain wrote: > Hi Dan, > > Thank you for your detailed review. > My answers are in-lined below. > > New webrev: > > http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/ Re-reviewed by comparing 8046936.0[12].hotspot.patch in jfilemerge... Just a couple of nits: src/os/windows/vm/os_windows.cpp L2365: assert(fr->safe_for_sender(thread), "Safety check"); Wrong indent; should be 6 spaces instead of 8; actually I think this one is a tab. src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp L381: assert(fr->safe_for_sender(thread), "Safety check"); Wrong indent; this one also might be a tab src/os_cpu/linux_x86/vm/os_linux_x86.cpp L194: assert(fr->safe_for_sender(thread), "Safety check"); Wrong indent; this one also might be a tab src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp L267: assert(fr->safe_for_sender(thread), "Safety check"); Wrong indent; this one also might be a tab src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp L255: assert(fr->safe_for_sender(thread), "Safety check"); Wrong indent; this one also might be a tab Thumbs up! I do not need to see a webrev for the above nits. Dan > > > On 24/11/2015 17:26, Daniel D. Daugherty wrote: >> >> src/cpu/sparc/vm/frame_sparc.cpp >> (old) L635: if (fp() - sp() > 1024 + >> m->max_stack()*Interpreter::stackElementSize) { >> (new) L635: if (fp() - unextended_sp() > 1024 + >> m->max_stack()*Interpreter::stackElementSize) { >> This looks like a bug fix independent of this fix. > > Correct, this is the SPARC version of JDK-8068655. > >> src/share/vm/runtime/thread.hpp >> L953: intptr_t* _reserved_stack_activation; >> L1382: intptr_t* reserved_stack_activation() const { return >> _reserved_stack_activation; } >> L1383: void set_reserved_stack_activation(intptr_t* addr) { >> >> I was expecting this type to be 'address' instead of >> 'intptr_t*'. >> >> Update: I've gone back through the changes and I still don't >> see a reason that this is 'intptr_t*'. > > The _reserved_stack_activation has been declared as an 'intptr_t*' > just to be consistent with the _sp and _fp fields of the frame class. > However, this is not really a requirement, the content stored at the > _reserved_stack_activation address is never read. This address is just > a "marker" on the stack to quickly check if the thread has exited the > annotated code section or not. I've change the type to address, there's > slightly less casts, and it doesn't impact the ReservedStackArea logic. > > Note: I've removed all further comments about _reserved_stack_activation > type in order to improve the e-mail readability. > >> L1341: { return stack_yellow_zone_base();} >> '{' should be at the end of the previous line. >> Missing space after ';'. > > Fixed > >> L1343: { return StackReservedPages * os::vm_page_size(); } >> '{' should be at the end of the previous line. > > Fixed > >> src/share/vm/runtime/thread.cpp >> L2543: // The base notation is from the stacks point of view, >> growing downward. >> L2565: // The base notation is from the stacks point of view, >> growing downward. >> Typo: "stacks point of view" -> "stack's point of view" > > Fixed > >> L2552: } else { >> L2553: warning("Attempt to guard stack reserved zone failed."); >> L2554: } >> L2555: enable_register_stack_guard(); >> >> Should enable_register_stack_guard() be called when we issued >> the warning on L2553? >> >> L2571: } else { >> L2572: warning("Attempt to unguard stack reserved zone >> failed."); >> L2573: } >> L2574: disable_register_stack_guard(); >> >> Should disable_register_stack_guard() be called when we issued >> the warning on L2572? > > enable_register_stack_guard() and disable_register_stack_guard() are > relics of the Itanium code (Itanium had a very different stack > management). These methods are currently empty on all OpenJDK and > Oracle platforms. May be another clean up opportunity here. > Regarding the placement of the calls, I followed the same pattern > as the other red/yellow pages management functions. > >> src/share/vm/runtime/sharedRuntime.cpp >> >> L784: java_lang_Throwable::set_message(exception_oop, >> L785: Universe::delayed_stack_overflow_error_message()); >> Wrong indent; this should line up under the 'e' after the '('. > > Fixed > >> L2976: if (fr.is_interpreted_frame()) { >> L2978: prv_fr = fr; >> L2982: prv_fr = fr; >> This line is in both branches of the if-statement on L2976. >> Is there a reason not to save prv_fr before L2976? > > No particular reason, fixed. > >> L2996 continue; >> Wrong indent; needs one more space. > > Fixed > >> L2958: frame activation; >> L3013: return activation; >> The return on L3013 can return a default constructed 'frame'. >> Is that default safe to return here? > > Yes, the caller performs a check before using the returned > frame: > if (activation.sp() != NULL) { ... > >> >> src/os/bsd/vm/os_bsd.hpp >> L109: static bool get_frame_at_stack_banging_point(JavaThread* >> thread, ucontext_t* uc, frame* fr); >> Wrong indent; needs one less space. > > Fixed > >> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >> L322: // For Forte Analyzer AsyncGetCallTrace profiling support - >> thread >> L323: // is currently interrupted by SIGPROF. >> Now fetch_frame_from_ucontext() is also used for stack overflow >> signal handling. > > Fixed > >> L379: assert(fr->safe_for_sender(thread), "Safety check"); >> L380: if (!fr->is_first_java_frame()) { >> L381: *fr = fr->java_sender(); >> The assert() on L379 should be before the java_sender() >> call on L381. > > Fixed > >> src/os/linux/vm/os_linux.cpp >> L1902: jt->stack_guards_enabled()) { // No pending >> stack overflow exceptions >> This line's comment used to align with the previous line's >> comment. >> Can you move the previous line's comment to align with this >> one? > > Done. > >> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >> L135: // For Forte Analyzer AsyncGetCallTrace profiling support - >> thread >> L136: // is currently interrupted by SIGPROF. >> Now fetch_frame_from_ucontext() is also used for stack overflow >> signal handling. > > Fixed > >> L192: assert(fr->safe_for_sender(thread), "Safety check"); >> L193: if (!fr->is_first_java_frame()) { >> L194: *fr = fr->java_sender(); >> The assert() on L192 should be before the java_sender() >> call on L194. > > Fixed > >> src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp >> L209: // For Forte Analyzer AsyncGetCallTrace profiling support - >> thread >> L210: // is currently interrupted by SIGPROF. >> Now fetch_frame_from_ucontext() is also used for stack overflow >> signal handling. > > Fixed > >> L265: assert(fr->safe_for_sender(thread), "Safety check"); >> L266: if (!fr->is_first_java_frame()) { >> L267: *fr = fr->java_sender(); >> The assert() on L265 should be before the java_sender() >> call on L267. > > Fixed > >> L279: //assert(fr->safe_for_sender(thread), "Safety check"); >> Delete this line; you copied it to L282. > > Done > >> L287 return true; >> Should this assert be added above this line? >> assert(fr->is_java_frame(), "Safety check"); > > Yes, this assert exists on other platforms, and there's no > reason to omit it on Solaris/SPARC > >> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >> L195: // For Forte Analyzer AsyncGetCallTrace profiling support - >> thread >> L196: // is currently interrupted by SIGPROF. >> Now fetch_frame_from_ucontext() is also used for stack overflow >> signal handling. > > Fixed > >> L253: assert(fr->safe_for_sender(thread), "Safety check"); >> L254: if (!fr->is_first_java_frame()) { >> L255: *fr = fr->java_sender(); >> The assert() on L253 should be before the java_sender() >> call on L255. > > Fixed > >> L273: *fr = fr->java_sender(); >> Wrong indent; one too many spaces. > > Fixed > > >> src/os/windows/vm/os_windows.cpp >> L2364: assert(fr->safe_for_sender(thread), "Safety check"); >> L2365: if (!fr->is_first_java_frame()) { >> L2366: *fr = fr->java_sender(); >> The assert() on L2364 should be before the java_sender() >> call on L2366. > > Fixed > >> L2387: return true; >> Should this assert be added above this line? >> assert(fr->is_java_frame(), "Safety check"); > > Certainly, fixed. > >> src/share/vm/oops/method.hpp >> (old) L87: u1 _flags; >> (new) L88: u2 _flags; >> Ouch - just needed one more bit... > > The initial implementation of the reserved stack area used the last > bit, but unfortunately, someone else steal it before I could push > my code :-( So I had to extend the flags field > >> L834: return (_flags & _reserved_stack_access) != 0; >> Wrong indent; two fewer spaces. > > Fixed > >> src/share/vm/runtime/globals.hpp >> L3549: range(MIN_STACK_RESERVED_PAGES, >> (DEFAULT_STACK_RESERVED_PAGES+10))\ >> Wrong indent; should line up below the double quote in >> the previous line. > > Fixed > >> src/share/vm/interpreter/interpreterRuntime.cpp >> L328 IRT_ENTRY(void, >> InterpreterRuntime::throw_delayed_StackOverflowError(JavaThread* >> thread)) >> >> The regular throw_StackOverflowError() increments >> a counter: >> >> L313: Atomic::inc(&Exceptions::_stack_overflow_errors); >> >> Should this function increment the same counter or >> a different counter? > > Good catch! I've added the counter increment to the method > throw_delayed_StackOverflowError(). I don't see a strong > rational to create a new counter for delayed stack overflows, > so it increments the same counter as throw_StackOverflowError(). > >> >> src/cpu/sparc/vm/macroAssembler_sparc.hpp >> L1423: // Check for reserved stack access in method being exited >> (for the compilers) >> The X86 version says "for JIT compilers". I prefer "JIT". > > Fixed > >> src/cpu/x86/vm/macroAssembler_x86.hpp >> L643: // Check for reserved stack access in method being exited >> (for JIT compilers) >> The SPARC version says "for the compilers". > > Fixed > >> src/share/vm/ci/ciMethod.cpp >> L95: _has_reserved_stack_access = >> h_m()->has_reserved_stack_access(); >> Wrong indent; should be only one space before '='. > > Fixed > >> src/share/vm/c1/c1_GraphBuilder.cpp >> L3323: if(callee->has_reserved_stack_access()) { >> L3336: if(callee->has_reserved_stack_access()) { >> L3356: if(callee->has_reserved_stack_access()) { >> Missing space between 'if' and '('. > > All fixed. > >> src/cpu/x86/vm/x86_32.ad >> L737: size += 64; // added to support ReservedStackAccess >> Usually I hate literals like this, but this function has >> them in spades. :-( > > I agree but I didn't find a better solution. > >> src/cpu/x86/vm/x86_64.ad >> L960: MacroAssembler _masm(&cbuf); >> L965: MacroAssembler _masm(&cbuf); >> >> I think you can delete the _masm on L965. > > Right, removed. > >> src/share/vm/opto/compile.cpp >> L675: >> _has_reserved_stack_access(target->has_reserved_stack_access()) { >> Wrong indent; should be a single space between ')' and '{'. > > Fixed > >> test/runtime/ReservedStack/ReservedStackTest.java >> L26: * @run main/othervm -XX:-Inline >> -XX:CompileCommand=exclude,java/util/concurrent/locks/AbstractOwnableSynchronizer,setExclusiveOwnerThread >> >> ReservedStackTest >> >> Should the comma before 'setExclusiveOwnerThread' be a period? >> Perhaps both formats work... > > Both formats work, but I changed it to be a period, it's cleaner. > >> L47: * else >> Wrong indent; needs one more space before 'else'. >> >> L52: * successfully update the status of the lock but he method >> Typo: 'update the' -> 'updates the' >> Typo: 'he method' -> 'the method' >> >> L60: * first StackOverflowError is thrown, the Error is catched >> Typo: 'is catched' -> 'is caught' >> >> L61: * and a few dozens frames are exited. Now the thread has >> Typo: 'a few dozens frames' -> 'a few dozen frames' >> >> L66: * of its invocation, tries to acquire the next lock >> Typo: 'its invocation' -> 'its invocations' >> >> L81: * stack to prevent false sharing. The test is using this >> Perhaps 'The test is using this' >> -> 'The test relies on this' >> >> to better match wording on L225-6. >> >> L82: * to have different stack alignments and hit the targeted >> Grammar: 'and hit' -> 'when it hits' >> >> L102: * exploit the property that interpreter frames are (much) >> Typo: 'exploit' -> 'exploits' >> Delete extra space after 'the'. >> >> L123: //LOCK_ARRAY_SIZE value >> Add a space after '//'. >> >> L188: @jdk.internal.vm.annotation.ReservedStackAccess >> This isn't privileged code and -XX:-RestrictReservedStack >> isn't specified so what does this do? > > It checks that by default the annotation is ignored for non-privileged > code, in case it is not ignored, the test would fail. > >> >> L201: System.exit(-1); >> Wrong indent; needs two more spaces. > > All fixed. > > Thank you very much! > > Fred > >>> >>> On 20/11/2015 19:44, Karen Kinnear wrote: >>>> Frederic, >>>> >>>> Code review for web revs you sent out. >>>> Code looks good. I am not as familiar with the compiler code. >>>> >>>> I realize you need to check in at least a subset of the >>>> java.util.concurrent changes for >>>> the test to work, so maybe I should not have asked Doug about his >>>> preference there. >>>> Sorry. >>>> >>>> I am impressed you found a way to make a reproducible test! >>>> >>>> Comments/questions: >>>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >>> >>> Fixed >>> >>>> 2. IIRC, due to another bug with windows handling of our guard pages, >>>> this >>>> is disabled for Windows. Would it be worth putting a comment in the >>>> bug , 8067946, that once this is fixed, the reserved stack logic on >>>> windows >>>> will need testing before enabling? >>> >>> More than testing, the implementation would have to be completed on >>> Windows. I've added a comment to JDK-8067946. >>> >>>> 3. In get_frame_at_stack_banging_point on Linux, BSD and >>>> solaris_x86 if >>>> this is in interpreter code, you explicitly return the Java sender >>>> of the current frame. I was expecting to see that on Solaris_sparc >>>> and Windows >>>> as well? I do see the assertion in caller that you do have a java >>>> frame. >>> >>> It doesn't make sense to check the current frame (no bytecode has been >>> executed yet, so risk of partially executed critical section). I did >>> the >>> change but not for all platforms. This is now fixed for Solaris_SPARC >>> and Windows too. >>> >>>> 4. test line 83 ?writtent? -> ?written? >>> >>> Fixed >>> >>>> 5. I like the way you set up the preallocated exception and then set >>>> the message - we may >>>> try that for default methods in future. >>>> >>>> 6. I had a memory that you had found a bug in safe_for_sender - did >>>> you already check that in? >>> >>> I've fixed x86 platforms in JDK-8068655. >>> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >>> I had hoped it would have been silently accepted :-) >>> >>> >>>> 7. I see the change in trace.xml, and I see an include added to >>>> SharedRuntime.cpp, >>>> but I didn?t see where it was used - did I just miss it? >>> >>> trace.xml changes define a new event. >>> This event is created at sharedRuntime.cpp::3006 and it is used >>> in the next 3 lines. >>> >>> Thanks, >>> >>> Fred >>> >> > From sangheon.kim at oracle.com Wed Dec 2 20:11:19 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 2 Dec 2015 12:11:19 -0800 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <565DDD90.1010506@oracle.com> References: <564F8ADB.9090008@oracle.com> <5654747A.3000908@oracle.com> <56547635.9060808@oracle.com> <56563D89.5090902@oracle.com> <565CD030.50507@oracle.com> <565CDEA5.10603@oracle.com> <565CF8F5.9040504@oracle.com> <565DDD90.1010506@oracle.com> Message-ID: <565F5067.80606@oracle.com> Hi all, Gerard and I discussed about NewSizeThreadIncrease and we agreed to file a new CR[1] to handle it. The reason is that under current validation, we can't detect the overflow. The flag NewSizeThreadIncrease is used with total of non-daemon threads after actual GC happened and the flag validation happens at the beginning of VM. [1]: https://bugs.openjdk.java.net/browse/JDK-8144527 Thanks, Sangheon On 12/01/2015 09:49 AM, gerard ziemski wrote: > > > On 11/30/2015 07:33 PM, sangheon.kim wrote: >>> >>>> >>>> src/share/vm/runtime/globals.hpp lines: >>>> 3419 product(uintx, TLABRefillWasteFraction, >>>> 64, \ >>>> 3420 "Maximum TLAB waste at a refill (internal >>>> fragmentation)") \ >>>> 3421 range(1, >>>> max_juint) \ >>>> >>>> >>>> ------------- >>>> #6 We multiply NewSizeThreadIncrease later, like >>>> >>>> size_t thread_increase_size = threads_count * NewSizeThreadIncrease; >>>> >>>> so the range's max needs to be smaller than max_uintx by some large >>>> enough constant (MAX thread count?) >>> You are right. >>> We don't have any problem without constraint function but it would >>> be better to have one. >>> I will post next webrev soon with this constraint function. >> Looking at the code again, it is hard to add constraint function for >> this flag. >> When we run the constraint function('threads_count' is zero at this >> time), we don't know how many non-daemon threads >> will be running. >> i.e. 'size_t thread_increase_size = threads_count * >> NewSizeThreadIncrease; ' is executed after GC is happened and the >> flag validation is occurred much earlier. >> And as we are using both MIN/MAX macro, I think there will be no >> value range problem with this flag. >> What do you think about this? > > Our SQE testing framework for ranges will use the MAX value from the > range guranteed, so our testing will hit this for sure. > > Should we perhaps then at least define the range as (1, > max_juint/2048) or some other reasonable value instead of 2048? > > > cheers From ioi.lam at oracle.com Wed Dec 2 20:50:53 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 02 Dec 2015 12:50:53 -0800 Subject: RFR (S) 8144491 ElfSymbolTable::lookup returns bad value In-Reply-To: <565F304B.8040204@oracle.com> References: <565F008B.1060405@oracle.com> <565F20D0.2020102@oracle.com> <565F304B.8040204@oracle.com> Message-ID: <565F59AD.3060800@oracle.com> On 12/2/15 9:54 AM, Daniel D. Daugherty wrote: > On 12/2/15 9:48 AM, Stefan Karlsson wrote: >> Hi Ioi, >> >> On 2015-12-02 15:30, Ioi Lam wrote: >>> Please review a small fix: >>> >>> http://cr.openjdk.java.net/~iklam/8144491-ElfSymbolTable-lookup/ >>> >>> Bug: ElfSymbolTable::lookup returns bad value when the lookup has >>> failed >>> >>> https://bugs.openjdk.java.net/browse/JDK-8144491 > > src/share/vm/utilities/elfSymbolTable.hpp > L67: bool compare(const Elf_Sym* sym, address addr, int* > stringtableIndex, > int* posIndex, int* offset, ElfFuncDescTable* funcDescTable); > Should funcDescTable be a 'const'? > > > src/share/vm/utilities/elfSymbolTable.cpp > L72: bool ElfSymbolTable::compare(const Elf_Sym* sym, address addr, > int* stringtableIndex, int* posIndex, int* offset, > ElfFuncDescTable* funcDescTable) { > > Should funcDescTable be a 'const'? > Hi Dan, I tried changing funcDescTable to const, but then gcc barfs on this line funcDescTable->lookup(sym->st_value) as the lookup() function is not declared as const (it modifies funcDescTable->m_status). So I will push the code exactly as in the webrev posted above. Thanks - Ioi > Thumbs up! Don't need to see another webrev if you change the > const-ness of funcDescTable > > More below... > >>> >>> Summary of fix: >>> >>> I found this when trying to make disassembler.cpp print out more >>> symbolic >>> information for PrintInterpreter. >>> >>> The fix is straight-forward -- if the lookup fails, >>> ElfSymbolTable::lookup >>> should return false. >>> >>> Impact: >>> The only caller to ElfSymbolTable::lookup is ElfFile::decode(), >>> so nothing >>> else would depend on the old (bad) behavior of >>> ElfSymbolTable::lookup. >>> >>> I also took the chance to refactor lookup is ElfFile::decode() >>> to split out >>> two blocks of identical code into a new function, >>> ElfSymbolTable::compare. >> >> The change looks correct. I would prefer if the refactoring was done >> as a separate patch, but since this is Runtime code I'll let other >> reviewers decide on that. > > For JDK9 we've been been doing both: > > - product changes plus cleanup changes in the same changeset > - cleanup changes in one changeset and product changes in another > > It really depends on how much the cleanup obscures the product > change. I don't think this one is too distracting... > > >> >> Thanks, >> StefanK >>> >>> Tests: >>> >>> JPRT >>> RBT (hotspot/test/:hotspot_all) <-- what other tests should I run? > > Dmitry Samersoff might have an opinion here since he tends to > do work on the ELF code... and probably knows what tests hit > this code. > > Dan > > > >>> >>> Thanks >>> - Ioi >> > From gnu.andrew at redhat.com Wed Dec 2 21:38:15 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 2 Dec 2015 16:38:15 -0500 (EST) Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> Message-ID: <902231413.22551266.1449092295615.JavaMail.zimbra@redhat.com> snip... > The new revision does that: > http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03 > http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03 > http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03/ > This has grown a lot from my version. The main change seems to be in having to handle a ppc64le define in numerous places, which seems unnecessary as ppc64 is present there. The version I'm looking at that we used in 8 deliberately avoids this by forcing ARCH back to ppc64 on ppc64le. Was there a reason not to do that? The only case where ppc64le is different to ppc64, the ABI is used: -#if defined(__ia64) || defined(__powerpc__) +#if defined(__ia64) || (defined(__powerpc__) && !defined(ABI_ELFv2)) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From asmundak at google.com Wed Dec 2 22:02:35 2015 From: asmundak at google.com (Alexander Smundak) Date: Wed, 2 Dec 2015 14:02:35 -0800 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <902231413.22551266.1449092295615.JavaMail.zimbra@redhat.com> References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <902231413.22551266.1449092295615.JavaMail.zimbra@redhat.com> Message-ID: On Wed, Dec 2, 2015 at 1:38 PM, Andrew Hughes wrote: > snip... > >> The new revision does that: >> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03 >> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03 >> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03/ >> > This has grown a lot from my version. I guess you are referring to the three additional files under hotspot/agent. > The main change seems to be in having to handle a ppc64le define > in numerous places, which seems unnecessary as ppc64 is present there. > The version I'm looking at that we used in 8 deliberately avoids this > by forcing ARCH back to ppc64 on ppc64le. Was there a reason not to do that? I think fiddling with ARCH is fragile. IMHO it's easier to have ppc64le checked explicitly in the agent. From gnu.andrew at redhat.com Wed Dec 2 22:18:54 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 2 Dec 2015 17:18:54 -0500 (EST) Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <902231413.22551266.1449092295615.JavaMail.zimbra@redhat.com> Message-ID: <501801523.22574565.1449094734051.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On Wed, Dec 2, 2015 at 1:38 PM, Andrew Hughes wrote: > > snip... > > > >> The new revision does that: > >> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03 > >> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03 > >> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03/ > >> > > This has grown a lot from my version. > I guess you are referring to the three additional files under hotspot/agent. > The extra define patches mainly. > > The main change seems to be in having to handle a ppc64le define > > in numerous places, which seems unnecessary as ppc64 is present there. > > The version I'm looking at that we used in 8 deliberately avoids this > > by forcing ARCH back to ppc64 on ppc64le. Was there a reason not to do > > that? > I think fiddling with ARCH is fragile. IMHO it's easier to have ppc64le > checked > explicitly in the agent. > I can see that point. Ok by me then. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From magnus.ihse.bursie at oracle.com Wed Dec 2 22:59:33 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 Dec 2015 23:59:33 +0100 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> Message-ID: <565F77D5.7090603@oracle.com> On 2015-12-01 04:31, Alexander Smundak wrote: >> On 2015-11-30 05:23, David Holmes wrote: >>> .. >>> At the top level if we see ppc64le then we set VAR_CPU to ppc64le instead >>> of ppc64. However, once we get into hotspot build we want ARCH to be ppc64 >>> again (in hotspot-spec.gmk.in) - why is that? >>> >>> Inside hotpot we want: >>> >>> SRCARCH := ppc >>> BUILDARCH := ppc64 >>> LIBARCH := ppc64le >>> >>> right? So can ARCH not be ppc64le from the top-level and then we adjust >>> SRCARCH and BUILDARCH? And avoid the top-level changes to ARCH. > The new revision does that: > http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03 > http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03 > http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03/ This version looks good to me. /Magnus > > common/autoconf/hotspot-spec.gmk.in has been left alone, and > hotspot/make/defs.make sets BUILDARCH and LIBARCH > (BUILDARCH should be the same for ppc64 and ppc64le because the file > linux/makefiels/$)BUILDARCH).make is pulled in by vm.make) > I have also reduced the changeset for hotspot by making > sun.jvm.hotspot.utilities.PlatformInfo.getCPU() return "ppc64" both > when > "os.arch" propertie's value is "ppc64" and "ppc64le". > >>> agent/src/os/linux/LinuxDebuggerLocal.c >>> agent/src/os/linux/libproc.h >>> >>> Is it not the case that ppc64le -> ppc64, so that we can avoid "if >>> defined(ppc64) | defined(ppc64le) ? I would hope that the only places in the >>> sources where you need to check for ppc64le is where that code differs from >>> the ppc64 code. > This is defined as -D$(OPENJDK_TARGET_CPU_LEGACY), but the same variable > is used in the generated hotspot-spec.gmk file, so I decided it's > easier to fix the > SA code. > >>> src/share/vm/runtime/vm_version.cpp >>> >>> I think this messy code block relates to builds where CPU is not set - >>> which should never be the case these days. Maybe just put in a check "ifndef >>> CPU -> error" ? >> I agree. There might be a case for handling zero, though. If I remember >> correctly the hotspot build might not set CPU, or set it incorrectly, when >> building zero. (Then again, zero is a strange beast, a mix between a variant >> and a platform...) > I have listed platform-specific options for building Hotspot above, > but here's the full command line to build vm_version.o for ppc64le: > > /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. > -I/hotspot/src/share/vm/prims -I/hotspot/src/share/vm > -I/hotspot/src/share/vm/precompiled > -I/hotspot/src/cpu/ppc/vm > -I/hotspot/src/os_cpu/linux_ppc/vm > -I/hotspot/src/os/linux/vm -I/hotspot/src/os/posix/vm > -I../generated -DHOTSPOT_BUILD_USER="\"asmundak\"" > -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" > -DHOTSPOT_RELEASE_VERSION="\"1.9.0-internal-asmundak_2015_11_26_17_11-b00\"" > -DJRE_RELEASE_VERSION="\"1.9.0-internal-asmundak_2015_11_26_17_11-b00\"" > -DJDK_MAJOR_VERSION="\"1\"" -DJDK_MINOR_VERSION="\"9\"" > -DJDK_MICRO_VERSION="\"0\"" -DJDK_BUILD_NUMBER="\"b00\"" > -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 > -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 > -DTARGET_COMPILER_gcc -DCOMPILER2 -DINCLUDE_JVMCI=0 -fPIC -fno-rtti > -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 > -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 > -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 > -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror > -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual > -Wtype-limits -Wno-format-zero-length -Wuninitialized -c -MMD -MP > -MF ../generated/dependencies/vm_version.o.d -fpch-deps -o > vm_version.o /hotspot/src/share/vm/runtime/vm_version.cpp > (I have replaced the actual path to the source tree with ) > > Preprocessor variable 'CPU' is not defined on the command line, and if I add > #error CPU is not defined > right after > #fndef CPU > on line 193 in vm_version.cpp, > it will fail to compile at least on Linux ppc64le and Linux x86_64. > >> I also think something's very weird here. OPENJDK_TARGET_CPU_ARCH is defined >> to ppc for both ppc64 and the new ppc64le platform, that it, it explicitely >> excludes address size. I think it's reasonable that it excludes endianness >> as well, but we have not really had to make that discussion before. In any >> case, it should not contain "64", otherwise the value will be "ppc" for >> ppc64 and "ppc64le" for ppc64le, and that's just plain wrong. > With the proposed patches the generated spec.gmk will contain > OPENJDK_TARGET_CPU_OSARCH:=ppc64le > when building JDK for the little endian and ppc64 for the big endian. > "os.arch" property is set from ARCHPROPNAME preprocessor variable, > whose value is $(OPENJDK_TARGET_CPU_ARCH). Did I misunderstand > something? From paul.sandoz at oracle.com Wed Dec 2 23:00:22 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Dec 2015 00:00:22 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <565F1A5A.4040509@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <9C417D00-F022-4CF6-87D3-0AF74CCD7441@oracle.com> <565F1A5A.4040509@oracle.com> Message-ID: <8D34B054-1832-428A-8A00-C7C5E1056061@oracle.com> Hi Stefan, > On 2 Dec 2015, at 17:20, Stefan S?rne wrote: > > > Hi Paul, > > The reason we stick on standard jtreg tests is because it is simpler. > For us, a java test is not a unit test, it is an application. :) > I tend to think of that as an artificial distinction since such java test classes often contain a logical grouping of tests (and perhaps data over which to test) and make test assertions. Let?s call it duck unit testing, it looks and quacks like a unit test :-) > I agree with you that when writing and debugging java code, I would choose testng over jtreg and run and debug it inside my java IDE. In the case of the JDK it's not jtreg over testng it is jtreg + testng. > But debugging the VM is instead done with a native debugger and what the framework gives you for java development, becomes a level of indirection in VM land. Just adding the test class as argument to the java launcher where a main method exists is preferred. > How do HotSpot engineers debug the VM with a jtreg test that uses @library (or @module once Jigsaw gets integrated), or uses WhiteBox, or uses ProcessTools? Paul. From coleen.phillimore at oracle.com Wed Dec 2 23:23:44 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 2 Dec 2015 18:23:44 -0500 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <8D34B054-1832-428A-8A00-C7C5E1056061@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <9C417D00-F022-4CF6-87D3-0AF74CCD7441@oracle.com> <565F1A5A.4040509@oracle.com> <8D34B054-1832-428A-8A00-C7C5E1056061@oracle.com> Message-ID: <565F7D80.7060708@oracle.com> Thank you Stefan for making the distinction between debugging Java inside an IDE vs. the JVM. On 12/2/15 6:00 PM, Paul Sandoz wrote: > Hi Stefan, > >> On 2 Dec 2015, at 17:20, Stefan S?rne wrote: >> >> >> Hi Paul, >> >> The reason we stick on standard jtreg tests is because it is simpler. >> For us, a java test is not a unit test, it is an application. :) >> > I tend to think of that as an artificial distinction since such java test classes often contain a logical grouping of tests (and perhaps data over which to test) and make test assertions. Let?s call it duck unit testing, it looks and quacks like a unit test :-) > >> I agree with you that when writing and debugging java code, I would choose testng over jtreg and run and debug it inside my java IDE. > In the case of the JDK it's not jtreg over testng it is jtreg + testng. We already use jtreg and do not welcome another layer on the java class files. When debugging a jtreg failure, I go to the "rerun" section in the .jtr file. Edit it for 10 minutes to remove the extra '\' at the end and remove jtreg so that I get simply: export CLASSPATH=... java ClassFile and save it to a rerun.sh file. I haven't figured out which -D test option I need for the test, but try to remove most of them also. Generally, I debug like: gdb --args $JAVA_HOME/bin/java ClassFile What we're interested in is generally in the ClassFile and not in the jtreg java code. I do not want to spend an additional 10 minutes to hack out testng. Also, if the test fails and has a agent.jar file, that's usually found in the directory below, so I have to copy my rerun.sh file there. > > >> But debugging the VM is instead done with a native debugger and what the framework gives you for java development, becomes a level of indirection in VM land. Just adding the test class as argument to the java launcher where a main method exists is preferred. >> > How do HotSpot engineers debug the VM with a jtreg test that uses @library (or @module once Jigsaw gets integrated), or uses WhiteBox, or uses ProcessTools? See above. Luckily CLASSPATH points to it in the end of the jtr file. So no. We do not want testng harness code added to the the Hotspot runtime tests. Coleen > > Paul. From coleen.phillimore at oracle.com Thu Dec 3 01:58:25 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 2 Dec 2015 20:58:25 -0500 Subject: RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions Message-ID: <565FA1C1.50909@oracle.com> Summary: merged templateInterpreter_x86_32/64 into templateInterpreterGenerator_x86.cpp (some 32/64 functions remain for the hand coded crc functions). open webrev at http://cr.openjdk.java.net/~coleenp/8144534.01/ bug link https://bugs.openjdk.java.net/browse/JDK-8144534 I tried to make this reviewable by hg renaming files. I basically renamed templateInterpreter_ppc.cpp and removed the AbstractInterpreter functions and put them back into templateInterpreter_ppc.cpp. I didn't really delete 4000 lines of code, more like 1500. Also, can someone with the PPC and AARCH port look at and test out these changes? I tried to reduce the #includes in the new templateInterpreter_ppc/aarch64.cpp files which worked for sparc. Tested with JPRT on all platforms, also ran jtreg and collocated/non-collocated tonga tests for linux x64 and i386 since that's were the real changes are. See the bug for more details and my partial vision of how these functions will be reorganized when I remove the broken c++ interpreter. Also tested that Zero still builds. Thanks! Coleen From ioi.lam at oracle.com Thu Dec 3 02:32:28 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 02 Dec 2015 18:32:28 -0800 Subject: RFR (XS) 8143615 compactHashtable.hpp includes oop.inline.hpp file Message-ID: <565FA9BC.2080808@oracle.com> Please review a very small fix: http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp/ Bug: compactHashtable.hpp includes oop.inline.hpp file https://bugs.openjdk.java.net/browse/JDK-8143615 Summary of fix: + deleted the include of oop.inline.hpp from compactHashtable.hpp + moved all inlined functions that require oop.inline.hpp into a new file, compactHashtable.inline.hpp Tests: JPRT Thanks - Ioi From coleen.phillimore at oracle.com Thu Dec 3 02:35:58 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 2 Dec 2015 21:35:58 -0500 Subject: RFR (XS) 8143615 compactHashtable.hpp includes oop.inline.hpp file In-Reply-To: <565FA9BC.2080808@oracle.com> References: <565FA9BC.2080808@oracle.com> Message-ID: <565FAA8E.3090908@oracle.com> Looks good. Thank you for fixing this. Coleen On 12/2/15 9:32 PM, Ioi Lam wrote: > Please review a very small fix: > > http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp/ > > Bug: compactHashtable.hpp includes oop.inline.hpp file > > https://bugs.openjdk.java.net/browse/JDK-8143615 > > Summary of fix: > > + deleted the include of oop.inline.hpp from compactHashtable.hpp > + moved all inlined functions that require oop.inline.hpp into a > new file, compactHashtable.inline.hpp > > Tests: > > JPRT > > Thanks > - Ioi From coleen.phillimore at oracle.com Thu Dec 3 02:58:02 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 2 Dec 2015 21:58:02 -0500 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <565DF808.7060806@oracle.com> Message-ID: <565FAFBA.9060405@oracle.com> I finally had a chance to look at this. Why are there pages of commit messages in these webrevs? http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/src/share/vm/prims/unsafe.cpp.udiff.html +static JNINativeMethod sun_misc_Unsafe_methods[] = { This looks like a copy of the list of methods that we already have. +static JNINativeMethod jdk_internal_misc_Unsafe_methods[] = { Can you just have: +static JNINativeMethod sun_misc_Unsafe_methods[] = methods; +static JNINativeMethod jdk_internal_misc_Unsafe_methods[] = methods; ??? http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/JdkInternalMiscUnsafeAccessTestBoolean.java.html I don't see the benefit of testng here. You probably already have Assert in our test library. http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/generate-unsafe-access-tests.sh.html Is this script and template how these tests were generated? It doesn't seem like it needs to be checked in (and is missing copyright). Maybe since the tests are stressing the compilation characteristics of the unsafe API, these tests belong in the test/compiler/unsafe directory. Maybe the compiler group doesn't mind slogging through testng to find bugs. Coleen On 12/2/15 3:54 AM, Paul Sandoz wrote: > Hi Coleen, > >> On 1 Dec 2015, at 20:42, Coleen Phillimore wrote: >>> ? >>> >>> Would i be correct in stating that the HotSpot runtime team is taking a conservative position and does not want to deal with such a library, contrary to other areas of the JDK? >> Yes. That is correct. We don't need more frameworks that hinder getting to the java command line for the class file. It's time consuming enough with jtreg. > So is the real underlying reason is you don?t want to run the tests *locally* with jtreg at all? (Note that jtreg spits out a script that one can use to re-run faster.) > > At some point later these tests will be even more dependent on jtreg because they have an internal dependency on Unsafe and jtreg will wire up things correctly to bust through the encapsulation, as these are white box tests. > > >>> Sorry to push back, but I don?t agree with that position (if correct). I am reluctant to change the tests. Please don?t think that complete pigheadedness on my part :-) I just don?t think it?s the right thing to do. >>> >>> If the HotSpot runtime team will not accept the use of TestNG then I suppose I could unblock by proposing to move the tests to the JDK repo, which I would also be reluctant to do since they caught an issue lying dormant for at least 8 years on certain platforms (not covered by the core testset) that existing hotspot tests never caught. >> Can you repost the whole webrev to hotspot-dev ? I didn't see the original to see why these tests require the testng framework and cannot be written as simple regression tests. If they have to be very complex, maybe they belong in a different test directory that has support and tolerance for this complexity. Maybe you can write a small regression test for the hotspot/test/runtime test and put the rest somewhere else. Again, this is in the abstract. I don't have the webrev. >> > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/webrev/ > > It?s not just about complexity, it?s also about better test code, consistency and reporting. > > It feels strange to be arguing for the utilisation of a unit test library. Most of the world moved on over 15 years ago :-) and most of the JDK has already moved on. > > Paul. From jiangli.zhou at oracle.com Thu Dec 3 04:25:52 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 2 Dec 2015 20:25:52 -0800 Subject: RFR (XS) 8143615 compactHashtable.hpp includes oop.inline.hpp file In-Reply-To: <565FAA8E.3090908@oracle.com> References: <565FA9BC.2080808@oracle.com> <565FAA8E.3090908@oracle.com> Message-ID: <3FE775CB-4164-4C46-ADCA-31C9176F3D1B@oracle.com> +1 Thanks, Jiangli > On Dec 2, 2015, at 6:35 PM, Coleen Phillimore wrote: > > > Looks good. Thank you for fixing this. > Coleen > > On 12/2/15 9:32 PM, Ioi Lam wrote: >> Please review a very small fix: >> >> http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp/ >> >> Bug: compactHashtable.hpp includes oop.inline.hpp file >> >> https://bugs.openjdk.java.net/browse/JDK-8143615 >> >> Summary of fix: >> >> + deleted the include of oop.inline.hpp from compactHashtable.hpp >> + moved all inlined functions that require oop.inline.hpp into a >> new file, compactHashtable.inline.hpp >> >> Tests: >> >> JPRT >> >> Thanks >> - Ioi > From david.holmes at oracle.com Thu Dec 3 04:49:27 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Dec 2015 14:49:27 +1000 Subject: RFR (XS) 8143615 compactHashtable.hpp includes oop.inline.hpp file In-Reply-To: <565FA9BC.2080808@oracle.com> References: <565FA9BC.2080808@oracle.com> Message-ID: <565FC9D7.1030907@oracle.com> Hi Ioi, On 3/12/2015 12:32 PM, Ioi Lam wrote: > Please review a very small fix: > > http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp/ > > Bug: compactHashtable.hpp includes oop.inline.hpp file > > https://bugs.openjdk.java.net/browse/JDK-8143615 > > Summary of fix: > > + deleted the include of oop.inline.hpp from compactHashtable.hpp > + moved all inlined functions that require oop.inline.hpp into a > new file, compactHashtable.inline.hpp Looks okay but in compactHashtable.hpp: #include "memory/allocation.inline.hpp" This also needs removing - right? Thanks, David > Tests: > > JPRT > > Thanks > - Ioi From david.holmes at oracle.com Thu Dec 3 05:53:12 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Dec 2015 15:53:12 +1000 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <565F0698.7080600@cs.oswego.edu> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu> <56525823.6010506@cs.oswego.edu> <744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com> <56572F4E.8050603@oracle.com> <565F0698.7080600@cs.oswego.edu> Message-ID: <565FD8C8.6020105@oracle.com> On 3/12/2015 12:56 AM, Doug Lea wrote: > > Bringing Martin's JEP comment > (https://bugs.openjdk.java.net/browse/JDK-8046936) > to the lists: > > Approximately 100% of the cases of StackOverflowError (SOE) we > hear about lately on concurrency-interest are due to long chains > of CompletableFutures that exist because of the lack of > tail-recursion loopification by compilers. I don't think > any of these have involved ReentrantLocks, but some hit problems > due to lack of finally { ... } cleanup inside Executors upon SOE. > > In the absence of any of: tail-recursion support, reliable cleanup, > or growable stacks, it seems reasonable to choose larger default > stack sizes so that these long but finite chains of completions > are far less likely to hit SOE. > > On 32bit systems the 1MB limit is completely defensible. But expanding > to say 64MB on 64bit systems would reduce practical encounters with > SOE in these kinds of constructions by a factor of 64 or so. > Is there any reason not to do this? The same discussion on the concurrency-interest mailing list seems to indicate that there are indeed reasons to not do this. http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014596.html David > -Doug > > > From david.holmes at oracle.com Thu Dec 3 06:30:30 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Dec 2015 16:30:30 +1000 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> Message-ID: <565FE186.7090508@oracle.com> On 1/12/2015 1:31 PM, Alexander Smundak wrote: >> On 2015-11-30 05:23, David Holmes wrote: >>> .. >>> At the top level if we see ppc64le then we set VAR_CPU to ppc64le instead >>> of ppc64. However, once we get into hotspot build we want ARCH to be ppc64 >>> again (in hotspot-spec.gmk.in) - why is that? >>> >>> Inside hotpot we want: >>> >>> SRCARCH := ppc >>> BUILDARCH := ppc64 >>> LIBARCH := ppc64le >>> >>> right? So can ARCH not be ppc64le from the top-level and then we adjust >>> SRCARCH and BUILDARCH? And avoid the top-level changes to ARCH. > The new revision does that: > http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03/ Looks good. > http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03 Looks good. > http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03 agent code: I'm still unclear why you can't, or shouldn't, pass through -Dppc64 and -Dppc64le, such that you don't need to check for either being defined ?? --- src/share/vm/runtime/vm_version.cpp Just a follow up note that I was surprised to see CPU not being set. This code needs cleaning up in the future as we definitely do not need this additional place that defines architecture names. Thanks, David ----- > > common/autoconf/hotspot-spec.gmk.in has been left alone, and > hotspot/make/defs.make sets BUILDARCH and LIBARCH > (BUILDARCH should be the same for ppc64 and ppc64le because the file > linux/makefiels/$)BUILDARCH).make is pulled in by vm.make) > I have also reduced the changeset for hotspot by making > sun.jvm.hotspot.utilities.PlatformInfo.getCPU() return "ppc64" both > when > "os.arch" propertie's value is "ppc64" and "ppc64le". > >>> >>> agent/src/os/linux/LinuxDebuggerLocal.c >>> agent/src/os/linux/libproc.h >>> >>> Is it not the case that ppc64le -> ppc64, so that we can avoid "if >>> defined(ppc64) | defined(ppc64le) ? I would hope that the only places in the >>> sources where you need to check for ppc64le is where that code differs from >>> the ppc64 code. > This is defined as -D$(OPENJDK_TARGET_CPU_LEGACY), but the same variable > is used in the generated hotspot-spec.gmk file, so I decided it's > easier to fix the > SA code. > >>> src/share/vm/runtime/vm_version.cpp >>> >>> I think this messy code block relates to builds where CPU is not set - >>> which should never be the case these days. Maybe just put in a check "ifndef >>> CPU -> error" ? >> >> I agree. There might be a case for handling zero, though. If I remember >> correctly the hotspot build might not set CPU, or set it incorrectly, when >> building zero. (Then again, zero is a strange beast, a mix between a variant >> and a platform...) > > I have listed platform-specific options for building Hotspot above, > but here's the full command line to build vm_version.o for ppc64le: > > /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. > -I/hotspot/src/share/vm/prims -I/hotspot/src/share/vm > -I/hotspot/src/share/vm/precompiled > -I/hotspot/src/cpu/ppc/vm > -I/hotspot/src/os_cpu/linux_ppc/vm > -I/hotspot/src/os/linux/vm -I/hotspot/src/os/posix/vm > -I../generated -DHOTSPOT_BUILD_USER="\"asmundak\"" > -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" > -DHOTSPOT_RELEASE_VERSION="\"1.9.0-internal-asmundak_2015_11_26_17_11-b00\"" > -DJRE_RELEASE_VERSION="\"1.9.0-internal-asmundak_2015_11_26_17_11-b00\"" > -DJDK_MAJOR_VERSION="\"1\"" -DJDK_MINOR_VERSION="\"9\"" > -DJDK_MICRO_VERSION="\"0\"" -DJDK_BUILD_NUMBER="\"b00\"" > -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 > -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 > -DTARGET_COMPILER_gcc -DCOMPILER2 -DINCLUDE_JVMCI=0 -fPIC -fno-rtti > -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 > -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 > -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 > -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror > -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual > -Wtype-limits -Wno-format-zero-length -Wuninitialized -c -MMD -MP > -MF ../generated/dependencies/vm_version.o.d -fpch-deps -o > vm_version.o /hotspot/src/share/vm/runtime/vm_version.cpp > (I have replaced the actual path to the source tree with ) > > Preprocessor variable 'CPU' is not defined on the command line, and if I add > #error CPU is not defined > right after > #fndef CPU > on line 193 in vm_version.cpp, > it will fail to compile at least on Linux ppc64le and Linux x86_64. > >> I also think something's very weird here. OPENJDK_TARGET_CPU_ARCH is defined >> to ppc for both ppc64 and the new ppc64le platform, that it, it explicitely >> excludes address size. I think it's reasonable that it excludes endianness >> as well, but we have not really had to make that discussion before. In any >> case, it should not contain "64", otherwise the value will be "ppc" for >> ppc64 and "ppc64le" for ppc64le, and that's just plain wrong. > With the proposed patches the generated spec.gmk will contain > OPENJDK_TARGET_CPU_OSARCH:=ppc64le > when building JDK for the little endian and ppc64 for the big endian. > "os.arch" property is set from ARCHPROPNAME preprocessor variable, > whose value is $(OPENJDK_TARGET_CPU_ARCH). Did I misunderstand > something? > From thomas.stuefe at gmail.com Thu Dec 3 07:11:43 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 3 Dec 2015 08:11:43 +0100 Subject: RFR(xs): 8144343: [aix] Stack bottom should be page aligned In-Reply-To: <565F281A.2050706@oracle.com> References: <565F281A.2050706@oracle.com> Message-ID: Thanks, Vladimir! On Wed, Dec 2, 2015 at 6:19 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > > On 12/2/15 7:49 AM, Thomas St?fe wrote: > >> Hi Volker, >> >> thank you for the review! >> >> I changed the offending comments: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8144343-aix-stack-bottom-align/webrev.01/webrev/ >> >> Kind Regards, Thomas >> >> On Wed, Dec 2, 2015 at 4:32 PM, Volker Simonis >> wrote: >> >> Hi Thomas, >>> >>> the change looks good. Just some minor comments (regarding the comments >>> :) >>> >>> - what's the meaning of the comment (i.e. the question marks) in line >>> 4348 >>> >>> 4348 // high addr --------------------- real base ? at page >>> border ? >>> >>> - you removed the link from line 4342 so please also remove "see also" >>> from line 4350. >>> >>> Thanks, >>> Volker >>> >>> >>> >>> On Wed, Dec 2, 2015 at 4:03 PM, Thomas St?fe >>> wrote: >>> >>>> Hi all, >>>> >>>> please review this tiny AIX-only fix. Basically, it takes care of the >>>> thread stack bottom - and hence the placement of the guard pages - to be >>>> always aligned to os::vm_page_size() . >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8144343 >>>> webrev: >>>> >>>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8144343-aix-stack-bottom-align/webrev.00/webrev/ >>> >>>> >>>> Kind Regards, Thomas >>>> >>> >>> From thomas.stuefe at gmail.com Thu Dec 3 09:07:12 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 3 Dec 2015 10:07:12 +0100 Subject: RFR(L): 8143125: [aix] Further Developments for AIX In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC41ED076B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41ED242C@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Volker, thank you for all that work! See my comments inline. On Wed, Dec 2, 2015 at 11:19 AM, Volker Simonis wrote: > Hi Thomas, > > thanks a lot for this nice cleanup. Please find my remaining comments > below: > > libo4.hpp > ======= > - please update the copyright year > - remove the following comments which reference SAP path or bugs > > 45 // See libo4.h (at //bas2/sapjvm/dev/common/libs/libo4/include) > 46 // for details on this API. > > 59 // See libo4.h (at //bas2/sapjvm/dev/common/libs/libo4/include) > 60 // for details on this API. > > 72 // See also CSN Internal Message 0001182318 2008 > 73 // > 74 // See libo4.h (at //bas2/sapjvm/dev/common/libs/libo4/include) > 75 // for details on this API. > > libo4.cpp > ======= > - please update the copyright year > > vmStructs_aix_ppc.hpp > ================= > - please update the copyright year > > > All fixed. > misc_aix.hpp > ========== > - "trc" is defined to the empty string and doesn't seemed to be used > anywhere: > > 45 #define trc(fmt, ...) > > do we still need it? > > I removed it. > os_aix.cpp > ======== > - why do we need the following define right in-between the includes: > > 76 #include "utilities/defaultStream.hpp" > 77 #define PV_8_Compat 0x308000 /* Power PC 8 */ > 78 #include "utilities/events.hpp" > > it doesn't seem to be used in os_aix.cpp > > Fixed. > - you replaced most of the logging with trcVerbose but there are still > tow or three places using fprintf and jio_fprintf. Could you please > replace them by calls to trcVerbose as well. > > Fixed. All those trcVerbose calls are ugly crutches; I plan to transform all these trcVerbose calls to the new Unified Logging in the near future, just to get a feel for it. > - I can't see where the kernel thread id is initialized. Shouldn't you > call set_kernel_thread_id() from os::create_thread and > os::create_attached_thread() ? > > Good catch, fixed. > - in os::commit_memory() are you sure you always have 4K pages: > > 2342 if (UseExplicitCommit) { > 2343 // AIX commits memory on touch. So, touch all pages to be > committed. > 2344 for (char* p = addr; p < (addr + size); p += SIZE_4K) { > 2345 *p = '\0'; > 2346 } > 2347 } > wouldn?t it be better (i.e. potentially faster) to use > os::vm_page_size() instead of SIZE_4K ? > > Unfortunately, I cannot be sure. It may be possible to find out, but it seems easier to just do 4K paged touching. Once the page is paged in, it should not cost much. Note also that this is a development option and normally off. > - it doesn't seem we use '_large_page_size'. We statically initialize > it to '0' and later on in os::init() to '-1'. Better remove it and > directly return '0' (or '-1') from os::large_page_size(). > > True. But I still left that in, because the other platforms have the same code in them (eg bsd and solaris, which both don't seem to support large pages either). This is worth a cleanup, but should be done cross platform in a different patch. > libperfstat_aix.{cpp, hpp} > ================== > - please update the copyright year > - I want to second Goetz - we really don't need > perfstat_cpu_total_t_52. Please remove it from both > libperfstat_aix.{cpp, hpp} > > Ok, I removed the AIX 5.2 structure definitions. As I explained before, I was afraid of cutting off old, unpatched AIX 5.3 releases as well, if they still happen to carry an old libperfstat. But you guys seem to really want this removed, so I removed it. > loadlib_aix.cpp > ================== > - please update the copyright year > Fixed > > misc_aix.{hpp,cpp} > ============== > - I don't see why we need MiscUtils::describe_errno(). Can you please > instead use strerror() to get the error message (as we already do in a > lot of other places, e.g. in os_aix.cpp). That said, I realized that > strerror() is not thread-safe. So we should probably change it to the > POSIX function strerror_r(). But this is not only an AIX problem, so > better do that in a follow up change. > > Ok, I removed MiscUtils::desribe_errno(). I really do not like strerror(), though: - it is not threadsafe, which is quite unnecessary - strerror_r is threadsafe but may fail and requires error handling if done correctly - it gives lenghty, localized (!) error descriptions, which clog up log files and are less easy to grep for. - it carries the risk of not printing anything at all if the locale is set weird, e.g. "????" for japanese LC_MESSAGES. Just google for "strerror useless" All in all I think strerror is not good for the task of printing errno values into log files which are to be consumed by programmers, not users. But for now I removed describe_errno and replaced it with printing the numeric value of the errno. Maybe we can have this strerror discussion in the mailing list, see what others think. > - the same holds true for MiscUtils::sleep_ms(). Why do we need yet > another AIX-specific helper function? Moreover, it is used only once. > Can you please instead use usleep() or sleep() directly, depending on > how long you want to wait. (Just as a side note: your current > implementation of sleep_ms() would sleep for three seconds if called > with 1000ms as argument, and it would call usleep() with an argument > of 1.000.000 which should be avoided according to your comment (which > I couldn't verify in the AIX man-page (see > > https://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.basetechref/doc/basetrf2/sleep.htm)) > ). > So please remove MiscUtils::sleep_ms(). > > Ok, I did remove this and replaced the one call with plain usleep. The error was embarrassing :) thanks for catching that. As for the "1.000.000" restriction, that comes from Linux. MiscUtils::sleep_ms is used crossplatform in the SAP JVM. > There's no need to provide a new webrev, if you check that the your > latest changes will build and run. > > Thank you and best regards, > Volker > > Thanks again! ..Thomas > > On Thu, Nov 26, 2015 at 9:29 AM, Lindenmaier, Goetz > wrote: > > Hi Thomas, > > > > thanks a lot for doing all these changes. > > Looks good now. > > > > Could you add the change comment to the patch before you > > Make a webrev next time? Simplifies sponsoring ;) > > > > Best regards, > > Goetz. > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > > Sent: Mittwoch, 25. November 2015 18:01 > > To: Lindenmaier, Goetz > > Cc: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers < > hotspot-dev at openjdk.java.net> > > Subject: Re: RFR(L): 8143125: [aix] Further Developments for AIX > > > > Hi Goetz, > > > > new webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8143125-Further/webrev.01/webrev/ > > > > thank you for reviewing! See remarks inline... > > > > On Tue, Nov 24, 2015 at 12:38 PM, Lindenmaier, Goetz < > goetz.lindenmaier at sap.com> wrote: > > Hi Thomas, > > > > I looked at your change. It?s good we get these improvements into > > openJDK. But I think we should skip some stuff that's not (yet?) > > used there. I'll sponsor the change. Details: > > > > libperfstat_aix.cpp: > > > > What do you need > > static fun_perfstat_partition_total_t g_fun_perfstat_partition_total = > NULL; > > static fun_perfstat_wpar_total_t g_fun_perfstat_wpar_total = NULL; > > static fun_wpar_getcid_t g_fun_wpar_getcid = NULL; > > for? I think they are never used. > > > > They are now used (for the respective wrapper functions which in turn > are used in os_aix.cpp. Sorry for omitting this code. > > > > libperfstat_aix.cpp:161 > > We support AIX 5.3 with xlC12 only. I think we need not add the older > > #defines to openJDK. Also, the comment should be adapted and not mention > xlc8 etc. > > Also, there are datastructures for 5.2 which can be removed. > > > > Removed the older defines. > > I would for now prefer to leave the AIX 5.2 data structures in this > file. I am not sure if we could encounter older libperfstat versions on AIX > 5.3 too. I plan to rework this coding to get rid of the duplicate structure > definitions, but would prefer to do this in a separate patch. > > > > > > Where is this used? > > bool libperfstat::get_wparinfo(wparinfo_t* pwi) > > Do we need it if it's not used? > > > > It is now used :) in os_aix.cpp. > > > > > > libperfstat.hpp:835 > > I would remove these prototypes commented out. > > > > I removed them. > > > > loadlib_aix.cpp > > Why do you do these changes? Please revert them. > > > > I reverted them. > > > > os_aix.hpp:219 > > What's this good for? > > get_brk_at_startup() > > get_lowest_allocation_above_brk() > > > > I removed those prototypes. > > > > os_aix.hpp:259 > > What's this good for? > > parse_qsyslib_path() > > > > I removed this prototype. > > > > os_aix.cpp:410 > > Why do you move query_multipage_support()? > > > > I moved this back to its original position. > > > > os_aix.inline.hpp:164 > > Why do you reverse the order of the functions here? > > The old order is the same as in the related files os_linux.inline.hpp > etc. > > > > I reversed the order back to original order. > > > > Best regards, > > Goetz. > > > > > > Kind Regards, Thomas > > > > > >> -----Original Message----- > >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net hotspot-dev-bounces at openjdk.java.net>] On > >> Behalf Of Thomas St?fe > >> Sent: Freitag, 20. November 2015 11:49 > >> To: ppc-aix-port-dev at openjdk.java.net ppc-aix-port-dev at openjdk.java.net>; HotSpot Open Source Developers > >> Subject: RFR(L): 8143125: [aix] Further Developments for AIX > >> > >> Hi all, > >> > >> please review and sponsor these AIX only changes. Basically, with this > >> change we bring the OpenJDK AIX hotspot port up to speed with the > >> developments done at SAP in the recent months. > >> > >> For a more detailled number of changes and fixes, please refer to the > bug > >> description. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8143125 > >> webrev: > >> http://cr.openjdk.java.net/~stuefe/webrevs/8143125- > >> Further/webrev.00/webrev/index.html > >> > >> Kind Regards, Thomas > > > From sangheon.kim at oracle.com Thu Dec 3 09:08:22 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 3 Dec 2015 01:08:22 -0800 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <565E3382.7050502@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> <565DEC2D.3010308@oracle.com> <565E3382.7050502@oracle.com> Message-ID: <56600686.4060606@oracle.com> Hi all, Here is next webrev. http://cr.openjdk.java.net/~sangheki/8142341/webrev.02/ http://cr.openjdk.java.net/~sangheki/8142341/webrev.02_to_01/ Testing: JPRT and TestOptionsWithRanges.java on machines that have over 120GB memory. *Summary 1. Enhanced the constraint function for HeapBaseMinAddress: (Tom) 1) It will check an overflow the addition of MaxHeapSize and HeapBaseMinAddress. And the overflow only happens when MaxHeapSize is default and using compressed oop. Since MaxHeapSize is updated after ergo, FLAG_IS_ERGO(MaxHeapSize) is necessary at the constraint function. 2) As HeapBaseMinAddress has 'AfterErgo' tag, the constraint function will be called after the overflow happens at Arguments::set_heap_size(). However it is okay as we can detect the overflow before actual use of creating virtual space. And the problem of the overflow is setting MaxHeapSize with bigger value that it should be. 3) Changed the order of HeapBaseMinAddress to locate later than MaxHeapSize from globals.hpp as HeapBaseMinAddress refers MaxHeapSize. 2. Added missing single quote in commandLineFlagConstraintsGC.cpp at line 510. (Tom) 3. Changed test to add dependency for NewSizeThreadIncrease. Thanks, Sangheon On 12/01/2015 03:55 PM, sangheon.kim wrote: > Hi Tom, > > Thank you for this kind analysis! > > > On 12/01/2015 10:51 AM, Tom Benson wrote: >> Hi Sangheon, >> >> On 11/30/2015 6:51 PM, sangheon.kim wrote: >>> Hi Tom, >>> >>> Thank you for reviewing this! >>> >>> On 11/30/2015 02:46 PM, Tom Benson wrote: >>>> Hi Sangheon, >>>> >>>> I think there's a problem with using the same routine to check >>>> HeapBaseMinAddress as is used for checking heap size in >>>> commandLineFlagConstraintsGC.cpp. I tried running this, to make >>>> sure I understood what it was trying to do. When I specified >>>> something too large for HeapBaseMinAddress, the check reported that >>>> the value must be greater than or equal to maximum value N. >>> Sorry Tom, I can't understand. >>> Currently we print the error message if its value is too large like, >>> "must be less than or equal to aligned maximum value (xxx)". >>> Do you mean it should be 'address' instead of 'value'? >> >> What I meant was that I got an internal error when I used the value >> the message recommended, so perhaps the value should be further >> constrained. > I see. > >> >>> I thought it is okay. >>> >>>> Re-running with that (still huge) value, I get a fatal internal >>>> error out of virtualspace.cpp. (In the debug version, an assertion >>>> in universe.cpp triggers before reaching this point). EG: >>> I am trying to reproduce this assert but I can't. Do you have more >>> information to reproduce this? >>> I did -version and running GCOld to trigger GC. >>> >>> java -XX:HeapBaseMinAddress=18446744073642442752 -version >>> java -XX:HeapBaseMinAddress=18446744073642442752 GCOld 20 200 10 100 >>> 5000 >>> >> >> You probably didn't hit the problem because you're running on a >> smaller memory system than I am. On the system I'm on, the >> (computed) max heap size is 32G. And if you specify an Xmx, you >> don't go through the code path that causes it. > Okay, my machine is 32G but when I test on bigger memory machine, I > could see the assert. Thank you. > >> >> Here's the root of the problem. In Arguments::set_heap_size(), we >> have this code: >> >> if (FLAG_IS_DEFAULT(MaxHeapSize)) { >> . . . >> if (UseCompressedOops) { >> // Limit the heap size to the maximum possible when using >> compressed oops >> julong max_coop_heap = (julong)max_heap_for_compressed_oops(); >> . . . >> if (HeapBaseMinAddress + MaxHeapSize < max_coop_heap) { >> <======== *** PROBLEM IS HERE *** >> // Heap should be above HeapBaseMinAddress to get zero based >> compressed oops >> // but it should be not less than default MaxHeapSize. >> max_coop_heap -= HeapBaseMinAddress; >> } >> reasonable_max = MIN2(reasonable_max, max_coop_heap); >> } >> >> HeapBaseMinAddress is 64-bit unsigned, and in this case is >> 0xfffffffffc000000 (the 18446744073642442752 from the command line). >> MaxHeapSize is 0x7CCCCC8 and max_coop_heap is 0x7FE000000. The >> addition of HeapBaseMinAddress and MaxHeapSize overflows to >> 0x3ccccc8. Since this is less than 0x7FE000000, we subtract the >> 0xfffffffffc000000 from max_coop_heap, getting the result >> 0x802000000. reasonable_max is 0x800000000, so it stays at that >> value after the MIN2, rather than being reduced as it should be. >> >> Changing the conditional to also check for overflow avoids the >> problem. But of course you don't get the requested >> HeapBaseMinAddress anyway, since it's too high. >> >> So another approach would be to change your constraint to ensure that >> (HeapBaseMinAddress plus MaxHeapSize) won't overflow. I don't think >> there's any point in allowing a HeapBaseMinAddress so high that it >> would. > Okay, I'm thinking about this. > I will post a new webrev after testing. > > * I also read your other email that fixing constraint function makes > sense. > ** I already fixed your previous comment of extraneous single quote in > commandLineFlagConstraintsGC.cpp at line 510. > > Thanks, > Sangheon > > >> >> Tom >> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=0xffffffffffffffff >>>> -version >>>> HeapBaseMinAddress (18446744073709551615) must be less than or >>>> equal to aligned maximum value (18446744073642442752) >>>> Error: Could not create the Java Virtual Machine. >>>> Error: A fatal exception has occurred. Program will exit. >>>> >>>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=18446744073642442752 >>>> -version >>>> # >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # Internal Error (virtualspace.cpp:456), pid=10359, tid=10360 >>>> # guarantee(size + noaccess_prefix_size(alignment) <= >>>> OopEncodingHeapMax) failed: can not allocate compressed oop heap >>>> for this size >>>> # >>>> >>>> Perhaps you should check only the alignment in the constraint code, >>>> without checking the range, because I'm not sure you have the final >>>> heap size at that point. Then maybe the heap reservation code >>>> should report this as a non-internal error, at the point where the >>>> assertion occurs, if the user specified a base address. >>>> >>>> There's also an extraneous single quote in >>>> commandLineFlagConstraintsGC.cpp in the comment at line 510. >>>> >>>> Tom >>>> >>>> >>>> Date: Tue, 24 Nov 2015 06:37:41 -0800 >>>> From: "sangheon.kim" >>>> To: Dmitry Dmitriev, >>>> "hotspot-dev at openjdk.java.net Developers" >>>> >>>> Subject: Re: RFR(S): 8142341: GC: current flags need ranges to be >>>> implemented >>>> Message-ID:<56547635.9060808 at oracle.com> >>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>> >>>> Hi Dmitry, >>>> >>>> Thank you for the review! >>>> Sure I will update my patch related to your enhancement. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote: >>>> >>>>> Hi Sangheon, >>>>> >>>>> Looks good to me! Thank you for fixing that. I hope that enhancement >>>>> will be pushed today(currently in JPRT queue), so please update your >>>>> patch after that! >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>>> On 21.11.2015 0:04, sangheon.kim wrote: >>>>>> Hi all, >>>>>> >>>>>> Could I have a couple of reviews for this change to add explicit >>>>>> 'range' for flags? >>>>>> >>>>>> Previously, we added 'range' when it is needed to avoid assert/crash >>>>>> but now explicit 'range' are needed for all flags. >>>>>> All flags should have 'range' or 'constraint' at least. >>>>>> >>>>>> CR:https://bugs.openjdk.java.net/browse/JDK-8142341 >>>>>> Webrev:http://cr.openjdk.java.net/~sangheki/8142341/webrev.00 >>>>>> Testing: JPRT, RBT >>>>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for >>>>>> embedded >>>>>> >>>>>> * Summary >>>>>> 1. Added 3 new constraint functions. >>>>>> 1) HeapBaseMinAddress: Added to avoid an overflow after align up >>>>>> and this flag makes hang up without constraint function. (newly >>>>>> added >>>>>> as a part of GC work) >>>>>> 2) TLABWasteIncrement: Without this constraint function we don't >>>>>> have problems (even many GCs happen). But added to avoid an overflow >>>>>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are also >>>>>> separate CR for this overflow ( JDK-8143352 ). >>>>>> 3) NUMAInterleaveGranularity: Added to avoid an overflow after >>>>>> align up. >>>>>> >>>>>> 2. Some flags have narrower range than their type. >>>>>> 1) Here's the reason why some flags should have different range. >>>>>> (same order from globals.hpp) >>>>>> {flag type} {flag name}: (range), {comment} >>>>>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), >>>>>> max_uintx), there is a comment at numa_interleaving_init() that this >>>>>> flag should be larger than vm_allocation_granularity(). >>>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as >>>>>> used for multiplication >>>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which >>>>>> has 'unsigned int' type input parameter. >>>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function which >>>>>> has 'unsigned int' type input parameter. >>>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function >>>>>> which has 'long' type input parameter. >>>>>> uintx PausePadding: (0, max_juint), used to set a function which has >>>>>> 'unsigned int' type input parameter. >>>>>> uintx PromotedPadding: (0, max_juint), used to set a function which >>>>>> has 'unsigned int' type input parameter. >>>>>> uintx SurvivorPadding: (0, max_juint), used to set a function which >>>>>> has 'unsigned int' type input parameter. >>>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag >>>>>> is divided by 100 I assume this is percentage. >>>>>> uintx GCTimeRatio: (0, max_juint), used to set a function which has >>>>>> 'unsigned int' type input parameter. >>>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint) >>>>>> intx PrefetchScanIntervalInBytes: (-1, max_jint) >>>>>> intx PrefetchFieldsAhead: (-1, max_jint), I think these 3 Prefetch* >>>>>> flags should have same upper limit and looking at their related >>>>>> codes >>>>>> 'max_jint' seems appropriate ( no problem with 'max_jint' during >>>>>> testing). However, as Prefetch::read/write() needs 'intx', 'intx' >>>>>> also seems good but we have to fix some codes (maybe including >>>>>> generated codes). >>>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function which >>>>>> has 'unsigned int' type input parameter. >>>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint >>>>>> variable and used 'for loop' which has uint increment. i.e. for >>>>>> (uint >>>>>> i=0; i>>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at >>>>>> 'increment for loop()' as max value and the increment is uint. >>>>>> uintx CMSYieldSleepCount: (0, max_juint), used at 'increment for >>>>>> loop()' as max value and the increment is uint. >>>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return >>>>>> value >>>>>> of uint type function and for division. i.e. uint >>>>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return >>>>>> TLABRefillWasteFraction; } >>>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int) >>>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we >>>>>> only >>>>>> use " if (a !=0, >0, >1)". >>>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we >>>>>> only >>>>>> use " if (a !=0, >0, >1)". >>>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only >>>>>> use >>>>>> " if (a !=0, >0)". >>>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned >>>>>> int' >>>>>> >>>>>> (g1_globals.hpp) >>>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int) >>>>>> type variable. >>>>>> >>>>>> 3. Excluded flags from TestOptionsWithRanges.java >>>>>> 1) Memory and thread related flags: tests for these flags will >>>>>> consume too many resources from the system. >>>>>> 2) VMThreadStackSize: range work for this flag is not included in >>>>>> this patch but I faced OOME several times, so excluded. >>>>>> >>>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] >>>>>> TestOptionsWithRanges: allow excluding only a subset of tested >>>>>> values >>>>>> specified for a flag) next time. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>> >>> >> > From stefan.karlsson at oracle.com Thu Dec 3 09:09:09 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 3 Dec 2015 10:09:09 +0100 Subject: RFR (XS) 8143615 compactHashtable.hpp includes oop.inline.hpp file In-Reply-To: <565FA9BC.2080808@oracle.com> References: <565FA9BC.2080808@oracle.com> Message-ID: <566006B5.7010500@oracle.com> Hi Ioi, Thanks a lot for fixing this! Would you mind swapping these lines around?: #include "classfile/javaClasses.hpp" +#include "classfile/compactHashtable.inline.hpp" Except for that nit, this looks good. As David says, we should get rid of the allocation.inline.hpp include as well, but I think we could defer that to a separate patch (if you want to). Thanks, StefanK On 2015-12-03 03:32, Ioi Lam wrote: > Please review a very small fix: > > http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp/ > > Bug: compactHashtable.hpp includes oop.inline.hpp file > > https://bugs.openjdk.java.net/browse/JDK-8143615 > > Summary of fix: > > + deleted the include of oop.inline.hpp from compactHashtable.hpp > + moved all inlined functions that require oop.inline.hpp into a > new file, compactHashtable.inline.hpp > > Tests: > > JPRT > > Thanks > - Ioi From paul.sandoz at oracle.com Thu Dec 3 09:41:03 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Dec 2015 10:41:03 +0100 Subject: Testing Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <565F7D80.7060708@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <9C417D00-F022-4CF6-87D3-0AF74CCD7441@oracle.com> <565F1A5A.4040509@oracle.com> <8D34B054-1832-428A-8A00-C7C5E1056061@oracle.com> <565F7D80.7060708@oracle.com> Message-ID: <4EC53498-5497-47F1-A98B-971B52360C69@oracle.com> Hi Coleen, Thanks for the useful information. I am surprised that the Java class used by jtreg to execute the test in the generated script gets in the way of debugging the VM since it?s all executed from within the same process. Within a few minutes I was able to successfully debug in the VM using jtreg + testng on my Mac by prefixing the java command with "lldb --?. [*] The annoying part was actually dealing with the ?$? character for the launcher class "com.sun.javatest.regtest.TestNGAction$TestNGRunner? :-) With a little more time i replaced the jtreg launcher with the explicit testng launcher (just to reduce a layer, if it makes any difference). However, this is harder than it should be because the version of testng bundled with jtreg is missing stuff. It does involve the jtreg and testing launcher but is that really a major issue? If the test fails when running with the launcher class then presumably debugging wise it?s also useful to run with that too? but i can understand in certain cases it may be preferable not to do that. Overall, with my admittedly more JDK core libraries goggles, on the above does not seems that different to your existing process. ? Perhaps jtreg could be enhanced to make it easier to execute the test under gdb or lldb? Paul. [*] Here is an example requiring two modifications to the script jtreg output: DISPLAY=/private/tmp/com.apple.launchd.dfh3MfqE9D/org.macosforge.xquartz:0 \ HOME=/Users/sandoz \ JTREG_HOME=/Users/sandoz/Applications/jtreg \ LANG=en_GB.UTF-8 \ PATH=/bin:/usr/bin \ lldb -- /Users/sandoz/Projects/jdk9/hs-comp/build/macosx-x86_64-normal-server-release/jdk/bin/java \ -Dtest.class.path.prefix=/Users/sandoz/Projects/jdk9/hs-comp/jdk/JTwork/classes/java/util/Arrays:/Users/sandoz/Projects/jdk9/hs-comp/jdk/test/java/util/Arrays \ -Dtest.src=/Users/sandoz/Projects/jdk9/hs-comp/jdk/test/java/util/Arrays \ -Dtest.src.path=/Users/sandoz/Projects/jdk9/hs-comp/jdk/test/java/util/Arrays \ -Dtest.classes=/Users/sandoz/Projects/jdk9/hs-comp/jdk/JTwork/classes/java/util/Arrays \ -Dtest.class.path=/Users/sandoz/Projects/jdk9/hs-comp/jdk/JTwork/classes/java/util/Arrays \ -Dtest.vm.opts='-ea -esa' \ -Dtest.tool.vm.opts='-J-ea -J-esa' \ -Dtest.compiler.opts= \ -Dtest.java.opts= \ -Dtest.jdk=/Users/sandoz/Projects/jdk9/hs-comp/build/macosx-x86_64-normal-server-release/jdk \ -Dcompile.jdk=/Users/sandoz/Projects/jdk9/hs-comp/build/macosx-x86_64-normal-server-release/jdk \ -Dtest.timeout.factor=1.0 \ -classpath /Users/sandoz/Applications/jtreg/lib/javatest.jar:/Users/sandoz/Applications/jtreg/lib/jtreg.jar:/Users/sandoz/Applications/jtreg/lib/testng.jar:/Users/sandoz/Projects/jdk9/hs-comp/jdk/JTwork/classes/java/util/Arrays:/Users/sandoz/Projects/jdk9/hs-comp/jdk/test/java/util/Arrays \ com.sun.javatest.regtest.TestNGAction\\\$TestNGRunner java/util/Arrays/ArraysEqCmpTest.java ArraysEqCmpTest > On 3 Dec 2015, at 00:23, Coleen Phillimore wrote: > > > Thank you Stefan for making the distinction between debugging Java inside an IDE vs. the JVM. > > On 12/2/15 6:00 PM, Paul Sandoz wrote: >> Hi Stefan, >> >>> On 2 Dec 2015, at 17:20, Stefan S?rne wrote: >>> >>> >>> Hi Paul, >>> >>> The reason we stick on standard jtreg tests is because it is simpler. >>> For us, a java test is not a unit test, it is an application. :) >>> >> I tend to think of that as an artificial distinction since such java test classes often contain a logical grouping of tests (and perhaps data over which to test) and make test assertions. Let?s call it duck unit testing, it looks and quacks like a unit test :-) >> >>> I agree with you that when writing and debugging java code, I would choose testng over jtreg and run and debug it inside my java IDE. >> In the case of the JDK it's not jtreg over testng it is jtreg + testng. > > We already use jtreg and do not welcome another layer on the java class files. > > When debugging a jtreg failure, I go to the "rerun" section in the .jtr file. Edit it for 10 minutes to remove the extra '\' at the end and remove jtreg so that I get simply: > > export CLASSPATH=... > java ClassFile > > and save it to a rerun.sh file. > > I haven't figured out which -D test option I need for the test, but try to remove most of them also. > > Generally, I debug like: > > gdb --args $JAVA_HOME/bin/java ClassFile > > What we're interested in is generally in the ClassFile and not in the jtreg java code. > > I do not want to spend an additional 10 minutes to hack out testng. > > Also, if the test fails and has a agent.jar file, that's usually found in the directory below, so I have to copy my rerun.sh file there. >> >> >>> But debugging the VM is instead done with a native debugger and what the framework gives you for java development, becomes a level of indirection in VM land. Just adding the test class as argument to the java launcher where a main method exists is preferred. >>> >> How do HotSpot engineers debug the VM with a jtreg test that uses @library (or @module once Jigsaw gets integrated), or uses WhiteBox, or uses ProcessTools? > > See above. Luckily CLASSPATH points to it in the end of the jtr file. > > So no. We do not want testng harness code added to the the Hotspot runtime tests. > > Coleen >> >> Paul. > From paul.sandoz at oracle.com Thu Dec 3 09:51:07 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Dec 2015 10:51:07 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <565FAFBA.9060405@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <565DF808.7060806@oracle.com> <565FAFBA.9060405@oracle.com> Message-ID: <3403D394-DB0F-4419-A799-DA2AABBC15A8@oracle.com> > On 3 Dec 2015, at 03:58, Coleen Phillimore wrote: > > > I finally had a chance to look at this. Why are there pages of commit messages in these webrevs? > Not sure, it seems to be a bug with webrev (and may be a consequence of the interaction with patch queues, but i have not had time to dig into why this occurs). > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/src/share/vm/prims/unsafe.cpp.udiff.html > > +static JNINativeMethod sun_misc_Unsafe_methods[] = { > > This looks like a copy of the list of methods that we already have. > It's currently a subset of jdk_internal_misc_Unsafe_methods, notice that the entries for the following are not present in sun_misc_Unsafe_methods: private native boolean unalignedAccess0(); private native boolean isBigEndian0(); The internal one will further diverge later on as we include additional access methods, and may likely becoming intersecting sets. Hence i deliberately kept them separate. > +static JNINativeMethod jdk_internal_misc_Unsafe_methods[] = { > > Can you just have: > > +static JNINativeMethod sun_misc_Unsafe_methods[] = methods; +static JNINativeMethod jdk_internal_misc_Unsafe_methods[] = methods; ??? > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/JdkInternalMiscUnsafeAccessTestBoolean.java.html > > I don't see the benefit of testng here. The benefits are: 1) Each test is clearly identified 2) Each test runs regardless of the failure of any other test 3) Each test result is reported > You probably already have Assert in our test library. > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/generate-unsafe-access-tests.sh.html > > Is this script and template how these tests were generated? Yes, it?s the same pattern as used in nio tests. If we evolve the tests we will edit the template and run the generation script rather than potentially editing 18 files. > It doesn't seem like it needs to be checked in (and is missing copyright). > Ah, thanks, i will add the copyright. > Maybe since the tests are stressing the compilation characteristics of the unsafe API, these tests belong in the test/compiler/unsafe directory. Maybe the compiler group doesn't mind slogging through testng to find bugs. > But how much of an actual slog is it? (see my reply to you on hotspot-dev) If i cannot persuade you and others in the runtime team (my powers of persuasion are failing and it is looking unlikely, but i am still trying :-) ), i will move them to the idk test area. Thanks, Paul. From volker.simonis at gmail.com Thu Dec 3 10:03:07 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 3 Dec 2015 11:03:07 +0100 Subject: RFR(L): 8143125: [aix] Further Developments for AIX In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC41ED076B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41ED242C@DEWDFEMB12A.global.corp.sap> Message-ID: Great - I think the change is now ready to push :) Thanks, Volker On Thu, Dec 3, 2015 at 10:07 AM, Thomas St?fe wrote: > Hi Volker, > > thank you for all that work! See my comments inline. > > On Wed, Dec 2, 2015 at 11:19 AM, Volker Simonis > wrote: >> >> Hi Thomas, >> >> thanks a lot for this nice cleanup. Please find my remaining comments >> below: >> >> libo4.hpp >> ======= >> - please update the copyright year >> - remove the following comments which reference SAP path or bugs >> >> 45 // See libo4.h (at //bas2/sapjvm/dev/common/libs/libo4/include) >> 46 // for details on this API. >> >> 59 // See libo4.h (at //bas2/sapjvm/dev/common/libs/libo4/include) >> 60 // for details on this API. >> >> 72 // See also CSN Internal Message 0001182318 2008 >> 73 // >> 74 // See libo4.h (at //bas2/sapjvm/dev/common/libs/libo4/include) >> 75 // for details on this API. >> >> libo4.cpp >> ======= >> - please update the copyright year >> >> vmStructs_aix_ppc.hpp >> ================= >> - please update the copyright year >> >> > > All fixed. > >> >> misc_aix.hpp >> ========== >> - "trc" is defined to the empty string and doesn't seemed to be used >> anywhere: >> >> 45 #define trc(fmt, ...) >> >> do we still need it? >> > > I removed it. > >> >> os_aix.cpp >> ======== >> - why do we need the following define right in-between the includes: >> >> 76 #include "utilities/defaultStream.hpp" >> 77 #define PV_8_Compat 0x308000 /* Power PC 8 */ >> 78 #include "utilities/events.hpp" >> >> it doesn't seem to be used in os_aix.cpp >> > > Fixed. > >> >> - you replaced most of the logging with trcVerbose but there are still >> tow or three places using fprintf and jio_fprintf. Could you please >> replace them by calls to trcVerbose as well. >> > > Fixed. All those trcVerbose calls are ugly crutches; I plan to transform all > these trcVerbose calls to the new Unified Logging in the near future, just > to get a feel for it. > >> >> - I can't see where the kernel thread id is initialized. Shouldn't you >> call set_kernel_thread_id() from os::create_thread and >> os::create_attached_thread() ? >> > > Good catch, fixed. > >> >> - in os::commit_memory() are you sure you always have 4K pages: >> >> 2342 if (UseExplicitCommit) { >> 2343 // AIX commits memory on touch. So, touch all pages to be >> committed. >> 2344 for (char* p = addr; p < (addr + size); p += SIZE_4K) { >> 2345 *p = '\0'; >> 2346 } >> 2347 } >> >> >> >> wouldn?t it be better (i.e. potentially faster) to use >> os::vm_page_size() instead of SIZE_4K ? >> > > Unfortunately, I cannot be sure. It may be possible to find out, but it > seems easier to just do 4K paged touching. Once the page is paged in, it > should not cost much. Note also that this is a development option and > normally off. > >> >> - it doesn't seem we use '_large_page_size'. We statically initialize >> it to '0' and later on in os::init() to '-1'. Better remove it and >> directly return '0' (or '-1') from os::large_page_size(). >> > > True. But I still left that in, because the other platforms have the same > code in them (eg bsd and solaris, which both don't seem to support large > pages either). This is worth a cleanup, but should be done cross platform in > a different patch. > >> >> libperfstat_aix.{cpp, hpp} >> ================== >> - please update the copyright year >> - I want to second Goetz - we really don't need >> perfstat_cpu_total_t_52. Please remove it from both >> libperfstat_aix.{cpp, hpp} >> > > Ok, I removed the AIX 5.2 structure definitions. As I explained before, I > was afraid of cutting off old, unpatched AIX 5.3 releases as well, if they > still happen to carry an old libperfstat. But you guys seem to really want > this removed, so I removed it. > >> >> loadlib_aix.cpp >> ================== >> - please update the copyright year > > > Fixed >> >> >> misc_aix.{hpp,cpp} >> ============== >> - I don't see why we need MiscUtils::describe_errno(). Can you please >> instead use strerror() to get the error message (as we already do in a >> lot of other places, e.g. in os_aix.cpp). That said, I realized that >> strerror() is not thread-safe. So we should probably change it to the >> POSIX function strerror_r(). But this is not only an AIX problem, so >> better do that in a follow up change. >> > > Ok, I removed MiscUtils::desribe_errno(). > > I really do not like strerror(), though: > - it is not threadsafe, which is quite unnecessary > - strerror_r is threadsafe but may fail and requires error handling if done > correctly > - it gives lenghty, localized (!) error descriptions, which clog up log > files and are less easy to grep for. > - it carries the risk of not printing anything at all if the locale is set > weird, e.g. "????" for japanese LC_MESSAGES. Just google for "strerror > useless" > > All in all I think strerror is not good for the task of printing errno > values into log files which are to be consumed by programmers, not users. > > But for now I removed describe_errno and replaced it with printing the > numeric value of the errno. Maybe we can have this strerror discussion in > the mailing list, see what others think. > >> >> - the same holds true for MiscUtils::sleep_ms(). Why do we need yet >> another AIX-specific helper function? Moreover, it is used only once. >> Can you please instead use usleep() or sleep() directly, depending on >> how long you want to wait. (Just as a side note: your current >> implementation of sleep_ms() would sleep for three seconds if called >> with 1000ms as argument, and it would call usleep() with an argument >> of 1.000.000 which should be avoided according to your comment (which >> I couldn't verify in the AIX man-page (see >> >> https://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.basetechref/doc/basetrf2/sleep.htm))). >> So please remove MiscUtils::sleep_ms(). >> > > Ok, I did remove this and replaced the one call with plain usleep. > > The error was embarrassing :) thanks for catching that. > > As for the "1.000.000" restriction, that comes from Linux. > MiscUtils::sleep_ms is used crossplatform in the SAP JVM. > > >> >> There's no need to provide a new webrev, if you check that the your >> latest changes will build and run. >> >> Thank you and best regards, >> Volker >> > > Thanks again! > > ..Thomas > > >> >> >> On Thu, Nov 26, 2015 at 9:29 AM, Lindenmaier, Goetz >> wrote: >> > Hi Thomas, >> > >> > thanks a lot for doing all these changes. >> > Looks good now. >> > >> > Could you add the change comment to the patch before you >> > Make a webrev next time? Simplifies sponsoring ;) >> > >> > Best regards, >> > Goetz. >> > >> > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >> > Sent: Mittwoch, 25. November 2015 18:01 >> > To: Lindenmaier, Goetz >> > Cc: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers >> > >> > Subject: Re: RFR(L): 8143125: [aix] Further Developments for AIX >> > >> > Hi Goetz, >> > >> > new webrev: >> > http://cr.openjdk.java.net/~stuefe/webrevs/8143125-Further/webrev.01/webrev/ >> > >> > thank you for reviewing! See remarks inline... >> > >> > On Tue, Nov 24, 2015 at 12:38 PM, Lindenmaier, Goetz >> > > wrote: >> > Hi Thomas, >> > >> > I looked at your change. It?s good we get these improvements into >> > openJDK. But I think we should skip some stuff that's not (yet?) >> > used there. I'll sponsor the change. Details: >> > >> > libperfstat_aix.cpp: >> > >> > What do you need >> > static fun_perfstat_partition_total_t g_fun_perfstat_partition_total = >> > NULL; >> > static fun_perfstat_wpar_total_t g_fun_perfstat_wpar_total = NULL; >> > static fun_wpar_getcid_t g_fun_wpar_getcid = NULL; >> > for? I think they are never used. >> > >> > They are now used (for the respective wrapper functions which in turn >> > are used in os_aix.cpp. Sorry for omitting this code. >> > >> > libperfstat_aix.cpp:161 >> > We support AIX 5.3 with xlC12 only. I think we need not add the older >> > #defines to openJDK. Also, the comment should be adapted and not mention >> > xlc8 etc. >> > Also, there are datastructures for 5.2 which can be removed. >> > >> > Removed the older defines. >> > I would for now prefer to leave the AIX 5.2 data structures in this >> > file. I am not sure if we could encounter older libperfstat versions on AIX >> > 5.3 too. I plan to rework this coding to get rid of the duplicate structure >> > definitions, but would prefer to do this in a separate patch. >> > >> > >> > Where is this used? >> > bool libperfstat::get_wparinfo(wparinfo_t* pwi) >> > Do we need it if it's not used? >> > >> > It is now used :) in os_aix.cpp. >> > >> > >> > libperfstat.hpp:835 >> > I would remove these prototypes commented out. >> > >> > I removed them. >> > >> > loadlib_aix.cpp >> > Why do you do these changes? Please revert them. >> > >> > I reverted them. >> > >> > os_aix.hpp:219 >> > What's this good for? >> > get_brk_at_startup() >> > get_lowest_allocation_above_brk() >> > >> > I removed those prototypes. >> > >> > os_aix.hpp:259 >> > What's this good for? >> > parse_qsyslib_path() >> > >> > I removed this prototype. >> > >> > os_aix.cpp:410 >> > Why do you move query_multipage_support()? >> > >> > I moved this back to its original position. >> > >> > os_aix.inline.hpp:164 >> > Why do you reverse the order of the functions here? >> > The old order is the same as in the related files os_linux.inline.hpp >> > etc. >> > >> > I reversed the order back to original order. >> > >> > Best regards, >> > Goetz. >> > >> > >> > Kind Regards, Thomas >> > >> > >> >> -----Original Message----- >> >> From: hotspot-dev >> >> [mailto:hotspot-dev-bounces at openjdk.java.net] >> >> On >> >> Behalf Of Thomas St?fe >> >> Sent: Freitag, 20. November 2015 11:49 >> >> To: >> >> ppc-aix-port-dev at openjdk.java.net; >> >> HotSpot Open Source Developers >> >> Subject: RFR(L): 8143125: [aix] Further Developments for AIX >> >> >> >> Hi all, >> >> >> >> please review and sponsor these AIX only changes. Basically, with this >> >> change we bring the OpenJDK AIX hotspot port up to speed with the >> >> developments done at SAP in the recent months. >> >> >> >> For a more detailled number of changes and fixes, please refer to the >> >> bug >> >> description. >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8143125 >> >> webrev: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8143125- >> >> Further/webrev.00/webrev/index.html >> >> >> >> Kind Regards, Thomas >> > > > From jaroslav.bachorik at oracle.com Thu Dec 3 11:09:12 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 3 Dec 2015 12:09:12 +0100 Subject: RFR 8141526: Allow to collect stdout/stderr from the FinalizationRunner even before the process returns In-Reply-To: <56562D60.80306@oracle.com> References: <563CD13B.8040800@oracle.com> <56562D60.80306@oracle.com> Message-ID: <566022D8.5000706@oracle.com> On 25.11.2015 22:51, Dmitry Samersoff wrote: > Jaroslav, > > Looks good for me. > > PS: I found a bug in canPtraceAttachLinux not related to your changes - > it's probably my mistake: > > 181 if (userName.equals("root")) { > 182 return true; > 183 } > > shouldn't be there. > > Could you file a separate CR and assign it to me? Actually, it is the result of my merge of the hotspot and jdk version of Platform.java. I will just remove it from there: http://cr.openjdk.java.net/~jbachorik/8141526/webrev.01 -JB- > > -Dmitry > > On 2015-11-06 19:11, Jaroslav Bachorik wrote: >> [wider audience included] >> >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8141526 >> Webrev: >> top> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00 >> hotspot> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/hotspot >> jdk> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/jdk >> >> After the fix for https://bugs.openjdk.java.net/browse/JDK-8135188 we >> are not able to get the debug info about the run of the launcher >> FinalizationRunner application in case it gets stuck and harness times >> out. This is because the stdout/err of the application started via >> ProcessTools.executeProcess() is collected only after the application >> has exited. >> >> The solution is to use ProcessTools.startProcess() and consume the >> application stdout/err in a streaming mode. Because this method has only >> been available in the 'jdk' version of ProcessTools and not in the >> 'hotspot' one I decided to merge both of those versions and place the >> merged version into the shared location 'test/lib/share/classes/'. >> During this I decided to change the package for the shared ProcessTools >> class to be 'jdk.test.lib.process' to be more in line with the way this >> shared library is structured. I had to move few other lib classes >> required by ProcessTools to the shared lib as well. All the moved lib >> classes have been marked as deprecated in their original location. >> >> >> Thanks, >> >> -JB- >> > > From dmitry.samersoff at oracle.com Thu Dec 3 12:29:19 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 3 Dec 2015 15:29:19 +0300 Subject: RFR 8141526: Allow to collect stdout/stderr from the FinalizationRunner even before the process returns In-Reply-To: <566022D8.5000706@oracle.com> References: <563CD13B.8040800@oracle.com> <56562D60.80306@oracle.com> <566022D8.5000706@oracle.com> Message-ID: <5660359F.7000702@oracle.com> Jaroslav, Looks good for me! -Dmitry On 2015-12-03 14:09, Jaroslav Bachorik wrote: > On 25.11.2015 22:51, Dmitry Samersoff wrote: >> Jaroslav, >> >> Looks good for me. >> >> PS: I found a bug in canPtraceAttachLinux not related to your changes - >> it's probably my mistake: >> >> 181 if (userName.equals("root")) { >> 182 return true; >> 183 } >> >> shouldn't be there. >> >> Could you file a separate CR and assign it to me? > > Actually, it is the result of my merge of the hotspot and jdk version of > Platform.java. I will just remove it from there: > http://cr.openjdk.java.net/~jbachorik/8141526/webrev.01 > > -JB- > >> >> -Dmitry >> >> On 2015-11-06 19:11, Jaroslav Bachorik wrote: >>> [wider audience included] >>> >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8141526 >>> Webrev: >>> top> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00 >>> hotspot> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/hotspot >>> jdk> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/jdk >>> >>> After the fix for https://bugs.openjdk.java.net/browse/JDK-8135188 we >>> are not able to get the debug info about the run of the launcher >>> FinalizationRunner application in case it gets stuck and harness times >>> out. This is because the stdout/err of the application started via >>> ProcessTools.executeProcess() is collected only after the application >>> has exited. >>> >>> The solution is to use ProcessTools.startProcess() and consume the >>> application stdout/err in a streaming mode. Because this method has only >>> been available in the 'jdk' version of ProcessTools and not in the >>> 'hotspot' one I decided to merge both of those versions and place the >>> merged version into the shared location 'test/lib/share/classes/'. >>> During this I decided to change the package for the shared ProcessTools >>> class to be 'jdk.test.lib.process' to be more in line with the way this >>> shared library is structured. I had to move few other lib classes >>> required by ProcessTools to the shared lib as well. All the moved lib >>> classes have been marked as deprecated in their original location. >>> >>> >>> Thanks, >>> >>> -JB- >>> >> >> > -- 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 aph at redhat.com Thu Dec 3 13:00:26 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 3 Dec 2015 13:00:26 +0000 Subject: RFR: 8144582: AArch64 does not generate correct branch profile data Message-ID: <56603CEA.9050500@redhat.com> This is a trivial matter of register corruption. It turns out that this has always been wrong, but it doesn't do anything significant unless you use -Xbatch -XX:-TieredCompilation. I also added a using statement to silence a compiler warning. http://cr.openjdk.java.net/~aph/8144582/ Andrew. From coleen.phillimore at oracle.com Thu Dec 3 13:12:41 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 3 Dec 2015 08:12:41 -0500 Subject: Testing Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <4EC53498-5497-47F1-A98B-971B52360C69@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <9C417D00-F022-4CF6-87D3-0AF74CCD7441@oracle.com> <565F1A5A.4040509@oracle.com> <8D34B054-1832-428A-8A00-C7C5E1056061@oracle.com> <565F7D80.7060708@oracle.com> <4EC53498-5497-47F1-A98B-971B52360C69@oracle.com> Message-ID: <56603FC9.7080000@oracle.com> On 12/3/15 4:41 AM, Paul Sandoz wrote: > Hi Coleen, > > Thanks for the useful information. > > I am surprised that the Java class used by jtreg to execute the test in the generated script gets in the way of debugging the VM since it?s all executed from within the same process. > > Within a few minutes I was able to successfully debug in the VM using jtreg + testng on my Mac by prefixing the java command with "lldb --?. [*] The annoying part was actually dealing with the ?$? character for the launcher class "com.sun.javatest.regtest.TestNGAction$TestNGRunner? :-) > > With a little more time i replaced the jtreg launcher with the explicit testng launcher (just to reduce a layer, if it makes any difference). However, this is harder than it should be because the version of testng bundled with jtreg is missing stuff. > > It does involve the jtreg and testing launcher but is that really a major issue? If the test fails when running with the launcher class then presumably debugging wise it?s also useful to run with that too? but i can understand in certain cases it may be preferable not to do that. Overall, with my admittedly more JDK core libraries goggles, on the above does not seems that different to your existing process. No, we're not trying to debug the launcher but the little java program that we're testing. Do -Xlog:itables=debug with your experiment, or TraceClassInitialization or set a breakpoint in InterpreterRuntime::resolve_invoke. The point is that we don't have extra time to hack out out new frameworks in order to get to the problem that we're trying to solve. It's a time issue, not a possibility issue. In your sample below, I'd hack out at least 10 more lines to get to the java class for the test program but I haven't had time to test if this works yet. Last time I tried to debug a test with testng in jdk/test/java/lang/invoke, I had to run it in the background and do 'ps' to find the java command. I may have had to give up and look through the hotspot sources. As I said, you can see if the compiler group will accept these tests. They seem to belong in the hotspot repository, not the jdk repository because we run these tests with JPRT. Coleen > > ? > > Perhaps jtreg could be enhanced to make it easier to execute the test under gdb or lldb? > > Paul. > > [*] Here is an example requiring two modifications to the script jtreg output: > > DISPLAY=/private/tmp/com.apple.launchd.dfh3MfqE9D/org.macosforge.xquartz:0 \ > HOME=/Users/sandoz \ > JTREG_HOME=/Users/sandoz/Applications/jtreg \ > LANG=en_GB.UTF-8 \ > PATH=/bin:/usr/bin \ > lldb -- /Users/sandoz/Projects/jdk9/hs-comp/build/macosx-x86_64-normal-server-release/jdk/bin/java \ > -Dtest.class.path.prefix=/Users/sandoz/Projects/jdk9/hs-comp/jdk/JTwork/classes/java/util/Arrays:/Users/sandoz/Projects/jdk9/hs-comp/jdk/test/java/util/Arrays \ > -Dtest.src=/Users/sandoz/Projects/jdk9/hs-comp/jdk/test/java/util/Arrays \ > -Dtest.src.path=/Users/sandoz/Projects/jdk9/hs-comp/jdk/test/java/util/Arrays \ > -Dtest.classes=/Users/sandoz/Projects/jdk9/hs-comp/jdk/JTwork/classes/java/util/Arrays \ > -Dtest.class.path=/Users/sandoz/Projects/jdk9/hs-comp/jdk/JTwork/classes/java/util/Arrays \ > -Dtest.vm.opts='-ea -esa' \ > -Dtest.tool.vm.opts='-J-ea -J-esa' \ > -Dtest.compiler.opts= \ > -Dtest.java.opts= \ > -Dtest.jdk=/Users/sandoz/Projects/jdk9/hs-comp/build/macosx-x86_64-normal-server-release/jdk \ > -Dcompile.jdk=/Users/sandoz/Projects/jdk9/hs-comp/build/macosx-x86_64-normal-server-release/jdk \ > -Dtest.timeout.factor=1.0 \ > -classpath /Users/sandoz/Applications/jtreg/lib/javatest.jar:/Users/sandoz/Applications/jtreg/lib/jtreg.jar:/Users/sandoz/Applications/jtreg/lib/testng.jar:/Users/sandoz/Projects/jdk9/hs-comp/jdk/JTwork/classes/java/util/Arrays:/Users/sandoz/Projects/jdk9/hs-comp/jdk/test/java/util/Arrays \ > com.sun.javatest.regtest.TestNGAction\\\$TestNGRunner java/util/Arrays/ArraysEqCmpTest.java ArraysEqCmpTest > > >> On 3 Dec 2015, at 00:23, Coleen Phillimore wrote: >> >> >> Thank you Stefan for making the distinction between debugging Java inside an IDE vs. the JVM. >> >> On 12/2/15 6:00 PM, Paul Sandoz wrote: >>> Hi Stefan, >>> >>>> On 2 Dec 2015, at 17:20, Stefan S?rne wrote: >>>> >>>> >>>> Hi Paul, >>>> >>>> The reason we stick on standard jtreg tests is because it is simpler. >>>> For us, a java test is not a unit test, it is an application. :) >>>> >>> I tend to think of that as an artificial distinction since such java test classes often contain a logical grouping of tests (and perhaps data over which to test) and make test assertions. Let?s call it duck unit testing, it looks and quacks like a unit test :-) >>> >>>> I agree with you that when writing and debugging java code, I would choose testng over jtreg and run and debug it inside my java IDE. >>> In the case of the JDK it's not jtreg over testng it is jtreg + testng. >> We already use jtreg and do not welcome another layer on the java class files. >> >> When debugging a jtreg failure, I go to the "rerun" section in the .jtr file. Edit it for 10 minutes to remove the extra '\' at the end and remove jtreg so that I get simply: >> >> export CLASSPATH=... >> java ClassFile >> >> and save it to a rerun.sh file. >> >> I haven't figured out which -D test option I need for the test, but try to remove most of them also. >> >> Generally, I debug like: >> >> gdb --args $JAVA_HOME/bin/java ClassFile >> >> What we're interested in is generally in the ClassFile and not in the jtreg java code. >> >> I do not want to spend an additional 10 minutes to hack out testng. >> >> Also, if the test fails and has a agent.jar file, that's usually found in the directory below, so I have to copy my rerun.sh file there. >>> >>>> But debugging the VM is instead done with a native debugger and what the framework gives you for java development, becomes a level of indirection in VM land. Just adding the test class as argument to the java launcher where a main method exists is preferred. >>>> >>> How do HotSpot engineers debug the VM with a jtreg test that uses @library (or @module once Jigsaw gets integrated), or uses WhiteBox, or uses ProcessTools? >> See above. Luckily CLASSPATH points to it in the end of the jtr file. >> >> So no. We do not want testng harness code added to the the Hotspot runtime tests. >> >> Coleen >>> Paul. From goetz.lindenmaier at sap.com Thu Dec 3 13:14:01 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 3 Dec 2015 13:14:01 +0000 Subject: RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions In-Reply-To: <565FA1C1.50909@oracle.com> References: <565FA1C1.50909@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> Hi Coleen, I've been looking at this change. A cleanup in this area is really useful. I missed templateInterpreter_ppc.cpp in your patch, I guess you forgot "hg add" for it. In addition, I had to fix some code around math_entry_available(), see this patch: http://cr.openjdk.java.net/~goetz/webrevs/8144534-interp/8144534-fixes_for_ppc.patch In general, I think it's strange that AbstractInterpreterGenerator implementations are in interpreter_.cpp, as mentioned In the bug. Why not move them to templateInterpreterGenerator_.cpp? Or will this be subject to a later change that removes the funny common subclasses Interpreter/InterpreterGenerator? Should I make a change removing the CC_INTERP support from ppc? Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Coleen Phillimore > Sent: Donnerstag, 3. Dezember 2015 02:58 > To: hotspot-dev developers > Subject: RFR 8144534: Refactor templateInterpreter and > templateInterpreterGenerator functions > > Summary: merged templateInterpreter_x86_32/64 into > templateInterpreterGenerator_x86.cpp (some 32/64 functions remain for > the hand coded crc functions). > > open webrev at http://cr.openjdk.java.net/~coleenp/8144534.01/ > bug link https://bugs.openjdk.java.net/browse/JDK-8144534 > > I tried to make this reviewable by hg renaming files. I basically > renamed templateInterpreter_ppc.cpp and removed the > AbstractInterpreter > functions and put them back into templateInterpreter_ppc.cpp. I didn't > really delete 4000 lines of code, more like 1500. > > Also, can someone with the PPC and AARCH port look at and test out these > changes? I tried to reduce the #includes in the new > templateInterpreter_ppc/aarch64.cpp files which worked for sparc. > > Tested with JPRT on all platforms, also ran jtreg and > collocated/non-collocated tonga tests for linux x64 and i386 since > that's were the real changes are. > > See the bug for more details and my partial vision of how these > functions will be reorganized when I remove the broken c++ interpreter. > > Also tested that Zero still builds. > > Thanks! > Coleen > From coleen.phillimore at oracle.com Thu Dec 3 13:16:06 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 3 Dec 2015 08:16:06 -0500 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <3403D394-DB0F-4419-A799-DA2AABBC15A8@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <565DF808.7060806@oracle.com> <565FAFBA.9060405@oracle.com> <3403D394-DB0F-4419-A799-DA2AABBC15A8@oracle.com> Message-ID: <56604096.7080401@oracle.com> On 12/3/15 4:51 AM, Paul Sandoz wrote: >> On 3 Dec 2015, at 03:58, Coleen Phillimore wrote: >> >> >> I finally had a chance to look at this. Why are there pages of commit messages in these webrevs? >> > Not sure, it seems to be a bug with webrev (and may be a consequence of the interaction with patch queues, but i have not had time to dig into why this occurs). I think this is a bug with the interaction with your patch queues. Before you send stuff out for review (at least to the hotspot lists), can you export the patch into a clean repository so that we don't have to find the changes in pages of stuff? > > >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/src/share/vm/prims/unsafe.cpp.udiff.html >> >> +static JNINativeMethod sun_misc_Unsafe_methods[] = { >> >> This looks like a copy of the list of methods that we already have. >> > It's currently a subset of jdk_internal_misc_Unsafe_methods, notice that the entries for the following are not present in sun_misc_Unsafe_methods: > > private native boolean unalignedAccess0(); > private native boolean isBigEndian0(); > > The internal one will further diverge later on as we include additional access methods, and may likely becoming intersecting sets. Hence i deliberately kept them separate. > > >> +static JNINativeMethod jdk_internal_misc_Unsafe_methods[] = { >> >> Can you just have: >> >> +static JNINativeMethod sun_misc_Unsafe_methods[] = methods; +static JNINativeMethod jdk_internal_misc_Unsafe_methods[] = methods; ??? >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/JdkInternalMiscUnsafeAccessTestBoolean.java.html >> >> I don't see the benefit of testng here. > The benefits are: > > 1) Each test is clearly identified > 2) Each test runs regardless of the failure of any other test > 3) Each test result is reported > > >> You probably already have Assert in our test library. >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/generate-unsafe-access-tests.sh.html >> >> Is this script and template how these tests were generated? > Yes, it?s the same pattern as used in nio tests. If we evolve the tests we will edit the template and run the generation script rather than potentially editing 18 files. That seems ok, as long as running the script isn't part of the testing. > >> It doesn't seem like it needs to be checked in (and is missing copyright). >> > Ah, thanks, i will add the copyright. > > >> Maybe since the tests are stressing the compilation characteristics of the unsafe API, these tests belong in the test/compiler/unsafe directory. Maybe the compiler group doesn't mind slogging through testng to find bugs. >> > But how much of an actual slog is it? (see my reply to you on hotspot-dev) > > If i cannot persuade you and others in the runtime team (my powers of persuasion are failing and it is looking unlikely, but i am still trying :-) ), i will move them to the idk test area. As I said in my last email, the test should be in the hotspot test repositories because it seems like compiler changes could break them and we'd want to run the tests with each putback. See if the compiler group can tolerate an additional harness. Coleen > Thanks, > Paul. From coleen.phillimore at oracle.com Thu Dec 3 13:22:33 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 3 Dec 2015 08:22:33 -0500 Subject: RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> References: <565FA1C1.50909@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> Message-ID: <56604219.9080904@oracle.com> Goetz, Thank you for trying this out and your comments. I was hoping you weren't on vacation... On 12/3/15 8:14 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > I've been looking at this change. A cleanup in this area is really > useful. > I missed templateInterpreter_ppc.cpp in your patch, I guess you forgot > "hg add" for it. > In addition, I had to fix some code around math_entry_available(), see this patch: > http://cr.openjdk.java.net/~goetz/webrevs/8144534-interp/8144534-fixes_for_ppc.patch > > In general, I think it's strange that AbstractInterpreterGenerator > implementations are in interpreter_.cpp, as mentioned In the bug. > Why not move them to templateInterpreterGenerator_.cpp? Or will > this be subject to a later change that removes the funny common > subclasses Interpreter/InterpreterGenerator? Yes. It is strange. I've been confused by where things are for way too long! I think when the CC_INTERP goes away this interpreter_.cpp file will go away and the functions moved to templateInterpreterGenerator_.cpp Or templateIntepreterGenerator_.cpp could be InterpreterGenerator_.cpp and maybe there is no AbstractInterpreterGenerator for Zero. I haven't gotten that far yet and wanted to break this out into chunks so it's possible to do. > > Should I make a change removing the CC_INTERP support from ppc? I can make them when I figure out how to do keep Zero working and can you test them for me? Or you can help remove it and be contributed-by but I don't know if you care about that. Thanks!! and Thanks for the patch. Coleen > > Best regards, > Goetz. > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Coleen Phillimore >> Sent: Donnerstag, 3. Dezember 2015 02:58 >> To: hotspot-dev developers >> Subject: RFR 8144534: Refactor templateInterpreter and >> templateInterpreterGenerator functions >> >> Summary: merged templateInterpreter_x86_32/64 into >> templateInterpreterGenerator_x86.cpp (some 32/64 functions remain for >> the hand coded crc functions). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8144534.01/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8144534 >> >> I tried to make this reviewable by hg renaming files. I basically >> renamed templateInterpreter_ppc.cpp and removed the >> AbstractInterpreter >> functions and put them back into templateInterpreter_ppc.cpp. I didn't >> really delete 4000 lines of code, more like 1500. >> >> Also, can someone with the PPC and AARCH port look at and test out these >> changes? I tried to reduce the #includes in the new >> templateInterpreter_ppc/aarch64.cpp files which worked for sparc. >> >> Tested with JPRT on all platforms, also ran jtreg and >> collocated/non-collocated tonga tests for linux x64 and i386 since >> that's were the real changes are. >> >> See the bug for more details and my partial vision of how these >> functions will be reorganized when I remove the broken c++ interpreter. >> >> Also tested that Zero still builds. >> >> Thanks! >> Coleen >> From frederic.parain at oracle.com Thu Dec 3 14:15:39 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 3 Dec 2015 15:15:39 +0100 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <565F36DA.4060004@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <56548F9B.1000507@oracle.com> <565DC91B.9060206@oracle.com> <565F36DA.4060004@oracle.com> Message-ID: <56604E8B.6010101@oracle.com> All fixed. Thank you Dan. Fred On 02/12/2015 19:22, Daniel D. Daugherty wrote: > > On 12/1/15 9:21 AM, Frederic Parain wrote: >> Hi Dan, >> >> Thank you for your detailed review. >> My answers are in-lined below. >> >> New webrev: >> >> http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/ > > Re-reviewed by comparing 8046936.0[12].hotspot.patch in jfilemerge... > > Just a couple of nits: > > src/os/windows/vm/os_windows.cpp > L2365: assert(fr->safe_for_sender(thread), "Safety check"); > Wrong indent; should be 6 spaces instead of 8; actually I think > this one is a tab. > > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > L381: assert(fr->safe_for_sender(thread), "Safety check"); > Wrong indent; this one also might be a tab > > src/os_cpu/linux_x86/vm/os_linux_x86.cpp > L194: assert(fr->safe_for_sender(thread), "Safety check"); > Wrong indent; this one also might be a tab > > src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp > L267: assert(fr->safe_for_sender(thread), "Safety check"); > Wrong indent; this one also might be a tab > > src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp > L255: assert(fr->safe_for_sender(thread), "Safety check"); > Wrong indent; this one also might be a tab > > > Thumbs up! I do not need to see a webrev for the above nits. > > Dan > > >> >> >> On 24/11/2015 17:26, Daniel D. Daugherty wrote: >>> >>> src/cpu/sparc/vm/frame_sparc.cpp >>> (old) L635: if (fp() - sp() > 1024 + >>> m->max_stack()*Interpreter::stackElementSize) { >>> (new) L635: if (fp() - unextended_sp() > 1024 + >>> m->max_stack()*Interpreter::stackElementSize) { >>> This looks like a bug fix independent of this fix. >> >> Correct, this is the SPARC version of JDK-8068655. >> >>> src/share/vm/runtime/thread.hpp >>> L953: intptr_t* _reserved_stack_activation; >>> L1382: intptr_t* reserved_stack_activation() const { return >>> _reserved_stack_activation; } >>> L1383: void set_reserved_stack_activation(intptr_t* addr) { >>> >>> I was expecting this type to be 'address' instead of >>> 'intptr_t*'. >>> >>> Update: I've gone back through the changes and I still don't >>> see a reason that this is 'intptr_t*'. >> >> The _reserved_stack_activation has been declared as an 'intptr_t*' >> just to be consistent with the _sp and _fp fields of the frame class. >> However, this is not really a requirement, the content stored at the >> _reserved_stack_activation address is never read. This address is just >> a "marker" on the stack to quickly check if the thread has exited the >> annotated code section or not. I've change the type to address, there's >> slightly less casts, and it doesn't impact the ReservedStackArea logic. >> >> Note: I've removed all further comments about _reserved_stack_activation >> type in order to improve the e-mail readability. >> >>> L1341: { return stack_yellow_zone_base();} >>> '{' should be at the end of the previous line. >>> Missing space after ';'. >> >> Fixed >> >>> L1343: { return StackReservedPages * os::vm_page_size(); } >>> '{' should be at the end of the previous line. >> >> Fixed >> >>> src/share/vm/runtime/thread.cpp >>> L2543: // The base notation is from the stacks point of view, >>> growing downward. >>> L2565: // The base notation is from the stacks point of view, >>> growing downward. >>> Typo: "stacks point of view" -> "stack's point of view" >> >> Fixed >> >>> L2552: } else { >>> L2553: warning("Attempt to guard stack reserved zone failed."); >>> L2554: } >>> L2555: enable_register_stack_guard(); >>> >>> Should enable_register_stack_guard() be called when we issued >>> the warning on L2553? >>> >>> L2571: } else { >>> L2572: warning("Attempt to unguard stack reserved zone >>> failed."); >>> L2573: } >>> L2574: disable_register_stack_guard(); >>> >>> Should disable_register_stack_guard() be called when we issued >>> the warning on L2572? >> >> enable_register_stack_guard() and disable_register_stack_guard() are >> relics of the Itanium code (Itanium had a very different stack >> management). These methods are currently empty on all OpenJDK and >> Oracle platforms. May be another clean up opportunity here. >> Regarding the placement of the calls, I followed the same pattern >> as the other red/yellow pages management functions. >> >>> src/share/vm/runtime/sharedRuntime.cpp >>> >>> L784: java_lang_Throwable::set_message(exception_oop, >>> L785: Universe::delayed_stack_overflow_error_message()); >>> Wrong indent; this should line up under the 'e' after the '('. >> >> Fixed >> >>> L2976: if (fr.is_interpreted_frame()) { >>> L2978: prv_fr = fr; >>> L2982: prv_fr = fr; >>> This line is in both branches of the if-statement on L2976. >>> Is there a reason not to save prv_fr before L2976? >> >> No particular reason, fixed. >> >>> L2996 continue; >>> Wrong indent; needs one more space. >> >> Fixed >> >>> L2958: frame activation; >>> L3013: return activation; >>> The return on L3013 can return a default constructed 'frame'. >>> Is that default safe to return here? >> >> Yes, the caller performs a check before using the returned >> frame: >> if (activation.sp() != NULL) { ... >> >>> >>> src/os/bsd/vm/os_bsd.hpp >>> L109: static bool get_frame_at_stack_banging_point(JavaThread* >>> thread, ucontext_t* uc, frame* fr); >>> Wrong indent; needs one less space. >> >> Fixed >> >>> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >>> L322: // For Forte Analyzer AsyncGetCallTrace profiling support - >>> thread >>> L323: // is currently interrupted by SIGPROF. >>> Now fetch_frame_from_ucontext() is also used for stack overflow >>> signal handling. >> >> Fixed >> >>> L379: assert(fr->safe_for_sender(thread), "Safety check"); >>> L380: if (!fr->is_first_java_frame()) { >>> L381: *fr = fr->java_sender(); >>> The assert() on L379 should be before the java_sender() >>> call on L381. >> >> Fixed >> >>> src/os/linux/vm/os_linux.cpp >>> L1902: jt->stack_guards_enabled()) { // No pending >>> stack overflow exceptions >>> This line's comment used to align with the previous line's >>> comment. >>> Can you move the previous line's comment to align with this >>> one? >> >> Done. >> >>> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >>> L135: // For Forte Analyzer AsyncGetCallTrace profiling support - >>> thread >>> L136: // is currently interrupted by SIGPROF. >>> Now fetch_frame_from_ucontext() is also used for stack overflow >>> signal handling. >> >> Fixed >> >>> L192: assert(fr->safe_for_sender(thread), "Safety check"); >>> L193: if (!fr->is_first_java_frame()) { >>> L194: *fr = fr->java_sender(); >>> The assert() on L192 should be before the java_sender() >>> call on L194. >> >> Fixed >> >>> src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp >>> L209: // For Forte Analyzer AsyncGetCallTrace profiling support - >>> thread >>> L210: // is currently interrupted by SIGPROF. >>> Now fetch_frame_from_ucontext() is also used for stack overflow >>> signal handling. >> >> Fixed >> >>> L265: assert(fr->safe_for_sender(thread), "Safety check"); >>> L266: if (!fr->is_first_java_frame()) { >>> L267: *fr = fr->java_sender(); >>> The assert() on L265 should be before the java_sender() >>> call on L267. >> >> Fixed >> >>> L279: //assert(fr->safe_for_sender(thread), "Safety check"); >>> Delete this line; you copied it to L282. >> >> Done >> >>> L287 return true; >>> Should this assert be added above this line? >>> assert(fr->is_java_frame(), "Safety check"); >> >> Yes, this assert exists on other platforms, and there's no >> reason to omit it on Solaris/SPARC >> >>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >>> L195: // For Forte Analyzer AsyncGetCallTrace profiling support - >>> thread >>> L196: // is currently interrupted by SIGPROF. >>> Now fetch_frame_from_ucontext() is also used for stack overflow >>> signal handling. >> >> Fixed >> >>> L253: assert(fr->safe_for_sender(thread), "Safety check"); >>> L254: if (!fr->is_first_java_frame()) { >>> L255: *fr = fr->java_sender(); >>> The assert() on L253 should be before the java_sender() >>> call on L255. >> >> Fixed >> >>> L273: *fr = fr->java_sender(); >>> Wrong indent; one too many spaces. >> >> Fixed >> >> >>> src/os/windows/vm/os_windows.cpp >>> L2364: assert(fr->safe_for_sender(thread), "Safety check"); >>> L2365: if (!fr->is_first_java_frame()) { >>> L2366: *fr = fr->java_sender(); >>> The assert() on L2364 should be before the java_sender() >>> call on L2366. >> >> Fixed >> >>> L2387: return true; >>> Should this assert be added above this line? >>> assert(fr->is_java_frame(), "Safety check"); >> >> Certainly, fixed. >> >>> src/share/vm/oops/method.hpp >>> (old) L87: u1 _flags; >>> (new) L88: u2 _flags; >>> Ouch - just needed one more bit... >> >> The initial implementation of the reserved stack area used the last >> bit, but unfortunately, someone else steal it before I could push >> my code :-( So I had to extend the flags field >> >>> L834: return (_flags & _reserved_stack_access) != 0; >>> Wrong indent; two fewer spaces. >> >> Fixed >> >>> src/share/vm/runtime/globals.hpp >>> L3549: range(MIN_STACK_RESERVED_PAGES, >>> (DEFAULT_STACK_RESERVED_PAGES+10))\ >>> Wrong indent; should line up below the double quote in >>> the previous line. >> >> Fixed >> >>> src/share/vm/interpreter/interpreterRuntime.cpp >>> L328 IRT_ENTRY(void, >>> InterpreterRuntime::throw_delayed_StackOverflowError(JavaThread* >>> thread)) >>> >>> The regular throw_StackOverflowError() increments >>> a counter: >>> >>> L313: Atomic::inc(&Exceptions::_stack_overflow_errors); >>> >>> Should this function increment the same counter or >>> a different counter? >> >> Good catch! I've added the counter increment to the method >> throw_delayed_StackOverflowError(). I don't see a strong >> rational to create a new counter for delayed stack overflows, >> so it increments the same counter as throw_StackOverflowError(). >> >>> >>> src/cpu/sparc/vm/macroAssembler_sparc.hpp >>> L1423: // Check for reserved stack access in method being exited >>> (for the compilers) >>> The X86 version says "for JIT compilers". I prefer "JIT". >> >> Fixed >> >>> src/cpu/x86/vm/macroAssembler_x86.hpp >>> L643: // Check for reserved stack access in method being exited >>> (for JIT compilers) >>> The SPARC version says "for the compilers". >> >> Fixed >> >>> src/share/vm/ci/ciMethod.cpp >>> L95: _has_reserved_stack_access = >>> h_m()->has_reserved_stack_access(); >>> Wrong indent; should be only one space before '='. >> >> Fixed >> >>> src/share/vm/c1/c1_GraphBuilder.cpp >>> L3323: if(callee->has_reserved_stack_access()) { >>> L3336: if(callee->has_reserved_stack_access()) { >>> L3356: if(callee->has_reserved_stack_access()) { >>> Missing space between 'if' and '('. >> >> All fixed. >> >>> src/cpu/x86/vm/x86_32.ad >>> L737: size += 64; // added to support ReservedStackAccess >>> Usually I hate literals like this, but this function has >>> them in spades. :-( >> >> I agree but I didn't find a better solution. >> >>> src/cpu/x86/vm/x86_64.ad >>> L960: MacroAssembler _masm(&cbuf); >>> L965: MacroAssembler _masm(&cbuf); >>> >>> I think you can delete the _masm on L965. >> >> Right, removed. >> >>> src/share/vm/opto/compile.cpp >>> L675: >>> _has_reserved_stack_access(target->has_reserved_stack_access()) { >>> Wrong indent; should be a single space between ')' and '{'. >> >> Fixed >> >>> test/runtime/ReservedStack/ReservedStackTest.java >>> L26: * @run main/othervm -XX:-Inline >>> -XX:CompileCommand=exclude,java/util/concurrent/locks/AbstractOwnableSynchronizer,setExclusiveOwnerThread >>> >>> ReservedStackTest >>> >>> Should the comma before 'setExclusiveOwnerThread' be a period? >>> Perhaps both formats work... >> >> Both formats work, but I changed it to be a period, it's cleaner. >> >>> L47: * else >>> Wrong indent; needs one more space before 'else'. >>> >>> L52: * successfully update the status of the lock but he method >>> Typo: 'update the' -> 'updates the' >>> Typo: 'he method' -> 'the method' >>> >>> L60: * first StackOverflowError is thrown, the Error is catched >>> Typo: 'is catched' -> 'is caught' >>> >>> L61: * and a few dozens frames are exited. Now the thread has >>> Typo: 'a few dozens frames' -> 'a few dozen frames' >>> >>> L66: * of its invocation, tries to acquire the next lock >>> Typo: 'its invocation' -> 'its invocations' >>> >>> L81: * stack to prevent false sharing. The test is using this >>> Perhaps 'The test is using this' >>> -> 'The test relies on this' >>> >>> to better match wording on L225-6. >>> >>> L82: * to have different stack alignments and hit the targeted >>> Grammar: 'and hit' -> 'when it hits' >>> >>> L102: * exploit the property that interpreter frames are (much) >>> Typo: 'exploit' -> 'exploits' >>> Delete extra space after 'the'. >>> >>> L123: //LOCK_ARRAY_SIZE value >>> Add a space after '//'. >>> >>> L188: @jdk.internal.vm.annotation.ReservedStackAccess >>> This isn't privileged code and -XX:-RestrictReservedStack >>> isn't specified so what does this do? >> >> It checks that by default the annotation is ignored for non-privileged >> code, in case it is not ignored, the test would fail. >> >>> >>> L201: System.exit(-1); >>> Wrong indent; needs two more spaces. >> >> All fixed. >> >> Thank you very much! >> >> Fred >> >>>> >>>> On 20/11/2015 19:44, Karen Kinnear wrote: >>>>> Frederic, >>>>> >>>>> Code review for web revs you sent out. >>>>> Code looks good. I am not as familiar with the compiler code. >>>>> >>>>> I realize you need to check in at least a subset of the >>>>> java.util.concurrent changes for >>>>> the test to work, so maybe I should not have asked Doug about his >>>>> preference there. >>>>> Sorry. >>>>> >>>>> I am impressed you found a way to make a reproducible test! >>>>> >>>>> Comments/questions: >>>>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >>>> >>>> Fixed >>>> >>>>> 2. IIRC, due to another bug with windows handling of our guard pages, >>>>> this >>>>> is disabled for Windows. Would it be worth putting a comment in the >>>>> bug , 8067946, that once this is fixed, the reserved stack logic on >>>>> windows >>>>> will need testing before enabling? >>>> >>>> More than testing, the implementation would have to be completed on >>>> Windows. I've added a comment to JDK-8067946. >>>> >>>>> 3. In get_frame_at_stack_banging_point on Linux, BSD and >>>>> solaris_x86 if >>>>> this is in interpreter code, you explicitly return the Java sender >>>>> of the current frame. I was expecting to see that on Solaris_sparc >>>>> and Windows >>>>> as well? I do see the assertion in caller that you do have a java >>>>> frame. >>>> >>>> It doesn't make sense to check the current frame (no bytecode has been >>>> executed yet, so risk of partially executed critical section). I did >>>> the >>>> change but not for all platforms. This is now fixed for Solaris_SPARC >>>> and Windows too. >>>> >>>>> 4. test line 83 ?writtent? -> ?written? >>>> >>>> Fixed >>>> >>>>> 5. I like the way you set up the preallocated exception and then set >>>>> the message - we may >>>>> try that for default methods in future. >>>>> >>>>> 6. I had a memory that you had found a bug in safe_for_sender - did >>>>> you already check that in? >>>> >>>> I've fixed x86 platforms in JDK-8068655. >>>> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >>>> I had hoped it would have been silently accepted :-) >>>> >>>> >>>>> 7. I see the change in trace.xml, and I see an include added to >>>>> SharedRuntime.cpp, >>>>> but I didn?t see where it was used - did I just miss it? >>>> >>>> trace.xml changes define a new event. >>>> This event is created at sharedRuntime.cpp::3006 and it is used >>>> in the next 3 lines. >>>> >>>> Thanks, >>>> >>>> Fred >>>> >>> >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From ioi.lam at oracle.com Thu Dec 3 14:44:04 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 03 Dec 2015 06:44:04 -0800 Subject: RFR (XS) 8143615 compactHashtable.hpp includes oop.inline.hpp file In-Reply-To: <566006B5.7010500@oracle.com> References: <565FA9BC.2080808@oracle.com> <566006B5.7010500@oracle.com> Message-ID: <56605534.7040308@oracle.com> On 12/3/15 1:09 AM, Stefan Karlsson wrote: > Hi Ioi, > > Thanks a lot for fixing this! > > Would you mind swapping these lines around?: > > #include "classfile/javaClasses.hpp" > +#include "classfile/compactHashtable.inline.hpp" Thanks for noticing. I will fix that. > Except for that nit, this looks good. > > As David says, we should get rid of the allocation.inline.hpp include > as well, but I think we could defer that to a separate patch (if you > want to). TL;DR -- this fix probably won't do much in terms of speeding up a rebuild, but may still be a good clean up ... Read the following if you're bored ----v Actually, I am not quite familiar with the rules of when/if *.inline.hpp can be inlcluded by a "regular" hpp file.Is that documented somewhere? My guess is this happened when Stefan reported the bug: + precompiled header is used + oop.inline.hpp was (indirectly) included into precompiled.hpp.gch.d - this was actually not caused by compactHashtable.hpp(this file is not included by precompiled.hpp) You can verified this from auto-generated files such as hotspot/linux_amd64_compiler2/generated/dependencies/precompiled.hpp.gch.d - the culprit is src/share/vm/compiler/compilerDirectives.hpp, which also includes oop.inline.hpp,introduced in this changeset: changeset: 9323:a176d4737606 user: neliasso 8137167: JEP165: Compiler Control: Implementation task Summary: Compiler Control JEP - the depedndency is precompiled.hpp -> ciEnv.hpp -> compilerDirectives.hpp-> oop.inline.hpp + oop.inline.hpp itself includes many GC header files, so when Stefan touches one of them, everything is recompiled. So my interpretation is: + We should try to minimize the number of other header files included in "regular" .hpp files - Complex inline functions should be defined in .inline.hpp files. + Avoid including .inline.hpp files in "regular" .hpp files, since that may indirectly include a large set of header files. Anyway, I don't think this can be easily adhered to, or easily understood, or cared about, by the developers.Moreover, there are actually a lot of various inline.hpp files being included in .hpp files. hotspot/src/share$ find . -name \*inline.hpp -prune -o -name \*.hpp -print | xargs grep inline.hpp | grep -v precompiled.hpp | wc 60 189 4387 So I think in an ideal world, we should have a tool that can automatically flags the "bad" includes. But, I am not sure how much time we want to invest in that :-( In this particular case, after I removed oop.inline.hpp from compilerDirectives.hpp (it turned out to be an unnecessary include), only 7 include files were removed from precompiled.hpp.gch.d, so I am not sure it's a big win. But in terms of clean up, it's still a good idea to move big inline function definitions out of compactHashtable.hpp. Also, I can see that allocation.inline.hpp is included by many .hpp files, so I guess it's OK for compactHashtable.hpp to do the same. If a clean up is needed, that would need to be done in a separate RFE. hotspot/src/share$ find . -name \*inline.hpp -prune -o -name \*.hpp -print | xargs grep allocation.inline.hpp ./vm/precompiled/precompiled.hpp:# include "memory/allocation.inline.hpp" ./vm/prims/jvmtiEventController.hpp:#include "memory/allocation.inline.hpp" ./vm/prims/jvmtiEnvThreadState.hpp:#include "memory/allocation.inline.hpp" ./vm/prims/jvmtiThreadState.hpp:#include "memory/allocation.inline.hpp" ./vm/oops/generateOopMap.hpp:#include "memory/allocation.inline.hpp" ./vm/compiler/compileTask.hpp:#include "memory/allocation.inline.hpp" ./vm/compiler/methodMatcher.hpp:#include "memory/allocation.inline.hpp" ./vm/classfile/compactHashtable.hpp:#include "memory/allocation.inline.hpp" ./vm/classfile/symbolTable.hpp:#include "memory/allocation.inline.hpp" ./vm/classfile/stringTable.hpp:#include "memory/allocation.inline.hpp" ./vm/utilities/growableArray.hpp:#include "memory/allocation.inline.hpp" ./vm/utilities/stack.hpp:#include "memory/allocation.inline.hpp" ./vm/utilities/array.hpp:#include "memory/allocation.inline.hpp" ./vm/gc/g1/g1Predictions.hpp:#include "memory/allocation.inline.hpp" ./vm/runtime/perfData.hpp:#include "memory/allocation.inline.hpp" ./vm/logging/log.hpp:#include "memory/allocation.inline.hpp" ./vm/libadt/dict.hpp:#include "memory/allocation.inline.hpp" Thanks - Ioi > Thanks, > StefanK > > On 2015-12-03 03:32, Ioi Lam wrote: >> Please review a very small fix: >> >> http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp/ >> >> Bug: compactHashtable.hpp includes oop.inline.hpp file >> >> https://bugs.openjdk.java.net/browse/JDK-8143615 >> >> Summary of fix: >> >> + deleted the include of oop.inline.hpp from compactHashtable.hpp >> + moved all inlined functions that require oop.inline.hpp into a >> new file, compactHashtable.inline.hpp >> >> Tests: >> >> JPRT >> >> Thanks >> - Ioi > From paul.sandoz at oracle.com Thu Dec 3 16:38:40 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Dec 2015 17:38:40 +0100 Subject: Testing Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <56603FC9.7080000@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <9C417D00-F022-4CF6-87D3-0AF74CCD7441@oracle.com> <565F1A5A.4040509@oracle.com> <8D34B054-1832-428A-8A00-C7C5E1056061@oracle.com> <565F7D80.7060708@oracle.com> <4EC53498-5497-47F1-A98B-971B52360C69@oracle.com> <56603FC9.7080000@oracle.com> Message-ID: > On 3 Dec 2015, at 14:12, Coleen Phillimore wrote: >> >> It does involve the jtreg and testing launcher but is that really a major issue? If the test fails when running with the launcher class then presumably debugging wise it?s also useful to run with that too? but i can understand in certain cases it may be preferable not to do that. Overall, with my admittedly more JDK core libraries goggles, on the above does not seems that different to your existing process. > > No, we're not trying to debug the launcher but the little java program that we're testing. Do -Xlog:itables=debug with your experiment, or TraceClassInitialization or set a breakpoint in InterpreterRuntime::resolve_invoke. > IIUC the examples you present are also relevant to Java classes before main is invoked. How do you deal with the ?noise? of Java booting up before main is invoked? Do you have some conditional breakpoint logic configured? A data point: AFAICT (e.g. with TraceClassInitialization) the use of the jtreg TestNGAction$TestNGRunner launcher results in ~the same number of classes initialized up to the actual test class as occurs between startup and the main class. > The point is that we don't have extra time to hack out out new frameworks in order to get to the problem that we're trying to solve. It's a time issue, not a possibility issue. > > In your sample below, I'd hack out at least 10 more lines to get to the java class for the test program but I haven't had time to test if this works yet. Last time I tried to debug a test with testng in jdk/test/java/lang/invoke, I had to run it in the background and do 'ps' to find the java command. I may have had to give up and look through the hotspot sources. > That?s odd, i don?t know the particular details and constraints of what you were testing, but if you use the script jtreg spits it will not fork a new Java process (unless the test explicitly does so). I was just able to run a debug VM with no issue with a j.l.invoke testng test. > As I said, you can see if the compiler group will accept these tests. They seem to belong in the hotspot repository, not the jdk repository because we run these tests with JPRT. > Yes, my reluctance to move to jdk was because they may get run less often. There does appear there might be less resistance from members of the compiler group :-) Paul. From paul.sandoz at oracle.com Thu Dec 3 17:14:43 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Dec 2015 18:14:43 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <56604096.7080401@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <565DF808.7060806@oracle.com> <565FAFBA.9060405@oracle.com> <3403D394-DB0F-4419-A799-DA2AABBC15A8@oracle.com> <56604096.7080401@oracle.com> Message-ID: <140243F4-5A3C-48E5-8963-F78FD18138C6@oracle.com> > On 3 Dec 2015, at 14:16, Coleen Phillimore wrote: > > > > On 12/3/15 4:51 AM, Paul Sandoz wrote: >>> On 3 Dec 2015, at 03:58, Coleen Phillimore wrote: >>> >>> >>> I finally had a chance to look at this. Why are there pages of commit messages in these webrevs? >>> >> Not sure, it seems to be a bug with webrev (and may be a consequence of the interaction with patch queues, but i have not had time to dig into why this occurs). > > I think this is a bug with the interaction with your patch queues. Before you send stuff out for review (at least to the hotspot lists), can you export the patch into a clean repository so that we don't have to find the changes in pages of stuff? (With 4 or so patches concurrently in flight for various issues across jdk and hotspot of hs-comp that approach does not scale very well.) Thanks to Claes who proposed a workaround: remove the use of ?follow in webrev.ksh (and in ~/.hgrc if present). I updated the webrevs. >> >>> You probably already have Assert in our test library. >>> >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/generate-unsafe-access-tests.sh.html >>> >>> Is this script and template how these tests were generated? >> Yes, it?s the same pattern as used in nio tests. If we evolve the tests we will edit the template and run the generation script rather than potentially editing 18 files. > > That seems ok, as long as running the script isn't part of the testing. Yes, it?s separate, don?t worry i am not piling on more stuff beyond that of TestNG! >> >>> It doesn't seem like it needs to be checked in (and is missing copyright). >>> >> Ah, thanks, i will add the copyright. >> >> >>> Maybe since the tests are stressing the compilation characteristics of the unsafe API, these tests belong in the test/compiler/unsafe directory. Maybe the compiler group doesn't mind slogging through testng to find bugs. >>> >> But how much of an actual slog is it? (see my reply to you on hotspot-dev) >> >> If i cannot persuade you and others in the runtime team (my powers of persuasion are failing and it is looking unlikely, but i am still trying :-) ), i will move them to the idk test area. > > As I said in my last email, the test should be in the hotspot test repositories because it seems like compiler changes could break them and we'd want to run the tests with each putback. It tests the native methods, and C1/C2 intrinsics if given the freedom to do so, thus it really exercises both runtime and compiler, but an argument can be made for locating in compiler. > See if the compiler group can tolerate an additional harness. > ?Wanted: one careful owner? :-) Paul. From coleen.phillimore at oracle.com Thu Dec 3 18:18:08 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 3 Dec 2015 13:18:08 -0500 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <140243F4-5A3C-48E5-8963-F78FD18138C6@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <565DF808.7060806@oracle.com> <565FAFBA.9060405@oracle.com> <3403D394-DB0F-4419-A799-DA2AABBC15A8@oracle.com> <56604096.7080401@oracle.com> <140243F4-5A3C-48E5-8963-F78FD18138C6@oracle.com> Message-ID: <56608760.4010604@oracle.com> On 12/3/15 12:14 PM, Paul Sandoz wrote: >> On 3 Dec 2015, at 14:16, Coleen Phillimore wrote: >> >> >> >> On 12/3/15 4:51 AM, Paul Sandoz wrote: >>>> On 3 Dec 2015, at 03:58, Coleen Phillimore wrote: >>>> >>>> >>>> I finally had a chance to look at this. Why are there pages of commit messages in these webrevs? >>>> >>> Not sure, it seems to be a bug with webrev (and may be a consequence of the interaction with patch queues, but i have not had time to dig into why this occurs). >> I think this is a bug with the interaction with your patch queues. Before you send stuff out for review (at least to the hotspot lists), can you export the patch into a clean repository so that we don't have to find the changes in pages of stuff? > (With 4 or so patches concurrently in flight for various issues across jdk and hotspot of hs-comp that approach does not scale very well.) Having all of hotspot-dev look at pages of junk doesn't scale well either. > > Thanks to Claes who proposed a workaround: remove the use of ?follow in webrev.ksh (and in ~/.hgrc if present). I updated the webrevs. > > >>>> You probably already have Assert in our test library. >>>> >>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/generate-unsafe-access-tests.sh.html >>>> >>>> Is this script and template how these tests were generated? >>> Yes, it?s the same pattern as used in nio tests. If we evolve the tests we will edit the template and run the generation script rather than potentially editing 18 files. >> That seems ok, as long as running the script isn't part of the testing. > Yes, it?s separate, don?t worry i am not piling on more stuff beyond that of TestNG! > > >>>> It doesn't seem like it needs to be checked in (and is missing copyright). >>>> >>> Ah, thanks, i will add the copyright. >>> >>> >>>> Maybe since the tests are stressing the compilation characteristics of the unsafe API, these tests belong in the test/compiler/unsafe directory. Maybe the compiler group doesn't mind slogging through testng to find bugs. >>>> >>> But how much of an actual slog is it? (see my reply to you on hotspot-dev) >>> >>> If i cannot persuade you and others in the runtime team (my powers of persuasion are failing and it is looking unlikely, but i am still trying :-) ), i will move them to the idk test area. >> As I said in my last email, the test should be in the hotspot test repositories because it seems like compiler changes could break them and we'd want to run the tests with each putback. > It tests the native methods, and C1/C2 intrinsics if given the freedom to do so, thus it really exercises both runtime and compiler, but an argument can be made for locating in compiler. You give the tests various compilation options, the interesting bit of code is in the compiler (the native entries are trivial), and the most likely people to break it are in the compiler (duck!). The runtime test SQE lead and myself and others (offline unfortunately) have said "no" to testng in the runtime tests. So yes, for all these reasons the tests belong in the compiler test directories. Thanks, Coleen > >> See if the compiler group can tolerate an additional harness. >> > ?Wanted: one careful owner? :-) > > Paul. From christian.thalinger at oracle.com Thu Dec 3 18:25:50 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Dec 2015 08:25:50 -1000 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <56608760.4010604@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <565DF808.7060806@oracle.com> <565FAFBA.9060405@oracle.com> <3403D394-DB0F-4419-A799-DA2AABBC15A8@oracle.com> <56604096.7080401@oracle.com> <140243F4-5A3C-48E5-8963-F78FD18138C6@oracle.com> <56608760.4010604@oracle.com> Message-ID: <1ECB3D88-DEDC-4DF5-A851-680FBDF6383E@oracle.com> > On Dec 3, 2015, at 8:18 AM, Coleen Phillimore wrote: > > > > On 12/3/15 12:14 PM, Paul Sandoz wrote: >>> On 3 Dec 2015, at 14:16, Coleen Phillimore wrote: >>> >>> >>> >>> On 12/3/15 4:51 AM, Paul Sandoz wrote: >>>>> On 3 Dec 2015, at 03:58, Coleen Phillimore wrote: >>>>> >>>>> >>>>> I finally had a chance to look at this. Why are there pages of commit messages in these webrevs? >>>>> >>>> Not sure, it seems to be a bug with webrev (and may be a consequence of the interaction with patch queues, but i have not had time to dig into why this occurs). >>> I think this is a bug with the interaction with your patch queues. Before you send stuff out for review (at least to the hotspot lists), can you export the patch into a clean repository so that we don't have to find the changes in pages of stuff? >> (With 4 or so patches concurrently in flight for various issues across jdk and hotspot of hs-comp that approach does not scale very well.) > > Having all of hotspot-dev look at pages of junk doesn't scale well either. >> >> Thanks to Claes who proposed a workaround: remove the use of ?follow in webrev.ksh (and in ~/.hgrc if present). I updated the webrevs. >> >> >>>>> You probably already have Assert in our test library. >>>>> >>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/generate-unsafe-access-tests.sh.html >>>>> >>>>> Is this script and template how these tests were generated? >>>> Yes, it?s the same pattern as used in nio tests. If we evolve the tests we will edit the template and run the generation script rather than potentially editing 18 files. >>> That seems ok, as long as running the script isn't part of the testing. >> Yes, it?s separate, don?t worry i am not piling on more stuff beyond that of TestNG! >> >> >>>>> It doesn't seem like it needs to be checked in (and is missing copyright). >>>>> >>>> Ah, thanks, i will add the copyright. >>>> >>>> >>>>> Maybe since the tests are stressing the compilation characteristics of the unsafe API, these tests belong in the test/compiler/unsafe directory. Maybe the compiler group doesn't mind slogging through testng to find bugs. >>>>> >>>> But how much of an actual slog is it? (see my reply to you on hotspot-dev) >>>> >>>> If i cannot persuade you and others in the runtime team (my powers of persuasion are failing and it is looking unlikely, but i am still trying :-) ), i will move them to the idk test area. >>> As I said in my last email, the test should be in the hotspot test repositories because it seems like compiler changes could break them and we'd want to run the tests with each putback. >> It tests the native methods, and C1/C2 intrinsics if given the freedom to do so, thus it really exercises both runtime and compiler, but an argument can be made for locating in compiler. > > You give the tests various compilation options, the interesting bit of code is in the compiler (the native entries are trivial), and the most likely people to break it are in the compiler (duck!). The runtime test SQE lead and myself and others (offline unfortunately) have said "no" to testng in the runtime tests. So yes, for all these reasons the tests belong in the compiler test directories. We already have testng tests so go ahead and put them in test/compiler/unsafe/. The compiler team is not afraid of the future! > > Thanks, > Coleen > >> >>> See if the compiler group can tolerate an additional harness. >>> >> ?Wanted: one careful owner? :-) >> >> Paul. From asmundak at google.com Thu Dec 3 18:29:26 2015 From: asmundak at google.com (Alexander Smundak) Date: Thu, 3 Dec 2015 10:29:26 -0800 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <565FE186.7090508@oracle.com> References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> Message-ID: On Wed, Dec 2, 2015 at 10:30 PM, David Holmes wrote: > agent code: > > I'm still unclear why you can't, or shouldn't, pass through -Dppc64 and > -Dppc64le, such that you don't need to check for either being defined ?? You mean, add -Dppc64 to the compilation flags explicitly if the value of the OPENJDK_TARGET_CPU_LEGACY is 'ppc64le'? Sasha From vladimir.kozlov at oracle.com Thu Dec 3 19:12:29 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 3 Dec 2015 11:12:29 -0800 Subject: RFR: 8144582: AArch64 does not generate correct branch profile data In-Reply-To: <56603CEA.9050500@redhat.com> References: <56603CEA.9050500@redhat.com> Message-ID: <5660941D.4060802@oracle.com> Looks good. Did it solved bit-test code generation problem with -Xbatch? Thanks, Vladimir On 12/3/15 5:00 AM, Andrew Haley wrote: > This is a trivial matter of register corruption. It turns out > that this has always been wrong, but it doesn't do anything > significant unless you use -Xbatch -XX:-TieredCompilation. > > I also added a using statement to silence a compiler warning. > > http://cr.openjdk.java.net/~aph/8144582/ > > Andrew. > From coleen.phillimore at oracle.com Thu Dec 3 23:51:18 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 3 Dec 2015 18:51:18 -0500 Subject: RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> References: <565FA1C1.50909@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> Message-ID: <5660D576.80904@oracle.com> Hi Goetz, Thank you for looking at my change. I made the ppc changes and hg added templateInterpreter_ppc/aarch64.cpp back, so they should be in the patch. Now webrev thinks I've deleted 7785 lines, but I didn't really. http://cr.openjdk.java.net/~coleenp/8144534.02/ The most interesting part of this change is in the x86 code: http://cr.openjdk.java.net/~coleenp/8144534.02/src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp.udiff.html This is where the 32 and 64 bit template interpreter code is merged. Thanks, Coleen On 12/3/15 8:14 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > I've been looking at this change. A cleanup in this area is really > useful. > I missed templateInterpreter_ppc.cpp in your patch, I guess you forgot > "hg add" for it. > In addition, I had to fix some code around math_entry_available(), see this patch: > http://cr.openjdk.java.net/~goetz/webrevs/8144534-interp/8144534-fixes_for_ppc.patch > > In general, I think it's strange that AbstractInterpreterGenerator > implementations are in interpreter_.cpp, as mentioned In the bug. > Why not move them to templateInterpreterGenerator_.cpp? Or will > this be subject to a later change that removes the funny common > subclasses Interpreter/InterpreterGenerator? > > Should I make a change removing the CC_INTERP support from ppc? > > Best regards, > Goetz. > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Coleen Phillimore >> Sent: Donnerstag, 3. Dezember 2015 02:58 >> To: hotspot-dev developers >> Subject: RFR 8144534: Refactor templateInterpreter and >> templateInterpreterGenerator functions >> >> Summary: merged templateInterpreter_x86_32/64 into >> templateInterpreterGenerator_x86.cpp (some 32/64 functions remain for >> the hand coded crc functions). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8144534.01/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8144534 >> >> I tried to make this reviewable by hg renaming files. I basically >> renamed templateInterpreter_ppc.cpp and removed the >> AbstractInterpreter >> functions and put them back into templateInterpreter_ppc.cpp. I didn't >> really delete 4000 lines of code, more like 1500. >> >> Also, can someone with the PPC and AARCH port look at and test out these >> changes? I tried to reduce the #includes in the new >> templateInterpreter_ppc/aarch64.cpp files which worked for sparc. >> >> Tested with JPRT on all platforms, also ran jtreg and >> collocated/non-collocated tonga tests for linux x64 and i386 since >> that's were the real changes are. >> >> See the bug for more details and my partial vision of how these >> functions will be reorganized when I remove the broken c++ interpreter. >> >> Also tested that Zero still builds. >> >> Thanks! >> Coleen >> From john.r.rose at oracle.com Fri Dec 4 01:13:17 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 3 Dec 2015 17:13:17 -0800 Subject: RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions In-Reply-To: <5660D576.80904@oracle.com> References: <565FA1C1.50909@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> <5660D576.80904@oracle.com> Message-ID: On Dec 3, 2015, at 3:51 PM, Coleen Phillimore wrote: > > The most interesting part of this change is in the x86 code: > > http://cr.openjdk.java.net/~coleenp/8144534.02/src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp.udiff.html > > This is where the 32 and 64 bit template interpreter code is merged. This is a magnificent case of CDE (Code Deletion Engineering). About 1/3 of the textual lines in each merged file are unique: $ diff -U9999 templateInterpreter_x86_{32,64}.cpp > templateInterpreter_x86_MERGED.cpp $ wc templateInterpreter_x86_{32,64,MERGED}.cpp 1916 7955 71138 templateInterpreter_x86_32.cpp 1866 7348 67194 templateInterpreter_x86_64.cpp 2610 12638 104592 templateInterpreter_x86_MERGED.cpp Any many of the unique lines differ from their counterparts only trivially. I read over the changes and found what I hoped to find. A few of the multi-line #ifdefs could be compressed even more, but that can be done later if we want, as we touch the code. Cleanups like this make our system more maintainable. They also reduce the cost of future changes, like value types. Thanks for doing this. You can count me as a reviewer. ? John P.S. One request: Please prefer putting the semicolons outside of the macro calls, even when they are logically inside. It makes it easier for auto-indenting tools like Emacs to DTRT. (They treat semicolon at the end of a line as a signal to indent normally on the next line, but a paren at the end of the line is a signal to indent extra on the next line, on the assumption that it is a continuation line.) The majority convention appears to be putting the semicolon outside the paren: -------- grep '_ONLY(.*);' $(hg loc -I src) | wc 667 3514 65119 -------- grep '_ONLY(.*;)' $(hg loc -I src) | wc 216 868 19884 -------- grep 'NOT_[A-Z0-9]*(.*);' $(hg loc -I src) | wc 855 4098 82619 -------- grep 'NOT_[A-Z0-9]*(.*;)' $(hg loc -I src) | wc 296 1320 27929 -------- From david.holmes at oracle.com Fri Dec 4 07:17:27 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Dec 2015 17:17:27 +1000 Subject: RFR (XS) 8143615 compactHashtable.hpp includes oop.inline.hpp file In-Reply-To: <56605534.7040308@oracle.com> References: <565FA9BC.2080808@oracle.com> <566006B5.7010500@oracle.com> <56605534.7040308@oracle.com> Message-ID: <56613E07.1040602@oracle.com> On 4/12/2015 12:44 AM, Ioi Lam wrote: > On 12/3/15 1:09 AM, Stefan Karlsson wrote: >> Hi Ioi, >> >> Thanks a lot for fixing this! >> >> Would you mind swapping these lines around?: >> >> #include "classfile/javaClasses.hpp" >> +#include "classfile/compactHashtable.inline.hpp" > > Thanks for noticing. I will fix that. >> Except for that nit, this looks good. >> >> As David says, we should get rid of the allocation.inline.hpp include >> as well, but I think we could defer that to a separate patch (if you >> want to). > > TL;DR -- this fix probably won't do much in terms of speeding up a > rebuild, but > may still be a good clean up ... > > > Read the following if you're bored ----v > > Actually, I am not quite familiar with the rules of when/if *.inline.hpp > can > be inlcluded by a "regular" hpp file.Is that documented somewhere? I think this is evolving based on a number of cleanups in this area. Unfortunately include strategies can be many and varied and hotspot is certainly not an example of consistency. My understanding of what we should aim for is that: - no .hpp file should include a .inline.hpp file - any .hpp file that needs to be included by other .hpp files should not have any implicit or explicit inline functions (they should be moved to a .inline.hpp file) - .cpp files include .inline.hpp files if they need the inlined functions (else the .hpp file) - .inline.hpp files include their associated .hpp files Trying to enforce this in the current code base can lead to a transitive closure of changes that touches dozens of files. I know Mikael V. has also been looking into a problematic case. :) David ----- > My guess is this happened when Stefan reported the bug: > > + precompiled header is used > > + oop.inline.hpp was (indirectly) included into precompiled.hpp.gch.d > - this was actually not caused by compactHashtable.hpp(this file is not > included by precompiled.hpp) > You can verified this from auto-generated files such as > hotspot/linux_amd64_compiler2/generated/dependencies/precompiled.hpp.gch.d > - the culprit is src/share/vm/compiler/compilerDirectives.hpp, which > also > includes oop.inline.hpp,introduced in this changeset: > changeset: 9323:a176d4737606 > user: neliasso > 8137167: JEP165: Compiler Control: Implementation task > Summary: Compiler Control JEP > - the depedndency is precompiled.hpp -> ciEnv.hpp -> > compilerDirectives.hpp-> oop.inline.hpp > > + oop.inline.hpp itself includes many GC header files, so when Stefan > touches one of them, > everything is recompiled. > > So my interpretation is: > > + We should try to minimize the number of other header files included in > "regular" .hpp files > - Complex inline functions should be defined in .inline.hpp files. > + Avoid including .inline.hpp files in "regular" .hpp files, since that > may indirectly > include a large set of header files. > > Anyway, I don't think this can be easily adhered to, or easily > understood, or cared > about, by the developers.Moreover, there are actually a lot of various > inline.hpp files > being included in .hpp files. > > hotspot/src/share$ find . -name \*inline.hpp -prune -o -name \*.hpp > -print | xargs grep inline.hpp | grep -v precompiled.hpp | wc > 60 189 4387 > > So I think in an ideal world, we should have a tool that can automatically > flags the "bad" includes. But, I am not sure how much time we want to > invest in that :-( > > In this particular case, after I removed oop.inline.hpp from > compilerDirectives.hpp > (it turned out to be an unnecessary include), only 7 include files were > removed from > precompiled.hpp.gch.d, so I am not sure it's a big win. > > But in terms of clean up, it's still a good idea to move big inline > function > definitions out of compactHashtable.hpp. > > > Also, I can see that allocation.inline.hpp is included by many .hpp > files, so > I guess it's OK for compactHashtable.hpp to do the same. If a clean up > is needed, > that would need to be done in a separate RFE. > > hotspot/src/share$ find . -name \*inline.hpp -prune -o -name \*.hpp > -print | xargs grep allocation.inline.hpp > ./vm/precompiled/precompiled.hpp:# include "memory/allocation.inline.hpp" > ./vm/prims/jvmtiEventController.hpp:#include "memory/allocation.inline.hpp" > ./vm/prims/jvmtiEnvThreadState.hpp:#include "memory/allocation.inline.hpp" > ./vm/prims/jvmtiThreadState.hpp:#include "memory/allocation.inline.hpp" > ./vm/oops/generateOopMap.hpp:#include "memory/allocation.inline.hpp" > ./vm/compiler/compileTask.hpp:#include "memory/allocation.inline.hpp" > ./vm/compiler/methodMatcher.hpp:#include "memory/allocation.inline.hpp" > ./vm/classfile/compactHashtable.hpp:#include "memory/allocation.inline.hpp" > ./vm/classfile/symbolTable.hpp:#include "memory/allocation.inline.hpp" > ./vm/classfile/stringTable.hpp:#include "memory/allocation.inline.hpp" > ./vm/utilities/growableArray.hpp:#include "memory/allocation.inline.hpp" > ./vm/utilities/stack.hpp:#include "memory/allocation.inline.hpp" > ./vm/utilities/array.hpp:#include "memory/allocation.inline.hpp" > ./vm/gc/g1/g1Predictions.hpp:#include "memory/allocation.inline.hpp" > ./vm/runtime/perfData.hpp:#include "memory/allocation.inline.hpp" > ./vm/logging/log.hpp:#include "memory/allocation.inline.hpp" > ./vm/libadt/dict.hpp:#include "memory/allocation.inline.hpp" > > > Thanks > - Ioi > > > >> Thanks, >> StefanK >> >> On 2015-12-03 03:32, Ioi Lam wrote: >>> Please review a very small fix: >>> >>> http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp/ >>> >>> Bug: compactHashtable.hpp includes oop.inline.hpp file >>> >>> https://bugs.openjdk.java.net/browse/JDK-8143615 >>> >>> Summary of fix: >>> >>> + deleted the include of oop.inline.hpp from compactHashtable.hpp >>> + moved all inlined functions that require oop.inline.hpp into a >>> new file, compactHashtable.inline.hpp >>> >>> Tests: >>> >>> JPRT >>> >>> Thanks >>> - Ioi >> > From david.holmes at oracle.com Fri Dec 4 07:59:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Dec 2015 17:59:43 +1000 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> Message-ID: <566147EF.4000109@oracle.com> On 4/12/2015 4:29 AM, Alexander Smundak wrote: > On Wed, Dec 2, 2015 at 10:30 PM, David Holmes wrote: >> agent code: >> >> I'm still unclear why you can't, or shouldn't, pass through -Dppc64 and >> -Dppc64le, such that you don't need to check for either being defined ?? > You mean, add -Dppc64 to the compilation flags explicitly if the value > of the OPENJDK_TARGET_CPU_LEGACY is 'ppc64le'? Yes. Is that feasible? Thanks, David > Sasha > From stefan.karlsson at oracle.com Fri Dec 4 09:23:19 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 4 Dec 2015 10:23:19 +0100 Subject: RFR (XS) 8143615 compactHashtable.hpp includes oop.inline.hpp file In-Reply-To: <56605534.7040308@oracle.com> References: <565FA9BC.2080808@oracle.com> <566006B5.7010500@oracle.com> <56605534.7040308@oracle.com> Message-ID: <56615B87.40303@oracle.com> On 2015-12-03 15:44, Ioi Lam wrote: > On 12/3/15 1:09 AM, Stefan Karlsson wrote: >> Hi Ioi, >> >> Thanks a lot for fixing this! >> >> Would you mind swapping these lines around?: >> >> #include "classfile/javaClasses.hpp" >> +#include "classfile/compactHashtable.inline.hpp" > > Thanks for noticing. I will fix that. >> Except for that nit, this looks good. >> >> As David says, we should get rid of the allocation.inline.hpp include >> as well, but I think we could defer that to a separate patch (if you >> want to). > > TL;DR -- this fix probably won't do much in terms of speeding up a > rebuild, but > may still be a good clean up ... My main concern is not about the compile times, but that we're spreading the include mess. > > > Read the following if you're bored ----v > > Actually, I am not quite familiar with the rules of when/if > *.inline.hpp can > be inlcluded by a "regular" hpp file.Is that documented somewhere? https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files > > My guess is this happened when Stefan reported the bug: > > + precompiled header is used I compile without precompiled headers. > > + oop.inline.hpp was (indirectly) included into precompiled.hpp.gch.d > - this was actually not caused by compactHashtable.hpp(this file is > not > included by precompiled.hpp) > You can verified this from auto-generated files such as > hotspot/linux_amd64_compiler2/generated/dependencies/precompiled.hpp.gch.d > > - the culprit is src/share/vm/compiler/compilerDirectives.hpp, > which also > includes oop.inline.hpp,introduced in this changeset: > changeset: 9323:a176d4737606 > user: neliasso > 8137167: JEP165: Compiler Control: Implementation task > Summary: Compiler Control JEP > - the depedndency is precompiled.hpp -> ciEnv.hpp -> > compilerDirectives.hpp-> oop.inline.hpp :( > > + oop.inline.hpp itself includes many GC header files, so when Stefan > touches one of them, > everything is recompiled. Yes. > > So my interpretation is: > > + We should try to minimize the number of other header files included > in "regular" .hpp files > - Complex inline functions should be defined in .inline.hpp files. Yes. > + Avoid including .inline.hpp files in "regular" .hpp files, since > that may indirectly > include a large set of header files. Yes. > > Anyway, I don't think this can be easily adhered to, or easily > understood, or cared > about, by the developers. It's quite simple if you by default _don't_ put definitions in the header file. Put all implementation in the .cpp files, and if it's important to inline the functions, put the code in an .inline.hpp files. It's when code is put into .hpp that things start to become problematic. Granted, _simple_ getters and setters in header files don't pose a problem. > Moreover, there are actually a lot of various inline.hpp files > being included in .hpp files. > > hotspot/src/share$ find . -name \*inline.hpp -prune -o -name \*.hpp > -print | xargs grep inline.hpp | grep -v precompiled.hpp | wc > 60 189 4387 $ find . -name \*inline.hpp -prune -o -name \*.hpp -print | xargs grep inline.hpp | grep -v precompiled.hpp | grep "#include" | awk -F: '{ print $2}' | sort | uniq -c 5 #include "asm/macroAssembler.inline.hpp" 1 #include "assembler_zero.inline.hpp" 1 #include "bytes_linux_ppc.inline.hpp" 17 #include "memory/allocation.inline.hpp" 2 #include "memory/universe.inline.hpp" 2 #include "oops/oop.inline.hpp" 1 #include "os_windows.inline.hpp" // needed for sockaddr_in 1 #include "prims/jvmtiThreadState.inline.hpp" 6 #include "runtime/frame.inline.hpp" 6 #include "runtime/handles.inline.hpp" 1 #include "runtime/objectMonitor.inline.hpp" 2 #include "runtime/orderAccess.inline.hpp" 8 #include "runtime/thread.inline.hpp" 2 #include "utilities/bitMap.inline.hpp" 1 #include "utilities/hashtable.inline.hpp" There used to be loads more includes of oop.inline.hpp, but I removed them. > > So I think in an ideal world, we should have a tool that can > automatically > flags the "bad" includes. But, I am not sure how much time we want to > invest in that :-( > > In this particular case, after I removed oop.inline.hpp from > compilerDirectives.hpp > (it turned out to be an unnecessary include), only 7 include files > were removed from > precompiled.hpp.gch.d, so I am not sure it's a big win. > > But in terms of clean up, it's still a good idea to move big inline > function > definitions out of compactHashtable.hpp. Not that the size shouldn't be measured in number of lines, but what they depend on: 120 void add(unsigned int hash, Symbol* symbol) { 121 add(hash, new Entry(hash, symbol)); 122 } 123 124 void add(unsigned int hash, oop string) { 125 add(hash, new Entry(hash, string)); 126 } Take these lines, for example, they force the include of allocation.inline.hpp in compactHashtable.cpp. Simply moving these definitions to the .cpp removes the need to include allocation.inline.hpp. > > > Also, I can see that allocation.inline.hpp is included by many .hpp > files, so > I guess it's OK for compactHashtable.hpp to do the same. If a clean up > is needed, > that would need to be done in a separate RFE. > > hotspot/src/share$ find . -name \*inline.hpp -prune -o -name \*.hpp > -print | xargs grep allocation.inline.hpp > ./vm/precompiled/precompiled.hpp:# include "memory/allocation.inline.hpp" > ./vm/prims/jvmtiEventController.hpp:#include > "memory/allocation.inline.hpp" > ./vm/prims/jvmtiEnvThreadState.hpp:#include > "memory/allocation.inline.hpp" > ./vm/prims/jvmtiThreadState.hpp:#include "memory/allocation.inline.hpp" > ./vm/oops/generateOopMap.hpp:#include "memory/allocation.inline.hpp" > ./vm/compiler/compileTask.hpp:#include "memory/allocation.inline.hpp" > ./vm/compiler/methodMatcher.hpp:#include "memory/allocation.inline.hpp" > ./vm/classfile/compactHashtable.hpp:#include > "memory/allocation.inline.hpp" > ./vm/classfile/symbolTable.hpp:#include "memory/allocation.inline.hpp" > ./vm/classfile/stringTable.hpp:#include "memory/allocation.inline.hpp" > ./vm/utilities/growableArray.hpp:#include "memory/allocation.inline.hpp" > ./vm/utilities/stack.hpp:#include "memory/allocation.inline.hpp" > ./vm/utilities/array.hpp:#include "memory/allocation.inline.hpp" > ./vm/gc/g1/g1Predictions.hpp:#include "memory/allocation.inline.hpp" > ./vm/runtime/perfData.hpp:#include "memory/allocation.inline.hpp" > ./vm/logging/log.hpp:#include "memory/allocation.inline.hpp" > ./vm/libadt/dict.hpp:#include "memory/allocation.inline.hpp" It would be good to decrease that list, not add to it. Maybe allocation.inline.hpp needs to fixed, and parts moved to the .cpp file. I see that g1Predictions.hpp added allocation.inline.hpp. I recently went over the entire GC code base and got rid of _all_ includes of .inline.hpp files from .hpp files. Stefank > > > Thanks > - Ioi > > > >> Thanks, >> StefanK >> >> On 2015-12-03 03:32, Ioi Lam wrote: >>> Please review a very small fix: >>> >>> http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp/ >>> >>> Bug: compactHashtable.hpp includes oop.inline.hpp file >>> >>> https://bugs.openjdk.java.net/browse/JDK-8143615 >>> >>> Summary of fix: >>> >>> + deleted the include of oop.inline.hpp from compactHashtable.hpp >>> + moved all inlined functions that require oop.inline.hpp into a >>> new file, compactHashtable.inline.hpp >>> >>> Tests: >>> >>> JPRT >>> >>> Thanks >>> - Ioi >> > From aph at redhat.com Fri Dec 4 09:28:02 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 4 Dec 2015 09:28:02 +0000 Subject: RFR: 8144582: AArch64 does not generate correct branch profile data In-Reply-To: <5660941D.4060802@oracle.com> References: <56603CEA.9050500@redhat.com> <5660941D.4060802@oracle.com> Message-ID: <56615CA2.6050108@redhat.com> On 03/12/15 19:12, Vladimir Kozlov wrote: > Looks good. Did it solved bit-test code generation problem with -Xbatch? It did. I wouldn't have found that one but for you! Andrew. From adinn at redhat.com Fri Dec 4 09:33:53 2015 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 4 Dec 2015 09:33:53 +0000 Subject: RFR: 8144582: AArch64 does not generate correct branch profile data In-Reply-To: <5660941D.4060802@oracle.com> References: <56603CEA.9050500@redhat.com> <5660941D.4060802@oracle.com> Message-ID: <56615E01.9080809@redhat.com> On 03/12/15 19:12, Vladimir Kozlov wrote: > Looks good. . . . If you still require an OK from an aarch64-project reviewer then this is it. regards, Andrew Dinn ----------- From goetz.lindenmaier at sap.com Fri Dec 4 10:21:01 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 4 Dec 2015 10:21:01 +0000 Subject: RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions In-Reply-To: <5660D576.80904@oracle.com> References: <565FA1C1.50909@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> <5660D576.80904@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDA72F@DEWDFEMB12A.global.corp.sap> Hi Coleen, thanks for incorporating my changes! I missed one detail in my patch yesterday -- no clue why it compiled: diff -r 4a05b14492dc src/cpu/ppc/vm/templateInterpreter_ppc.cpp --- a/src/cpu/ppc/vm/templateInterpreter_ppc.cpp Fri Dec 04 08:27:28 2015 +0100 +++ b/src/cpu/ppc/vm/templateInterpreter_ppc.cpp Fri Dec 04 11:18:50 2015 +0100 @@ -55,7 +55,7 @@ // These should never be compiled since the interpreter will prefer // the compiled version to the intrinsic version. bool AbstractInterpreter::can_be_compiled(methodHandle m) { - return !math_entry_available(method_kind(m)); + return !TemplateInterpreter::math_entry_available(method_kind(m)); } // How much stack a method activation needs in stack slots. Could you please fix this? Sorry for the trouble. Besides that it now works fine. Best regards, Goetz. > -----Original Message----- > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > Sent: Freitag, 4. Dezember 2015 00:51 > To: Lindenmaier, Goetz ; hotspot-dev > developers > Subject: Re: RFR 8144534: Refactor templateInterpreter and > templateInterpreterGenerator functions > > > Hi Goetz, > > Thank you for looking at my change. I made the ppc changes and hg added > templateInterpreter_ppc/aarch64.cpp back, so they should be in the patch. > > Now webrev thinks I've deleted 7785 lines, but I didn't really. > > http://cr.openjdk.java.net/~coleenp/8144534.02/ > > The most interesting part of this change is in the x86 code: > > http://cr.openjdk.java.net/~coleenp/8144534.02/src/cpu/x86/vm/templateI > nterpreterGenerator_x86.cpp.udiff.html > > This is where the 32 and 64 bit template interpreter code is merged. > > Thanks, > Coleen > > On 12/3/15 8:14 AM, Lindenmaier, Goetz wrote: > > Hi Coleen, > > > > I've been looking at this change. A cleanup in this area is really > > useful. > > I missed templateInterpreter_ppc.cpp in your patch, I guess you forgot > > "hg add" for it. > > In addition, I had to fix some code around math_entry_available(), see this > patch: > > http://cr.openjdk.java.net/~goetz/webrevs/8144534-interp/8144534- > fixes_for_ppc.patch > > > > In general, I think it's strange that AbstractInterpreterGenerator > > implementations are in interpreter_.cpp, as mentioned In the bug. > > Why not move them to templateInterpreterGenerator_.cpp? Or will > > this be subject to a later change that removes the funny common > > subclasses Interpreter/InterpreterGenerator? > > > > Should I make a change removing the CC_INTERP support from ppc? > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > >> Behalf Of Coleen Phillimore > >> Sent: Donnerstag, 3. Dezember 2015 02:58 > >> To: hotspot-dev developers > >> Subject: RFR 8144534: Refactor templateInterpreter and > >> templateInterpreterGenerator functions > >> > >> Summary: merged templateInterpreter_x86_32/64 into > >> templateInterpreterGenerator_x86.cpp (some 32/64 functions remain for > >> the hand coded crc functions). > >> > >> open webrev at http://cr.openjdk.java.net/~coleenp/8144534.01/ > >> bug link https://bugs.openjdk.java.net/browse/JDK-8144534 > >> > >> I tried to make this reviewable by hg renaming files. I basically > >> renamed templateInterpreter_ppc.cpp and removed the > >> AbstractInterpreter > >> functions and put them back into templateInterpreter_ppc.cpp. I didn't > >> really delete 4000 lines of code, more like 1500. > >> > >> Also, can someone with the PPC and AARCH port look at and test out > these > >> changes? I tried to reduce the #includes in the new > >> templateInterpreter_ppc/aarch64.cpp files which worked for sparc. > >> > >> Tested with JPRT on all platforms, also ran jtreg and > >> collocated/non-collocated tonga tests for linux x64 and i386 since > >> that's were the real changes are. > >> > >> See the bug for more details and my partial vision of how these > >> functions will be reorganized when I remove the broken c++ interpreter. > >> > >> Also tested that Zero still builds. > >> > >> Thanks! > >> Coleen > >> From paul.sandoz at oracle.com Fri Dec 4 12:57:37 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Dec 2015 13:57:37 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <1ECB3D88-DEDC-4DF5-A851-680FBDF6383E@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <565DF808.7060806@oracle.com> <565FAFBA.9060405@oracle.com> <3403D394-DB0F-4419-A799-DA2AABBC15A8@oracle.com> <56604096.7080401@oracle.com> <140243F4-5A3C-48E5-8963-F78FD18138C6@oracle.com> <56608760.4010604@oracle.com> <1ECB3D88-DEDC-4DF5-A851-680FBDF6383E@oracle.com> Message-ID: <9259517F-FB36-4810-987B-04CAD0FDE6D0@oracle.com> > On 3 Dec 2015, at 19:25, Christian Thalinger wrote: >> You give the tests various compilation options, the interesting bit of code is in the compiler (the native entries are trivial), and the most likely people to break it are in the compiler (duck!). The runtime test SQE lead and myself and others (offline unfortunately) have said "no" to testng in the runtime tests. Coleen, to better understand the HotSpot runtime team?s debugging process and requirements i am still curious about how you do stuff as discussed on the now separate test-related thread. I think it would be useful to continue that discussion. >> So yes, for all these reasons the tests belong in the compiler test directories. > > We already have testng tests so go ahead and put them in test/compiler/unsafe/. The compiler team is not afraid of the future! > Onward then! :-) Thanks! Updated: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/ Paul. From coleen.phillimore at oracle.com Fri Dec 4 14:11:14 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 4 Dec 2015 09:11:14 -0500 Subject: RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions In-Reply-To: References: <565FA1C1.50909@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> <5660D576.80904@oracle.com> Message-ID: <56619F02.2070007@oracle.com> Thank you John!! On 12/3/15 8:13 PM, John Rose wrote: > On Dec 3, 2015, at 3:51 PM, Coleen Phillimore > > > wrote: >> >> The most interesting part of this change is in the x86 code: >> >> http://cr.openjdk.java.net/~coleenp/8144534.02/src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp.udiff.html >> >> >> This is where the 32 and 64 bit template interpreter code is merged. > > This is a magnificent case of CDE (Code Deletion Engineering). :) > > About 1/3 of the textual lines in each merged file are unique: > > $ diff -U9999 templateInterpreter_x86_{32,64}.cpp > > templateInterpreter_x86_MERGED.cpp > $ wc templateInterpreter_x86_{32,64,MERGED}.cpp > 1916 7955 71138 templateInterpreter_x86_32.cpp > 1866 7348 67194 templateInterpreter_x86_64.cpp > 2610 12638 104592 templateInterpreter_x86_MERGED.cpp > > Any many of the unique lines differ from their counterparts only > trivially. > > I read over the changes and found what I hoped to find. > A few of the multi-line #ifdefs could be compressed even more, > but that can be done later if we want, as we touch the code. > > Cleanups like this make our system more maintainable. > They also reduce the cost of future changes, like value types. > Yes, I believe this. > Thanks for doing this. You can count me as a reviewer. > > ? John > > P.S. One request: Please prefer putting the semicolons outside of the > macro calls, > even when they are logically inside. It makes it easier for > auto-indenting tools > like Emacs to DTRT. (They treat semicolon at the end of a line as a > signal to > indent normally on the next line, but a paren at the end of the line > is a signal > to indent extra on the next line, on the assumption that it is a > continuation line.) > > The majority convention appears to be putting the semicolon outside > the paren: > -------- > grep '_ONLY(.*);' $(hg loc -I src) | wc > 667 3514 65119 > -------- > grep '_ONLY(.*;)' $(hg loc -I src) | wc > 216 868 19884 > -------- > grep 'NOT_[A-Z0-9]*(.*);' $(hg loc -I src) | wc > 855 4098 82619 > -------- > grep 'NOT_[A-Z0-9]*(.*;)' $(hg loc -I src) | wc > 296 1320 27929 > -------- > Done. I didn't know which was the convention because I've seen both. We should declare this to be the convention: LP64_ONLY(statement); // semi after the ) for the macro. Thanks!! Coleen From coleen.phillimore at oracle.com Fri Dec 4 14:13:16 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 4 Dec 2015 09:13:16 -0500 Subject: RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDA72F@DEWDFEMB12A.global.corp.sap> References: <565FA1C1.50909@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> <5660D576.80904@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA72F@DEWDFEMB12A.global.corp.sap> Message-ID: <56619F7C.903@oracle.com> Hi Goetz, Thank you again for testing and reviewing this. This was my mismerge because I did it by hand. Another reason why this class hierarchy is strange (which I'm trying to fix next). Thanks, Coleen ps. I hope someone from aarch64 (RedHat) can test out my patch. Please? On 12/4/15 5:21 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > thanks for incorporating my changes! > I missed one detail in my patch yesterday -- no clue why it compiled: > > diff -r 4a05b14492dc src/cpu/ppc/vm/templateInterpreter_ppc.cpp > --- a/src/cpu/ppc/vm/templateInterpreter_ppc.cpp Fri Dec 04 08:27:28 2015 +0100 > +++ b/src/cpu/ppc/vm/templateInterpreter_ppc.cpp Fri Dec 04 11:18:50 2015 +0100 > @@ -55,7 +55,7 @@ > // These should never be compiled since the interpreter will prefer > // the compiled version to the intrinsic version. > bool AbstractInterpreter::can_be_compiled(methodHandle m) { > - return !math_entry_available(method_kind(m)); > + return !TemplateInterpreter::math_entry_available(method_kind(m)); > } > > // How much stack a method activation needs in stack slots. > > Could you please fix this? Sorry for the trouble. > > Besides that it now works fine. > > Best regards, > Goetz. > > > > > >> -----Original Message----- >> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >> Sent: Freitag, 4. Dezember 2015 00:51 >> To: Lindenmaier, Goetz ; hotspot-dev >> developers >> Subject: Re: RFR 8144534: Refactor templateInterpreter and >> templateInterpreterGenerator functions >> >> >> Hi Goetz, >> >> Thank you for looking at my change. I made the ppc changes and hg added >> templateInterpreter_ppc/aarch64.cpp back, so they should be in the patch. >> >> Now webrev thinks I've deleted 7785 lines, but I didn't really. >> >> http://cr.openjdk.java.net/~coleenp/8144534.02/ >> >> The most interesting part of this change is in the x86 code: >> >> http://cr.openjdk.java.net/~coleenp/8144534.02/src/cpu/x86/vm/templateI >> nterpreterGenerator_x86.cpp.udiff.html >> >> This is where the 32 and 64 bit template interpreter code is merged. >> >> Thanks, >> Coleen >> >> On 12/3/15 8:14 AM, Lindenmaier, Goetz wrote: >>> Hi Coleen, >>> >>> I've been looking at this change. A cleanup in this area is really >>> useful. >>> I missed templateInterpreter_ppc.cpp in your patch, I guess you forgot >>> "hg add" for it. >>> In addition, I had to fix some code around math_entry_available(), see this >> patch: >>> http://cr.openjdk.java.net/~goetz/webrevs/8144534-interp/8144534- >> fixes_for_ppc.patch >>> In general, I think it's strange that AbstractInterpreterGenerator >>> implementations are in interpreter_.cpp, as mentioned In the bug. >>> Why not move them to templateInterpreterGenerator_.cpp? Or will >>> this be subject to a later change that removes the funny common >>> subclasses Interpreter/InterpreterGenerator? >>> >>> Should I make a change removing the CC_INTERP support from ppc? >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Coleen Phillimore >>>> Sent: Donnerstag, 3. Dezember 2015 02:58 >>>> To: hotspot-dev developers >>>> Subject: RFR 8144534: Refactor templateInterpreter and >>>> templateInterpreterGenerator functions >>>> >>>> Summary: merged templateInterpreter_x86_32/64 into >>>> templateInterpreterGenerator_x86.cpp (some 32/64 functions remain for >>>> the hand coded crc functions). >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144534.01/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144534 >>>> >>>> I tried to make this reviewable by hg renaming files. I basically >>>> renamed templateInterpreter_ppc.cpp and removed the >>>> AbstractInterpreter >>>> functions and put them back into templateInterpreter_ppc.cpp. I didn't >>>> really delete 4000 lines of code, more like 1500. >>>> >>>> Also, can someone with the PPC and AARCH port look at and test out >> these >>>> changes? I tried to reduce the #includes in the new >>>> templateInterpreter_ppc/aarch64.cpp files which worked for sparc. >>>> >>>> Tested with JPRT on all platforms, also ran jtreg and >>>> collocated/non-collocated tonga tests for linux x64 and i386 since >>>> that's were the real changes are. >>>> >>>> See the bug for more details and my partial vision of how these >>>> functions will be reorganized when I remove the broken c++ interpreter. >>>> >>>> Also tested that Zero still builds. >>>> >>>> Thanks! >>>> Coleen >>>> From jon.masamitsu at oracle.com Fri Dec 4 16:39:50 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 4 Dec 2015 08:39:50 -0800 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <565F2E6B.30802@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> Message-ID: <5661C1D6.4030901@oracle.com> Here's a new version of the fix (simpler thanks to a suggestion from Kim). http://cr.openjdk.java.net/~jmasa/8133023/webrev.05/ In the above webrev vm_version_x86.hpp appears but has no changes. There were changes to it in the previous version (04) but were undone in this latest version and may be why it appears in the webrev. The delta webrev is http://cr.openjdk.java.net/~jmasa/8133023/delta.05/ It has a white-space change in vm_version_sparc.hpp which does not appear in the diffs. Thanks. Jon On 12/2/2015 9:46 AM, Jon Masamitsu wrote: > > > On 11/30/2015 11:47 AM, Kim Barrett wrote: >> On Nov 30, 2015, at 12:20 PM, Jon Masamitsu >> wrote: >>>> src/share/vm/runtime/os.cpp >>>> 319 VM_Version::vm_init_before_ergo(); >>>> >>>> This call is in generic code, but only two definitions have been >>>> provided, for sparc and x86. Missing are aarch64, ppc, and zero. >>>> >>> Add vm_init_before_ergo() for those even though JPRT does not >>> build them? I don't need to be convinced to do it. Just >>> encouraged. Say "do it" and I'll do it. >> I think you should do it, rather than knowingly breaking the build >> for those targets when the needed code is so trivial. >> > > Here's the webrev for the delta for review comments to this point. > > http://cr.openjdk.java.net/~jmasa/8133023/delta.04/ > > Webrev for complete patch is here. > > http://cr.openjdk.java.net/~jmasa/8133023/webrev.04/ > > Jon From christian.thalinger at oracle.com Fri Dec 4 17:48:28 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Dec 2015 07:48:28 -1000 Subject: RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions In-Reply-To: <5660D576.80904@oracle.com> References: <565FA1C1.50909@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> <5660D576.80904@oracle.com> Message-ID: > On Dec 3, 2015, at 1:51 PM, Coleen Phillimore wrote: > > > Hi Goetz, > > Thank you for looking at my change. I made the ppc changes and hg added templateInterpreter_ppc/aarch64.cpp back, so they should be in the patch. > > Now webrev thinks I've deleted 7785 lines, but I didn't really. > > http://cr.openjdk.java.net/~coleenp/8144534.02/ > > The most interesting part of this change is in the x86 code: > > http://cr.openjdk.java.net/~coleenp/8144534.02/src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp.udiff.html > > This is where the 32 and 64 bit template interpreter code is merged. + Register rarg = NOT_LP64(rax) LP64_ONLY(c_rarg1); + Register rarg2 = NOT_LP64(rbx) LP64_ONLY(c_rarg2); Aren?t these always the same and could also be defined globally? Maybe keep rarg1. ! // compute beginning of parameters (rdi/r14) ! __ lea(rlocals, Address(rsp, rcx, Interpreter::stackElementScale(), -wordSize)); You can remove the rdi/r14 part. ! // restore rsi/r13 to have legal interpreter frame, i.e., bci == 0 <=> // r13 == code_base() // compute beginning of parameters (r14) Same for these. ExternalAddress unsatisfied(SharedRuntime::native_method_throw_unsatisfied_link_error_entry()); ! __ movptr(rscratch2, unsatisfied.addr()); __ cmpptr(rax, rscratch2); ! __ cmpptr(rax, unsatisfied.addr()); I think this is wrong. On 64-bit cmp can?t take a 64-bit immediate. That?s why we have the move. Otherwise this looks good but I?ve only looked at this one file. > > Thanks, > Coleen > > On 12/3/15 8:14 AM, Lindenmaier, Goetz wrote: >> Hi Coleen, >> >> I've been looking at this change. A cleanup in this area is really >> useful. >> I missed templateInterpreter_ppc.cpp in your patch, I guess you forgot >> "hg add" for it. >> In addition, I had to fix some code around math_entry_available(), see this patch: >> http://cr.openjdk.java.net/~goetz/webrevs/8144534-interp/8144534-fixes_for_ppc.patch >> >> In general, I think it's strange that AbstractInterpreterGenerator >> implementations are in interpreter_.cpp, as mentioned In the bug. >> Why not move them to templateInterpreterGenerator_.cpp? Or will >> this be subject to a later change that removes the funny common >> subclasses Interpreter/InterpreterGenerator? >> >> Should I make a change removing the CC_INTERP support from ppc? >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>> Behalf Of Coleen Phillimore >>> Sent: Donnerstag, 3. Dezember 2015 02:58 >>> To: hotspot-dev developers >>> Subject: RFR 8144534: Refactor templateInterpreter and >>> templateInterpreterGenerator functions >>> >>> Summary: merged templateInterpreter_x86_32/64 into >>> templateInterpreterGenerator_x86.cpp (some 32/64 functions remain for >>> the hand coded crc functions). >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8144534.01/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8144534 >>> >>> I tried to make this reviewable by hg renaming files. I basically >>> renamed templateInterpreter_ppc.cpp and removed the >>> AbstractInterpreter >>> functions and put them back into templateInterpreter_ppc.cpp. I didn't >>> really delete 4000 lines of code, more like 1500. >>> >>> Also, can someone with the PPC and AARCH port look at and test out these >>> changes? I tried to reduce the #includes in the new >>> templateInterpreter_ppc/aarch64.cpp files which worked for sparc. >>> >>> Tested with JPRT on all platforms, also ran jtreg and >>> collocated/non-collocated tonga tests for linux x64 and i386 since >>> that's were the real changes are. >>> >>> See the bug for more details and my partial vision of how these >>> functions will be reorganized when I remove the broken c++ interpreter. >>> >>> Also tested that Zero still builds. >>> >>> Thanks! >>> Coleen >>> > From christian.thalinger at oracle.com Fri Dec 4 17:52:37 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Dec 2015 07:52:37 -1000 Subject: RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions In-Reply-To: References: <565FA1C1.50909@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> <5660D576.80904@oracle.com> Message-ID: > On Dec 4, 2015, at 7:48 AM, Christian Thalinger wrote: > >> >> On Dec 3, 2015, at 1:51 PM, Coleen Phillimore wrote: >> >> >> Hi Goetz, >> >> Thank you for looking at my change. I made the ppc changes and hg added templateInterpreter_ppc/aarch64.cpp back, so they should be in the patch. >> >> Now webrev thinks I've deleted 7785 lines, but I didn't really. >> >> http://cr.openjdk.java.net/~coleenp/8144534.02/ >> >> The most interesting part of this change is in the x86 code: >> >> http://cr.openjdk.java.net/~coleenp/8144534.02/src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp.udiff.html >> >> This is where the 32 and 64 bit template interpreter code is merged. > > + Register rarg = NOT_LP64(rax) LP64_ONLY(c_rarg1); > + Register rarg2 = NOT_LP64(rbx) LP64_ONLY(c_rarg2); > > Aren?t these always the same and could also be defined globally? Maybe keep rarg1. > > ! // compute beginning of parameters (rdi/r14) > ! __ lea(rlocals, Address(rsp, rcx, Interpreter::stackElementScale(), -wordSize)); > > You can remove the rdi/r14 part. > > ! // restore rsi/r13 to have legal interpreter frame, i.e., bci == 0 <=> > // r13 == code_base() > > // compute beginning of parameters (r14) > > Same for these. > > ExternalAddress unsatisfied(SharedRuntime::native_method_throw_unsatisfied_link_error_entry()); > ! __ movptr(rscratch2, unsatisfied.addr()); > __ cmpptr(rax, rscratch2); > ! __ cmpptr(rax, unsatisfied.addr()); > > I think this is wrong. On 64-bit cmp can?t take a 64-bit immediate. That?s why we have the move. Maybe not. I should have looked at cmpptr first. Seems like it?s handling all this. Truly a macro instruction?. > > Otherwise this looks good but I?ve only looked at this one file. > >> >> Thanks, >> Coleen >> >> On 12/3/15 8:14 AM, Lindenmaier, Goetz wrote: >>> Hi Coleen, >>> >>> I've been looking at this change. A cleanup in this area is really >>> useful. >>> I missed templateInterpreter_ppc.cpp in your patch, I guess you forgot >>> "hg add" for it. >>> In addition, I had to fix some code around math_entry_available(), see this patch: >>> http://cr.openjdk.java.net/~goetz/webrevs/8144534-interp/8144534-fixes_for_ppc.patch >>> >>> In general, I think it's strange that AbstractInterpreterGenerator >>> implementations are in interpreter_.cpp, as mentioned In the bug. >>> Why not move them to templateInterpreterGenerator_.cpp? Or will >>> this be subject to a later change that removes the funny common >>> subclasses Interpreter/InterpreterGenerator? >>> >>> Should I make a change removing the CC_INTERP support from ppc? >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Coleen Phillimore >>>> Sent: Donnerstag, 3. Dezember 2015 02:58 >>>> To: hotspot-dev developers >>>> Subject: RFR 8144534: Refactor templateInterpreter and >>>> templateInterpreterGenerator functions >>>> >>>> Summary: merged templateInterpreter_x86_32/64 into >>>> templateInterpreterGenerator_x86.cpp (some 32/64 functions remain for >>>> the hand coded crc functions). >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144534.01/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144534 >>>> >>>> I tried to make this reviewable by hg renaming files. I basically >>>> renamed templateInterpreter_ppc.cpp and removed the >>>> AbstractInterpreter >>>> functions and put them back into templateInterpreter_ppc.cpp. I didn't >>>> really delete 4000 lines of code, more like 1500. >>>> >>>> Also, can someone with the PPC and AARCH port look at and test out these >>>> changes? I tried to reduce the #includes in the new >>>> templateInterpreter_ppc/aarch64.cpp files which worked for sparc. >>>> >>>> Tested with JPRT on all platforms, also ran jtreg and >>>> collocated/non-collocated tonga tests for linux x64 and i386 since >>>> that's were the real changes are. >>>> >>>> See the bug for more details and my partial vision of how these >>>> functions will be reorganized when I remove the broken c++ interpreter. >>>> >>>> Also tested that Zero still builds. >>>> >>>> Thanks! >>>> Coleen From asmundak at google.com Fri Dec 4 17:55:18 2015 From: asmundak at google.com (Alexander Smundak) Date: Fri, 4 Dec 2015 09:55:18 -0800 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <566147EF.4000109@oracle.com> References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> Message-ID: I am not convinced that increasing the complexity of the already quite intricate build machinery to avoid three additional checks in the source file is the right trade-off. Sasha On Thu, Dec 3, 2015 at 11:59 PM, David Holmes wrote: > On 4/12/2015 4:29 AM, Alexander Smundak wrote: >> >> On Wed, Dec 2, 2015 at 10:30 PM, David Holmes >> wrote: >>> >>> agent code: >>> >>> I'm still unclear why you can't, or shouldn't, pass through -Dppc64 and >>> -Dppc64le, such that you don't need to check for either being defined ?? >> >> You mean, add -Dppc64 to the compilation flags explicitly if the value >> of the OPENJDK_TARGET_CPU_LEGACY is 'ppc64le'? > > > Yes. Is that feasible? > > Thanks, > David > >> Sasha >> > From kim.barrett at oracle.com Fri Dec 4 18:00:13 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 4 Dec 2015 13:00:13 -0500 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <5661C1D6.4030901@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> Message-ID: <74CA79A0-947E-4A47-961B-E416F2176DFB@oracle.com> On Dec 4, 2015, at 11:39 AM, Jon Masamitsu wrote: > > Here's a new version of the fix (simpler thanks to a suggestion > from Kim). > > http://cr.openjdk.java.net/~jmasa/8133023/webrev.05/ > > In the above webrev vm_version_x86.hpp appears but has no changes. > There were changes to it in the previous version (04) but were undone in > this latest version and may be why it appears in the webrev. > > The delta webrev is > > http://cr.openjdk.java.net/~jmasa/8133023/delta.05/ > > It has a white-space change in vm_version_sparc.hpp which > does not appear in the diffs. Looks good. From jesper.wilhelmsson at oracle.com Fri Dec 4 18:07:39 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 4 Dec 2015 19:07:39 +0100 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <56600686.4060606@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> <565DEC2D.3010308@oracle.com> <565E3382.7050502@oracle.com> <56600686.4060606@oracle.com> Message-ID: <5661D66B.3080708@oracle.com> Looks good! I would prefer if there was a space after the comma in the new constraint lines in globals.hpp. I see that there are no spaces in the old lines as well. I you feel like it this could be cleaned up. Since you filed the other bug regarding the overflow I think this patch is good to go. /Jesper Den 3/12/15 kl. 10:08, skrev sangheon.kim: > Hi all, > > Here is next webrev. > http://cr.openjdk.java.net/~sangheki/8142341/webrev.02/ > http://cr.openjdk.java.net/~sangheki/8142341/webrev.02_to_01/ > > Testing: JPRT and TestOptionsWithRanges.java on machines that have over 120GB > memory. > > *Summary > 1. Enhanced the constraint function for HeapBaseMinAddress: (Tom) > 1) It will check an overflow the addition of MaxHeapSize and HeapBaseMinAddress. > And the overflow only happens when MaxHeapSize is default and using compressed > oop. Since MaxHeapSize is updated after ergo, FLAG_IS_ERGO(MaxHeapSize) is > necessary at the constraint function. > 2) As HeapBaseMinAddress has 'AfterErgo' tag, the constraint function will be > called after the overflow happens at Arguments::set_heap_size(). However it is > okay as we can detect the overflow before actual use of creating virtual space. > And the problem of the overflow is setting MaxHeapSize with bigger value that it > should be. > 3) Changed the order of HeapBaseMinAddress to locate later than MaxHeapSize from > globals.hpp as HeapBaseMinAddress refers MaxHeapSize. > > 2. Added missing single quote in commandLineFlagConstraintsGC.cpp at line 510. > (Tom) > > 3. Changed test to add dependency for NewSizeThreadIncrease. > > Thanks, > Sangheon > > > On 12/01/2015 03:55 PM, sangheon.kim wrote: >> Hi Tom, >> >> Thank you for this kind analysis! >> >> >> On 12/01/2015 10:51 AM, Tom Benson wrote: >>> Hi Sangheon, >>> >>> On 11/30/2015 6:51 PM, sangheon.kim wrote: >>>> Hi Tom, >>>> >>>> Thank you for reviewing this! >>>> >>>> On 11/30/2015 02:46 PM, Tom Benson wrote: >>>>> Hi Sangheon, >>>>> >>>>> I think there's a problem with using the same routine to check >>>>> HeapBaseMinAddress as is used for checking heap size in >>>>> commandLineFlagConstraintsGC.cpp. I tried running this, to make sure I >>>>> understood what it was trying to do. When I specified something too large >>>>> for HeapBaseMinAddress, the check reported that the value must be greater >>>>> than or equal to maximum value N. >>>> Sorry Tom, I can't understand. >>>> Currently we print the error message if its value is too large like, "must >>>> be less than or equal to aligned maximum value (xxx)". >>>> Do you mean it should be 'address' instead of 'value'? >>> >>> What I meant was that I got an internal error when I used the value the >>> message recommended, so perhaps the value should be further constrained. >> I see. >> >>> >>>> I thought it is okay. >>>> >>>>> Re-running with that (still huge) value, I get a fatal internal error out >>>>> of virtualspace.cpp. (In the debug version, an assertion in universe.cpp >>>>> triggers before reaching this point). EG: >>>> I am trying to reproduce this assert but I can't. Do you have more >>>> information to reproduce this? >>>> I did -version and running GCOld to trigger GC. >>>> >>>> java -XX:HeapBaseMinAddress=18446744073642442752 -version >>>> java -XX:HeapBaseMinAddress=18446744073642442752 GCOld 20 200 10 100 5000 >>>> >>> >>> You probably didn't hit the problem because you're running on a smaller >>> memory system than I am. On the system I'm on, the (computed) max heap size >>> is 32G. And if you specify an Xmx, you don't go through the code path that >>> causes it. >> Okay, my machine is 32G but when I test on bigger memory machine, I could see >> the assert. Thank you. >> >>> >>> Here's the root of the problem. In Arguments::set_heap_size(), we have this >>> code: >>> >>> if (FLAG_IS_DEFAULT(MaxHeapSize)) { >>> . . . >>> if (UseCompressedOops) { >>> // Limit the heap size to the maximum possible when using compressed oops >>> julong max_coop_heap = (julong)max_heap_for_compressed_oops(); >>> . . . >>> if (HeapBaseMinAddress + MaxHeapSize < max_coop_heap) { <======== *** >>> PROBLEM IS HERE *** >>> // Heap should be above HeapBaseMinAddress to get zero based >>> compressed oops >>> // but it should be not less than default MaxHeapSize. >>> max_coop_heap -= HeapBaseMinAddress; >>> } >>> reasonable_max = MIN2(reasonable_max, max_coop_heap); >>> } >>> >>> HeapBaseMinAddress is 64-bit unsigned, and in this case is 0xfffffffffc000000 >>> (the 18446744073642442752 from the command line). MaxHeapSize is 0x7CCCCC8 >>> and max_coop_heap is 0x7FE000000. The addition of HeapBaseMinAddress and >>> MaxHeapSize overflows to 0x3ccccc8. Since this is less than 0x7FE000000, we >>> subtract the 0xfffffffffc000000 from max_coop_heap, getting the result >>> 0x802000000. reasonable_max is 0x800000000, so it stays at that value after >>> the MIN2, rather than being reduced as it should be. >>> >>> Changing the conditional to also check for overflow avoids the problem. But >>> of course you don't get the requested HeapBaseMinAddress anyway, since it's >>> too high. >>> >>> So another approach would be to change your constraint to ensure that >>> (HeapBaseMinAddress plus MaxHeapSize) won't overflow. I don't think there's >>> any point in allowing a HeapBaseMinAddress so high that it would. >> Okay, I'm thinking about this. >> I will post a new webrev after testing. >> >> * I also read your other email that fixing constraint function makes sense. >> ** I already fixed your previous comment of extraneous single quote in >> commandLineFlagConstraintsGC.cpp at line 510. >> >> Thanks, >> Sangheon >> >> >>> >>> Tom >>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=0xffffffffffffffff -version >>>>> HeapBaseMinAddress (18446744073709551615) must be less than or equal to >>>>> aligned maximum value (18446744073642442752) >>>>> Error: Could not create the Java Virtual Machine. >>>>> Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=18446744073642442752 -version >>>>> # >>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>> # >>>>> # Internal Error (virtualspace.cpp:456), pid=10359, tid=10360 >>>>> # guarantee(size + noaccess_prefix_size(alignment) <= OopEncodingHeapMax) >>>>> failed: can not allocate compressed oop heap for this size >>>>> # >>>>> >>>>> Perhaps you should check only the alignment in the constraint code, without >>>>> checking the range, because I'm not sure you have the final heap size at >>>>> that point. Then maybe the heap reservation code should report this as a >>>>> non-internal error, at the point where the assertion occurs, if the user >>>>> specified a base address. >>>>> >>>>> There's also an extraneous single quote in commandLineFlagConstraintsGC.cpp >>>>> in the comment at line 510. >>>>> >>>>> Tom >>>>> >>>>> >>>>> Date: Tue, 24 Nov 2015 06:37:41 -0800 >>>>> From: "sangheon.kim" >>>>> To: Dmitry Dmitriev, >>>>> "hotspot-dev at openjdk.java.net Developers" >>>>> >>>>> Subject: Re: RFR(S): 8142341: GC: current flags need ranges to be >>>>> implemented >>>>> Message-ID:<56547635.9060808 at oracle.com> >>>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>>> >>>>> Hi Dmitry, >>>>> >>>>> Thank you for the review! >>>>> Sure I will update my patch related to your enhancement. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote: >>>>> >>>>>> Hi Sangheon, >>>>>> >>>>>> Looks good to me! Thank you for fixing that. I hope that enhancement >>>>>> will be pushed today(currently in JPRT queue), so please update your >>>>>> patch after that! >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>> >>>>>> On 21.11.2015 0:04, sangheon.kim wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Could I have a couple of reviews for this change to add explicit >>>>>>> 'range' for flags? >>>>>>> >>>>>>> Previously, we added 'range' when it is needed to avoid assert/crash >>>>>>> but now explicit 'range' are needed for all flags. >>>>>>> All flags should have 'range' or 'constraint' at least. >>>>>>> >>>>>>> CR:https://bugs.openjdk.java.net/browse/JDK-8142341 >>>>>>> Webrev:http://cr.openjdk.java.net/~sangheki/8142341/webrev.00 >>>>>>> Testing: JPRT, RBT >>>>>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for >>>>>>> embedded >>>>>>> >>>>>>> * Summary >>>>>>> 1. Added 3 new constraint functions. >>>>>>> 1) HeapBaseMinAddress: Added to avoid an overflow after align up >>>>>>> and this flag makes hang up without constraint function. (newly added >>>>>>> as a part of GC work) >>>>>>> 2) TLABWasteIncrement: Without this constraint function we don't >>>>>>> have problems (even many GCs happen). But added to avoid an overflow >>>>>>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are also >>>>>>> separate CR for this overflow ( JDK-8143352 ). >>>>>>> 3) NUMAInterleaveGranularity: Added to avoid an overflow after >>>>>>> align up. >>>>>>> >>>>>>> 2. Some flags have narrower range than their type. >>>>>>> 1) Here's the reason why some flags should have different range. >>>>>>> (same order from globals.hpp) >>>>>>> {flag type} {flag name}: (range), {comment} >>>>>>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), >>>>>>> max_uintx), there is a comment at numa_interleaving_init() that this >>>>>>> flag should be larger than vm_allocation_granularity(). >>>>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as >>>>>>> used for multiplication >>>>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which >>>>>>> has 'unsigned int' type input parameter. >>>>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function which >>>>>>> has 'unsigned int' type input parameter. >>>>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function >>>>>>> which has 'long' type input parameter. >>>>>>> uintx PausePadding: (0, max_juint), used to set a function which has >>>>>>> 'unsigned int' type input parameter. >>>>>>> uintx PromotedPadding: (0, max_juint), used to set a function which >>>>>>> has 'unsigned int' type input parameter. >>>>>>> uintx SurvivorPadding: (0, max_juint), used to set a function which >>>>>>> has 'unsigned int' type input parameter. >>>>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag >>>>>>> is divided by 100 I assume this is percentage. >>>>>>> uintx GCTimeRatio: (0, max_juint), used to set a function which has >>>>>>> 'unsigned int' type input parameter. >>>>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint) >>>>>>> intx PrefetchScanIntervalInBytes: (-1, max_jint) >>>>>>> intx PrefetchFieldsAhead: (-1, max_jint), I think these 3 Prefetch* >>>>>>> flags should have same upper limit and looking at their related codes >>>>>>> 'max_jint' seems appropriate ( no problem with 'max_jint' during >>>>>>> testing). However, as Prefetch::read/write() needs 'intx', 'intx' >>>>>>> also seems good but we have to fix some codes (maybe including >>>>>>> generated codes). >>>>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function which >>>>>>> has 'unsigned int' type input parameter. >>>>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint >>>>>>> variable and used 'for loop' which has uint increment. i.e. for (uint >>>>>>> i=0; i>>>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at >>>>>>> 'increment for loop()' as max value and the increment is uint. >>>>>>> uintx CMSYieldSleepCount: (0, max_juint), used at 'increment for >>>>>>> loop()' as max value and the increment is uint. >>>>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return value >>>>>>> of uint type function and for division. i.e. uint >>>>>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return >>>>>>> TLABRefillWasteFraction; } >>>>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int) >>>>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we only >>>>>>> use " if (a !=0, >0, >1)". >>>>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we only >>>>>>> use " if (a !=0, >0, >1)". >>>>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only use >>>>>>> " if (a !=0, >0)". >>>>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned >>>>>>> int' >>>>>>> >>>>>>> (g1_globals.hpp) >>>>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int) >>>>>>> type variable. >>>>>>> >>>>>>> 3. Excluded flags from TestOptionsWithRanges.java >>>>>>> 1) Memory and thread related flags: tests for these flags will >>>>>>> consume too many resources from the system. >>>>>>> 2) VMThreadStackSize: range work for this flag is not included in >>>>>>> this patch but I faced OOME several times, so excluded. >>>>>>> >>>>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] >>>>>>> TestOptionsWithRanges: allow excluding only a subset of tested values >>>>>>> specified for a flag) next time. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>> >>>> >>> >> > From tom.benson at oracle.com Fri Dec 4 19:17:20 2015 From: tom.benson at oracle.com (Tom Benson) Date: Fri, 4 Dec 2015 14:17:20 -0500 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <5661D66B.3080708@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> <565DEC2D.3010308@oracle.com> <565E3382.7050502@oracle.com> <56600686.4060606@oracle.com> <5661D66B.3080708@oracle.com> Message-ID: <5661E6C0.1090504@oracle.com> Hi Sangheon, I'm also also OK with the change, but I found the wording of this comment a little confusing, because 'value' is also the name of the argument which is the HeapBaseMinAddress being checked: 554 // But below check is okay as the wrong value means bigger than the value should be. How about something like: If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value. Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx. ? Tnx, Tom On 12/4/2015 1:07 PM, Jesper Wilhelmsson wrote: > Looks good! > > I would prefer if there was a space after the comma in the new > constraint lines in globals.hpp. I see that there are no spaces in the > old lines as well. I you feel like it this could be cleaned up. > > Since you filed the other bug regarding the overflow I think this > patch is good to go. > /Jesper > > Den 3/12/15 kl. 10:08, skrev sangheon.kim: >> Hi all, >> >> Here is next webrev. >> http://cr.openjdk.java.net/~sangheki/8142341/webrev.02/ >> http://cr.openjdk.java.net/~sangheki/8142341/webrev.02_to_01/ >> >> Testing: JPRT and TestOptionsWithRanges.java on machines that have >> over 120GB >> memory. >> >> *Summary >> 1. Enhanced the constraint function for HeapBaseMinAddress: (Tom) >> 1) It will check an overflow the addition of MaxHeapSize and >> HeapBaseMinAddress. >> And the overflow only happens when MaxHeapSize is default and using >> compressed >> oop. Since MaxHeapSize is updated after ergo, >> FLAG_IS_ERGO(MaxHeapSize) is >> necessary at the constraint function. >> 2) As HeapBaseMinAddress has 'AfterErgo' tag, the constraint function >> will be >> called after the overflow happens at Arguments::set_heap_size(). >> However it is >> okay as we can detect the overflow before actual use of creating >> virtual space. >> And the problem of the overflow is setting MaxHeapSize with bigger >> value that it >> should be. >> 3) Changed the order of HeapBaseMinAddress to locate later than >> MaxHeapSize from >> globals.hpp as HeapBaseMinAddress refers MaxHeapSize. >> >> 2. Added missing single quote in commandLineFlagConstraintsGC.cpp at >> line 510. >> (Tom) >> >> 3. Changed test to add dependency for NewSizeThreadIncrease. >> >> Thanks, >> Sangheon >> >> >> On 12/01/2015 03:55 PM, sangheon.kim wrote: >>> Hi Tom, >>> >>> Thank you for this kind analysis! >>> >>> >>> On 12/01/2015 10:51 AM, Tom Benson wrote: >>>> Hi Sangheon, >>>> >>>> On 11/30/2015 6:51 PM, sangheon.kim wrote: >>>>> Hi Tom, >>>>> >>>>> Thank you for reviewing this! >>>>> >>>>> On 11/30/2015 02:46 PM, Tom Benson wrote: >>>>>> Hi Sangheon, >>>>>> >>>>>> I think there's a problem with using the same routine to check >>>>>> HeapBaseMinAddress as is used for checking heap size in >>>>>> commandLineFlagConstraintsGC.cpp. I tried running this, to make >>>>>> sure I >>>>>> understood what it was trying to do. When I specified something >>>>>> too large >>>>>> for HeapBaseMinAddress, the check reported that the value must be >>>>>> greater >>>>>> than or equal to maximum value N. >>>>> Sorry Tom, I can't understand. >>>>> Currently we print the error message if its value is too large >>>>> like, "must >>>>> be less than or equal to aligned maximum value (xxx)". >>>>> Do you mean it should be 'address' instead of 'value'? >>>> >>>> What I meant was that I got an internal error when I used the value >>>> the >>>> message recommended, so perhaps the value should be further >>>> constrained. >>> I see. >>> >>>> >>>>> I thought it is okay. >>>>> >>>>>> Re-running with that (still huge) value, I get a fatal internal >>>>>> error out >>>>>> of virtualspace.cpp. (In the debug version, an assertion in >>>>>> universe.cpp >>>>>> triggers before reaching this point). EG: >>>>> I am trying to reproduce this assert but I can't. Do you have more >>>>> information to reproduce this? >>>>> I did -version and running GCOld to trigger GC. >>>>> >>>>> java -XX:HeapBaseMinAddress=18446744073642442752 -version >>>>> java -XX:HeapBaseMinAddress=18446744073642442752 GCOld 20 200 10 >>>>> 100 5000 >>>>> >>>> >>>> You probably didn't hit the problem because you're running on a >>>> smaller >>>> memory system than I am. On the system I'm on, the (computed) max >>>> heap size >>>> is 32G. And if you specify an Xmx, you don't go through the code >>>> path that >>>> causes it. >>> Okay, my machine is 32G but when I test on bigger memory machine, I >>> could see >>> the assert. Thank you. >>> >>>> >>>> Here's the root of the problem. In Arguments::set_heap_size(), we >>>> have this >>>> code: >>>> >>>> if (FLAG_IS_DEFAULT(MaxHeapSize)) { >>>> . . . >>>> if (UseCompressedOops) { >>>> // Limit the heap size to the maximum possible when using >>>> compressed oops >>>> julong max_coop_heap = (julong)max_heap_for_compressed_oops(); >>>> . . . >>>> if (HeapBaseMinAddress + MaxHeapSize < max_coop_heap) { >>>> <======== *** >>>> PROBLEM IS HERE *** >>>> // Heap should be above HeapBaseMinAddress to get zero based >>>> compressed oops >>>> // but it should be not less than default MaxHeapSize. >>>> max_coop_heap -= HeapBaseMinAddress; >>>> } >>>> reasonable_max = MIN2(reasonable_max, max_coop_heap); >>>> } >>>> >>>> HeapBaseMinAddress is 64-bit unsigned, and in this case is >>>> 0xfffffffffc000000 >>>> (the 18446744073642442752 from the command line). MaxHeapSize is >>>> 0x7CCCCC8 >>>> and max_coop_heap is 0x7FE000000. The addition of >>>> HeapBaseMinAddress and >>>> MaxHeapSize overflows to 0x3ccccc8. Since this is less than >>>> 0x7FE000000, we >>>> subtract the 0xfffffffffc000000 from max_coop_heap, getting the result >>>> 0x802000000. reasonable_max is 0x800000000, so it stays at that >>>> value after >>>> the MIN2, rather than being reduced as it should be. >>>> >>>> Changing the conditional to also check for overflow avoids the >>>> problem. But >>>> of course you don't get the requested HeapBaseMinAddress anyway, >>>> since it's >>>> too high. >>>> >>>> So another approach would be to change your constraint to ensure that >>>> (HeapBaseMinAddress plus MaxHeapSize) won't overflow. I don't >>>> think there's >>>> any point in allowing a HeapBaseMinAddress so high that it would. >>> Okay, I'm thinking about this. >>> I will post a new webrev after testing. >>> >>> * I also read your other email that fixing constraint function makes >>> sense. >>> ** I already fixed your previous comment of extraneous single quote in >>> commandLineFlagConstraintsGC.cpp at line 510. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Tom >>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=0xffffffffffffffff >>>>>> -version >>>>>> HeapBaseMinAddress (18446744073709551615) must be less than or >>>>>> equal to >>>>>> aligned maximum value (18446744073642442752) >>>>>> Error: Could not create the Java Virtual Machine. >>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>> >>>>>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=18446744073642442752 >>>>>> -version >>>>>> # >>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>> # >>>>>> # Internal Error (virtualspace.cpp:456), pid=10359, tid=10360 >>>>>> # guarantee(size + noaccess_prefix_size(alignment) <= >>>>>> OopEncodingHeapMax) >>>>>> failed: can not allocate compressed oop heap for this size >>>>>> # >>>>>> >>>>>> Perhaps you should check only the alignment in the constraint >>>>>> code, without >>>>>> checking the range, because I'm not sure you have the final heap >>>>>> size at >>>>>> that point. Then maybe the heap reservation code should report >>>>>> this as a >>>>>> non-internal error, at the point where the assertion occurs, if >>>>>> the user >>>>>> specified a base address. >>>>>> >>>>>> There's also an extraneous single quote in >>>>>> commandLineFlagConstraintsGC.cpp >>>>>> in the comment at line 510. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> Date: Tue, 24 Nov 2015 06:37:41 -0800 >>>>>> From: "sangheon.kim" >>>>>> To: Dmitry Dmitriev, >>>>>> "hotspot-dev at openjdk.java.net Developers" >>>>>> >>>>>> Subject: Re: RFR(S): 8142341: GC: current flags need ranges to be >>>>>> implemented >>>>>> Message-ID:<56547635.9060808 at oracle.com> >>>>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>>>> >>>>>> Hi Dmitry, >>>>>> >>>>>> Thank you for the review! >>>>>> Sure I will update my patch related to your enhancement. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote: >>>>>> >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> Looks good to me! Thank you for fixing that. I hope that >>>>>>> enhancement >>>>>>> will be pushed today(currently in JPRT queue), so please update >>>>>>> your >>>>>>> patch after that! >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>>> >>>>>>> On 21.11.2015 0:04, sangheon.kim wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Could I have a couple of reviews for this change to add explicit >>>>>>>> 'range' for flags? >>>>>>>> >>>>>>>> Previously, we added 'range' when it is needed to avoid >>>>>>>> assert/crash >>>>>>>> but now explicit 'range' are needed for all flags. >>>>>>>> All flags should have 'range' or 'constraint' at least. >>>>>>>> >>>>>>>> CR:https://bugs.openjdk.java.net/browse/JDK-8142341 >>>>>>>> Webrev:http://cr.openjdk.java.net/~sangheki/8142341/webrev.00 >>>>>>>> Testing: JPRT, RBT >>>>>>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>>>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for >>>>>>>> embedded >>>>>>>> >>>>>>>> * Summary >>>>>>>> 1. Added 3 new constraint functions. >>>>>>>> 1) HeapBaseMinAddress: Added to avoid an overflow after >>>>>>>> align up >>>>>>>> and this flag makes hang up without constraint function. (newly >>>>>>>> added >>>>>>>> as a part of GC work) >>>>>>>> 2) TLABWasteIncrement: Without this constraint function we >>>>>>>> don't >>>>>>>> have problems (even many GCs happen). But added to avoid an >>>>>>>> overflow >>>>>>>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are >>>>>>>> also >>>>>>>> separate CR for this overflow ( JDK-8143352 ). >>>>>>>> 3) NUMAInterleaveGranularity: Added to avoid an overflow after >>>>>>>> align up. >>>>>>>> >>>>>>>> 2. Some flags have narrower range than their type. >>>>>>>> 1) Here's the reason why some flags should have different >>>>>>>> range. >>>>>>>> (same order from globals.hpp) >>>>>>>> {flag type} {flag name}: (range), {comment} >>>>>>>> size_t NUMAInterleaveGranularity: >>>>>>>> (os::vm_allocation_granularity(), >>>>>>>> max_uintx), there is a comment at numa_interleaving_init() that >>>>>>>> this >>>>>>>> flag should be larger than vm_allocation_granularity(). >>>>>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be >>>>>>>> zero as >>>>>>>> used for multiplication >>>>>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which >>>>>>>> has 'unsigned int' type input parameter. >>>>>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function >>>>>>>> which >>>>>>>> has 'unsigned int' type input parameter. >>>>>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function >>>>>>>> which has 'long' type input parameter. >>>>>>>> uintx PausePadding: (0, max_juint), used to set a function >>>>>>>> which has >>>>>>>> 'unsigned int' type input parameter. >>>>>>>> uintx PromotedPadding: (0, max_juint), used to set a function >>>>>>>> which >>>>>>>> has 'unsigned int' type input parameter. >>>>>>>> uintx SurvivorPadding: (0, max_juint), used to set a function >>>>>>>> which >>>>>>>> has 'unsigned int' type input parameter. >>>>>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this >>>>>>>> flag >>>>>>>> is divided by 100 I assume this is percentage. >>>>>>>> uintx GCTimeRatio: (0, max_juint), used to set a function which >>>>>>>> has >>>>>>>> 'unsigned int' type input parameter. >>>>>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint) >>>>>>>> intx PrefetchScanIntervalInBytes: (-1, max_jint) >>>>>>>> intx PrefetchFieldsAhead: (-1, max_jint), I think these 3 >>>>>>>> Prefetch* >>>>>>>> flags should have same upper limit and looking at their related >>>>>>>> codes >>>>>>>> 'max_jint' seems appropriate ( no problem with 'max_jint' during >>>>>>>> testing). However, as Prefetch::read/write() needs 'intx', 'intx' >>>>>>>> also seems good but we have to fix some codes (maybe including >>>>>>>> generated codes). >>>>>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function >>>>>>>> which >>>>>>>> has 'unsigned int' type input parameter. >>>>>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint >>>>>>>> variable and used 'for loop' which has uint increment. i.e. for >>>>>>>> (uint >>>>>>>> i=0; i>>>>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at >>>>>>>> 'increment for loop()' as max value and the increment is uint. >>>>>>>> uintx CMSYieldSleepCount: (0, max_juint), used at 'increment for >>>>>>>> loop()' as max value and the increment is uint. >>>>>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return >>>>>>>> value >>>>>>>> of uint type function and for division. i.e. uint >>>>>>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return >>>>>>>> TLABRefillWasteFraction; } >>>>>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int) >>>>>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and >>>>>>>> we only >>>>>>>> use " if (a !=0, >0, >1)". >>>>>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and >>>>>>>> we only >>>>>>>> use " if (a !=0, >0, >1)". >>>>>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we >>>>>>>> only use >>>>>>>> " if (a !=0, >0)". >>>>>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to >>>>>>>> 'unsigned >>>>>>>> int' >>>>>>>> >>>>>>>> (g1_globals.hpp) >>>>>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set >>>>>>>> (int) >>>>>>>> type variable. >>>>>>>> >>>>>>>> 3. Excluded flags from TestOptionsWithRanges.java >>>>>>>> 1) Memory and thread related flags: tests for these flags will >>>>>>>> consume too many resources from the system. >>>>>>>> 2) VMThreadStackSize: range work for this flag is not included in >>>>>>>> this patch but I faced OOME several times, so excluded. >>>>>>>> >>>>>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] >>>>>>>> TestOptionsWithRanges: allow excluding only a subset of tested >>>>>>>> values >>>>>>>> specified for a flag) next time. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>> >>> >> From sangheon.kim at oracle.com Fri Dec 4 19:59:59 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Fri, 4 Dec 2015 11:59:59 -0800 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <5661D66B.3080708@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> <565DEC2D.3010308@oracle.com> <565E3382.7050502@oracle.com> <56600686.4060606@oracle.com> <5661D66B.3080708@oracle.com> Message-ID: <5661F0BF.5080302@oracle.com> Hi Jesper, Thank you for reviewing this. On 12/04/2015 10:07 AM, Jesper Wilhelmsson wrote: > Looks good! > > I would prefer if there was a space after the comma in the new > constraint lines in globals.hpp. I see that there are no spaces in the > old lines as well. I you feel like it this could be cleaned up. You are right. However let me address from a separate CR as you said old lines also don't have a space. > > Since you filed the other bug regarding the overflow I think this > patch is good to go. Thanks! Sangheon > /Jesper > > Den 3/12/15 kl. 10:08, skrev sangheon.kim: >> Hi all, >> >> Here is next webrev. >> http://cr.openjdk.java.net/~sangheki/8142341/webrev.02/ >> http://cr.openjdk.java.net/~sangheki/8142341/webrev.02_to_01/ >> >> Testing: JPRT and TestOptionsWithRanges.java on machines that have >> over 120GB >> memory. >> >> *Summary >> 1. Enhanced the constraint function for HeapBaseMinAddress: (Tom) >> 1) It will check an overflow the addition of MaxHeapSize and >> HeapBaseMinAddress. >> And the overflow only happens when MaxHeapSize is default and using >> compressed >> oop. Since MaxHeapSize is updated after ergo, >> FLAG_IS_ERGO(MaxHeapSize) is >> necessary at the constraint function. >> 2) As HeapBaseMinAddress has 'AfterErgo' tag, the constraint function >> will be >> called after the overflow happens at Arguments::set_heap_size(). >> However it is >> okay as we can detect the overflow before actual use of creating >> virtual space. >> And the problem of the overflow is setting MaxHeapSize with bigger >> value that it >> should be. >> 3) Changed the order of HeapBaseMinAddress to locate later than >> MaxHeapSize from >> globals.hpp as HeapBaseMinAddress refers MaxHeapSize. >> >> 2. Added missing single quote in commandLineFlagConstraintsGC.cpp at >> line 510. >> (Tom) >> >> 3. Changed test to add dependency for NewSizeThreadIncrease. >> >> Thanks, >> Sangheon >> >> >> On 12/01/2015 03:55 PM, sangheon.kim wrote: >>> Hi Tom, >>> >>> Thank you for this kind analysis! >>> >>> >>> On 12/01/2015 10:51 AM, Tom Benson wrote: >>>> Hi Sangheon, >>>> >>>> On 11/30/2015 6:51 PM, sangheon.kim wrote: >>>>> Hi Tom, >>>>> >>>>> Thank you for reviewing this! >>>>> >>>>> On 11/30/2015 02:46 PM, Tom Benson wrote: >>>>>> Hi Sangheon, >>>>>> >>>>>> I think there's a problem with using the same routine to check >>>>>> HeapBaseMinAddress as is used for checking heap size in >>>>>> commandLineFlagConstraintsGC.cpp. I tried running this, to make >>>>>> sure I >>>>>> understood what it was trying to do. When I specified something >>>>>> too large >>>>>> for HeapBaseMinAddress, the check reported that the value must be >>>>>> greater >>>>>> than or equal to maximum value N. >>>>> Sorry Tom, I can't understand. >>>>> Currently we print the error message if its value is too large >>>>> like, "must >>>>> be less than or equal to aligned maximum value (xxx)". >>>>> Do you mean it should be 'address' instead of 'value'? >>>> >>>> What I meant was that I got an internal error when I used the value >>>> the >>>> message recommended, so perhaps the value should be further >>>> constrained. >>> I see. >>> >>>> >>>>> I thought it is okay. >>>>> >>>>>> Re-running with that (still huge) value, I get a fatal internal >>>>>> error out >>>>>> of virtualspace.cpp. (In the debug version, an assertion in >>>>>> universe.cpp >>>>>> triggers before reaching this point). EG: >>>>> I am trying to reproduce this assert but I can't. Do you have more >>>>> information to reproduce this? >>>>> I did -version and running GCOld to trigger GC. >>>>> >>>>> java -XX:HeapBaseMinAddress=18446744073642442752 -version >>>>> java -XX:HeapBaseMinAddress=18446744073642442752 GCOld 20 200 10 >>>>> 100 5000 >>>>> >>>> >>>> You probably didn't hit the problem because you're running on a >>>> smaller >>>> memory system than I am. On the system I'm on, the (computed) max >>>> heap size >>>> is 32G. And if you specify an Xmx, you don't go through the code >>>> path that >>>> causes it. >>> Okay, my machine is 32G but when I test on bigger memory machine, I >>> could see >>> the assert. Thank you. >>> >>>> >>>> Here's the root of the problem. In Arguments::set_heap_size(), we >>>> have this >>>> code: >>>> >>>> if (FLAG_IS_DEFAULT(MaxHeapSize)) { >>>> . . . >>>> if (UseCompressedOops) { >>>> // Limit the heap size to the maximum possible when using >>>> compressed oops >>>> julong max_coop_heap = (julong)max_heap_for_compressed_oops(); >>>> . . . >>>> if (HeapBaseMinAddress + MaxHeapSize < max_coop_heap) { >>>> <======== *** >>>> PROBLEM IS HERE *** >>>> // Heap should be above HeapBaseMinAddress to get zero based >>>> compressed oops >>>> // but it should be not less than default MaxHeapSize. >>>> max_coop_heap -= HeapBaseMinAddress; >>>> } >>>> reasonable_max = MIN2(reasonable_max, max_coop_heap); >>>> } >>>> >>>> HeapBaseMinAddress is 64-bit unsigned, and in this case is >>>> 0xfffffffffc000000 >>>> (the 18446744073642442752 from the command line). MaxHeapSize is >>>> 0x7CCCCC8 >>>> and max_coop_heap is 0x7FE000000. The addition of >>>> HeapBaseMinAddress and >>>> MaxHeapSize overflows to 0x3ccccc8. Since this is less than >>>> 0x7FE000000, we >>>> subtract the 0xfffffffffc000000 from max_coop_heap, getting the result >>>> 0x802000000. reasonable_max is 0x800000000, so it stays at that >>>> value after >>>> the MIN2, rather than being reduced as it should be. >>>> >>>> Changing the conditional to also check for overflow avoids the >>>> problem. But >>>> of course you don't get the requested HeapBaseMinAddress anyway, >>>> since it's >>>> too high. >>>> >>>> So another approach would be to change your constraint to ensure that >>>> (HeapBaseMinAddress plus MaxHeapSize) won't overflow. I don't >>>> think there's >>>> any point in allowing a HeapBaseMinAddress so high that it would. >>> Okay, I'm thinking about this. >>> I will post a new webrev after testing. >>> >>> * I also read your other email that fixing constraint function makes >>> sense. >>> ** I already fixed your previous comment of extraneous single quote in >>> commandLineFlagConstraintsGC.cpp at line 510. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Tom >>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=0xffffffffffffffff >>>>>> -version >>>>>> HeapBaseMinAddress (18446744073709551615) must be less than or >>>>>> equal to >>>>>> aligned maximum value (18446744073642442752) >>>>>> Error: Could not create the Java Virtual Machine. >>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>> >>>>>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=18446744073642442752 >>>>>> -version >>>>>> # >>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>> # >>>>>> # Internal Error (virtualspace.cpp:456), pid=10359, tid=10360 >>>>>> # guarantee(size + noaccess_prefix_size(alignment) <= >>>>>> OopEncodingHeapMax) >>>>>> failed: can not allocate compressed oop heap for this size >>>>>> # >>>>>> >>>>>> Perhaps you should check only the alignment in the constraint >>>>>> code, without >>>>>> checking the range, because I'm not sure you have the final heap >>>>>> size at >>>>>> that point. Then maybe the heap reservation code should report >>>>>> this as a >>>>>> non-internal error, at the point where the assertion occurs, if >>>>>> the user >>>>>> specified a base address. >>>>>> >>>>>> There's also an extraneous single quote in >>>>>> commandLineFlagConstraintsGC.cpp >>>>>> in the comment at line 510. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> Date: Tue, 24 Nov 2015 06:37:41 -0800 >>>>>> From: "sangheon.kim" >>>>>> To: Dmitry Dmitriev, >>>>>> "hotspot-dev at openjdk.java.net Developers" >>>>>> >>>>>> Subject: Re: RFR(S): 8142341: GC: current flags need ranges to be >>>>>> implemented >>>>>> Message-ID:<56547635.9060808 at oracle.com> >>>>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>>>> >>>>>> Hi Dmitry, >>>>>> >>>>>> Thank you for the review! >>>>>> Sure I will update my patch related to your enhancement. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote: >>>>>> >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> Looks good to me! Thank you for fixing that. I hope that >>>>>>> enhancement >>>>>>> will be pushed today(currently in JPRT queue), so please update >>>>>>> your >>>>>>> patch after that! >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>>> >>>>>>> On 21.11.2015 0:04, sangheon.kim wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Could I have a couple of reviews for this change to add explicit >>>>>>>> 'range' for flags? >>>>>>>> >>>>>>>> Previously, we added 'range' when it is needed to avoid >>>>>>>> assert/crash >>>>>>>> but now explicit 'range' are needed for all flags. >>>>>>>> All flags should have 'range' or 'constraint' at least. >>>>>>>> >>>>>>>> CR:https://bugs.openjdk.java.net/browse/JDK-8142341 >>>>>>>> Webrev:http://cr.openjdk.java.net/~sangheki/8142341/webrev.00 >>>>>>>> Testing: JPRT, RBT >>>>>>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>>>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for >>>>>>>> embedded >>>>>>>> >>>>>>>> * Summary >>>>>>>> 1. Added 3 new constraint functions. >>>>>>>> 1) HeapBaseMinAddress: Added to avoid an overflow after >>>>>>>> align up >>>>>>>> and this flag makes hang up without constraint function. (newly >>>>>>>> added >>>>>>>> as a part of GC work) >>>>>>>> 2) TLABWasteIncrement: Without this constraint function we >>>>>>>> don't >>>>>>>> have problems (even many GCs happen). But added to avoid an >>>>>>>> overflow >>>>>>>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are >>>>>>>> also >>>>>>>> separate CR for this overflow ( JDK-8143352 ). >>>>>>>> 3) NUMAInterleaveGranularity: Added to avoid an overflow after >>>>>>>> align up. >>>>>>>> >>>>>>>> 2. Some flags have narrower range than their type. >>>>>>>> 1) Here's the reason why some flags should have different >>>>>>>> range. >>>>>>>> (same order from globals.hpp) >>>>>>>> {flag type} {flag name}: (range), {comment} >>>>>>>> size_t NUMAInterleaveGranularity: >>>>>>>> (os::vm_allocation_granularity(), >>>>>>>> max_uintx), there is a comment at numa_interleaving_init() that >>>>>>>> this >>>>>>>> flag should be larger than vm_allocation_granularity(). >>>>>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be >>>>>>>> zero as >>>>>>>> used for multiplication >>>>>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which >>>>>>>> has 'unsigned int' type input parameter. >>>>>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function >>>>>>>> which >>>>>>>> has 'unsigned int' type input parameter. >>>>>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function >>>>>>>> which has 'long' type input parameter. >>>>>>>> uintx PausePadding: (0, max_juint), used to set a function >>>>>>>> which has >>>>>>>> 'unsigned int' type input parameter. >>>>>>>> uintx PromotedPadding: (0, max_juint), used to set a function >>>>>>>> which >>>>>>>> has 'unsigned int' type input parameter. >>>>>>>> uintx SurvivorPadding: (0, max_juint), used to set a function >>>>>>>> which >>>>>>>> has 'unsigned int' type input parameter. >>>>>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this >>>>>>>> flag >>>>>>>> is divided by 100 I assume this is percentage. >>>>>>>> uintx GCTimeRatio: (0, max_juint), used to set a function which >>>>>>>> has >>>>>>>> 'unsigned int' type input parameter. >>>>>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint) >>>>>>>> intx PrefetchScanIntervalInBytes: (-1, max_jint) >>>>>>>> intx PrefetchFieldsAhead: (-1, max_jint), I think these 3 >>>>>>>> Prefetch* >>>>>>>> flags should have same upper limit and looking at their related >>>>>>>> codes >>>>>>>> 'max_jint' seems appropriate ( no problem with 'max_jint' during >>>>>>>> testing). However, as Prefetch::read/write() needs 'intx', 'intx' >>>>>>>> also seems good but we have to fix some codes (maybe including >>>>>>>> generated codes). >>>>>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function >>>>>>>> which >>>>>>>> has 'unsigned int' type input parameter. >>>>>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint >>>>>>>> variable and used 'for loop' which has uint increment. i.e. for >>>>>>>> (uint >>>>>>>> i=0; i>>>>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at >>>>>>>> 'increment for loop()' as max value and the increment is uint. >>>>>>>> uintx CMSYieldSleepCount: (0, max_juint), used at 'increment for >>>>>>>> loop()' as max value and the increment is uint. >>>>>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return >>>>>>>> value >>>>>>>> of uint type function and for division. i.e. uint >>>>>>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return >>>>>>>> TLABRefillWasteFraction; } >>>>>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int) >>>>>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and >>>>>>>> we only >>>>>>>> use " if (a !=0, >0, >1)". >>>>>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and >>>>>>>> we only >>>>>>>> use " if (a !=0, >0, >1)". >>>>>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we >>>>>>>> only use >>>>>>>> " if (a !=0, >0)". >>>>>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to >>>>>>>> 'unsigned >>>>>>>> int' >>>>>>>> >>>>>>>> (g1_globals.hpp) >>>>>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set >>>>>>>> (int) >>>>>>>> type variable. >>>>>>>> >>>>>>>> 3. Excluded flags from TestOptionsWithRanges.java >>>>>>>> 1) Memory and thread related flags: tests for these flags will >>>>>>>> consume too many resources from the system. >>>>>>>> 2) VMThreadStackSize: range work for this flag is not included in >>>>>>>> this patch but I faced OOME several times, so excluded. >>>>>>>> >>>>>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] >>>>>>>> TestOptionsWithRanges: allow excluding only a subset of tested >>>>>>>> values >>>>>>>> specified for a flag) next time. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>> >>> >> From sangheon.kim at oracle.com Fri Dec 4 20:01:25 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Fri, 4 Dec 2015 12:01:25 -0800 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <5661E6C0.1090504@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> <565DEC2D.3010308@oracle.com> <565E3382.7050502@oracle.com> <56600686.4060606@oracle.com> <5661D66B.3080708@oracle.com> <5661E6C0.1090504@oracle.com> Message-ID: <5661F115.3040406@oracle.com> Hi Tom, On 12/04/2015 11:17 AM, Tom Benson wrote: > Hi Sangheon, > I'm also also OK with the change, but I found the wording of this > comment a little confusing, because 'value' is also the name of the > argument which is the HeapBaseMinAddress being checked: > > 554 // But below check is okay as the wrong value means bigger than > the value should be. > > How about something like: If an overflow happened in > Arguments::set_heap_size(), MaxHeapSize will have too large a value. > Check for this by ensuring that MaxHeapSize plus the requested min > base address still fit within max_uintx. > ? Your suggestion seems much cleaner. I will use this! Do you need a new webrev for this? Thanks, Sangheon > Tnx, > Tom > > > On 12/4/2015 1:07 PM, Jesper Wilhelmsson wrote: >> Looks good! >> >> I would prefer if there was a space after the comma in the new >> constraint lines in globals.hpp. I see that there are no spaces in >> the old lines as well. I you feel like it this could be cleaned up. >> >> Since you filed the other bug regarding the overflow I think this >> patch is good to go. >> /Jesper >> >> Den 3/12/15 kl. 10:08, skrev sangheon.kim: >>> Hi all, >>> >>> Here is next webrev. >>> http://cr.openjdk.java.net/~sangheki/8142341/webrev.02/ >>> http://cr.openjdk.java.net/~sangheki/8142341/webrev.02_to_01/ >>> >>> Testing: JPRT and TestOptionsWithRanges.java on machines that have >>> over 120GB >>> memory. >>> >>> *Summary >>> 1. Enhanced the constraint function for HeapBaseMinAddress: (Tom) >>> 1) It will check an overflow the addition of MaxHeapSize and >>> HeapBaseMinAddress. >>> And the overflow only happens when MaxHeapSize is default and using >>> compressed >>> oop. Since MaxHeapSize is updated after ergo, >>> FLAG_IS_ERGO(MaxHeapSize) is >>> necessary at the constraint function. >>> 2) As HeapBaseMinAddress has 'AfterErgo' tag, the constraint >>> function will be >>> called after the overflow happens at Arguments::set_heap_size(). >>> However it is >>> okay as we can detect the overflow before actual use of creating >>> virtual space. >>> And the problem of the overflow is setting MaxHeapSize with bigger >>> value that it >>> should be. >>> 3) Changed the order of HeapBaseMinAddress to locate later than >>> MaxHeapSize from >>> globals.hpp as HeapBaseMinAddress refers MaxHeapSize. >>> >>> 2. Added missing single quote in commandLineFlagConstraintsGC.cpp at >>> line 510. >>> (Tom) >>> >>> 3. Changed test to add dependency for NewSizeThreadIncrease. >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 12/01/2015 03:55 PM, sangheon.kim wrote: >>>> Hi Tom, >>>> >>>> Thank you for this kind analysis! >>>> >>>> >>>> On 12/01/2015 10:51 AM, Tom Benson wrote: >>>>> Hi Sangheon, >>>>> >>>>> On 11/30/2015 6:51 PM, sangheon.kim wrote: >>>>>> Hi Tom, >>>>>> >>>>>> Thank you for reviewing this! >>>>>> >>>>>> On 11/30/2015 02:46 PM, Tom Benson wrote: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> I think there's a problem with using the same routine to check >>>>>>> HeapBaseMinAddress as is used for checking heap size in >>>>>>> commandLineFlagConstraintsGC.cpp. I tried running this, to make >>>>>>> sure I >>>>>>> understood what it was trying to do. When I specified something >>>>>>> too large >>>>>>> for HeapBaseMinAddress, the check reported that the value must >>>>>>> be greater >>>>>>> than or equal to maximum value N. >>>>>> Sorry Tom, I can't understand. >>>>>> Currently we print the error message if its value is too large >>>>>> like, "must >>>>>> be less than or equal to aligned maximum value (xxx)". >>>>>> Do you mean it should be 'address' instead of 'value'? >>>>> >>>>> What I meant was that I got an internal error when I used the >>>>> value the >>>>> message recommended, so perhaps the value should be further >>>>> constrained. >>>> I see. >>>> >>>>> >>>>>> I thought it is okay. >>>>>> >>>>>>> Re-running with that (still huge) value, I get a fatal internal >>>>>>> error out >>>>>>> of virtualspace.cpp. (In the debug version, an assertion in >>>>>>> universe.cpp >>>>>>> triggers before reaching this point). EG: >>>>>> I am trying to reproduce this assert but I can't. Do you have more >>>>>> information to reproduce this? >>>>>> I did -version and running GCOld to trigger GC. >>>>>> >>>>>> java -XX:HeapBaseMinAddress=18446744073642442752 -version >>>>>> java -XX:HeapBaseMinAddress=18446744073642442752 GCOld 20 200 10 >>>>>> 100 5000 >>>>>> >>>>> >>>>> You probably didn't hit the problem because you're running on a >>>>> smaller >>>>> memory system than I am. On the system I'm on, the (computed) >>>>> max heap size >>>>> is 32G. And if you specify an Xmx, you don't go through the code >>>>> path that >>>>> causes it. >>>> Okay, my machine is 32G but when I test on bigger memory machine, I >>>> could see >>>> the assert. Thank you. >>>> >>>>> >>>>> Here's the root of the problem. In Arguments::set_heap_size(), we >>>>> have this >>>>> code: >>>>> >>>>> if (FLAG_IS_DEFAULT(MaxHeapSize)) { >>>>> . . . >>>>> if (UseCompressedOops) { >>>>> // Limit the heap size to the maximum possible when using >>>>> compressed oops >>>>> julong max_coop_heap = (julong)max_heap_for_compressed_oops(); >>>>> . . . >>>>> if (HeapBaseMinAddress + MaxHeapSize < max_coop_heap) { >>>>> <======== *** >>>>> PROBLEM IS HERE *** >>>>> // Heap should be above HeapBaseMinAddress to get zero based >>>>> compressed oops >>>>> // but it should be not less than default MaxHeapSize. >>>>> max_coop_heap -= HeapBaseMinAddress; >>>>> } >>>>> reasonable_max = MIN2(reasonable_max, max_coop_heap); >>>>> } >>>>> >>>>> HeapBaseMinAddress is 64-bit unsigned, and in this case is >>>>> 0xfffffffffc000000 >>>>> (the 18446744073642442752 from the command line). MaxHeapSize is >>>>> 0x7CCCCC8 >>>>> and max_coop_heap is 0x7FE000000. The addition of >>>>> HeapBaseMinAddress and >>>>> MaxHeapSize overflows to 0x3ccccc8. Since this is less than >>>>> 0x7FE000000, we >>>>> subtract the 0xfffffffffc000000 from max_coop_heap, getting the >>>>> result >>>>> 0x802000000. reasonable_max is 0x800000000, so it stays at that >>>>> value after >>>>> the MIN2, rather than being reduced as it should be. >>>>> >>>>> Changing the conditional to also check for overflow avoids the >>>>> problem. But >>>>> of course you don't get the requested HeapBaseMinAddress anyway, >>>>> since it's >>>>> too high. >>>>> >>>>> So another approach would be to change your constraint to ensure that >>>>> (HeapBaseMinAddress plus MaxHeapSize) won't overflow. I don't >>>>> think there's >>>>> any point in allowing a HeapBaseMinAddress so high that it would. >>>> Okay, I'm thinking about this. >>>> I will post a new webrev after testing. >>>> >>>> * I also read your other email that fixing constraint function >>>> makes sense. >>>> ** I already fixed your previous comment of extraneous single quote in >>>> commandLineFlagConstraintsGC.cpp at line 510. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> Tom >>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=0xffffffffffffffff >>>>>>> -version >>>>>>> HeapBaseMinAddress (18446744073709551615) must be less than or >>>>>>> equal to >>>>>>> aligned maximum value (18446744073642442752) >>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>> >>>>>>> $ $JAVA_HOME/bin/java >>>>>>> -XX:HeapBaseMinAddress=18446744073642442752 -version >>>>>>> # >>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>> # >>>>>>> # Internal Error (virtualspace.cpp:456), pid=10359, tid=10360 >>>>>>> # guarantee(size + noaccess_prefix_size(alignment) <= >>>>>>> OopEncodingHeapMax) >>>>>>> failed: can not allocate compressed oop heap for this size >>>>>>> # >>>>>>> >>>>>>> Perhaps you should check only the alignment in the constraint >>>>>>> code, without >>>>>>> checking the range, because I'm not sure you have the final heap >>>>>>> size at >>>>>>> that point. Then maybe the heap reservation code should report >>>>>>> this as a >>>>>>> non-internal error, at the point where the assertion occurs, if >>>>>>> the user >>>>>>> specified a base address. >>>>>>> >>>>>>> There's also an extraneous single quote in >>>>>>> commandLineFlagConstraintsGC.cpp >>>>>>> in the comment at line 510. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>> Date: Tue, 24 Nov 2015 06:37:41 -0800 >>>>>>> From: "sangheon.kim" >>>>>>> To: Dmitry Dmitriev, >>>>>>> "hotspot-dev at openjdk.java.net Developers" >>>>>>> >>>>>>> Subject: Re: RFR(S): 8142341: GC: current flags need ranges to be >>>>>>> implemented >>>>>>> Message-ID:<56547635.9060808 at oracle.com> >>>>>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>>>>> >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> Thank you for the review! >>>>>>> Sure I will update my patch related to your enhancement. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote: >>>>>>> >>>>>>>> Hi Sangheon, >>>>>>>> >>>>>>>> Looks good to me! Thank you for fixing that. I hope that >>>>>>>> enhancement >>>>>>>> will be pushed today(currently in JPRT queue), so please update >>>>>>>> your >>>>>>>> patch after that! >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitry >>>>>>>> >>>>>>>> On 21.11.2015 0:04, sangheon.kim wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Could I have a couple of reviews for this change to add explicit >>>>>>>>> 'range' for flags? >>>>>>>>> >>>>>>>>> Previously, we added 'range' when it is needed to avoid >>>>>>>>> assert/crash >>>>>>>>> but now explicit 'range' are needed for all flags. >>>>>>>>> All flags should have 'range' or 'constraint' at least. >>>>>>>>> >>>>>>>>> CR:https://bugs.openjdk.java.net/browse/JDK-8142341 >>>>>>>>> Webrev:http://cr.openjdk.java.net/~sangheki/8142341/webrev.00 >>>>>>>>> Testing: JPRT, RBT >>>>>>>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>>>>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for >>>>>>>>> embedded >>>>>>>>> >>>>>>>>> * Summary >>>>>>>>> 1. Added 3 new constraint functions. >>>>>>>>> 1) HeapBaseMinAddress: Added to avoid an overflow after >>>>>>>>> align up >>>>>>>>> and this flag makes hang up without constraint function. >>>>>>>>> (newly added >>>>>>>>> as a part of GC work) >>>>>>>>> 2) TLABWasteIncrement: Without this constraint function we >>>>>>>>> don't >>>>>>>>> have problems (even many GCs happen). But added to avoid an >>>>>>>>> overflow >>>>>>>>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are >>>>>>>>> also >>>>>>>>> separate CR for this overflow ( JDK-8143352 ). >>>>>>>>> 3) NUMAInterleaveGranularity: Added to avoid an overflow >>>>>>>>> after >>>>>>>>> align up. >>>>>>>>> >>>>>>>>> 2. Some flags have narrower range than their type. >>>>>>>>> 1) Here's the reason why some flags should have different >>>>>>>>> range. >>>>>>>>> (same order from globals.hpp) >>>>>>>>> {flag type} {flag name}: (range), {comment} >>>>>>>>> size_t NUMAInterleaveGranularity: >>>>>>>>> (os::vm_allocation_granularity(), >>>>>>>>> max_uintx), there is a comment at numa_interleaving_init() >>>>>>>>> that this >>>>>>>>> flag should be larger than vm_allocation_granularity(). >>>>>>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be >>>>>>>>> zero as >>>>>>>>> used for multiplication >>>>>>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function >>>>>>>>> which >>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function >>>>>>>>> which >>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a >>>>>>>>> function >>>>>>>>> which has 'long' type input parameter. >>>>>>>>> uintx PausePadding: (0, max_juint), used to set a function >>>>>>>>> which has >>>>>>>>> 'unsigned int' type input parameter. >>>>>>>>> uintx PromotedPadding: (0, max_juint), used to set a function >>>>>>>>> which >>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>> uintx SurvivorPadding: (0, max_juint), used to set a function >>>>>>>>> which >>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as >>>>>>>>> this flag >>>>>>>>> is divided by 100 I assume this is percentage. >>>>>>>>> uintx GCTimeRatio: (0, max_juint), used to set a function >>>>>>>>> which has >>>>>>>>> 'unsigned int' type input parameter. >>>>>>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint) >>>>>>>>> intx PrefetchScanIntervalInBytes: (-1, max_jint) >>>>>>>>> intx PrefetchFieldsAhead: (-1, max_jint), I think these 3 >>>>>>>>> Prefetch* >>>>>>>>> flags should have same upper limit and looking at their >>>>>>>>> related codes >>>>>>>>> 'max_jint' seems appropriate ( no problem with 'max_jint' during >>>>>>>>> testing). However, as Prefetch::read/write() needs 'intx', 'intx' >>>>>>>>> also seems good but we have to fix some codes (maybe including >>>>>>>>> generated codes). >>>>>>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function >>>>>>>>> which >>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint >>>>>>>>> variable and used 'for loop' which has uint increment. i.e. >>>>>>>>> for (uint >>>>>>>>> i=0; i>>>>>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at >>>>>>>>> 'increment for loop()' as max value and the increment is uint. >>>>>>>>> uintx CMSYieldSleepCount: (0, max_juint), used at 'increment for >>>>>>>>> loop()' as max value and the increment is uint. >>>>>>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a >>>>>>>>> return value >>>>>>>>> of uint type function and for division. i.e. uint >>>>>>>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return >>>>>>>>> TLABRefillWasteFraction; } >>>>>>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int) >>>>>>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and >>>>>>>>> we only >>>>>>>>> use " if (a !=0, >0, >1)". >>>>>>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and >>>>>>>>> we only >>>>>>>>> use " if (a !=0, >0, >1)". >>>>>>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we >>>>>>>>> only use >>>>>>>>> " if (a !=0, >0)". >>>>>>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to >>>>>>>>> 'unsigned >>>>>>>>> int' >>>>>>>>> >>>>>>>>> (g1_globals.hpp) >>>>>>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set >>>>>>>>> (int) >>>>>>>>> type variable. >>>>>>>>> >>>>>>>>> 3. Excluded flags from TestOptionsWithRanges.java >>>>>>>>> 1) Memory and thread related flags: tests for these flags will >>>>>>>>> consume too many resources from the system. >>>>>>>>> 2) VMThreadStackSize: range work for this flag is not included in >>>>>>>>> this patch but I faced OOME several times, so excluded. >>>>>>>>> >>>>>>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] >>>>>>>>> TestOptionsWithRanges: allow excluding only a subset of tested >>>>>>>>> values >>>>>>>>> specified for a flag) next time. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>> >>>> >>> > From tom.benson at oracle.com Fri Dec 4 20:12:15 2015 From: tom.benson at oracle.com (Tom Benson) Date: Fri, 4 Dec 2015 15:12:15 -0500 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <5661F115.3040406@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> <565DEC2D.3010308@oracle.com> <565E3382.7050502@oracle.com> <56600686.4060606@oracle.com> <5661D66B.3080708@oracle.com> <5661E6C0.1090504@oracle.com> <5661F115.3040406@oracle.com> Message-ID: <5661F39F.1010703@oracle.com> Hi Sangheon, On 12/4/2015 3:01 PM, sangheon.kim wrote: > Hi Tom, > > On 12/04/2015 11:17 AM, Tom Benson wrote: >> Hi Sangheon, >> I'm also also OK with the change, but I found the wording of this >> comment a little confusing, because 'value' is also the name of the >> argument which is the HeapBaseMinAddress being checked: >> >> 554 // But below check is okay as the wrong value means bigger >> than the value should be. >> >> How about something like: If an overflow happened in >> Arguments::set_heap_size(), MaxHeapSize will have too large a value. >> Check for this by ensuring that MaxHeapSize plus the requested min >> base address still fit within max_uintx. >> ? > Your suggestion seems much cleaner. I will use this! > Do you need a new webrev for this? > No, I'm OK with it. (Assuming you're also going to remove the existing 553. 8^) ) Thanks, Tom > Thanks, > Sangheon > > >> Tnx, >> Tom >> >> From sangheon.kim at oracle.com Fri Dec 4 20:17:18 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Fri, 4 Dec 2015 12:17:18 -0800 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <5661F39F.1010703@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> <565DEC2D.3010308@oracle.com> <565E3382.7050502@oracle.com> <56600686.4060606@oracle.com> <5661D66B.3080708@oracle.com> <5661E6C0.1090504@oracle.com> <5661F115.3040406@oracle.com> <5661F39F.1010703@oracle.com> Message-ID: <5661F4CE.5040208@oracle.com> Hi Tom, On 12/04/2015 12:12 PM, Tom Benson wrote: > Hi Sangheon, > > On 12/4/2015 3:01 PM, sangheon.kim wrote: >> Hi Tom, >> >> On 12/04/2015 11:17 AM, Tom Benson wrote: >>> Hi Sangheon, >>> I'm also also OK with the change, but I found the wording of this >>> comment a little confusing, because 'value' is also the name of the >>> argument which is the HeapBaseMinAddress being checked: >>> >>> 554 // But below check is okay as the wrong value means bigger >>> than the value should be. >>> >>> How about something like: If an overflow happened in >>> Arguments::set_heap_size(), MaxHeapSize will have too large a value. >>> Check for this by ensuring that MaxHeapSize plus the requested min >>> base address still fit within max_uintx. >>> ? >> Your suggestion seems much cleaner. I will use this! >> Do you need a new webrev for this? >> > No, I'm OK with it. (Assuming you're also going to remove the > existing 553. 8^) ) Ooops! :) To make sure, here is the diff: Flag::Error HeapBaseMinAddressConstraintFunc(size_t value, bool verbose) { - // Current MaxHeapSize would have wrong value if an overflow happened at Arguments::set_heap_size(). - // But below check is okay as the wrong value means bigger than the value should be. + // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value. + // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx. if (UseCompressedOops && FLAG_IS_ERGO(MaxHeapSize) && (value > (max_uintx - MaxHeapSize))) { Thanks, Sangheon > Thanks, > Tom > > >> Thanks, >> Sangheon >> >> >>> Tnx, >>> Tom >>> >>> > From tom.benson at oracle.com Fri Dec 4 20:23:10 2015 From: tom.benson at oracle.com (Tom Benson) Date: Fri, 4 Dec 2015 15:23:10 -0500 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <5661F4CE.5040208@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> <565DEC2D.3010308@oracle.com> <565E3382.7050502@oracle.com> <56600686.4060606@oracle.com> <5661D66B.3080708@oracle.com> <5661E6C0.1090504@oracle.com> <5661F115.3040406@oracle.com> <5661F39F.1010703@oracle.com> <5661F4CE.5040208@oracle.com> Message-ID: <5661F62E.2000708@oracle.com> Looks OK to me. Thanks, Tom On 12/4/2015 3:17 PM, sangheon.kim wrote: > Hi Tom, > > On 12/04/2015 12:12 PM, Tom Benson wrote: >> Hi Sangheon, >> >> On 12/4/2015 3:01 PM, sangheon.kim wrote: >>> Hi Tom, >>> >>> On 12/04/2015 11:17 AM, Tom Benson wrote: >>>> Hi Sangheon, >>>> I'm also also OK with the change, but I found the wording of this >>>> comment a little confusing, because 'value' is also the name of the >>>> argument which is the HeapBaseMinAddress being checked: >>>> >>>> 554 // But below check is okay as the wrong value means bigger >>>> than the value should be. >>>> >>>> How about something like: If an overflow happened in >>>> Arguments::set_heap_size(), MaxHeapSize will have too large a >>>> value. Check for this by ensuring that MaxHeapSize plus the >>>> requested min base address still fit within max_uintx. >>>> ? >>> Your suggestion seems much cleaner. I will use this! >>> Do you need a new webrev for this? >>> >> No, I'm OK with it. (Assuming you're also going to remove the >> existing 553. 8^) ) > Ooops! :) > > To make sure, here is the diff: > > Flag::Error HeapBaseMinAddressConstraintFunc(size_t value, bool > verbose) { > - // Current MaxHeapSize would have wrong value if an overflow > happened at Arguments::set_heap_size(). > - // But below check is okay as the wrong value means bigger than the > value should be. > + // If an overflow happened in Arguments::set_heap_size(), > MaxHeapSize will have too large a value. > + // Check for this by ensuring that MaxHeapSize plus the requested > min base address still fit within max_uintx. > if (UseCompressedOops && FLAG_IS_ERGO(MaxHeapSize) && (value > > (max_uintx - MaxHeapSize))) { > > Thanks, > Sangheon > > >> Thanks, >> Tom >> >> >>> Thanks, >>> Sangheon >>> >>> >>>> Tnx, >>>> Tom >>>> >>>> >> > From coleen.phillimore at oracle.com Fri Dec 4 20:49:19 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 4 Dec 2015 15:49:19 -0500 Subject: RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions In-Reply-To: References: <565FA1C1.50909@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> <5660D576.80904@oracle.com> Message-ID: <5661FC4F.1030201@oracle.com> Hi Chris, Thank you for looking at this. Debt almost repaid. On 12/4/15 12:48 PM, Christian Thalinger wrote: >> On Dec 3, 2015, at 1:51 PM, Coleen Phillimore wrote: >> >> >> Hi Goetz, >> >> Thank you for looking at my change. I made the ppc changes and hg added templateInterpreter_ppc/aarch64.cpp back, so they should be in the patch. >> >> Now webrev thinks I've deleted 7785 lines, but I didn't really. >> >> http://cr.openjdk.java.net/~coleenp/8144534.02/ >> >> The most interesting part of this change is in the x86 code: >> >> http://cr.openjdk.java.net/~coleenp/8144534.02/src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp.udiff.html >> >> This is where the 32 and 64 bit template interpreter code is merged. > + Register rarg = NOT_LP64(rax) LP64_ONLY(c_rarg1); > + Register rarg2 = NOT_LP64(rbx) LP64_ONLY(c_rarg2); > > Aren?t these always the same and could also be defined globally? Maybe keep rarg1. No, I don't think we usually use rbx for 32 bit. I have other instances that we pick rdx and rbx. > > ! // compute beginning of parameters (rdi/r14) > ! __ lea(rlocals, Address(rsp, rcx, Interpreter::stackElementScale(), -wordSize)); > > You can remove the rdi/r14 part. done. > > ! // restore rsi/r13 to have legal interpreter frame, i.e., bci == 0 <=> > // r13 == code_base() > > // compute beginning of parameters (r14) > > Same for these. // restore to have legal interpreter frame, i.e., bci == 0 <=> code_base() Much better. > > ExternalAddress unsatisfied(SharedRuntime::native_method_throw_unsatisfied_link_error_entry()); > ! __ movptr(rscratch2, unsatisfied.addr()); > __ cmpptr(rax, rscratch2); > ! __ cmpptr(rax, unsatisfied.addr()); > > I think this is wrong. On 64-bit cmp can?t take a 64-bit immediate. That?s why we have the move. Wow, you're right cmpptr is a macroAssembler instruction because it does the mov depending on the address. We use cmpptr(reg, Address) all over. Thanks! Coleen > > Otherwise this looks good but I?ve only looked at this one file. > >> Thanks, >> Coleen >> >> On 12/3/15 8:14 AM, Lindenmaier, Goetz wrote: >>> Hi Coleen, >>> >>> I've been looking at this change. A cleanup in this area is really >>> useful. >>> I missed templateInterpreter_ppc.cpp in your patch, I guess you forgot >>> "hg add" for it. >>> In addition, I had to fix some code around math_entry_available(), see this patch: >>> http://cr.openjdk.java.net/~goetz/webrevs/8144534-interp/8144534-fixes_for_ppc.patch >>> >>> In general, I think it's strange that AbstractInterpreterGenerator >>> implementations are in interpreter_.cpp, as mentioned In the bug. >>> Why not move them to templateInterpreterGenerator_.cpp? Or will >>> this be subject to a later change that removes the funny common >>> subclasses Interpreter/InterpreterGenerator? >>> >>> Should I make a change removing the CC_INTERP support from ppc? >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Coleen Phillimore >>>> Sent: Donnerstag, 3. Dezember 2015 02:58 >>>> To: hotspot-dev developers >>>> Subject: RFR 8144534: Refactor templateInterpreter and >>>> templateInterpreterGenerator functions >>>> >>>> Summary: merged templateInterpreter_x86_32/64 into >>>> templateInterpreterGenerator_x86.cpp (some 32/64 functions remain for >>>> the hand coded crc functions). >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144534.01/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144534 >>>> >>>> I tried to make this reviewable by hg renaming files. I basically >>>> renamed templateInterpreter_ppc.cpp and removed the >>>> AbstractInterpreter >>>> functions and put them back into templateInterpreter_ppc.cpp. I didn't >>>> really delete 4000 lines of code, more like 1500. >>>> >>>> Also, can someone with the PPC and AARCH port look at and test out these >>>> changes? I tried to reduce the #includes in the new >>>> templateInterpreter_ppc/aarch64.cpp files which worked for sparc. >>>> >>>> Tested with JPRT on all platforms, also ran jtreg and >>>> collocated/non-collocated tonga tests for linux x64 and i386 since >>>> that's were the real changes are. >>>> >>>> See the bug for more details and my partial vision of how these >>>> functions will be reorganized when I remove the broken c++ interpreter. >>>> >>>> Also tested that Zero still builds. >>>> >>>> Thanks! >>>> Coleen >>>> From chris.plummer at oracle.com Fri Dec 4 21:00:21 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 4 Dec 2015 13:00:21 -0800 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets Message-ID: <5661FEE5.2040108@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8144677 http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ Tested with JPRT with: ? "-testset hotspot" ? "-testset svc" ? "-testset chris" from the example custom testset provided in the CR. ? no testset specified BTW, if anyone knows of an "include" mechanism for jprt.properties, please let me know. Although that won't change the need for the above changes, it would make it possible to put custom testsets in a file rather than having to paste them in your ~/.jprt.properties file. thanks, Chris From coleen.phillimore at oracle.com Fri Dec 4 21:31:36 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 4 Dec 2015 16:31:36 -0500 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <56604E8B.6010101@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <56548F9B.1000507@oracle.com> <565DC91B.9060206@oracle.com> <565F36DA.4060004@oracle.com> <56604E8B.6010101@oracle.com> Message-ID: <56620638.9070604@oracle.com> Frederic, I'm sorry that I'm late to this review. Maybe these are just questions that can be answered or additional RFEs filed. http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/src/cpu/sparc/vm/interp_masm_sparc.cpp.udiff.html This code added looks just like the function MacroAssembler::reserved_stack_check() here: why doesn't it call reserved_stack_check() with maybe a boolean to account for the call_VM vs. jump difference? http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/src/cpu/sparc/vm/interp_masm_sparc.cpp.udiff.html http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/src/cpu/x86/vm/interp_masm_x86.cpp.udiff.html + NOT_LP64(get_thread(rthread);) Apparently now preferred: + NOT_LP64(get_thread(rthread)); http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/src/cpu/x86/vm/templateInterpreter_x86_32.cpp.udiff.html Why is templateInterpreter_sparc.cpp generate_stack_overflow_check() different and not account for StackShadow/ReservedPages ? http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/src/cpu/x86/vm/templateInterpreter_x86_64.cpp.udiff.html I've merged these with my latest change. I was waiting for you to check in first but if I check in first, you'll have a smaller merge than I will. http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/test/runtime/ReservedStack/ReservedStackTest.java.html Thank you for the comments in the test. http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/src/share/vm/runtime/vmStructs.cpp.udiff.html Since you changed the size of _flags in Method, were there changes to the serviceability agent? http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/src/share/vm/interpreter/interpreterRuntime.cpp.udiff.html I don't see any callers for InterpreterRuntime::check_ReservedStackAccess_annotated_methods Do you need someone from the compiler group to review the compiler parts of this change? Again, sorry I'm late to review this but I was just reviewing code in exactly the same places for another bug. thanks, Coleen On 12/3/15 9:15 AM, Frederic Parain wrote: > All fixed. > > Thank you Dan. > > Fred > > On 02/12/2015 19:22, Daniel D. Daugherty wrote: >> >> On 12/1/15 9:21 AM, Frederic Parain wrote: >>> Hi Dan, >>> >>> Thank you for your detailed review. >>> My answers are in-lined below. >>> >>> New webrev: >>> >>> http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/ >> >> Re-reviewed by comparing 8046936.0[12].hotspot.patch in jfilemerge... >> >> Just a couple of nits: >> >> src/os/windows/vm/os_windows.cpp >> L2365: assert(fr->safe_for_sender(thread), "Safety check"); >> Wrong indent; should be 6 spaces instead of 8; actually I think >> this one is a tab. >> >> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >> L381: assert(fr->safe_for_sender(thread), "Safety check"); >> Wrong indent; this one also might be a tab >> >> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >> L194: assert(fr->safe_for_sender(thread), "Safety check"); >> Wrong indent; this one also might be a tab >> >> src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp >> L267: assert(fr->safe_for_sender(thread), "Safety check"); >> Wrong indent; this one also might be a tab >> >> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >> L255: assert(fr->safe_for_sender(thread), "Safety check"); >> Wrong indent; this one also might be a tab >> >> >> Thumbs up! I do not need to see a webrev for the above nits. >> >> Dan >> >> >>> >>> >>> On 24/11/2015 17:26, Daniel D. Daugherty wrote: >>>> >>>> src/cpu/sparc/vm/frame_sparc.cpp >>>> (old) L635: if (fp() - sp() > 1024 + >>>> m->max_stack()*Interpreter::stackElementSize) { >>>> (new) L635: if (fp() - unextended_sp() > 1024 + >>>> m->max_stack()*Interpreter::stackElementSize) { >>>> This looks like a bug fix independent of this fix. >>> >>> Correct, this is the SPARC version of JDK-8068655. >>> >>>> src/share/vm/runtime/thread.hpp >>>> L953: intptr_t* _reserved_stack_activation; >>>> L1382: intptr_t* reserved_stack_activation() const { return >>>> _reserved_stack_activation; } >>>> L1383: void set_reserved_stack_activation(intptr_t* addr) { >>>> >>>> I was expecting this type to be 'address' instead of >>>> 'intptr_t*'. >>>> >>>> Update: I've gone back through the changes and I still don't >>>> see a reason that this is 'intptr_t*'. >>> >>> The _reserved_stack_activation has been declared as an 'intptr_t*' >>> just to be consistent with the _sp and _fp fields of the frame class. >>> However, this is not really a requirement, the content stored at the >>> _reserved_stack_activation address is never read. This address is just >>> a "marker" on the stack to quickly check if the thread has exited the >>> annotated code section or not. I've change the type to address, there's >>> slightly less casts, and it doesn't impact the ReservedStackArea logic. >>> >>> Note: I've removed all further comments about >>> _reserved_stack_activation >>> type in order to improve the e-mail readability. >>> >>>> L1341: { return stack_yellow_zone_base();} >>>> '{' should be at the end of the previous line. >>>> Missing space after ';'. >>> >>> Fixed >>> >>>> L1343: { return StackReservedPages * os::vm_page_size(); } >>>> '{' should be at the end of the previous line. >>> >>> Fixed >>> >>>> src/share/vm/runtime/thread.cpp >>>> L2543: // The base notation is from the stacks point of view, >>>> growing downward. >>>> L2565: // The base notation is from the stacks point of view, >>>> growing downward. >>>> Typo: "stacks point of view" -> "stack's point of view" >>> >>> Fixed >>> >>>> L2552: } else { >>>> L2553: warning("Attempt to guard stack reserved zone >>>> failed."); >>>> L2554: } >>>> L2555: enable_register_stack_guard(); >>>> >>>> Should enable_register_stack_guard() be called when we issued >>>> the warning on L2553? >>>> >>>> L2571: } else { >>>> L2572: warning("Attempt to unguard stack reserved zone >>>> failed."); >>>> L2573: } >>>> L2574: disable_register_stack_guard(); >>>> >>>> Should disable_register_stack_guard() be called when we >>>> issued >>>> the warning on L2572? >>> >>> enable_register_stack_guard() and disable_register_stack_guard() are >>> relics of the Itanium code (Itanium had a very different stack >>> management). These methods are currently empty on all OpenJDK and >>> Oracle platforms. May be another clean up opportunity here. >>> Regarding the placement of the calls, I followed the same pattern >>> as the other red/yellow pages management functions. >>> >>>> src/share/vm/runtime/sharedRuntime.cpp >>>> >>>> L784: java_lang_Throwable::set_message(exception_oop, >>>> L785: Universe::delayed_stack_overflow_error_message()); >>>> Wrong indent; this should line up under the 'e' after the >>>> '('. >>> >>> Fixed >>> >>>> L2976: if (fr.is_interpreted_frame()) { >>>> L2978: prv_fr = fr; >>>> L2982: prv_fr = fr; >>>> This line is in both branches of the if-statement on L2976. >>>> Is there a reason not to save prv_fr before L2976? >>> >>> No particular reason, fixed. >>> >>>> L2996 continue; >>>> Wrong indent; needs one more space. >>> >>> Fixed >>> >>>> L2958: frame activation; >>>> L3013: return activation; >>>> The return on L3013 can return a default constructed 'frame'. >>>> Is that default safe to return here? >>> >>> Yes, the caller performs a check before using the returned >>> frame: >>> if (activation.sp() != NULL) { ... >>> >>>> >>>> src/os/bsd/vm/os_bsd.hpp >>>> L109: static bool get_frame_at_stack_banging_point(JavaThread* >>>> thread, ucontext_t* uc, frame* fr); >>>> Wrong indent; needs one less space. >>> >>> Fixed >>> >>>> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >>>> L322: // For Forte Analyzer AsyncGetCallTrace profiling support - >>>> thread >>>> L323: // is currently interrupted by SIGPROF. >>>> Now fetch_frame_from_ucontext() is also used for stack >>>> overflow >>>> signal handling. >>> >>> Fixed >>> >>>> L379: assert(fr->safe_for_sender(thread), "Safety check"); >>>> L380: if (!fr->is_first_java_frame()) { >>>> L381: *fr = fr->java_sender(); >>>> The assert() on L379 should be before the java_sender() >>>> call on L381. >>> >>> Fixed >>> >>>> src/os/linux/vm/os_linux.cpp >>>> L1902: jt->stack_guards_enabled()) { // No pending >>>> stack overflow exceptions >>>> This line's comment used to align with the previous line's >>>> comment. >>>> Can you move the previous line's comment to align with this >>>> one? >>> >>> Done. >>> >>>> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >>>> L135: // For Forte Analyzer AsyncGetCallTrace profiling support - >>>> thread >>>> L136: // is currently interrupted by SIGPROF. >>>> Now fetch_frame_from_ucontext() is also used for stack >>>> overflow >>>> signal handling. >>> >>> Fixed >>> >>>> L192: assert(fr->safe_for_sender(thread), "Safety check"); >>>> L193: if (!fr->is_first_java_frame()) { >>>> L194: *fr = fr->java_sender(); >>>> The assert() on L192 should be before the java_sender() >>>> call on L194. >>> >>> Fixed >>> >>>> src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp >>>> L209: // For Forte Analyzer AsyncGetCallTrace profiling support - >>>> thread >>>> L210: // is currently interrupted by SIGPROF. >>>> Now fetch_frame_from_ucontext() is also used for stack >>>> overflow >>>> signal handling. >>> >>> Fixed >>> >>>> L265: assert(fr->safe_for_sender(thread), "Safety check"); >>>> L266: if (!fr->is_first_java_frame()) { >>>> L267: *fr = fr->java_sender(); >>>> The assert() on L265 should be before the java_sender() >>>> call on L267. >>> >>> Fixed >>> >>>> L279: //assert(fr->safe_for_sender(thread), "Safety check"); >>>> Delete this line; you copied it to L282. >>> >>> Done >>> >>>> L287 return true; >>>> Should this assert be added above this line? >>>> assert(fr->is_java_frame(), "Safety check"); >>> >>> Yes, this assert exists on other platforms, and there's no >>> reason to omit it on Solaris/SPARC >>> >>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >>>> L195: // For Forte Analyzer AsyncGetCallTrace profiling support - >>>> thread >>>> L196: // is currently interrupted by SIGPROF. >>>> Now fetch_frame_from_ucontext() is also used for stack >>>> overflow >>>> signal handling. >>> >>> Fixed >>> >>>> L253: assert(fr->safe_for_sender(thread), "Safety check"); >>>> L254: if (!fr->is_first_java_frame()) { >>>> L255: *fr = fr->java_sender(); >>>> The assert() on L253 should be before the java_sender() >>>> call on L255. >>> >>> Fixed >>> >>>> L273: *fr = fr->java_sender(); >>>> Wrong indent; one too many spaces. >>> >>> Fixed >>> >>> >>>> src/os/windows/vm/os_windows.cpp >>>> L2364: assert(fr->safe_for_sender(thread), "Safety check"); >>>> L2365: if (!fr->is_first_java_frame()) { >>>> L2366: *fr = fr->java_sender(); >>>> The assert() on L2364 should be before the java_sender() >>>> call on L2366. >>> >>> Fixed >>> >>>> L2387: return true; >>>> Should this assert be added above this line? >>>> assert(fr->is_java_frame(), "Safety check"); >>> >>> Certainly, fixed. >>> >>>> src/share/vm/oops/method.hpp >>>> (old) L87: u1 _flags; >>>> (new) L88: u2 _flags; >>>> Ouch - just needed one more bit... >>> >>> The initial implementation of the reserved stack area used the last >>> bit, but unfortunately, someone else steal it before I could push >>> my code :-( So I had to extend the flags field >>> >>>> L834: return (_flags & _reserved_stack_access) != 0; >>>> Wrong indent; two fewer spaces. >>> >>> Fixed >>> >>>> src/share/vm/runtime/globals.hpp >>>> L3549: range(MIN_STACK_RESERVED_PAGES, >>>> (DEFAULT_STACK_RESERVED_PAGES+10))\ >>>> Wrong indent; should line up below the double quote in >>>> the previous line. >>> >>> Fixed >>> >>>> src/share/vm/interpreter/interpreterRuntime.cpp >>>> L328 IRT_ENTRY(void, >>>> InterpreterRuntime::throw_delayed_StackOverflowError(JavaThread* >>>> thread)) >>>> >>>> The regular throw_StackOverflowError() increments >>>> a counter: >>>> >>>> L313: Atomic::inc(&Exceptions::_stack_overflow_errors); >>>> >>>> Should this function increment the same counter or >>>> a different counter? >>> >>> Good catch! I've added the counter increment to the method >>> throw_delayed_StackOverflowError(). I don't see a strong >>> rational to create a new counter for delayed stack overflows, >>> so it increments the same counter as throw_StackOverflowError(). >>> >>>> >>>> src/cpu/sparc/vm/macroAssembler_sparc.hpp >>>> L1423: // Check for reserved stack access in method being >>>> exited >>>> (for the compilers) >>>> The X86 version says "for JIT compilers". I prefer "JIT". >>> >>> Fixed >>> >>>> src/cpu/x86/vm/macroAssembler_x86.hpp >>>> L643: // Check for reserved stack access in method being exited >>>> (for JIT compilers) >>>> The SPARC version says "for the compilers". >>> >>> Fixed >>> >>>> src/share/vm/ci/ciMethod.cpp >>>> L95: _has_reserved_stack_access = >>>> h_m()->has_reserved_stack_access(); >>>> Wrong indent; should be only one space before '='. >>> >>> Fixed >>> >>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>> L3323: if(callee->has_reserved_stack_access()) { >>>> L3336: if(callee->has_reserved_stack_access()) { >>>> L3356: if(callee->has_reserved_stack_access()) { >>>> Missing space between 'if' and '('. >>> >>> All fixed. >>> >>>> src/cpu/x86/vm/x86_32.ad >>>> L737: size += 64; // added to support ReservedStackAccess >>>> Usually I hate literals like this, but this function has >>>> them in spades. :-( >>> >>> I agree but I didn't find a better solution. >>> >>>> src/cpu/x86/vm/x86_64.ad >>>> L960: MacroAssembler _masm(&cbuf); >>>> L965: MacroAssembler _masm(&cbuf); >>>> >>>> I think you can delete the _masm on L965. >>> >>> Right, removed. >>> >>>> src/share/vm/opto/compile.cpp >>>> L675: >>>> _has_reserved_stack_access(target->has_reserved_stack_access()) { >>>> Wrong indent; should be a single space between ')' and '{'. >>> >>> Fixed >>> >>>> test/runtime/ReservedStack/ReservedStackTest.java >>>> L26: * @run main/othervm -XX:-Inline >>>> -XX:CompileCommand=exclude,java/util/concurrent/locks/AbstractOwnableSynchronizer,setExclusiveOwnerThread >>>> >>>> >>>> ReservedStackTest >>>> >>>> Should the comma before 'setExclusiveOwnerThread' be a >>>> period? >>>> Perhaps both formats work... >>> >>> Both formats work, but I changed it to be a period, it's cleaner. >>> >>>> L47: * else >>>> Wrong indent; needs one more space before 'else'. >>>> >>>> L52: * successfully update the status of the lock but he method >>>> Typo: 'update the' -> 'updates the' >>>> Typo: 'he method' -> 'the method' >>>> >>>> L60: * first StackOverflowError is thrown, the Error is catched >>>> Typo: 'is catched' -> 'is caught' >>>> >>>> L61: * and a few dozens frames are exited. Now the thread has >>>> Typo: 'a few dozens frames' -> 'a few dozen frames' >>>> >>>> L66: * of its invocation, tries to acquire the next lock >>>> Typo: 'its invocation' -> 'its invocations' >>>> >>>> L81: * stack to prevent false sharing. The test is using this >>>> Perhaps 'The test is using this' >>>> -> 'The test relies on this' >>>> >>>> to better match wording on L225-6. >>>> >>>> L82: * to have different stack alignments and hit the targeted >>>> Grammar: 'and hit' -> 'when it hits' >>>> >>>> L102: * exploit the property that interpreter frames are (much) >>>> Typo: 'exploit' -> 'exploits' >>>> Delete extra space after 'the'. >>>> >>>> L123: //LOCK_ARRAY_SIZE value >>>> Add a space after '//'. >>>> >>>> L188: @jdk.internal.vm.annotation.ReservedStackAccess >>>> This isn't privileged code and -XX:-RestrictReservedStack >>>> isn't specified so what does this do? >>> >>> It checks that by default the annotation is ignored for non-privileged >>> code, in case it is not ignored, the test would fail. >>> >>>> >>>> L201: System.exit(-1); >>>> Wrong indent; needs two more spaces. >>> >>> All fixed. >>> >>> Thank you very much! >>> >>> Fred >>> >>>>> >>>>> On 20/11/2015 19:44, Karen Kinnear wrote: >>>>>> Frederic, >>>>>> >>>>>> Code review for web revs you sent out. >>>>>> Code looks good. I am not as familiar with the compiler code. >>>>>> >>>>>> I realize you need to check in at least a subset of the >>>>>> java.util.concurrent changes for >>>>>> the test to work, so maybe I should not have asked Doug about his >>>>>> preference there. >>>>>> Sorry. >>>>>> >>>>>> I am impressed you found a way to make a reproducible test! >>>>>> >>>>>> Comments/questions: >>>>>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >>>>> >>>>> Fixed >>>>> >>>>>> 2. IIRC, due to another bug with windows handling of our guard >>>>>> pages, >>>>>> this >>>>>> is disabled for Windows. Would it be worth putting a comment in the >>>>>> bug , 8067946, that once this is fixed, the reserved stack logic on >>>>>> windows >>>>>> will need testing before enabling? >>>>> >>>>> More than testing, the implementation would have to be completed on >>>>> Windows. I've added a comment to JDK-8067946. >>>>> >>>>>> 3. In get_frame_at_stack_banging_point on Linux, BSD and >>>>>> solaris_x86 if >>>>>> this is in interpreter code, you explicitly return the Java sender >>>>>> of the current frame. I was expecting to see that on Solaris_sparc >>>>>> and Windows >>>>>> as well? I do see the assertion in caller that you do have a java >>>>>> frame. >>>>> >>>>> It doesn't make sense to check the current frame (no bytecode has >>>>> been >>>>> executed yet, so risk of partially executed critical section). I did >>>>> the >>>>> change but not for all platforms. This is now fixed for Solaris_SPARC >>>>> and Windows too. >>>>> >>>>>> 4. test line 83 ?writtent? -> ?written? >>>>> >>>>> Fixed >>>>> >>>>>> 5. I like the way you set up the preallocated exception and then set >>>>>> the message - we may >>>>>> try that for default methods in future. >>>>>> >>>>>> 6. I had a memory that you had found a bug in safe_for_sender - did >>>>>> you already check that in? >>>>> >>>>> I've fixed x86 platforms in JDK-8068655. >>>>> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >>>>> I had hoped it would have been silently accepted :-) >>>>> >>>>> >>>>>> 7. I see the change in trace.xml, and I see an include added to >>>>>> SharedRuntime.cpp, >>>>>> but I didn?t see where it was used - did I just miss it? >>>>> >>>>> trace.xml changes define a new event. >>>>> This event is created at sharedRuntime.cpp::3006 and it is used >>>>> in the next 3 lines. >>>>> >>>>> Thanks, >>>>> >>>>> Fred >>>>> >>>> >>> >> > From jesper.wilhelmsson at oracle.com Fri Dec 4 22:41:18 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 4 Dec 2015 23:41:18 +0100 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <5661F0BF.5080302@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> <565DEC2D.3010308@oracle.com> <565E3382.7050502@oracle.com> <56600686.4060606@oracle.com> <5661D66B.3080708@oracle.com> <5661F0BF.5080302@oracle.com> Message-ID: <5662168E.9090303@oracle.com> Den 4/12/15 kl. 20:59, skrev sangheon.kim: > Hi Jesper, > > Thank you for reviewing this. > > On 12/04/2015 10:07 AM, Jesper Wilhelmsson wrote: >> Looks good! >> >> I would prefer if there was a space after the comma in the new constraint >> lines in globals.hpp. I see that there are no spaces in the old lines as well. >> I you feel like it this could be cleaned up. > You are right. > However let me address from a separate CR as you said old lines also don't have > a space. I'm fine with that. Ship it! /Jesper > >> >> Since you filed the other bug regarding the overflow I think this patch is >> good to go. > Thanks! > > Sangheon > > >> /Jesper >> >> Den 3/12/15 kl. 10:08, skrev sangheon.kim: >>> Hi all, >>> >>> Here is next webrev. >>> http://cr.openjdk.java.net/~sangheki/8142341/webrev.02/ >>> http://cr.openjdk.java.net/~sangheki/8142341/webrev.02_to_01/ >>> >>> Testing: JPRT and TestOptionsWithRanges.java on machines that have over 120GB >>> memory. >>> >>> *Summary >>> 1. Enhanced the constraint function for HeapBaseMinAddress: (Tom) >>> 1) It will check an overflow the addition of MaxHeapSize and HeapBaseMinAddress. >>> And the overflow only happens when MaxHeapSize is default and using compressed >>> oop. Since MaxHeapSize is updated after ergo, FLAG_IS_ERGO(MaxHeapSize) is >>> necessary at the constraint function. >>> 2) As HeapBaseMinAddress has 'AfterErgo' tag, the constraint function will be >>> called after the overflow happens at Arguments::set_heap_size(). However it is >>> okay as we can detect the overflow before actual use of creating virtual space. >>> And the problem of the overflow is setting MaxHeapSize with bigger value that it >>> should be. >>> 3) Changed the order of HeapBaseMinAddress to locate later than MaxHeapSize from >>> globals.hpp as HeapBaseMinAddress refers MaxHeapSize. >>> >>> 2. Added missing single quote in commandLineFlagConstraintsGC.cpp at line 510. >>> (Tom) >>> >>> 3. Changed test to add dependency for NewSizeThreadIncrease. >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 12/01/2015 03:55 PM, sangheon.kim wrote: >>>> Hi Tom, >>>> >>>> Thank you for this kind analysis! >>>> >>>> >>>> On 12/01/2015 10:51 AM, Tom Benson wrote: >>>>> Hi Sangheon, >>>>> >>>>> On 11/30/2015 6:51 PM, sangheon.kim wrote: >>>>>> Hi Tom, >>>>>> >>>>>> Thank you for reviewing this! >>>>>> >>>>>> On 11/30/2015 02:46 PM, Tom Benson wrote: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> I think there's a problem with using the same routine to check >>>>>>> HeapBaseMinAddress as is used for checking heap size in >>>>>>> commandLineFlagConstraintsGC.cpp. I tried running this, to make sure I >>>>>>> understood what it was trying to do. When I specified something too large >>>>>>> for HeapBaseMinAddress, the check reported that the value must be greater >>>>>>> than or equal to maximum value N. >>>>>> Sorry Tom, I can't understand. >>>>>> Currently we print the error message if its value is too large like, "must >>>>>> be less than or equal to aligned maximum value (xxx)". >>>>>> Do you mean it should be 'address' instead of 'value'? >>>>> >>>>> What I meant was that I got an internal error when I used the value the >>>>> message recommended, so perhaps the value should be further constrained. >>>> I see. >>>> >>>>> >>>>>> I thought it is okay. >>>>>> >>>>>>> Re-running with that (still huge) value, I get a fatal internal error out >>>>>>> of virtualspace.cpp. (In the debug version, an assertion in universe.cpp >>>>>>> triggers before reaching this point). EG: >>>>>> I am trying to reproduce this assert but I can't. Do you have more >>>>>> information to reproduce this? >>>>>> I did -version and running GCOld to trigger GC. >>>>>> >>>>>> java -XX:HeapBaseMinAddress=18446744073642442752 -version >>>>>> java -XX:HeapBaseMinAddress=18446744073642442752 GCOld 20 200 10 100 5000 >>>>>> >>>>> >>>>> You probably didn't hit the problem because you're running on a smaller >>>>> memory system than I am. On the system I'm on, the (computed) max heap size >>>>> is 32G. And if you specify an Xmx, you don't go through the code path that >>>>> causes it. >>>> Okay, my machine is 32G but when I test on bigger memory machine, I could see >>>> the assert. Thank you. >>>> >>>>> >>>>> Here's the root of the problem. In Arguments::set_heap_size(), we have this >>>>> code: >>>>> >>>>> if (FLAG_IS_DEFAULT(MaxHeapSize)) { >>>>> . . . >>>>> if (UseCompressedOops) { >>>>> // Limit the heap size to the maximum possible when using compressed >>>>> oops >>>>> julong max_coop_heap = (julong)max_heap_for_compressed_oops(); >>>>> . . . >>>>> if (HeapBaseMinAddress + MaxHeapSize < max_coop_heap) { <======== *** >>>>> PROBLEM IS HERE *** >>>>> // Heap should be above HeapBaseMinAddress to get zero based >>>>> compressed oops >>>>> // but it should be not less than default MaxHeapSize. >>>>> max_coop_heap -= HeapBaseMinAddress; >>>>> } >>>>> reasonable_max = MIN2(reasonable_max, max_coop_heap); >>>>> } >>>>> >>>>> HeapBaseMinAddress is 64-bit unsigned, and in this case is 0xfffffffffc000000 >>>>> (the 18446744073642442752 from the command line). MaxHeapSize is 0x7CCCCC8 >>>>> and max_coop_heap is 0x7FE000000. The addition of HeapBaseMinAddress and >>>>> MaxHeapSize overflows to 0x3ccccc8. Since this is less than 0x7FE000000, we >>>>> subtract the 0xfffffffffc000000 from max_coop_heap, getting the result >>>>> 0x802000000. reasonable_max is 0x800000000, so it stays at that value after >>>>> the MIN2, rather than being reduced as it should be. >>>>> >>>>> Changing the conditional to also check for overflow avoids the problem. But >>>>> of course you don't get the requested HeapBaseMinAddress anyway, since it's >>>>> too high. >>>>> >>>>> So another approach would be to change your constraint to ensure that >>>>> (HeapBaseMinAddress plus MaxHeapSize) won't overflow. I don't think there's >>>>> any point in allowing a HeapBaseMinAddress so high that it would. >>>> Okay, I'm thinking about this. >>>> I will post a new webrev after testing. >>>> >>>> * I also read your other email that fixing constraint function makes sense. >>>> ** I already fixed your previous comment of extraneous single quote in >>>> commandLineFlagConstraintsGC.cpp at line 510. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> Tom >>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=0xffffffffffffffff -version >>>>>>> HeapBaseMinAddress (18446744073709551615) must be less than or equal to >>>>>>> aligned maximum value (18446744073642442752) >>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>> >>>>>>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=18446744073642442752 -version >>>>>>> # >>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>> # >>>>>>> # Internal Error (virtualspace.cpp:456), pid=10359, tid=10360 >>>>>>> # guarantee(size + noaccess_prefix_size(alignment) <= OopEncodingHeapMax) >>>>>>> failed: can not allocate compressed oop heap for this size >>>>>>> # >>>>>>> >>>>>>> Perhaps you should check only the alignment in the constraint code, without >>>>>>> checking the range, because I'm not sure you have the final heap size at >>>>>>> that point. Then maybe the heap reservation code should report this as a >>>>>>> non-internal error, at the point where the assertion occurs, if the user >>>>>>> specified a base address. >>>>>>> >>>>>>> There's also an extraneous single quote in commandLineFlagConstraintsGC.cpp >>>>>>> in the comment at line 510. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>> Date: Tue, 24 Nov 2015 06:37:41 -0800 >>>>>>> From: "sangheon.kim" >>>>>>> To: Dmitry Dmitriev, >>>>>>> "hotspot-dev at openjdk.java.net Developers" >>>>>>> >>>>>>> Subject: Re: RFR(S): 8142341: GC: current flags need ranges to be >>>>>>> implemented >>>>>>> Message-ID:<56547635.9060808 at oracle.com> >>>>>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>>>>> >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> Thank you for the review! >>>>>>> Sure I will update my patch related to your enhancement. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote: >>>>>>> >>>>>>>> Hi Sangheon, >>>>>>>> >>>>>>>> Looks good to me! Thank you for fixing that. I hope that enhancement >>>>>>>> will be pushed today(currently in JPRT queue), so please update your >>>>>>>> patch after that! >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitry >>>>>>>> >>>>>>>> On 21.11.2015 0:04, sangheon.kim wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Could I have a couple of reviews for this change to add explicit >>>>>>>>> 'range' for flags? >>>>>>>>> >>>>>>>>> Previously, we added 'range' when it is needed to avoid assert/crash >>>>>>>>> but now explicit 'range' are needed for all flags. >>>>>>>>> All flags should have 'range' or 'constraint' at least. >>>>>>>>> >>>>>>>>> CR:https://bugs.openjdk.java.net/browse/JDK-8142341 >>>>>>>>> Webrev:http://cr.openjdk.java.net/~sangheki/8142341/webrev.00 >>>>>>>>> Testing: JPRT, RBT >>>>>>>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>>>>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for >>>>>>>>> embedded >>>>>>>>> >>>>>>>>> * Summary >>>>>>>>> 1. Added 3 new constraint functions. >>>>>>>>> 1) HeapBaseMinAddress: Added to avoid an overflow after align up >>>>>>>>> and this flag makes hang up without constraint function. (newly added >>>>>>>>> as a part of GC work) >>>>>>>>> 2) TLABWasteIncrement: Without this constraint function we don't >>>>>>>>> have problems (even many GCs happen). But added to avoid an overflow >>>>>>>>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are also >>>>>>>>> separate CR for this overflow ( JDK-8143352 ). >>>>>>>>> 3) NUMAInterleaveGranularity: Added to avoid an overflow after >>>>>>>>> align up. >>>>>>>>> >>>>>>>>> 2. Some flags have narrower range than their type. >>>>>>>>> 1) Here's the reason why some flags should have different range. >>>>>>>>> (same order from globals.hpp) >>>>>>>>> {flag type} {flag name}: (range), {comment} >>>>>>>>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), >>>>>>>>> max_uintx), there is a comment at numa_interleaving_init() that this >>>>>>>>> flag should be larger than vm_allocation_granularity(). >>>>>>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as >>>>>>>>> used for multiplication >>>>>>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which >>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function which >>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function >>>>>>>>> which has 'long' type input parameter. >>>>>>>>> uintx PausePadding: (0, max_juint), used to set a function which has >>>>>>>>> 'unsigned int' type input parameter. >>>>>>>>> uintx PromotedPadding: (0, max_juint), used to set a function which >>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>> uintx SurvivorPadding: (0, max_juint), used to set a function which >>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag >>>>>>>>> is divided by 100 I assume this is percentage. >>>>>>>>> uintx GCTimeRatio: (0, max_juint), used to set a function which has >>>>>>>>> 'unsigned int' type input parameter. >>>>>>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint) >>>>>>>>> intx PrefetchScanIntervalInBytes: (-1, max_jint) >>>>>>>>> intx PrefetchFieldsAhead: (-1, max_jint), I think these 3 Prefetch* >>>>>>>>> flags should have same upper limit and looking at their related codes >>>>>>>>> 'max_jint' seems appropriate ( no problem with 'max_jint' during >>>>>>>>> testing). However, as Prefetch::read/write() needs 'intx', 'intx' >>>>>>>>> also seems good but we have to fix some codes (maybe including >>>>>>>>> generated codes). >>>>>>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function which >>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint >>>>>>>>> variable and used 'for loop' which has uint increment. i.e. for (uint >>>>>>>>> i=0; i>>>>>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at >>>>>>>>> 'increment for loop()' as max value and the increment is uint. >>>>>>>>> uintx CMSYieldSleepCount: (0, max_juint), used at 'increment for >>>>>>>>> loop()' as max value and the increment is uint. >>>>>>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return value >>>>>>>>> of uint type function and for division. i.e. uint >>>>>>>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return >>>>>>>>> TLABRefillWasteFraction; } >>>>>>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int) >>>>>>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we only >>>>>>>>> use " if (a !=0, >0, >1)". >>>>>>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we only >>>>>>>>> use " if (a !=0, >0, >1)". >>>>>>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only use >>>>>>>>> " if (a !=0, >0)". >>>>>>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned >>>>>>>>> int' >>>>>>>>> >>>>>>>>> (g1_globals.hpp) >>>>>>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int) >>>>>>>>> type variable. >>>>>>>>> >>>>>>>>> 3. Excluded flags from TestOptionsWithRanges.java >>>>>>>>> 1) Memory and thread related flags: tests for these flags will >>>>>>>>> consume too many resources from the system. >>>>>>>>> 2) VMThreadStackSize: range work for this flag is not included in >>>>>>>>> this patch but I faced OOME several times, so excluded. >>>>>>>>> >>>>>>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] >>>>>>>>> TestOptionsWithRanges: allow excluding only a subset of tested values >>>>>>>>> specified for a flag) next time. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>> >>>> >>> > From ioi.lam at oracle.com Fri Dec 4 22:59:41 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 04 Dec 2015 14:59:41 -0800 Subject: RFR (XS) 8143615 compactHashtable.hpp includes oop.inline.hpp file In-Reply-To: <56615B87.40303@oracle.com> References: <565FA9BC.2080808@oracle.com> <566006B5.7010500@oracle.com> <56605534.7040308@oracle.com> <56615B87.40303@oracle.com> Message-ID: <56621ADD.1040804@oracle.com> Hi Stefan, Thanks for the explanation. I have updated the webrev http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp.v2/ updates from the last version: [1] Move the two add functions identified by Stefan to compactHashtable.inline.hpp [2] Removed allocation.inline.hpp from compactHashtable.hpp [3] Removed oop.inline.hpp from compilerDirectives.hpp Thanks - Ioi On 12/4/15 1:23 AM, Stefan Karlsson wrote: > On 2015-12-03 15:44, Ioi Lam wrote: >> On 12/3/15 1:09 AM, Stefan Karlsson wrote: >>> Hi Ioi, >>> >>> Thanks a lot for fixing this! >>> >>> Would you mind swapping these lines around?: >>> >>> #include "classfile/javaClasses.hpp" >>> +#include "classfile/compactHashtable.inline.hpp" >> >> Thanks for noticing. I will fix that. >>> Except for that nit, this looks good. >>> >>> As David says, we should get rid of the allocation.inline.hpp >>> include as well, but I think we could defer that to a separate patch >>> (if you want to). >> >> TL;DR -- this fix probably won't do much in terms of speeding up a >> rebuild, but >> may still be a good clean up ... > > My main concern is not about the compile times, but that we're > spreading the include mess. > >> >> >> Read the following if you're bored ----v >> >> Actually, I am not quite familiar with the rules of when/if >> *.inline.hpp can >> be inlcluded by a "regular" hpp file.Is that documented somewhere? > > https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files > >> >> My guess is this happened when Stefan reported the bug: >> >> + precompiled header is used > > I compile without precompiled headers. > >> >> + oop.inline.hpp was (indirectly) included into precompiled.hpp.gch.d >> - this was actually not caused by compactHashtable.hpp(this file >> is not >> included by precompiled.hpp) >> You can verified this from auto-generated files such as >> hotspot/linux_amd64_compiler2/generated/dependencies/precompiled.hpp.gch.d >> >> - the culprit is src/share/vm/compiler/compilerDirectives.hpp, >> which also >> includes oop.inline.hpp,introduced in this changeset: >> changeset: 9323:a176d4737606 >> user: neliasso >> 8137167: JEP165: Compiler Control: Implementation task >> Summary: Compiler Control JEP >> - the depedndency is precompiled.hpp -> ciEnv.hpp -> >> compilerDirectives.hpp-> oop.inline.hpp > > :( > >> >> + oop.inline.hpp itself includes many GC header files, so when Stefan >> touches one of them, >> everything is recompiled. > > Yes. > >> >> So my interpretation is: >> >> + We should try to minimize the number of other header files included >> in "regular" .hpp files >> - Complex inline functions should be defined in .inline.hpp files. > > Yes. > >> + Avoid including .inline.hpp files in "regular" .hpp files, since >> that may indirectly >> include a large set of header files. > > Yes. > >> >> Anyway, I don't think this can be easily adhered to, or easily >> understood, or cared >> about, by the developers. > > It's quite simple if you by default _don't_ put definitions in the > header file. Put all implementation in the .cpp files, and if it's > important to inline the functions, put the code in an .inline.hpp > files. It's when code is put into .hpp that things start to become > problematic. > > Granted, _simple_ getters and setters in header files don't pose a > problem. > >> Moreover, there are actually a lot of various inline.hpp files >> being included in .hpp files. >> >> hotspot/src/share$ find . -name \*inline.hpp -prune -o -name \*.hpp >> -print | xargs grep inline.hpp | grep -v precompiled.hpp | wc >> 60 189 4387 > > $ find . -name \*inline.hpp -prune -o -name \*.hpp -print | xargs grep > inline.hpp | grep -v precompiled.hpp | grep "#include" | awk -F: '{ > print $2}' | sort | uniq -c > 5 #include "asm/macroAssembler.inline.hpp" > 1 #include "assembler_zero.inline.hpp" > 1 #include "bytes_linux_ppc.inline.hpp" > 17 #include "memory/allocation.inline.hpp" > 2 #include "memory/universe.inline.hpp" > 2 #include "oops/oop.inline.hpp" > 1 #include "os_windows.inline.hpp" // needed for sockaddr_in > 1 #include "prims/jvmtiThreadState.inline.hpp" > 6 #include "runtime/frame.inline.hpp" > 6 #include "runtime/handles.inline.hpp" > 1 #include "runtime/objectMonitor.inline.hpp" > 2 #include "runtime/orderAccess.inline.hpp" > 8 #include "runtime/thread.inline.hpp" > 2 #include "utilities/bitMap.inline.hpp" > 1 #include "utilities/hashtable.inline.hpp" > > > There used to be loads more includes of oop.inline.hpp, but I removed > them. > >> >> So I think in an ideal world, we should have a tool that can >> automatically >> flags the "bad" includes. But, I am not sure how much time we want to >> invest in that :-( >> >> In this particular case, after I removed oop.inline.hpp from >> compilerDirectives.hpp >> (it turned out to be an unnecessary include), only 7 include files >> were removed from >> precompiled.hpp.gch.d, so I am not sure it's a big win. >> >> But in terms of clean up, it's still a good idea to move big inline >> function >> definitions out of compactHashtable.hpp. > > Not that the size shouldn't be measured in number of lines, but what > they depend on: > > 120 void add(unsigned int hash, Symbol* symbol) { > 121 add(hash, new Entry(hash, symbol)); > 122 } > 123 > 124 void add(unsigned int hash, oop string) { > 125 add(hash, new Entry(hash, string)); > 126 } > > > Take these lines, for example, they force the include of > allocation.inline.hpp in compactHashtable.cpp. Simply moving these > definitions to the .cpp removes the need to include > allocation.inline.hpp. > >> >> >> Also, I can see that allocation.inline.hpp is included by many .hpp >> files, so >> I guess it's OK for compactHashtable.hpp to do the same. If a clean >> up is needed, >> that would need to be done in a separate RFE. >> >> hotspot/src/share$ find . -name \*inline.hpp -prune -o -name \*.hpp >> -print | xargs grep allocation.inline.hpp >> ./vm/precompiled/precompiled.hpp:# include >> "memory/allocation.inline.hpp" >> ./vm/prims/jvmtiEventController.hpp:#include >> "memory/allocation.inline.hpp" >> ./vm/prims/jvmtiEnvThreadState.hpp:#include >> "memory/allocation.inline.hpp" >> ./vm/prims/jvmtiThreadState.hpp:#include "memory/allocation.inline.hpp" >> ./vm/oops/generateOopMap.hpp:#include "memory/allocation.inline.hpp" >> ./vm/compiler/compileTask.hpp:#include "memory/allocation.inline.hpp" >> ./vm/compiler/methodMatcher.hpp:#include "memory/allocation.inline.hpp" >> ./vm/classfile/compactHashtable.hpp:#include >> "memory/allocation.inline.hpp" >> ./vm/classfile/symbolTable.hpp:#include "memory/allocation.inline.hpp" >> ./vm/classfile/stringTable.hpp:#include "memory/allocation.inline.hpp" >> ./vm/utilities/growableArray.hpp:#include "memory/allocation.inline.hpp" >> ./vm/utilities/stack.hpp:#include "memory/allocation.inline.hpp" >> ./vm/utilities/array.hpp:#include "memory/allocation.inline.hpp" >> ./vm/gc/g1/g1Predictions.hpp:#include "memory/allocation.inline.hpp" >> ./vm/runtime/perfData.hpp:#include "memory/allocation.inline.hpp" >> ./vm/logging/log.hpp:#include "memory/allocation.inline.hpp" >> ./vm/libadt/dict.hpp:#include "memory/allocation.inline.hpp" > > It would be good to decrease that list, not add to it. Maybe > allocation.inline.hpp needs to fixed, and parts moved to the .cpp file. > > I see that g1Predictions.hpp added allocation.inline.hpp. I recently > went over the entire GC code base and got rid of _all_ includes of > .inline.hpp files from .hpp files. > > Stefank > >> >> >> Thanks >> - Ioi >> >> >> >>> Thanks, >>> StefanK >>> >>> On 2015-12-03 03:32, Ioi Lam wrote: >>>> Please review a very small fix: >>>> >>>> http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp/ >>>> >>>> Bug: compactHashtable.hpp includes oop.inline.hpp file >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8143615 >>>> >>>> Summary of fix: >>>> >>>> + deleted the include of oop.inline.hpp from compactHashtable.hpp >>>> + moved all inlined functions that require oop.inline.hpp into a >>>> new file, compactHashtable.inline.hpp >>>> >>>> Tests: >>>> >>>> JPRT >>>> >>>> Thanks >>>> - Ioi >>> >> > From sangheon.kim at oracle.com Fri Dec 4 23:19:41 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Fri, 4 Dec 2015 15:19:41 -0800 Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented In-Reply-To: <5662168E.9090303@oracle.com> References: <565CD1AD.90902@oracle.com> <565CE0FB.8000303@oracle.com> <565DEC2D.3010308@oracle.com> <565E3382.7050502@oracle.com> <56600686.4060606@oracle.com> <5661D66B.3080708@oracle.com> <5661F0BF.5080302@oracle.com> <5662168E.9090303@oracle.com> Message-ID: <56621F8D.5040908@oracle.com> Hi Jesper, Okay, thanks. Sangheon On 12/04/2015 02:41 PM, Jesper Wilhelmsson wrote: > Den 4/12/15 kl. 20:59, skrev sangheon.kim: >> Hi Jesper, >> >> Thank you for reviewing this. >> >> On 12/04/2015 10:07 AM, Jesper Wilhelmsson wrote: >>> Looks good! >>> >>> I would prefer if there was a space after the comma in the new >>> constraint >>> lines in globals.hpp. I see that there are no spaces in the old >>> lines as well. >>> I you feel like it this could be cleaned up. >> You are right. >> However let me address from a separate CR as you said old lines also >> don't have >> a space. > > I'm fine with that. > Ship it! > /Jesper > >> >>> >>> Since you filed the other bug regarding the overflow I think this >>> patch is >>> good to go. >> Thanks! >> >> Sangheon >> >> >>> /Jesper >>> >>> Den 3/12/15 kl. 10:08, skrev sangheon.kim: >>>> Hi all, >>>> >>>> Here is next webrev. >>>> http://cr.openjdk.java.net/~sangheki/8142341/webrev.02/ >>>> http://cr.openjdk.java.net/~sangheki/8142341/webrev.02_to_01/ >>>> >>>> Testing: JPRT and TestOptionsWithRanges.java on machines that have >>>> over 120GB >>>> memory. >>>> >>>> *Summary >>>> 1. Enhanced the constraint function for HeapBaseMinAddress: (Tom) >>>> 1) It will check an overflow the addition of MaxHeapSize and >>>> HeapBaseMinAddress. >>>> And the overflow only happens when MaxHeapSize is default and using >>>> compressed >>>> oop. Since MaxHeapSize is updated after ergo, >>>> FLAG_IS_ERGO(MaxHeapSize) is >>>> necessary at the constraint function. >>>> 2) As HeapBaseMinAddress has 'AfterErgo' tag, the constraint >>>> function will be >>>> called after the overflow happens at Arguments::set_heap_size(). >>>> However it is >>>> okay as we can detect the overflow before actual use of creating >>>> virtual space. >>>> And the problem of the overflow is setting MaxHeapSize with bigger >>>> value that it >>>> should be. >>>> 3) Changed the order of HeapBaseMinAddress to locate later than >>>> MaxHeapSize from >>>> globals.hpp as HeapBaseMinAddress refers MaxHeapSize. >>>> >>>> 2. Added missing single quote in commandLineFlagConstraintsGC.cpp >>>> at line 510. >>>> (Tom) >>>> >>>> 3. Changed test to add dependency for NewSizeThreadIncrease. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 12/01/2015 03:55 PM, sangheon.kim wrote: >>>>> Hi Tom, >>>>> >>>>> Thank you for this kind analysis! >>>>> >>>>> >>>>> On 12/01/2015 10:51 AM, Tom Benson wrote: >>>>>> Hi Sangheon, >>>>>> >>>>>> On 11/30/2015 6:51 PM, sangheon.kim wrote: >>>>>>> Hi Tom, >>>>>>> >>>>>>> Thank you for reviewing this! >>>>>>> >>>>>>> On 11/30/2015 02:46 PM, Tom Benson wrote: >>>>>>>> Hi Sangheon, >>>>>>>> >>>>>>>> I think there's a problem with using the same routine to check >>>>>>>> HeapBaseMinAddress as is used for checking heap size in >>>>>>>> commandLineFlagConstraintsGC.cpp. I tried running this, to make >>>>>>>> sure I >>>>>>>> understood what it was trying to do. When I specified something >>>>>>>> too large >>>>>>>> for HeapBaseMinAddress, the check reported that the value must >>>>>>>> be greater >>>>>>>> than or equal to maximum value N. >>>>>>> Sorry Tom, I can't understand. >>>>>>> Currently we print the error message if its value is too large >>>>>>> like, "must >>>>>>> be less than or equal to aligned maximum value (xxx)". >>>>>>> Do you mean it should be 'address' instead of 'value'? >>>>>> >>>>>> What I meant was that I got an internal error when I used the >>>>>> value the >>>>>> message recommended, so perhaps the value should be further >>>>>> constrained. >>>>> I see. >>>>> >>>>>> >>>>>>> I thought it is okay. >>>>>>> >>>>>>>> Re-running with that (still huge) value, I get a fatal internal >>>>>>>> error out >>>>>>>> of virtualspace.cpp. (In the debug version, an assertion in >>>>>>>> universe.cpp >>>>>>>> triggers before reaching this point). EG: >>>>>>> I am trying to reproduce this assert but I can't. Do you have more >>>>>>> information to reproduce this? >>>>>>> I did -version and running GCOld to trigger GC. >>>>>>> >>>>>>> java -XX:HeapBaseMinAddress=18446744073642442752 -version >>>>>>> java -XX:HeapBaseMinAddress=18446744073642442752 GCOld 20 200 10 >>>>>>> 100 5000 >>>>>>> >>>>>> >>>>>> You probably didn't hit the problem because you're running on a >>>>>> smaller >>>>>> memory system than I am. On the system I'm on, the (computed) >>>>>> max heap size >>>>>> is 32G. And if you specify an Xmx, you don't go through the >>>>>> code path that >>>>>> causes it. >>>>> Okay, my machine is 32G but when I test on bigger memory machine, >>>>> I could see >>>>> the assert. Thank you. >>>>> >>>>>> >>>>>> Here's the root of the problem. In Arguments::set_heap_size(), >>>>>> we have this >>>>>> code: >>>>>> >>>>>> if (FLAG_IS_DEFAULT(MaxHeapSize)) { >>>>>> . . . >>>>>> if (UseCompressedOops) { >>>>>> // Limit the heap size to the maximum possible when using >>>>>> compressed >>>>>> oops >>>>>> julong max_coop_heap = (julong)max_heap_for_compressed_oops(); >>>>>> . . . >>>>>> if (HeapBaseMinAddress + MaxHeapSize < max_coop_heap) { >>>>>> <======== *** >>>>>> PROBLEM IS HERE *** >>>>>> // Heap should be above HeapBaseMinAddress to get zero based >>>>>> compressed oops >>>>>> // but it should be not less than default MaxHeapSize. >>>>>> max_coop_heap -= HeapBaseMinAddress; >>>>>> } >>>>>> reasonable_max = MIN2(reasonable_max, max_coop_heap); >>>>>> } >>>>>> >>>>>> HeapBaseMinAddress is 64-bit unsigned, and in this case is >>>>>> 0xfffffffffc000000 >>>>>> (the 18446744073642442752 from the command line). MaxHeapSize is >>>>>> 0x7CCCCC8 >>>>>> and max_coop_heap is 0x7FE000000. The addition of >>>>>> HeapBaseMinAddress and >>>>>> MaxHeapSize overflows to 0x3ccccc8. Since this is less than >>>>>> 0x7FE000000, we >>>>>> subtract the 0xfffffffffc000000 from max_coop_heap, getting the >>>>>> result >>>>>> 0x802000000. reasonable_max is 0x800000000, so it stays at that >>>>>> value after >>>>>> the MIN2, rather than being reduced as it should be. >>>>>> >>>>>> Changing the conditional to also check for overflow avoids the >>>>>> problem. But >>>>>> of course you don't get the requested HeapBaseMinAddress anyway, >>>>>> since it's >>>>>> too high. >>>>>> >>>>>> So another approach would be to change your constraint to ensure >>>>>> that >>>>>> (HeapBaseMinAddress plus MaxHeapSize) won't overflow. I don't >>>>>> think there's >>>>>> any point in allowing a HeapBaseMinAddress so high that it would. >>>>> Okay, I'm thinking about this. >>>>> I will post a new webrev after testing. >>>>> >>>>> * I also read your other email that fixing constraint function >>>>> makes sense. >>>>> ** I already fixed your previous comment of extraneous single >>>>> quote in >>>>> commandLineFlagConstraintsGC.cpp at line 510. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> Tom >>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=0xffffffffffffffff >>>>>>>> -version >>>>>>>> HeapBaseMinAddress (18446744073709551615) must be less than or >>>>>>>> equal to >>>>>>>> aligned maximum value (18446744073642442752) >>>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>>> >>>>>>>> $ $JAVA_HOME/bin/java >>>>>>>> -XX:HeapBaseMinAddress=18446744073642442752 -version >>>>>>>> # >>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>> # >>>>>>>> # Internal Error (virtualspace.cpp:456), pid=10359, tid=10360 >>>>>>>> # guarantee(size + noaccess_prefix_size(alignment) <= >>>>>>>> OopEncodingHeapMax) >>>>>>>> failed: can not allocate compressed oop heap for this size >>>>>>>> # >>>>>>>> >>>>>>>> Perhaps you should check only the alignment in the constraint >>>>>>>> code, without >>>>>>>> checking the range, because I'm not sure you have the final >>>>>>>> heap size at >>>>>>>> that point. Then maybe the heap reservation code should report >>>>>>>> this as a >>>>>>>> non-internal error, at the point where the assertion occurs, if >>>>>>>> the user >>>>>>>> specified a base address. >>>>>>>> >>>>>>>> There's also an extraneous single quote in >>>>>>>> commandLineFlagConstraintsGC.cpp >>>>>>>> in the comment at line 510. >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> >>>>>>>> Date: Tue, 24 Nov 2015 06:37:41 -0800 >>>>>>>> From: "sangheon.kim" >>>>>>>> To: Dmitry Dmitriev, >>>>>>>> "hotspot-dev at openjdk.java.net Developers" >>>>>>>> >>>>>>>> Subject: Re: RFR(S): 8142341: GC: current flags need ranges to be >>>>>>>> implemented >>>>>>>> Message-ID:<56547635.9060808 at oracle.com> >>>>>>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>>>>>> >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> Thank you for the review! >>>>>>>> Sure I will update my patch related to your enhancement. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote: >>>>>>>> >>>>>>>>> Hi Sangheon, >>>>>>>>> >>>>>>>>> Looks good to me! Thank you for fixing that. I hope that >>>>>>>>> enhancement >>>>>>>>> will be pushed today(currently in JPRT queue), so please >>>>>>>>> update your >>>>>>>>> patch after that! >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitry >>>>>>>>> >>>>>>>>> On 21.11.2015 0:04, sangheon.kim wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Could I have a couple of reviews for this change to add explicit >>>>>>>>>> 'range' for flags? >>>>>>>>>> >>>>>>>>>> Previously, we added 'range' when it is needed to avoid >>>>>>>>>> assert/crash >>>>>>>>>> but now explicit 'range' are needed for all flags. >>>>>>>>>> All flags should have 'range' or 'constraint' at least. >>>>>>>>>> >>>>>>>>>> CR:https://bugs.openjdk.java.net/browse/JDK-8142341 >>>>>>>>>> Webrev:http://cr.openjdk.java.net/~sangheki/8142341/webrev.00 >>>>>>>>>> Testing: JPRT, RBT >>>>>>>>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>>>>>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for >>>>>>>>>> embedded >>>>>>>>>> >>>>>>>>>> * Summary >>>>>>>>>> 1. Added 3 new constraint functions. >>>>>>>>>> 1) HeapBaseMinAddress: Added to avoid an overflow after >>>>>>>>>> align up >>>>>>>>>> and this flag makes hang up without constraint function. >>>>>>>>>> (newly added >>>>>>>>>> as a part of GC work) >>>>>>>>>> 2) TLABWasteIncrement: Without this constraint function >>>>>>>>>> we don't >>>>>>>>>> have problems (even many GCs happen). But added to avoid an >>>>>>>>>> overflow >>>>>>>>>> at ThreadLocalAllocBuffer::record_slow_allocation(). There >>>>>>>>>> are also >>>>>>>>>> separate CR for this overflow ( JDK-8143352 ). >>>>>>>>>> 3) NUMAInterleaveGranularity: Added to avoid an overflow >>>>>>>>>> after >>>>>>>>>> align up. >>>>>>>>>> >>>>>>>>>> 2. Some flags have narrower range than their type. >>>>>>>>>> 1) Here's the reason why some flags should have different >>>>>>>>>> range. >>>>>>>>>> (same order from globals.hpp) >>>>>>>>>> {flag type} {flag name}: (range), {comment} >>>>>>>>>> size_t NUMAInterleaveGranularity: >>>>>>>>>> (os::vm_allocation_granularity(), >>>>>>>>>> max_uintx), there is a comment at numa_interleaving_init() >>>>>>>>>> that this >>>>>>>>>> flag should be larger than vm_allocation_granularity(). >>>>>>>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be >>>>>>>>>> zero as >>>>>>>>>> used for multiplication >>>>>>>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function >>>>>>>>>> which >>>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a >>>>>>>>>> function which >>>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a >>>>>>>>>> function >>>>>>>>>> which has 'long' type input parameter. >>>>>>>>>> uintx PausePadding: (0, max_juint), used to set a function >>>>>>>>>> which has >>>>>>>>>> 'unsigned int' type input parameter. >>>>>>>>>> uintx PromotedPadding: (0, max_juint), used to set a function >>>>>>>>>> which >>>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>>> uintx SurvivorPadding: (0, max_juint), used to set a function >>>>>>>>>> which >>>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as >>>>>>>>>> this flag >>>>>>>>>> is divided by 100 I assume this is percentage. >>>>>>>>>> uintx GCTimeRatio: (0, max_juint), used to set a function >>>>>>>>>> which has >>>>>>>>>> 'unsigned int' type input parameter. >>>>>>>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint) >>>>>>>>>> intx PrefetchScanIntervalInBytes: (-1, max_jint) >>>>>>>>>> intx PrefetchFieldsAhead: (-1, max_jint), I think these 3 >>>>>>>>>> Prefetch* >>>>>>>>>> flags should have same upper limit and looking at their >>>>>>>>>> related codes >>>>>>>>>> 'max_jint' seems appropriate ( no problem with 'max_jint' during >>>>>>>>>> testing). However, as Prefetch::read/write() needs 'intx', >>>>>>>>>> 'intx' >>>>>>>>>> also seems good but we have to fix some codes (maybe including >>>>>>>>>> generated codes). >>>>>>>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function >>>>>>>>>> which >>>>>>>>>> has 'unsigned int' type input parameter. >>>>>>>>>> uintx ProcessDistributionStride: (0, max_juint), used to set >>>>>>>>>> uint >>>>>>>>>> variable and used 'for loop' which has uint increment. i.e. >>>>>>>>>> for (uint >>>>>>>>>> i=0; i>>>>>>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at >>>>>>>>>> 'increment for loop()' as max value and the increment is uint. >>>>>>>>>> uintx CMSYieldSleepCount: (0, max_juint), used at 'increment >>>>>>>>>> for >>>>>>>>>> loop()' as max value and the increment is uint. >>>>>>>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a >>>>>>>>>> return value >>>>>>>>>> of uint type function and for division. i.e. uint >>>>>>>>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return >>>>>>>>>> TLABRefillWasteFraction; } >>>>>>>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int) >>>>>>>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and >>>>>>>>>> we only >>>>>>>>>> use " if (a !=0, >0, >1)". >>>>>>>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and >>>>>>>>>> we only >>>>>>>>>> use " if (a !=0, >0, >1)". >>>>>>>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we >>>>>>>>>> only use >>>>>>>>>> " if (a !=0, >0)". >>>>>>>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to >>>>>>>>>> 'unsigned >>>>>>>>>> int' >>>>>>>>>> >>>>>>>>>> (g1_globals.hpp) >>>>>>>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to >>>>>>>>>> set (int) >>>>>>>>>> type variable. >>>>>>>>>> >>>>>>>>>> 3. Excluded flags from TestOptionsWithRanges.java >>>>>>>>>> 1) Memory and thread related flags: tests for these flags will >>>>>>>>>> consume too many resources from the system. >>>>>>>>>> 2) VMThreadStackSize: range work for this flag is not >>>>>>>>>> included in >>>>>>>>>> this patch but I faced OOME several times, so excluded. >>>>>>>>>> >>>>>>>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] >>>>>>>>>> TestOptionsWithRanges: allow excluding only a subset of >>>>>>>>>> tested values >>>>>>>>>> specified for a flag) next time. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From christian.thalinger at oracle.com Sat Dec 5 00:50:13 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Dec 2015 14:50:13 -1000 Subject: RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions In-Reply-To: <5661FC4F.1030201@oracle.com> References: <565FA1C1.50909@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA2E2@DEWDFEMB12A.global.corp.sap> <5660D576.80904@oracle.com> <5661FC4F.1030201@oracle.com> Message-ID: <3638BF63-D819-421A-A00D-5B5F4329C349@oracle.com> > On Dec 4, 2015, at 10:49 AM, Coleen Phillimore wrote: > > > Hi Chris, > Thank you for looking at this. Debt almost repaid. Good :-) > > On 12/4/15 12:48 PM, Christian Thalinger wrote: >>> On Dec 3, 2015, at 1:51 PM, Coleen Phillimore wrote: >>> >>> >>> Hi Goetz, >>> >>> Thank you for looking at my change. I made the ppc changes and hg added templateInterpreter_ppc/aarch64.cpp back, so they should be in the patch. >>> >>> Now webrev thinks I've deleted 7785 lines, but I didn't really. >>> >>> http://cr.openjdk.java.net/~coleenp/8144534.02/ >>> >>> The most interesting part of this change is in the x86 code: >>> >>> http://cr.openjdk.java.net/~coleenp/8144534.02/src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp.udiff.html >>> >>> This is where the 32 and 64 bit template interpreter code is merged. >> + Register rarg = NOT_LP64(rax) LP64_ONLY(c_rarg1); >> + Register rarg2 = NOT_LP64(rbx) LP64_ONLY(c_rarg2); >> >> Aren?t these always the same and could also be defined globally? Maybe keep rarg1. > > No, I don't think we usually use rbx for 32 bit. I have other instances that we pick rdx and rbx. Ok. > >> >> ! // compute beginning of parameters (rdi/r14) >> ! __ lea(rlocals, Address(rsp, rcx, Interpreter::stackElementScale(), -wordSize)); >> >> You can remove the rdi/r14 part. > > done. > >> >> ! // restore rsi/r13 to have legal interpreter frame, i.e., bci == 0 <=> >> // r13 == code_base() >> >> // compute beginning of parameters (r14) >> >> Same for these. > // restore to have legal interpreter frame, i.e., bci == 0 <=> code_base() > > Much better. > >> >> ExternalAddress unsatisfied(SharedRuntime::native_method_throw_unsatisfied_link_error_entry()); >> ! __ movptr(rscratch2, unsatisfied.addr()); >> __ cmpptr(rax, rscratch2); >> ! __ cmpptr(rax, unsatisfied.addr()); >> >> I think this is wrong. On 64-bit cmp can?t take a 64-bit immediate. That?s why we have the move. > > Wow, you're right cmpptr is a macroAssembler instruction because it does the mov depending on the address. We use cmpptr(reg, Address) all over. > > > Thanks! > Coleen >> >> Otherwise this looks good but I?ve only looked at this one file. >> >>> Thanks, >>> Coleen >>> >>> On 12/3/15 8:14 AM, Lindenmaier, Goetz wrote: >>>> Hi Coleen, >>>> >>>> I've been looking at this change. A cleanup in this area is really >>>> useful. >>>> I missed templateInterpreter_ppc.cpp in your patch, I guess you forgot >>>> "hg add" for it. >>>> In addition, I had to fix some code around math_entry_available(), see this patch: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8144534-interp/8144534-fixes_for_ppc.patch >>>> >>>> In general, I think it's strange that AbstractInterpreterGenerator >>>> implementations are in interpreter_.cpp, as mentioned In the bug. >>>> Why not move them to templateInterpreterGenerator_.cpp? Or will >>>> this be subject to a later change that removes the funny common >>>> subclasses Interpreter/InterpreterGenerator? >>>> >>>> Should I make a change removing the CC_INTERP support from ppc? >>>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>>> Behalf Of Coleen Phillimore >>>>> Sent: Donnerstag, 3. Dezember 2015 02:58 >>>>> To: hotspot-dev developers >>>>> Subject: RFR 8144534: Refactor templateInterpreter and >>>>> templateInterpreterGenerator functions >>>>> >>>>> Summary: merged templateInterpreter_x86_32/64 into >>>>> templateInterpreterGenerator_x86.cpp (some 32/64 functions remain for >>>>> the hand coded crc functions). >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144534.01/ >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144534 >>>>> >>>>> I tried to make this reviewable by hg renaming files. I basically >>>>> renamed templateInterpreter_ppc.cpp and removed the >>>>> AbstractInterpreter >>>>> functions and put them back into templateInterpreter_ppc.cpp. I didn't >>>>> really delete 4000 lines of code, more like 1500. >>>>> >>>>> Also, can someone with the PPC and AARCH port look at and test out these >>>>> changes? I tried to reduce the #includes in the new >>>>> templateInterpreter_ppc/aarch64.cpp files which worked for sparc. >>>>> >>>>> Tested with JPRT on all platforms, also ran jtreg and >>>>> collocated/non-collocated tonga tests for linux x64 and i386 since >>>>> that's were the real changes are. >>>>> >>>>> See the bug for more details and my partial vision of how these >>>>> functions will be reorganized when I remove the broken c++ interpreter. >>>>> >>>>> Also tested that Zero still builds. >>>>> >>>>> Thanks! >>>>> Coleen From david.holmes at oracle.com Sat Dec 5 04:57:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Sat, 5 Dec 2015 14:57:43 +1000 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <5661C1D6.4030901@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> Message-ID: <56626EC7.4050202@oracle.com> Hi Jon, On 5/12/2015 2:39 AM, Jon Masamitsu wrote: > Here's a new version of the fix (simpler thanks to a suggestion > from Kim). > > http://cr.openjdk.java.net/~jmasa/8133023/webrev.05/ Yes this seems quite neat. It is a pity about yet-another-VM_Version-init-function but ... Only minor comment is that in VM_Version::vm_init_before_ergo the "vm" part is somewhat unnecessary and doesn't fit with the existing: initialize() and early_initialize(). How about just initialize_before_ergo()? Also we now really need a comment explaining when the plain initialize() function is used. Thanks, David ----- > In the above webrev vm_version_x86.hpp appears but has no changes. > There were changes to it in the previous version (04) but were undone in > this latest version and may be why it appears in the webrev. > > The delta webrev is > > http://cr.openjdk.java.net/~jmasa/8133023/delta.05/ > > It has a white-space change in vm_version_sparc.hpp which > does not appear in the diffs. > > Thanks. > > Jon > > > On 12/2/2015 9:46 AM, Jon Masamitsu wrote: >> >> >> On 11/30/2015 11:47 AM, Kim Barrett wrote: >>> On Nov 30, 2015, at 12:20 PM, Jon Masamitsu >>> wrote: >>>>> src/share/vm/runtime/os.cpp >>>>> 319 VM_Version::vm_init_before_ergo(); >>>>> >>>>> This call is in generic code, but only two definitions have been >>>>> provided, for sparc and x86. Missing are aarch64, ppc, and zero. >>>>> >>>> Add vm_init_before_ergo() for those even though JPRT does not >>>> build them? I don't need to be convinced to do it. Just >>>> encouraged. Say "do it" and I'll do it. >>> I think you should do it, rather than knowingly breaking the build >>> for those targets when the needed code is so trivial. >>> >> >> Here's the webrev for the delta for review comments to this point. >> >> http://cr.openjdk.java.net/~jmasa/8133023/delta.04/ >> >> Webrev for complete patch is here. >> >> http://cr.openjdk.java.net/~jmasa/8133023/webrev.04/ >> >> Jon > From dl at cs.oswego.edu Sat Dec 5 16:23:49 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 5 Dec 2015 11:23:49 -0500 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <565FD8C8.6020105@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu> <56525823.6010506@cs.oswego.edu> <744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com> <56572F4E.8050603@oracle.com> <565F0698.7080600@cs.oswego.edu> <565FD8C8.6020105@oracle.com> Message-ID: <56630F95.4080908@cs.oswego.edu> On 12/03/2015 12:53 AM, David Holmes wrote: > On 3/12/2015 12:56 AM, Doug Lea wrote: >> In the absence of any of: tail-recursion support, reliable cleanup, >> or growable stacks, it seems reasonable to choose larger default >> stack sizes so that these long but finite chains of completions >> are far less likely to hit SOE. >> >> On 32bit systems the 1MB limit is completely defensible. But expanding >> to say 64MB on 64bit systems would reduce practical encounters with >> SOE in these kinds of constructions by a factor of 64 or so. >> Is there any reason not to do this? > > The same discussion on the concurrency-interest mailing list seems to indicate > that there are indeed reasons to not do this. > > http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014596.html > And all of them amount to arguments that it could interfere with other configuration assumptions and practices. Perhaps hotspot could at least support simpler ways that fluent/functionally-flavored programs could override defaults to start up with more friendly settings (as in "java -XX:+FP" ...) -Doug From david.holmes at oracle.com Sun Dec 6 23:52:42 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2015 09:52:42 +1000 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <5661FEE5.2040108@oracle.com> References: <5661FEE5.2040108@oracle.com> Message-ID: <5664CA4A.1090704@oracle.com> Hi Chris, On 5/12/2015 7:00 AM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8144677 > http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ > > Tested with JPRT with: > ? "-testset hotspot" > ? "-testset svc" > ? "-testset chris" from the example custom testset provided in the CR. > ? no testset specified Looks good! > BTW, if anyone knows of an "include" mechanism for jprt.properties, Properties files do not have an include mechanism. See: http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader- Thanks, David > please let me know. Although that won't change the need for the above > changes, it would make it possible to put custom testsets in a file > rather than having to paste them in your ~/.jprt.properties file. > > thanks, > > Chris > > From david.holmes at oracle.com Mon Dec 7 00:03:47 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2015 10:03:47 +1000 Subject: RFR (XS) 8143615 compactHashtable.hpp includes oop.inline.hpp file In-Reply-To: <56621ADD.1040804@oracle.com> References: <565FA9BC.2080808@oracle.com> <566006B5.7010500@oracle.com> <56605534.7040308@oracle.com> <56615B87.40303@oracle.com> <56621ADD.1040804@oracle.com> Message-ID: <5664CCE3.2090106@oracle.com> On 5/12/2015 8:59 AM, Ioi Lam wrote: > Hi Stefan, > > Thanks for the explanation. I have updated the webrev > > http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp.v2/ > > updates from the last version: > > [1] Move the two add functions identified by Stefan to > compactHashtable.inline.hpp > [2] Removed allocation.inline.hpp from compactHashtable.hpp > [3] Removed oop.inline.hpp from compilerDirectives.hpp Seems okay. Thanks, David > Thanks > - Ioi > > On 12/4/15 1:23 AM, Stefan Karlsson wrote: >> On 2015-12-03 15:44, Ioi Lam wrote: >>> On 12/3/15 1:09 AM, Stefan Karlsson wrote: >>>> Hi Ioi, >>>> >>>> Thanks a lot for fixing this! >>>> >>>> Would you mind swapping these lines around?: >>>> >>>> #include "classfile/javaClasses.hpp" >>>> +#include "classfile/compactHashtable.inline.hpp" >>> >>> Thanks for noticing. I will fix that. >>>> Except for that nit, this looks good. >>>> >>>> As David says, we should get rid of the allocation.inline.hpp >>>> include as well, but I think we could defer that to a separate patch >>>> (if you want to). >>> >>> TL;DR -- this fix probably won't do much in terms of speeding up a >>> rebuild, but >>> may still be a good clean up ... >> >> My main concern is not about the compile times, but that we're >> spreading the include mess. >> >>> >>> >>> Read the following if you're bored ----v >>> >>> Actually, I am not quite familiar with the rules of when/if >>> *.inline.hpp can >>> be inlcluded by a "regular" hpp file.Is that documented somewhere? >> >> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >> >>> >>> My guess is this happened when Stefan reported the bug: >>> >>> + precompiled header is used >> >> I compile without precompiled headers. >> >>> >>> + oop.inline.hpp was (indirectly) included into precompiled.hpp.gch.d >>> - this was actually not caused by compactHashtable.hpp(this file >>> is not >>> included by precompiled.hpp) >>> You can verified this from auto-generated files such as >>> hotspot/linux_amd64_compiler2/generated/dependencies/precompiled.hpp.gch.d >>> >>> - the culprit is src/share/vm/compiler/compilerDirectives.hpp, >>> which also >>> includes oop.inline.hpp,introduced in this changeset: >>> changeset: 9323:a176d4737606 >>> user: neliasso >>> 8137167: JEP165: Compiler Control: Implementation task >>> Summary: Compiler Control JEP >>> - the depedndency is precompiled.hpp -> ciEnv.hpp -> >>> compilerDirectives.hpp-> oop.inline.hpp >> >> :( >> >>> >>> + oop.inline.hpp itself includes many GC header files, so when Stefan >>> touches one of them, >>> everything is recompiled. >> >> Yes. >> >>> >>> So my interpretation is: >>> >>> + We should try to minimize the number of other header files included >>> in "regular" .hpp files >>> - Complex inline functions should be defined in .inline.hpp files. >> >> Yes. >> >>> + Avoid including .inline.hpp files in "regular" .hpp files, since >>> that may indirectly >>> include a large set of header files. >> >> Yes. >> >>> >>> Anyway, I don't think this can be easily adhered to, or easily >>> understood, or cared >>> about, by the developers. >> >> It's quite simple if you by default _don't_ put definitions in the >> header file. Put all implementation in the .cpp files, and if it's >> important to inline the functions, put the code in an .inline.hpp >> files. It's when code is put into .hpp that things start to become >> problematic. >> >> Granted, _simple_ getters and setters in header files don't pose a >> problem. >> >>> Moreover, there are actually a lot of various inline.hpp files >>> being included in .hpp files. >>> >>> hotspot/src/share$ find . -name \*inline.hpp -prune -o -name \*.hpp >>> -print | xargs grep inline.hpp | grep -v precompiled.hpp | wc >>> 60 189 4387 >> >> $ find . -name \*inline.hpp -prune -o -name \*.hpp -print | xargs grep >> inline.hpp | grep -v precompiled.hpp | grep "#include" | awk -F: '{ >> print $2}' | sort | uniq -c >> 5 #include "asm/macroAssembler.inline.hpp" >> 1 #include "assembler_zero.inline.hpp" >> 1 #include "bytes_linux_ppc.inline.hpp" >> 17 #include "memory/allocation.inline.hpp" >> 2 #include "memory/universe.inline.hpp" >> 2 #include "oops/oop.inline.hpp" >> 1 #include "os_windows.inline.hpp" // needed for sockaddr_in >> 1 #include "prims/jvmtiThreadState.inline.hpp" >> 6 #include "runtime/frame.inline.hpp" >> 6 #include "runtime/handles.inline.hpp" >> 1 #include "runtime/objectMonitor.inline.hpp" >> 2 #include "runtime/orderAccess.inline.hpp" >> 8 #include "runtime/thread.inline.hpp" >> 2 #include "utilities/bitMap.inline.hpp" >> 1 #include "utilities/hashtable.inline.hpp" >> >> >> There used to be loads more includes of oop.inline.hpp, but I removed >> them. >> >>> >>> So I think in an ideal world, we should have a tool that can >>> automatically >>> flags the "bad" includes. But, I am not sure how much time we want to >>> invest in that :-( >>> >>> In this particular case, after I removed oop.inline.hpp from >>> compilerDirectives.hpp >>> (it turned out to be an unnecessary include), only 7 include files >>> were removed from >>> precompiled.hpp.gch.d, so I am not sure it's a big win. >>> >>> But in terms of clean up, it's still a good idea to move big inline >>> function >>> definitions out of compactHashtable.hpp. >> >> Not that the size shouldn't be measured in number of lines, but what >> they depend on: >> >> 120 void add(unsigned int hash, Symbol* symbol) { >> 121 add(hash, new Entry(hash, symbol)); >> 122 } >> 123 >> 124 void add(unsigned int hash, oop string) { >> 125 add(hash, new Entry(hash, string)); >> 126 } >> >> >> Take these lines, for example, they force the include of >> allocation.inline.hpp in compactHashtable.cpp. Simply moving these >> definitions to the .cpp removes the need to include >> allocation.inline.hpp. >> >>> >>> >>> Also, I can see that allocation.inline.hpp is included by many .hpp >>> files, so >>> I guess it's OK for compactHashtable.hpp to do the same. If a clean >>> up is needed, >>> that would need to be done in a separate RFE. >>> >>> hotspot/src/share$ find . -name \*inline.hpp -prune -o -name \*.hpp >>> -print | xargs grep allocation.inline.hpp >>> ./vm/precompiled/precompiled.hpp:# include >>> "memory/allocation.inline.hpp" >>> ./vm/prims/jvmtiEventController.hpp:#include >>> "memory/allocation.inline.hpp" >>> ./vm/prims/jvmtiEnvThreadState.hpp:#include >>> "memory/allocation.inline.hpp" >>> ./vm/prims/jvmtiThreadState.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/oops/generateOopMap.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/compiler/compileTask.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/compiler/methodMatcher.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/classfile/compactHashtable.hpp:#include >>> "memory/allocation.inline.hpp" >>> ./vm/classfile/symbolTable.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/classfile/stringTable.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/utilities/growableArray.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/utilities/stack.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/utilities/array.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/gc/g1/g1Predictions.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/runtime/perfData.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/logging/log.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/libadt/dict.hpp:#include "memory/allocation.inline.hpp" >> >> It would be good to decrease that list, not add to it. Maybe >> allocation.inline.hpp needs to fixed, and parts moved to the .cpp file. >> >> I see that g1Predictions.hpp added allocation.inline.hpp. I recently >> went over the entire GC code base and got rid of _all_ includes of >> .inline.hpp files from .hpp files. >> >> Stefank >> >>> >>> >>> Thanks >>> - Ioi >>> >>> >>> >>>> Thanks, >>>> StefanK >>>> >>>> On 2015-12-03 03:32, Ioi Lam wrote: >>>>> Please review a very small fix: >>>>> >>>>> http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp/ >>>>> >>>>> Bug: compactHashtable.hpp includes oop.inline.hpp file >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8143615 >>>>> >>>>> Summary of fix: >>>>> >>>>> + deleted the include of oop.inline.hpp from compactHashtable.hpp >>>>> + moved all inlined functions that require oop.inline.hpp into a >>>>> new file, compactHashtable.inline.hpp >>>>> >>>>> Tests: >>>>> >>>>> JPRT >>>>> >>>>> Thanks >>>>> - Ioi >>>> >>> >> > From david.holmes at oracle.com Mon Dec 7 00:51:19 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2015 10:51:19 +1000 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <56630F95.4080908@cs.oswego.edu> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu> <56525823.6010506@cs.oswego.edu> <744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com> <56572F4E.8050603@oracle.com> <565F0698.7080600@cs.oswego.edu> <565FD8C8.6020105@oracle.com> <56630F95.4080908@cs.oswego.edu> Message-ID: <5664D807.9080600@oracle.com> On 6/12/2015 2:23 AM, Doug Lea wrote: > On 12/03/2015 12:53 AM, David Holmes wrote: >> On 3/12/2015 12:56 AM, Doug Lea wrote: >>> In the absence of any of: tail-recursion support, reliable cleanup, >>> or growable stacks, it seems reasonable to choose larger default >>> stack sizes so that these long but finite chains of completions >>> are far less likely to hit SOE. >>> >>> On 32bit systems the 1MB limit is completely defensible. But expanding >>> to say 64MB on 64bit systems would reduce practical encounters with >>> SOE in these kinds of constructions by a factor of 64 or so. >>> Is there any reason not to do this? >> >> The same discussion on the concurrency-interest mailing list seems to >> indicate >> that there are indeed reasons to not do this. >> >> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014596.html >> >> > > And all of them amount to arguments that it could interfere > with other configuration assumptions and practices. > Perhaps hotspot could at least support simpler ways that > fluent/functionally-flavored programs could override defaults > to start up with more friendly settings (as in "java -XX:+FP" ...) So some kind of guided ergonomics beyond that implied by server/client or raw machine parameters? Is there such a set that would be of general enough use to warrant something like -XX:+FP, or should these simply be set in a configuration file determined at deployment time? Thanks, David > > -Doug > > > > From david.holmes at oracle.com Mon Dec 7 01:08:09 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2015 11:08:09 +1000 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> Message-ID: <5664DBF9.7010708@oracle.com> On 5/12/2015 3:55 AM, Alexander Smundak wrote: > I am not convinced that increasing the complexity of the already quite > intricate build > machinery to avoid three additional checks in the source file is the > right trade-off. Does that mean you looked at how to achieve this? I think there is a more general issue that a ppc64le build is-a ppc64 build, so the latter should always be defined. David ----- > Sasha > > On Thu, Dec 3, 2015 at 11:59 PM, David Holmes wrote: >> On 4/12/2015 4:29 AM, Alexander Smundak wrote: >>> >>> On Wed, Dec 2, 2015 at 10:30 PM, David Holmes >>> wrote: >>>> >>>> agent code: >>>> >>>> I'm still unclear why you can't, or shouldn't, pass through -Dppc64 and >>>> -Dppc64le, such that you don't need to check for either being defined ?? >>> >>> You mean, add -Dppc64 to the compilation flags explicitly if the value >>> of the OPENJDK_TARGET_CPU_LEGACY is 'ppc64le'? >> >> >> Yes. Is that feasible? >> >> Thanks, >> David >> >>> Sasha >>> >> From stefan.karlsson at oracle.com Mon Dec 7 08:17:18 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 7 Dec 2015 09:17:18 +0100 Subject: RFR (XS) 8143615 compactHashtable.hpp includes oop.inline.hpp file In-Reply-To: <56621ADD.1040804@oracle.com> References: <565FA9BC.2080808@oracle.com> <566006B5.7010500@oracle.com> <56605534.7040308@oracle.com> <56615B87.40303@oracle.com> <56621ADD.1040804@oracle.com> Message-ID: <5665408E.5090305@oracle.com> On 2015-12-04 23:59, Ioi Lam wrote: > Hi Stefan, > > Thanks for the explanation. I have updated the webrev > > http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp.v2/ > > updates from the last version: > > [1] Move the two add functions identified by Stefan to > compactHashtable.inline.hpp > [2] Removed allocation.inline.hpp from compactHashtable.hpp > [3] Removed oop.inline.hpp from compilerDirectives.hpp Looks great! :) Thanks, StefanK > > Thanks > - Ioi > > On 12/4/15 1:23 AM, Stefan Karlsson wrote: >> On 2015-12-03 15:44, Ioi Lam wrote: >>> On 12/3/15 1:09 AM, Stefan Karlsson wrote: >>>> Hi Ioi, >>>> >>>> Thanks a lot for fixing this! >>>> >>>> Would you mind swapping these lines around?: >>>> >>>> #include "classfile/javaClasses.hpp" >>>> +#include "classfile/compactHashtable.inline.hpp" >>> >>> Thanks for noticing. I will fix that. >>>> Except for that nit, this looks good. >>>> >>>> As David says, we should get rid of the allocation.inline.hpp >>>> include as well, but I think we could defer that to a separate >>>> patch (if you want to). >>> >>> TL;DR -- this fix probably won't do much in terms of speeding up a >>> rebuild, but >>> may still be a good clean up ... >> >> My main concern is not about the compile times, but that we're >> spreading the include mess. >> >>> >>> >>> Read the following if you're bored ----v >>> >>> Actually, I am not quite familiar with the rules of when/if >>> *.inline.hpp can >>> be inlcluded by a "regular" hpp file.Is that documented somewhere? >> >> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >> >>> >>> My guess is this happened when Stefan reported the bug: >>> >>> + precompiled header is used >> >> I compile without precompiled headers. >> >>> >>> + oop.inline.hpp was (indirectly) included into precompiled.hpp.gch.d >>> - this was actually not caused by compactHashtable.hpp(this file >>> is not >>> included by precompiled.hpp) >>> You can verified this from auto-generated files such as >>> hotspot/linux_amd64_compiler2/generated/dependencies/precompiled.hpp.gch.d >>> >>> - the culprit is src/share/vm/compiler/compilerDirectives.hpp, >>> which also >>> includes oop.inline.hpp,introduced in this changeset: >>> changeset: 9323:a176d4737606 >>> user: neliasso >>> 8137167: JEP165: Compiler Control: Implementation task >>> Summary: Compiler Control JEP >>> - the depedndency is precompiled.hpp -> ciEnv.hpp -> >>> compilerDirectives.hpp-> oop.inline.hpp >> >> :( >> >>> >>> + oop.inline.hpp itself includes many GC header files, so when >>> Stefan touches one of them, >>> everything is recompiled. >> >> Yes. >> >>> >>> So my interpretation is: >>> >>> + We should try to minimize the number of other header files >>> included in "regular" .hpp files >>> - Complex inline functions should be defined in .inline.hpp files. >> >> Yes. >> >>> + Avoid including .inline.hpp files in "regular" .hpp files, since >>> that may indirectly >>> include a large set of header files. >> >> Yes. >> >>> >>> Anyway, I don't think this can be easily adhered to, or easily >>> understood, or cared >>> about, by the developers. >> >> It's quite simple if you by default _don't_ put definitions in the >> header file. Put all implementation in the .cpp files, and if it's >> important to inline the functions, put the code in an .inline.hpp >> files. It's when code is put into .hpp that things start to become >> problematic. >> >> Granted, _simple_ getters and setters in header files don't pose a >> problem. >> >>> Moreover, there are actually a lot of various inline.hpp files >>> being included in .hpp files. >>> >>> hotspot/src/share$ find . -name \*inline.hpp -prune -o -name \*.hpp >>> -print | xargs grep inline.hpp | grep -v precompiled.hpp | wc >>> 60 189 4387 >> >> $ find . -name \*inline.hpp -prune -o -name \*.hpp -print | xargs >> grep inline.hpp | grep -v precompiled.hpp | grep "#include" | awk >> -F: '{ print $2}' | sort | uniq -c >> 5 #include "asm/macroAssembler.inline.hpp" >> 1 #include "assembler_zero.inline.hpp" >> 1 #include "bytes_linux_ppc.inline.hpp" >> 17 #include "memory/allocation.inline.hpp" >> 2 #include "memory/universe.inline.hpp" >> 2 #include "oops/oop.inline.hpp" >> 1 #include "os_windows.inline.hpp" // needed for sockaddr_in >> 1 #include "prims/jvmtiThreadState.inline.hpp" >> 6 #include "runtime/frame.inline.hpp" >> 6 #include "runtime/handles.inline.hpp" >> 1 #include "runtime/objectMonitor.inline.hpp" >> 2 #include "runtime/orderAccess.inline.hpp" >> 8 #include "runtime/thread.inline.hpp" >> 2 #include "utilities/bitMap.inline.hpp" >> 1 #include "utilities/hashtable.inline.hpp" >> >> >> There used to be loads more includes of oop.inline.hpp, but I removed >> them. >> >>> >>> So I think in an ideal world, we should have a tool that can >>> automatically >>> flags the "bad" includes. But, I am not sure how much time we want >>> to invest in that :-( >>> >>> In this particular case, after I removed oop.inline.hpp from >>> compilerDirectives.hpp >>> (it turned out to be an unnecessary include), only 7 include files >>> were removed from >>> precompiled.hpp.gch.d, so I am not sure it's a big win. >>> >>> But in terms of clean up, it's still a good idea to move big inline >>> function >>> definitions out of compactHashtable.hpp. >> >> Not that the size shouldn't be measured in number of lines, but what >> they depend on: >> >> 120 void add(unsigned int hash, Symbol* symbol) { >> 121 add(hash, new Entry(hash, symbol)); >> 122 } >> 123 >> 124 void add(unsigned int hash, oop string) { >> 125 add(hash, new Entry(hash, string)); >> 126 } >> >> >> Take these lines, for example, they force the include of >> allocation.inline.hpp in compactHashtable.cpp. Simply moving these >> definitions to the .cpp removes the need to include >> allocation.inline.hpp. >> >>> >>> >>> Also, I can see that allocation.inline.hpp is included by many .hpp >>> files, so >>> I guess it's OK for compactHashtable.hpp to do the same. If a clean >>> up is needed, >>> that would need to be done in a separate RFE. >>> >>> hotspot/src/share$ find . -name \*inline.hpp -prune -o -name \*.hpp >>> -print | xargs grep allocation.inline.hpp >>> ./vm/precompiled/precompiled.hpp:# include >>> "memory/allocation.inline.hpp" >>> ./vm/prims/jvmtiEventController.hpp:#include >>> "memory/allocation.inline.hpp" >>> ./vm/prims/jvmtiEnvThreadState.hpp:#include >>> "memory/allocation.inline.hpp" >>> ./vm/prims/jvmtiThreadState.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/oops/generateOopMap.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/compiler/compileTask.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/compiler/methodMatcher.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/classfile/compactHashtable.hpp:#include >>> "memory/allocation.inline.hpp" >>> ./vm/classfile/symbolTable.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/classfile/stringTable.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/utilities/growableArray.hpp:#include >>> "memory/allocation.inline.hpp" >>> ./vm/utilities/stack.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/utilities/array.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/gc/g1/g1Predictions.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/runtime/perfData.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/logging/log.hpp:#include "memory/allocation.inline.hpp" >>> ./vm/libadt/dict.hpp:#include "memory/allocation.inline.hpp" >> >> It would be good to decrease that list, not add to it. Maybe >> allocation.inline.hpp needs to fixed, and parts moved to the .cpp file. >> >> I see that g1Predictions.hpp added allocation.inline.hpp. I recently >> went over the entire GC code base and got rid of _all_ includes of >> .inline.hpp files from .hpp files. >> >> Stefank >> >>> >>> >>> Thanks >>> - Ioi >>> >>> >>> >>>> Thanks, >>>> StefanK >>>> >>>> On 2015-12-03 03:32, Ioi Lam wrote: >>>>> Please review a very small fix: >>>>> >>>>> http://cr.openjdk.java.net/~iklam/8143615-compactHashtable-inline-hpp/ >>>>> >>>>> >>>>> Bug: compactHashtable.hpp includes oop.inline.hpp file >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8143615 >>>>> >>>>> Summary of fix: >>>>> >>>>> + deleted the include of oop.inline.hpp from compactHashtable.hpp >>>>> + moved all inlined functions that require oop.inline.hpp into a >>>>> new file, compactHashtable.inline.hpp >>>>> >>>>> Tests: >>>>> >>>>> JPRT >>>>> >>>>> Thanks >>>>> - Ioi >>>> >>> >> > From erik.joelsson at oracle.com Mon Dec 7 08:33:08 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Dec 2015 09:33:08 +0100 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <5661FEE5.2040108@oracle.com> References: <5661FEE5.2040108@oracle.com> Message-ID: <56654444.9050505@oracle.com> On 2015-12-04 22:00, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8144677 > http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ > > Tested with JPRT with: > ? "-testset hotspot" > ? "-testset svc" > ? "-testset chris" from the example custom testset provided in the CR. > ? no testset specified > > BTW, if anyone knows of an "include" mechanism for jprt.properties, > please let me know. Although that won't change the need for the above > changes, it would make it possible to put custom testsets in a file > rather than having to paste them in your ~/.jprt.properties file. > JPRT properties files are pretty special, but to my knowledge, there is no include mechanism. I don't think it would be hard to implement though. /Erik From goetz.lindenmaier at sap.com Mon Dec 7 09:35:50 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 7 Dec 2015 09:35:50 +0000 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <563B64EF.1000500@oracle.com> References: <563B64EF.1000500@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDADD3@DEWDFEMB12A.global.corp.sap> Hi Frederic, Coleen pointed me to your change, and I wanted to have a look at it. It seems to require some ppc adaptions. Unfortunately it does not apply to my hs-rt repository. Also, I can not find out the revision you built it against, as it is not a changeset patch, i.e., a webrev built from a submitted change. Could you please rebase the change to a more recent hs-rt repo? And please don't push it before at least the macros are defined in the globals_ppc.hpp file. And I really would like to check whether it at least builds. Thanks and best regards, Goetz. applying hotspot.patch patching file src/cpu/aarch64/vm/globals_aarch64.hpp Hunk #1 FAILED at 57 1 out of 1 hunks FAILED -- saving rejects to file src/cpu/aarch64/vm/globals_aarch64.hpp.rej patching file src/cpu/sparc/vm/stubGenerator_sparc.cpp Hunk #1 FAILED at 5322 1 out of 1 hunks FAILED -- saving rejects to file src/cpu/sparc/vm/stubGenerator_sparc.cpp.rej patching file src/cpu/x86/vm/macroAssembler_x86.hpp Hunk #1 FAILED at 0 1 out of 2 hunks FAILED -- saving rejects to file src/cpu/x86/vm/macroAssembler_x86.hpp.rej unable to find 'src/cpu/x86/vm/templateInterpreter_x86_32.cpp' for patching 1 out of 1 hunks FAILED -- saving rejects to file src/cpu/x86/vm/templateInterpreter_x86_32.cpp.rej unable to find 'src/cpu/x86/vm/templateInterpreter_x86_64.cpp' for patching 1 out of 1 hunks FAILED -- saving rejects to file src/cpu/x86/vm/templateInterpreter_x86_64.cpp.rej patching file src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java Hunk #1 FAILED at 0 Hunk #2 FAILED at 151 2 out of 2 hunks FAILED -- saving rejects to file src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java.rej patching file src/os/solaris/vm/os_solaris.hpp Hunk #1 FAILED at 0 1 out of 2 hunks FAILED -- saving rejects to file src/os/solaris/vm/os_solaris.hpp.rej patching file src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp Hunk #1 FAILED at 0 1 out of 4 hunks FAILED -- saving rejects to file src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp.rej patching file src/share/vm/c1/c1_Compilation.hpp Hunk #1 FAILED at 0 1 out of 3 hunks FAILED -- saving rejects to file src/share/vm/c1/c1_Compilation.hpp.rej patching file src/share/vm/classfile/classFileParser.cpp Hunk #1 FAILED at 1767 1 out of 2 hunks FAILED -- saving rejects to file src/share/vm/classfile/classFileParser.cpp.rej patching file src/share/vm/classfile/classFileParser.hpp Hunk #1 succeeded at 135 with fuzz 2 (offset 0 lines). patching file src/share/vm/classfile/vmSymbols.hpp Hunk #1 FAILED at 203 1 out of 1 hunks FAILED -- saving rejects to file src/share/vm/classfile/vmSymbols.hpp.rej patching file src/share/vm/opto/compile.cpp Hunk #1 succeeded at 674 with fuzz 2 (offset 1 lines). patching file src/share/vm/runtime/thread.inline.hpp Hunk #1 FAILED at 0 1 out of 3 hunks FAILED -- saving rejects to file src/share/vm/runtime/thread.inline.hpp.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh hotspot.patch > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Frederic Parain > Sent: Donnerstag, 5. November 2015 15:17 > To: hotspot-dev at openjdk.java.net > Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical > Sections > > Please review the changesets for JEP 270: Reserved Stack Areas for > Critical Sections > > CR: https://bugs.openjdk.java.net/browse/JDK-8046936 > > Webrevs: > hotspot: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/hotspot/ > JDK: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/jdk/ > > The CR contains a detailed description of the issue and the design > of the solution as well as implementation details. > > Tests: > > JPRT - hotspot & core > RBT - vm.quick > > Thanks > > Fred > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com From david.holmes at oracle.com Mon Dec 7 11:18:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2015 21:18:51 +1000 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <56654444.9050505@oracle.com> References: <5661FEE5.2040108@oracle.com> <56654444.9050505@oracle.com> Message-ID: <56656B1B.2020107@oracle.com> On 7/12/2015 6:33 PM, Erik Joelsson wrote: > > > On 2015-12-04 22:00, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8144677 >> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ >> >> Tested with JPRT with: >> ? "-testset hotspot" >> ? "-testset svc" >> ? "-testset chris" from the example custom testset provided in the CR. >> ? no testset specified >> >> BTW, if anyone knows of an "include" mechanism for jprt.properties, >> please let me know. Although that won't change the need for the above >> changes, it would make it possible to put custom testsets in a file >> rather than having to paste them in your ~/.jprt.properties file. >> > JPRT properties files are pretty special, but to my knowledge, there is > no include mechanism. I don't think it would be hard to implement though. They aren't really special they just use Properties.loadFromStream (or something like that). To do an include mechanism you'd have to implement all the reading and parsing logic yourself. David > /Erik > From erik.joelsson at oracle.com Mon Dec 7 11:39:25 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Dec 2015 12:39:25 +0100 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <56656B1B.2020107@oracle.com> References: <5661FEE5.2040108@oracle.com> <56654444.9050505@oracle.com> <56656B1B.2020107@oracle.com> Message-ID: <56656FED.5050105@oracle.com> On 2015-12-07 12:18, David Holmes wrote: > On 7/12/2015 6:33 PM, Erik Joelsson wrote: >> >> >> On 2015-12-04 22:00, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8144677 >>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ >>> >>> Tested with JPRT with: >>> ? "-testset hotspot" >>> ? "-testset svc" >>> ? "-testset chris" from the example custom testset provided in the >>> CR. >>> ? no testset specified >>> >>> BTW, if anyone knows of an "include" mechanism for jprt.properties, >>> please let me know. Although that won't change the need for the above >>> changes, it would make it possible to put custom testsets in a file >>> rather than having to paste them in your ~/.jprt.properties file. >>> >> JPRT properties files are pretty special, but to my knowledge, there is >> no include mechanism. I don't think it would be hard to implement >> though. > > They aren't really special they just use Properties.loadFromStream (or > something like that). To do an include mechanism you'd have to > implement all the reading and parsing logic yourself. > They are special in that there are a lot of constructs not normal to properties, like ${foo} expansion, weird conditionals and expanding variants {foo|bar}. None of these are order dependent however, meaning, it doesn't matter which order you put the properties in. The evaluation of all those things happens when a property is read, not when it is parsed. So the only reasonable implementation of include, at least as I see it, would be to read a file like now, check a special "include-file" property for new values and if so, read that file too. /Erik > David > > >> /Erik >> From jon.masamitsu at oracle.com Mon Dec 7 16:56:56 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 7 Dec 2015 08:56:56 -0800 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <56626EC7.4050202@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> <56626EC7.4050202@oracle.com> Message-ID: <5665BA58.3050606@oracle.com> David, On 12/04/2015 08:57 PM, David Holmes wrote: > Hi Jon, > > On 5/12/2015 2:39 AM, Jon Masamitsu wrote: >> Here's a new version of the fix (simpler thanks to a suggestion >> from Kim). >> >> http://cr.openjdk.java.net/~jmasa/8133023/webrev.05/ > > Yes this seems quite neat. It is a pity about > yet-another-VM_Version-init-function but ... > > Only minor comment is that in VM_Version::vm_init_before_ergo the "vm" > part is somewhat unnecessary and doesn't fit with the existing: > initialize() and early_initialize(). How about just > initialize_before_ergo()? I dropped the "vm_" from the name. > > Also we now really need a comment explaining when the plain > initialize() function is used. Is this along the lines of what you had in mind? // Called as part of the runtime services initialization // called from the management module initialization. Examines // a variety of the hardware capabilities of the platform // to determine which features can be used to execute the // program. static void initialize(); Jon > > Thanks, > David > ----- > >> In the above webrev vm_version_x86.hpp appears but has no changes. >> There were changes to it in the previous version (04) but were undone in >> this latest version and may be why it appears in the webrev. >> >> The delta webrev is >> >> http://cr.openjdk.java.net/~jmasa/8133023/delta.05/ >> >> It has a white-space change in vm_version_sparc.hpp which >> does not appear in the diffs. >> >> Thanks. >> >> Jon >> >> >> On 12/2/2015 9:46 AM, Jon Masamitsu wrote: >>> >>> >>> On 11/30/2015 11:47 AM, Kim Barrett wrote: >>>> On Nov 30, 2015, at 12:20 PM, Jon Masamitsu >>>> wrote: >>>>>> src/share/vm/runtime/os.cpp >>>>>> 319 VM_Version::vm_init_before_ergo(); >>>>>> >>>>>> This call is in generic code, but only two definitions have been >>>>>> provided, for sparc and x86. Missing are aarch64, ppc, and zero. >>>>>> >>>>> Add vm_init_before_ergo() for those even though JPRT does not >>>>> build them? I don't need to be convinced to do it. Just >>>>> encouraged. Say "do it" and I'll do it. >>>> I think you should do it, rather than knowingly breaking the build >>>> for those targets when the needed code is so trivial. >>>> >>> >>> Here's the webrev for the delta for review comments to this point. >>> >>> http://cr.openjdk.java.net/~jmasa/8133023/delta.04/ >>> >>> Webrev for complete patch is here. >>> >>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.04/ >>> >>> Jon >> From mark.reinhold at oracle.com Mon Dec 7 17:34:40 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 07 Dec 2015 09:34:40 -0800 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com>, <561428BC.3060806@cs.oswego.edu>, <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com>, <56164C3C.4050800@cs.oswego.edu>, <561E6F04.9030708@cs.oswego.edu>, <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com>, <561FC6F9.1080701@cs.oswego.edu>, <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com>, <562BC968.70603@cs.oswego.edu>, <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com>, <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> Message-ID: <20151207093440.607909@eggemoggin.niobe.net> 2015/11/30 6:58 -0800, gil at azul.com: > Update: After some significant back-and-forth between Doug and I on > naming and JavaDoc'ing, and with Martin (Thompson) stepping in to > help, we have what we think is a good spec and name selection for this > thing. We're proposing to add a new static method to the Runtime > class: > > class Runtime { /... > /** > * Method signifying that the caller is momentarily unable to > * progress until the occurrence of one or more actions of one or > * more other activities. When invoked within each iteration, this > * method typically improves performance of spin wait loop > * constructions. > */ > public static void onSpinWait() {}; > } I'm glad to see some agreement here, but I'm puzzled by the proposal to to place this in the Runtime class. What's the reasoning for that? Wouldn't this more naturally be placed in java.lang.Thread? Also, I don't think this single method needs a JEP, but you're welcome to do it that way if you really want to. - Mark From ioi.lam at oracle.com Mon Dec 7 18:18:42 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 07 Dec 2015 10:18:42 -0800 Subject: RFR (XS) 8144853: Print the names of callees in PrintAssembly/PrintInterprete Message-ID: <5665CD82.4070909@oracle.com> Please review a very small fix: http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names/ Bug: Print the names of callees in PrintAssembly/PrintInterprete https://bugs.openjdk.java.net/browse/JDK-8144853 Summary of fix: In -XX:+PrintAssembly and -XX:+PrintInterpreter, sometimes only the address of a callee is printed, and the name is missing. The fix is to use os::dll_address_to_function_name() to find the names of such functions and print them out if possible. EXAMPLES: -XX:+PrintInterpreter: 0x00007f1b018447c3: callq 0x00007f1b19b9bba0 = InterpreterRuntime::newarray(JavaThread*, BasicType, int) -XX:+PrintAssembly <....> 0x00007f75d87b9629: xchg %ax,%ax 0x00007f75d87b962b: callq 0x00007f75d0c11b60 ; ImmutableOopMap{rbp=Oop } ;*iflt {reexecute=1 rethrow=0 return_oop=0} ; - java.lang.StringLatin1::charAt at 1 (line 43) ; {runtime_call UncommonTrapBlob} 0x00007f75d87b9630: callq 0x00007f75e8e41370 = os::breakpoint() ;*iflt {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.StringLatin1::charAt at 1 (line 43) ; {runtime_call} TESTS: RBT hotspot/test/:hotspot_all (this includes tests cases with -XX:+PrintAssembly) Thanks - Ioi From vladimir.x.ivanov at oracle.com Mon Dec 7 18:58:51 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 7 Dec 2015 21:58:51 +0300 Subject: RFR (XS) 8144853: Print the names of callees in PrintAssembly/PrintInterprete In-Reply-To: <5665CD82.4070909@oracle.com> References: <5665CD82.4070909@oracle.com> Message-ID: <5665D6EB.1030207@oracle.com> Ioi, Nice improvement! Why don't you print "{runtime_call os::breakpoint()}" for -XX:+PrintAssemble instead? It looks more natural w.r.t. current format. Best regards, Vladimir Ivanov On 12/7/15 9:18 PM, Ioi Lam wrote: > Please review a very small fix: > > http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names/ > > > Bug: Print the names of callees in PrintAssembly/PrintInterprete > > https://bugs.openjdk.java.net/browse/JDK-8144853 > > Summary of fix: > > In -XX:+PrintAssembly and -XX:+PrintInterpreter, sometimes only > the address of a callee is printed, and the name is missing. > > The fix is to use os::dll_address_to_function_name() to find the > names of such functions and print them out if possible. > > EXAMPLES: > -XX:+PrintInterpreter: > 0x00007f1b018447c3: callq 0x00007f1b19b9bba0 = > InterpreterRuntime::newarray(JavaThread*, BasicType, int) > > -XX:+PrintAssembly > <....> > 0x00007f75d87b9629: xchg %ax,%ax > 0x00007f75d87b962b: callq 0x00007f75d0c11b60 ; > ImmutableOopMap{rbp=Oop } > ;*iflt {reexecute=1 > rethrow=0 return_oop=0} > ; - > java.lang.StringLatin1::charAt at 1 (line 43) > ; {runtime_call > UncommonTrapBlob} > 0x00007f75d87b9630: callq 0x00007f75e8e41370 = os::breakpoint() > ;*iflt {reexecute=0 > rethrow=0 return_oop=0} > ; - > java.lang.StringLatin1::charAt at 1 (line 43) > ; {runtime_call} > > > TESTS: > RBT hotspot/test/:hotspot_all (this includes tests cases with > -XX:+PrintAssembly) > > Thanks > - Ioi From ioi.lam at oracle.com Mon Dec 7 19:32:39 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 07 Dec 2015 11:32:39 -0800 Subject: RFR (XS) 8144853: Print the names of callees in PrintAssembly/PrintInterprete In-Reply-To: <5665D6EB.1030207@oracle.com> References: <5665CD82.4070909@oracle.com> <5665D6EB.1030207@oracle.com> Message-ID: <5665DED7.3000204@oracle.com> Hi Vladimir, Thanks for the suggestion. I've changed the patch to handle the nmethods differently than PrintInterpreter: http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names.v2/ The nmethod dump now looks like this: 0x00007f607940c657: callq 0x00007f607186bb60 ; ImmutableOopMap{[0]=Oop } ;*ifeq {reexecute=1 rethrow=0 return_oop=0} ; - java.lang.String::charAt at 4 (line 685) ; {runtime_call UncommonTrapBlob} 0x00007f607940c65c: callq 0x00007f608b05eb00 ;*ifeq {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.String::charAt at 4 (line 685) ; {runtime_call os::breakpoint()} Thanks - Ioi On 12/7/15 10:58 AM, Vladimir Ivanov wrote: > Ioi, > > Nice improvement! > > Why don't you print "{runtime_call os::breakpoint()}" for > -XX:+PrintAssemble instead? It looks more natural w.r.t. current format. > > Best regards, > Vladimir Ivanov > > On 12/7/15 9:18 PM, Ioi Lam wrote: >> Please review a very small fix: >> >> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names/ >> >> >> >> Bug: Print the names of callees in PrintAssembly/PrintInterprete >> >> https://bugs.openjdk.java.net/browse/JDK-8144853 >> >> Summary of fix: >> >> In -XX:+PrintAssembly and -XX:+PrintInterpreter, sometimes only >> the address of a callee is printed, and the name is missing. >> >> The fix is to use os::dll_address_to_function_name() to find the >> names of such functions and print them out if possible. >> >> EXAMPLES: >> -XX:+PrintInterpreter: >> 0x00007f1b018447c3: callq 0x00007f1b19b9bba0 = >> InterpreterRuntime::newarray(JavaThread*, BasicType, int) >> >> -XX:+PrintAssembly >> <....> >> 0x00007f75d87b9629: xchg %ax,%ax >> 0x00007f75d87b962b: callq 0x00007f75d0c11b60 ; >> ImmutableOopMap{rbp=Oop } >> ;*iflt {reexecute=1 >> rethrow=0 return_oop=0} >> ; - >> java.lang.StringLatin1::charAt at 1 (line 43) >> ; {runtime_call >> UncommonTrapBlob} >> 0x00007f75d87b9630: callq 0x00007f75e8e41370 = os::breakpoint() >> ;*iflt {reexecute=0 >> rethrow=0 return_oop=0} >> ; - >> java.lang.StringLatin1::charAt at 1 (line 43) >> ; {runtime_call} >> >> >> TESTS: >> RBT hotspot/test/:hotspot_all (this includes tests cases with >> -XX:+PrintAssembly) >> >> Thanks >> - Ioi From vladimir.x.ivanov at oracle.com Mon Dec 7 20:32:14 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 7 Dec 2015 23:32:14 +0300 Subject: RFR (XS) 8144853: Print the names of callees in PrintAssembly/PrintInterprete In-Reply-To: <5665DED7.3000204@oracle.com> References: <5665CD82.4070909@oracle.com> <5665D6EB.1030207@oracle.com> <5665DED7.3000204@oracle.com> Message-ID: <5665ECCE.2010003@oracle.com> Looks good. Best regards, Vladimir Ivanov On 12/7/15 10:32 PM, Ioi Lam wrote: > Hi Vladimir, > > Thanks for the suggestion. I've changed the patch to handle the nmethods > differently than PrintInterpreter: > > http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names.v2/ > > > The nmethod dump now looks like this: > > 0x00007f607940c657: callq 0x00007f607186bb60 ; > ImmutableOopMap{[0]=Oop } > ;*ifeq {reexecute=1 > rethrow=0 return_oop=0} > ; - > java.lang.String::charAt at 4 (line 685) > ; {runtime_call > UncommonTrapBlob} > 0x00007f607940c65c: callq 0x00007f608b05eb00 ;*ifeq {reexecute=0 > rethrow=0 return_oop=0} > ; - > java.lang.String::charAt at 4 (line 685) > ; {runtime_call > os::breakpoint()} > > > Thanks > - Ioi > > > On 12/7/15 10:58 AM, Vladimir Ivanov wrote: >> Ioi, >> >> Nice improvement! >> >> Why don't you print "{runtime_call os::breakpoint()}" for >> -XX:+PrintAssemble instead? It looks more natural w.r.t. current format. >> >> Best regards, >> Vladimir Ivanov >> >> On 12/7/15 9:18 PM, Ioi Lam wrote: >>> Please review a very small fix: >>> >>> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names/ >>> >>> >>> >>> Bug: Print the names of callees in PrintAssembly/PrintInterprete >>> >>> https://bugs.openjdk.java.net/browse/JDK-8144853 >>> >>> Summary of fix: >>> >>> In -XX:+PrintAssembly and -XX:+PrintInterpreter, sometimes only >>> the address of a callee is printed, and the name is missing. >>> >>> The fix is to use os::dll_address_to_function_name() to find the >>> names of such functions and print them out if possible. >>> >>> EXAMPLES: >>> -XX:+PrintInterpreter: >>> 0x00007f1b018447c3: callq 0x00007f1b19b9bba0 = >>> InterpreterRuntime::newarray(JavaThread*, BasicType, int) >>> >>> -XX:+PrintAssembly >>> <....> >>> 0x00007f75d87b9629: xchg %ax,%ax >>> 0x00007f75d87b962b: callq 0x00007f75d0c11b60 ; >>> ImmutableOopMap{rbp=Oop } >>> ;*iflt {reexecute=1 >>> rethrow=0 return_oop=0} >>> ; - >>> java.lang.StringLatin1::charAt at 1 (line 43) >>> ; {runtime_call >>> UncommonTrapBlob} >>> 0x00007f75d87b9630: callq 0x00007f75e8e41370 = os::breakpoint() >>> ;*iflt {reexecute=0 >>> rethrow=0 return_oop=0} >>> ; - >>> java.lang.StringLatin1::charAt at 1 (line 43) >>> ; {runtime_call} >>> >>> >>> TESTS: >>> RBT hotspot/test/:hotspot_all (this includes tests cases with >>> -XX:+PrintAssembly) >>> >>> Thanks >>> - Ioi > From chris.plummer at oracle.com Mon Dec 7 22:27:35 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 7 Dec 2015 14:27:35 -0800 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <5664CA4A.1090704@oracle.com> References: <5661FEE5.2040108@oracle.com> <5664CA4A.1090704@oracle.com> Message-ID: <566607D7.40909@oracle.com> Thanks David! Can I get a second reviewer please? thanks, Chris On 12/6/15 3:52 PM, David Holmes wrote: > Hi Chris, > > On 5/12/2015 7:00 AM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8144677 >> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ >> >> Tested with JPRT with: >> ? "-testset hotspot" >> ? "-testset svc" >> ? "-testset chris" from the example custom testset provided in the >> CR. >> ? no testset specified > > Looks good! > >> BTW, if anyone knows of an "include" mechanism for jprt.properties, > > Properties files do not have an include mechanism. See: > > http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader- > > > Thanks, > David > >> please let me know. Although that won't change the need for the above >> changes, it would make it possible to put custom testsets in a file >> rather than having to paste them in your ~/.jprt.properties file. >> >> thanks, >> >> Chris >> >> From mikael.vidstedt at oracle.com Mon Dec 7 23:22:24 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 7 Dec 2015 15:22:24 -0800 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <566607D7.40909@oracle.com> References: <5661FEE5.2040108@oracle.com> <5664CA4A.1090704@oracle.com> <566607D7.40909@oracle.com> Message-ID: <566614B0.8020809@oracle.com> Thumbs up! Cheers, Mikael On 2015-12-07 14:27, Chris Plummer wrote: > Thanks David! > > Can I get a second reviewer please? > > thanks, > > Chris > > On 12/6/15 3:52 PM, David Holmes wrote: >> Hi Chris, >> >> On 5/12/2015 7:00 AM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8144677 >>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ >>> >>> Tested with JPRT with: >>> ? "-testset hotspot" >>> ? "-testset svc" >>> ? "-testset chris" from the example custom testset provided in >>> the CR. >>> ? no testset specified >> >> Looks good! >> >>> BTW, if anyone knows of an "include" mechanism for jprt.properties, >> >> Properties files do not have an include mechanism. See: >> >> http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader- >> >> >> Thanks, >> David >> >>> please let me know. Although that won't change the need for the above >>> changes, it would make it possible to put custom testsets in a file >>> rather than having to paste them in your ~/.jprt.properties file. >>> >>> thanks, >>> >>> Chris >>> >>> > > From chris.plummer at oracle.com Tue Dec 8 01:06:34 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 7 Dec 2015 17:06:34 -0800 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <566614B0.8020809@oracle.com> References: <5661FEE5.2040108@oracle.com> <5664CA4A.1090704@oracle.com> <566607D7.40909@oracle.com> <566614B0.8020809@oracle.com> Message-ID: <56662D1A.7060205@oracle.com> Thanks Mikael! Chris On 12/7/15 3:22 PM, Mikael Vidstedt wrote: > > Thumbs up! > > Cheers, > Mikael > > On 2015-12-07 14:27, Chris Plummer wrote: >> Thanks David! >> >> Can I get a second reviewer please? >> >> thanks, >> >> Chris >> >> On 12/6/15 3:52 PM, David Holmes wrote: >>> Hi Chris, >>> >>> On 5/12/2015 7:00 AM, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8144677 >>>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ >>>> >>>> Tested with JPRT with: >>>> ? "-testset hotspot" >>>> ? "-testset svc" >>>> ? "-testset chris" from the example custom testset provided in >>>> the CR. >>>> ? no testset specified >>> >>> Looks good! >>> >>>> BTW, if anyone knows of an "include" mechanism for jprt.properties, >>> >>> Properties files do not have an include mechanism. See: >>> >>> http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader- >>> >>> >>> Thanks, >>> David >>> >>>> please let me know. Although that won't change the need for the above >>>> changes, it would make it possible to put custom testsets in a file >>>> rather than having to paste them in your ~/.jprt.properties file. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >> >> > From asmundak at google.com Tue Dec 8 03:44:55 2015 From: asmundak at google.com (Alexander Smundak) Date: Mon, 7 Dec 2015 19:44:55 -0800 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <5664DBF9.7010708@oracle.com> References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> <5664DBF9.7010708@oracle.com> Message-ID: It is achievable by adding a small ppc-specific check to the common/autoconf/platform.m4: @@ -282,6 +282,8 @@ elif test "x$OPENJDK_TARGET_OS" != xmacosx && test "x$OPENJDK_TARGET_CPU" = xx86_64; then # On all platforms except MacOSX replace x86_64 with amd64. OPENJDK_TARGET_CPU_LEGACY="amd64" + elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then + OPENJDK_TARGET_CPU_LEGACY="ppc64" fi AC_SUBST(OPENJDK_TARGET_CPU_LEGACY) However, there is a code in make/Images.gmk using OPENJDK_TARGET_CPU_LEGACY $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)") so that the 'release' file in the image directory will now have JAVA_VERSION="9" JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt" OS_NAME="Linux" OS_VERSION="2.6" OS_ARCH="ppc64" ^^^^^^^^ SOURCE=.., instead of "ppc64le". If someone can tell me which other variable I should use to achieve that without changing the contents of the 'release' file on other platforms, I'll be grateful. From david.holmes at oracle.com Tue Dec 8 03:49:02 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 13:49:02 +1000 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <56656FED.5050105@oracle.com> References: <5661FEE5.2040108@oracle.com> <56654444.9050505@oracle.com> <56656B1B.2020107@oracle.com> <56656FED.5050105@oracle.com> Message-ID: <5666532E.1050205@oracle.com> On 7/12/2015 9:39 PM, Erik Joelsson wrote: > > > On 2015-12-07 12:18, David Holmes wrote: >> On 7/12/2015 6:33 PM, Erik Joelsson wrote: >>> >>> >>> On 2015-12-04 22:00, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8144677 >>>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ >>>> >>>> Tested with JPRT with: >>>> ? "-testset hotspot" >>>> ? "-testset svc" >>>> ? "-testset chris" from the example custom testset provided in the >>>> CR. >>>> ? no testset specified >>>> >>>> BTW, if anyone knows of an "include" mechanism for jprt.properties, >>>> please let me know. Although that won't change the need for the above >>>> changes, it would make it possible to put custom testsets in a file >>>> rather than having to paste them in your ~/.jprt.properties file. >>>> >>> JPRT properties files are pretty special, but to my knowledge, there is >>> no include mechanism. I don't think it would be hard to implement >>> though. >> >> They aren't really special they just use Properties.loadFromStream (or >> something like that). To do an include mechanism you'd have to >> implement all the reading and parsing logic yourself. >> > They are special in that there are a lot of constructs not normal to > properties, like ${foo} expansion, weird conditionals and expanding > variants {foo|bar}. Yes but that is what JPRT does after loading the properties. It then post processes them to do expansion etc. > None of these are order dependent however, meaning, > it doesn't matter which order you put the properties in. The evaluation > of all those things happens when a property is read, not when it is > parsed. So the only reasonable implementation of include, at least as I > see it, would be to read a file like now, check a special "include-file" > property for new values and if so, read that file too. Yeah I guess that would work. Though there are some ordering issues as properties read from later files can override values read from earlier ones. In essence this would be a way to add another properties file to the set of files read (jprt distribution, repo, user). But if you want to do that its easier to just add a command-line arg to specify the additional file. Anyway this is going somewhat OT for Chris's change. If someone thinks allowing an additional custom properties file is useful then can file a RFE. Cheers, David > /Erik >> David >> >> >>> /Erik >>> > From david.holmes at oracle.com Tue Dec 8 04:46:42 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 14:46:42 +1000 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> <5664DBF9.7010708@oracle.com> Message-ID: <566660B2.4030100@oracle.com> On 8/12/2015 1:44 PM, Alexander Smundak wrote: > It is achievable by adding a small ppc-specific check to the > common/autoconf/platform.m4: > > @@ -282,6 +282,8 @@ > elif test "x$OPENJDK_TARGET_OS" != xmacosx && test > "x$OPENJDK_TARGET_CPU" = xx86_64; then > # On all platforms except MacOSX replace x86_64 with amd64. > OPENJDK_TARGET_CPU_LEGACY="amd64" > + elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then > + OPENJDK_TARGET_CPU_LEGACY="ppc64" > fi > AC_SUBST(OPENJDK_TARGET_CPU_LEGACY) > > However, there is a code in make/Images.gmk using OPENJDK_TARGET_CPU_LEGACY > $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)") > so that the 'release' file in the image directory will now have > JAVA_VERSION="9" > JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt" > OS_NAME="Linux" > OS_VERSION="2.6" > OS_ARCH="ppc64" > ^^^^^^^^ > SOURCE=.., > > instead of "ppc64le". > > If someone can tell me which other variable I should use to achieve > that without changing the contents of the 'release' file on other > platforms, I'll be grateful. Okay never mind - and thanks for looking into this. I see now this is set via: ./autoconf/flags.m4: COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY" so there is no way to add a second value without introducing some additional variable. At the hotspot level it could be handled differently if we had a platform_ppc64le file, as it could just be added to the SYSDEFS. Thanks, David From david.holmes at oracle.com Tue Dec 8 05:17:35 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 15:17:35 +1000 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <5665BA58.3050606@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> <56626EC7.4050202@oracle.com> <5665BA58.3050606@oracle.com> Message-ID: <566667EF.9080704@oracle.com> On 8/12/2015 2:56 AM, Jon Masamitsu wrote: > David, > > > On 12/04/2015 08:57 PM, David Holmes wrote: >> Hi Jon, >> >> On 5/12/2015 2:39 AM, Jon Masamitsu wrote: >>> Here's a new version of the fix (simpler thanks to a suggestion >>> from Kim). >>> >>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.05/ >> >> Yes this seems quite neat. It is a pity about >> yet-another-VM_Version-init-function but ... >> >> Only minor comment is that in VM_Version::vm_init_before_ergo the "vm" >> part is somewhat unnecessary and doesn't fit with the existing: >> initialize() and early_initialize(). How about just >> initialize_before_ergo()? > > I dropped the "vm_" from the name. > >> >> Also we now really need a comment explaining when the plain >> initialize() function is used. > > Is this along the lines of what you had in mind? > > // Called as part of the runtime services initialization > // called from the management module initialization. Examines > // a variety of the hardware capabilities of the platform > // to determine which features can be used to execute the > // program. > static void initialize(); I had to trace this myself to see where it is placed :) // Called via init_globals, after argument parsing and attaching // of the main thread has occurred Thanks, David > Jon > >> >> Thanks, >> David >> ----- >> >>> In the above webrev vm_version_x86.hpp appears but has no changes. >>> There were changes to it in the previous version (04) but were undone in >>> this latest version and may be why it appears in the webrev. >>> >>> The delta webrev is >>> >>> http://cr.openjdk.java.net/~jmasa/8133023/delta.05/ >>> >>> It has a white-space change in vm_version_sparc.hpp which >>> does not appear in the diffs. >>> >>> Thanks. >>> >>> Jon >>> >>> >>> On 12/2/2015 9:46 AM, Jon Masamitsu wrote: >>>> >>>> >>>> On 11/30/2015 11:47 AM, Kim Barrett wrote: >>>>> On Nov 30, 2015, at 12:20 PM, Jon Masamitsu >>>>> wrote: >>>>>>> src/share/vm/runtime/os.cpp >>>>>>> 319 VM_Version::vm_init_before_ergo(); >>>>>>> >>>>>>> This call is in generic code, but only two definitions have been >>>>>>> provided, for sparc and x86. Missing are aarch64, ppc, and zero. >>>>>>> >>>>>> Add vm_init_before_ergo() for those even though JPRT does not >>>>>> build them? I don't need to be convinced to do it. Just >>>>>> encouraged. Say "do it" and I'll do it. >>>>> I think you should do it, rather than knowingly breaking the build >>>>> for those targets when the needed code is so trivial. >>>>> >>>> >>>> Here's the webrev for the delta for review comments to this point. >>>> >>>> http://cr.openjdk.java.net/~jmasa/8133023/delta.04/ >>>> >>>> Webrev for complete patch is here. >>>> >>>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.04/ >>>> >>>> Jon >>> > From jamsheed.c.m at oracle.com Tue Dec 8 09:11:34 2015 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 8 Dec 2015 14:41:34 +0530 Subject: RFR: 6808665: Use486InstrsOnly aborts 32-bit VM Message-ID: <56669EC6.4000004@oracle.com> Hi All, Review request for the removal of command line option -XX:+/-Use486InstrsOnly. Bug Id: https://bugs.openjdk.java.net/browse/JDK-6808665 Webrev: http://cr.openjdk.java.net/~thartmann/6808665/webrev.00/ Summary: The code supporting -XX:+/-Use486InstrsOnly was removed. This option is obsolete, and not maintained in Hotspot. ACCCrequest has been finalized for this change (http://ccc.us.oracle.com/6808665 ). Tested with jprt, verified with java -XX:+/-Use486InstrsOnly -version. Best Regards, Jamsheed From david.holmes at oracle.com Tue Dec 8 09:31:44 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 19:31:44 +1000 Subject: RFR: 6808665: Use486InstrsOnly aborts 32-bit VM In-Reply-To: <56669EC6.4000004@oracle.com> References: <56669EC6.4000004@oracle.com> Message-ID: <5666A380.8010309@oracle.com> Looks good Jamsheed. Where do you plan to push this? You will need a sponsor. Thanks, David On 8/12/2015 7:11 PM, Jamsheed C m wrote: > Hi All, > > Review request for the removal of command line option > -XX:+/-Use486InstrsOnly. > > Bug Id: https://bugs.openjdk.java.net/browse/JDK-6808665 > Webrev: http://cr.openjdk.java.net/~thartmann/6808665/webrev.00/ > > Summary: The code supporting -XX:+/-Use486InstrsOnly was removed. This > option is obsolete, and not maintained in Hotspot. > ACCCrequest has been finalized for this change > (http://ccc.us.oracle.com/6808665 ). > > Tested with jprt, verified with java -XX:+/-Use486InstrsOnly -version. > > > Best Regards, > Jamsheed > > > > > > > From jamsheed.c.m at oracle.com Tue Dec 8 10:01:44 2015 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 8 Dec 2015 15:31:44 +0530 Subject: RFR: 6808665: Use486InstrsOnly aborts 32-bit VM In-Reply-To: <5666A380.8010309@oracle.com> References: <56669EC6.4000004@oracle.com> <5666A380.8010309@oracle.com> Message-ID: <5666AA88.2070406@oracle.com> On 12/8/2015 3:01 PM, David Holmes wrote: > Looks good Jamsheed. > > Where do you plan to push this? You will need a sponsor. Thanks for the review David. i am planning to push this fix in hs-comp . Yes i need a sponsor. Best Regards, Jamsheed > > Thanks, > David > > On 8/12/2015 7:11 PM, Jamsheed C m wrote: >> Hi All, >> >> Review request for the removal of command line option >> -XX:+/-Use486InstrsOnly. >> >> Bug Id: https://bugs.openjdk.java.net/browse/JDK-6808665 >> Webrev: http://cr.openjdk.java.net/~thartmann/6808665/webrev.00/ >> >> Summary: The code supporting -XX:+/-Use486InstrsOnly was removed. This >> option is obsolete, and not maintained in Hotspot. >> >> Tested with jprt, verified with java -XX:+/-Use486InstrsOnly -version. >> >> >> Best Regards, >> Jamsheed >> >> >> >> >> >> >> From tobias.hartmann at oracle.com Tue Dec 8 11:26:41 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 8 Dec 2015 12:26:41 +0100 Subject: RFR: 6808665: Use486InstrsOnly aborts 32-bit VM In-Reply-To: <56669EC6.4000004@oracle.com> References: <56669EC6.4000004@oracle.com> Message-ID: <5666BE71.7070708@oracle.com> Hi Jamsheed, looks good to me. I can sponsor your fix. Best, Tobias On 08.12.2015 10:11, Jamsheed C m wrote: > Hi All, > > Review request for the removal of command line option -XX:+/-Use486InstrsOnly. > > Bug Id: https://bugs.openjdk.java.net/browse/JDK-6808665 > Webrev: http://cr.openjdk.java.net/~thartmann/6808665/webrev.00/ > > Summary: The code supporting -XX:+/-Use486InstrsOnly was removed. This option is obsolete, and not maintained in Hotspot. > ACCCrequest has been finalized for this change (http://ccc.us.oracle.com/6808665 ). > > Tested with jprt, verified with java -XX:+/-Use486InstrsOnly -version. > > > Best Regards, > Jamsheed > > > > > > > From jamsheed.c.m at oracle.com Tue Dec 8 11:33:07 2015 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 8 Dec 2015 17:03:07 +0530 Subject: RFR: 6808665: Use486InstrsOnly aborts 32-bit VM In-Reply-To: <5666BE71.7070708@oracle.com> References: <56669EC6.4000004@oracle.com> <5666BE71.7070708@oracle.com> Message-ID: <5666BFF3.6060705@oracle.com> Thanks for the review and sponsoring Tobias. Best, Jamsheed On 12/8/2015 4:56 PM, Tobias Hartmann wrote: > Hi Jamsheed, > > looks good to me. I can sponsor your fix. > > Best, > Tobias > > On 08.12.2015 10:11, Jamsheed C m wrote: >> Hi All, >> >> Review request for the removal of command line option -XX:+/-Use486InstrsOnly. >> >> Bug Id: https://bugs.openjdk.java.net/browse/JDK-6808665 >> Webrev: http://cr.openjdk.java.net/~thartmann/6808665/webrev.00/ >> >> Summary: The code supporting -XX:+/-Use486InstrsOnly was removed. This option is obsolete, and not maintained in Hotspot. >> ACCCrequest has been finalized for this change (http://ccc.us.oracle.com/6808665 ). >> >> Tested with jprt, verified with java -XX:+/-Use486InstrsOnly -version. >> >> >> Best Regards, >> Jamsheed >> >> >> >> >> >> >> From vladimir.x.ivanov at oracle.com Tue Dec 8 11:33:32 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 8 Dec 2015 14:33:32 +0300 Subject: RFR: 6808665: Use486InstrsOnly aborts 32-bit VM In-Reply-To: <56669EC6.4000004@oracle.com> References: <56669EC6.4000004@oracle.com> Message-ID: <5666C00C.7080203@oracle.com> Looks good. Best regards, Vladimir Ivanov On 12/8/15 12:11 PM, Jamsheed C m wrote: > Hi All, > > Review request for the removal of command line option > -XX:+/-Use486InstrsOnly. > > Bug Id: https://bugs.openjdk.java.net/browse/JDK-6808665 > Webrev: http://cr.openjdk.java.net/~thartmann/6808665/webrev.00/ > > Summary: The code supporting -XX:+/-Use486InstrsOnly was removed. This > option is obsolete, and not maintained in Hotspot. > ACCCrequest has been finalized for this change > (http://ccc.us.oracle.com/6808665 ). > > Tested with jprt, verified with java -XX:+/-Use486InstrsOnly -version. > > > Best Regards, > Jamsheed > > > > > > > From jamsheed.c.m at oracle.com Tue Dec 8 12:32:28 2015 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 8 Dec 2015 18:02:28 +0530 Subject: RFR: 6808665: Use486InstrsOnly aborts 32-bit VM In-Reply-To: <5666C00C.7080203@oracle.com> References: <56669EC6.4000004@oracle.com> <5666C00C.7080203@oracle.com> Message-ID: <5666CDDC.2050000@oracle.com> Thanks for the review Vladimir Ivanov. Best, Jamsheed On 12/8/2015 5:03 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 12/8/15 12:11 PM, Jamsheed C m wrote: >> Hi All, >> >> Review request for the removal of command line option >> -XX:+/-Use486InstrsOnly. >> >> Bug Id: https://bugs.openjdk.java.net/browse/JDK-6808665 >> Webrev: http://cr.openjdk.java.net/~thartmann/6808665/webrev.00/ >> >> Summary: The code supporting -XX:+/-Use486InstrsOnly was removed. This >> option is obsolete, and not maintained in Hotspot. >> ACCCrequest has been finalized for this change >> (http://ccc.us.oracle.com/6808665 ). >> >> Tested with jprt, verified with java -XX:+/-Use486InstrsOnly -version. >> >> >> Best Regards, >> Jamsheed >> >> >> >> >> >> >> From manasthakur17 at gmail.com Tue Dec 8 13:04:53 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Tue, 8 Dec 2015 18:34:53 +0530 Subject: Using IdealGraphVisualizer In-Reply-To: <4ECC0213-8AD0-4E17-91E6-0F14ECE1258C@oracle.com> References: <4ECC0213-8AD0-4E17-91E6-0F14ECE1258C@oracle.com> Message-ID: Hi Christian, I had referred to that file earlier as well. May be its a very novice question, but I don?t understand what does it mean by ?the JVM expects that it will connect to a visualizer on the local host on port 4444?. Can you please explain me how to do that? Thanks and regards, Manas > On 06-Nov-2015, at 1:37 AM, Christian Thalinger wrote: > > >> On Oct 27, 2015, at 4:03 AM, Manas Thakur wrote: >> >> Hello all >> >> I want to use the IdealGraphVisualizer shipped with OpenJDK 8. Using ?-XX:PrintIdealGraphLevel=#? in the debug build simply dumps the graph on the screen; how should I use the tool to actually visualise the graph? > > src/share/tools/IdealGraphVisualizer/README > >> >> Regards, >> Manas > From erik.helin at oracle.com Tue Dec 8 15:36:17 2015 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 8 Dec 2015 16:36:17 +0100 Subject: RFR: 8144913: Add extension point to execute_internal_vm_tests Message-ID: <20151208153617.GA28216@ehelin.jrpg.bea.com> Hi all, this small patch adds an extension point to execute_internal_vm_tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8144913 Webrev: http://cr.openjdk.java.net/~ehelin/8144913/webrev.00/ Testing: - JPRT Thanks, Erik From jesper.wilhelmsson at oracle.com Tue Dec 8 16:06:12 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 8 Dec 2015 17:06:12 +0100 Subject: RFR: 8144913: Add extension point to execute_internal_vm_tests In-Reply-To: <20151208153617.GA28216@ehelin.jrpg.bea.com> References: <20151208153617.GA28216@ehelin.jrpg.bea.com> Message-ID: <5666FFF4.4040103@oracle.com> Looks good! /Jesper Den 8/12/15 kl. 16:36, skrev Erik Helin: > Hi all, > > this small patch adds an extension point to execute_internal_vm_tests. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8144913 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8144913/webrev.00/ > > Testing: > - JPRT > > Thanks, > Erik > From jon.masamitsu at oracle.com Tue Dec 8 17:17:50 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 8 Dec 2015 09:17:50 -0800 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <566667EF.9080704@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> <56626EC7.4050202@oracle.com> <5665BA58.3050606@oracle.com> <566667EF.9080704@oracle.com> Message-ID: <566710BE.6070207@oracle.com> On 12/7/2015 9:17 PM, David Holmes wrote: > On 8/12/2015 2:56 AM, Jon Masamitsu wrote: >> David, >> >> >> On 12/04/2015 08:57 PM, David Holmes wrote: >>> Hi Jon, >>> >>> On 5/12/2015 2:39 AM, Jon Masamitsu wrote: >>>> Here's a new version of the fix (simpler thanks to a suggestion >>>> from Kim). >>>> >>>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.05/ >>> >>> Yes this seems quite neat. It is a pity about >>> yet-another-VM_Version-init-function but ... >>> >>> Only minor comment is that in VM_Version::vm_init_before_ergo the "vm" >>> part is somewhat unnecessary and doesn't fit with the existing: >>> initialize() and early_initialize(). How about just >>> initialize_before_ergo()? >> >> I dropped the "vm_" from the name. >> >>> >>> Also we now really need a comment explaining when the plain >>> initialize() function is used. >> >> Is this along the lines of what you had in mind? >> >> // Called as part of the runtime services initialization >> // called from the management module initialization. Examines >> // a variety of the hardware capabilities of the platform >> // to determine which features can be used to execute the >> // program. >> static void initialize(); > > I had to trace this myself to see where it is placed :) > > // Called via init_globals, after argument parsing and attaching > // of the main thread has occurred I'll add that and send out another webrev later today. Jon > > Thanks, > David > >> Jon >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> In the above webrev vm_version_x86.hpp appears but has no changes. >>>> There were changes to it in the previous version (04) but were >>>> undone in >>>> this latest version and may be why it appears in the webrev. >>>> >>>> The delta webrev is >>>> >>>> http://cr.openjdk.java.net/~jmasa/8133023/delta.05/ >>>> >>>> It has a white-space change in vm_version_sparc.hpp which >>>> does not appear in the diffs. >>>> >>>> Thanks. >>>> >>>> Jon >>>> >>>> >>>> On 12/2/2015 9:46 AM, Jon Masamitsu wrote: >>>>> >>>>> >>>>> On 11/30/2015 11:47 AM, Kim Barrett wrote: >>>>>> On Nov 30, 2015, at 12:20 PM, Jon Masamitsu >>>>>> wrote: >>>>>>>> src/share/vm/runtime/os.cpp >>>>>>>> 319 VM_Version::vm_init_before_ergo(); >>>>>>>> >>>>>>>> This call is in generic code, but only two definitions have been >>>>>>>> provided, for sparc and x86. Missing are aarch64, ppc, and zero. >>>>>>>> >>>>>>> Add vm_init_before_ergo() for those even though JPRT does not >>>>>>> build them? I don't need to be convinced to do it. Just >>>>>>> encouraged. Say "do it" and I'll do it. >>>>>> I think you should do it, rather than knowingly breaking the build >>>>>> for those targets when the needed code is so trivial. >>>>>> >>>>> >>>>> Here's the webrev for the delta for review comments to this point. >>>>> >>>>> http://cr.openjdk.java.net/~jmasa/8133023/delta.04/ >>>>> >>>>> Webrev for complete patch is here. >>>>> >>>>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.04/ >>>>> >>>>> Jon >>>> >> From asmundak at google.com Tue Dec 8 17:44:18 2015 From: asmundak at google.com (Alexander Smundak) Date: Tue, 8 Dec 2015 09:44:18 -0800 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <566660B2.4030100@oracle.com> References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> <5664DBF9.7010708@oracle.com> <566660B2.4030100@oracle.com> Message-ID: Thank you for the review. If everyone involved is satisfied with the patch, I need a sponsor. Sasha On Mon, Dec 7, 2015 at 8:46 PM, David Holmes wrote: > On 8/12/2015 1:44 PM, Alexander Smundak wrote: >> >> It is achievable by adding a small ppc-specific check to the >> common/autoconf/platform.m4: >> >> @@ -282,6 +282,8 @@ >> elif test "x$OPENJDK_TARGET_OS" != xmacosx && test >> "x$OPENJDK_TARGET_CPU" = xx86_64; then >> # On all platforms except MacOSX replace x86_64 with amd64. >> OPENJDK_TARGET_CPU_LEGACY="amd64" >> + elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then >> + OPENJDK_TARGET_CPU_LEGACY="ppc64" >> fi >> AC_SUBST(OPENJDK_TARGET_CPU_LEGACY) >> >> However, there is a code in make/Images.gmk using >> OPENJDK_TARGET_CPU_LEGACY >> $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)") >> so that the 'release' file in the image directory will now have >> JAVA_VERSION="9" >> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt" >> OS_NAME="Linux" >> OS_VERSION="2.6" >> OS_ARCH="ppc64" >> ^^^^^^^^ >> SOURCE=.., >> >> instead of "ppc64le". >> >> If someone can tell me which other variable I should use to achieve >> that without changing the contents of the 'release' file on other >> platforms, I'll be grateful. > > > Okay never mind - and thanks for looking into this. I see now this is set > via: > > ./autoconf/flags.m4: COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK > -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY" > > so there is no way to add a second value without introducing some additional > variable. At the hotspot level it could be handled differently if we had a > platform_ppc64le file, as it could just be added to the SYSDEFS. > > Thanks, > David From jon.masamitsu at oracle.com Tue Dec 8 18:41:19 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 8 Dec 2015 10:41:19 -0800 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <566667EF.9080704@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> <56626EC7.4050202@oracle.com> <5665BA58.3050606@oracle.com> <566667EF.9080704@oracle.com> Message-ID: <5667244F.50101@oracle.com> Latest delta on the patch is at http://cr.openjdk.java.net/~jmasa/8133023/delta.06/ It contains a name change from the original patch vm_init_before_ergo() -> init_before_ergo() and some additional comments. Full patch is at http://cr.openjdk.java.net/~jmasa/8133023/webrev.06/ Thanks. Jon On 12/7/2015 9:17 PM, David Holmes wrote: > On 8/12/2015 2:56 AM, Jon Masamitsu wrote: >> David, >> >> >> On 12/04/2015 08:57 PM, David Holmes wrote: >>> Hi Jon, >>> >>> On 5/12/2015 2:39 AM, Jon Masamitsu wrote: >>>> Here's a new version of the fix (simpler thanks to a suggestion >>>> from Kim). >>>> >>>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.05/ >>> >>> Yes this seems quite neat. It is a pity about >>> yet-another-VM_Version-init-function but ... >>> >>> Only minor comment is that in VM_Version::vm_init_before_ergo the "vm" >>> part is somewhat unnecessary and doesn't fit with the existing: >>> initialize() and early_initialize(). How about just >>> initialize_before_ergo()? >> >> I dropped the "vm_" from the name. >> >>> >>> Also we now really need a comment explaining when the plain >>> initialize() function is used. >> >> Is this along the lines of what you had in mind? >> >> // Called as part of the runtime services initialization >> // called from the management module initialization. Examines >> // a variety of the hardware capabilities of the platform >> // to determine which features can be used to execute the >> // program. >> static void initialize(); > > I had to trace this myself to see where it is placed :) > > // Called via init_globals, after argument parsing and attaching > // of the main thread has occurred > > Thanks, > David > >> Jon >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> In the above webrev vm_version_x86.hpp appears but has no changes. >>>> There were changes to it in the previous version (04) but were >>>> undone in >>>> this latest version and may be why it appears in the webrev. >>>> >>>> The delta webrev is >>>> >>>> http://cr.openjdk.java.net/~jmasa/8133023/delta.05/ >>>> >>>> It has a white-space change in vm_version_sparc.hpp which >>>> does not appear in the diffs. >>>> >>>> Thanks. >>>> >>>> Jon >>>> >>>> >>>> On 12/2/2015 9:46 AM, Jon Masamitsu wrote: >>>>> >>>>> >>>>> On 11/30/2015 11:47 AM, Kim Barrett wrote: >>>>>> On Nov 30, 2015, at 12:20 PM, Jon Masamitsu >>>>>> wrote: >>>>>>>> src/share/vm/runtime/os.cpp >>>>>>>> 319 VM_Version::vm_init_before_ergo(); >>>>>>>> >>>>>>>> This call is in generic code, but only two definitions have been >>>>>>>> provided, for sparc and x86. Missing are aarch64, ppc, and zero. >>>>>>>> >>>>>>> Add vm_init_before_ergo() for those even though JPRT does not >>>>>>> build them? I don't need to be convinced to do it. Just >>>>>>> encouraged. Say "do it" and I'll do it. >>>>>> I think you should do it, rather than knowingly breaking the build >>>>>> for those targets when the needed code is so trivial. >>>>>> >>>>> >>>>> Here's the webrev for the delta for review comments to this point. >>>>> >>>>> http://cr.openjdk.java.net/~jmasa/8133023/delta.04/ >>>>> >>>>> Webrev for complete patch is here. >>>>> >>>>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.04/ >>>>> >>>>> Jon >>>> >> From kim.barrett at oracle.com Tue Dec 8 19:37:46 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Dec 2015 14:37:46 -0500 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <5667244F.50101@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> <56626EC7.4050202@oracle.com> <5665BA58.3050606@oracle.com> <566667EF.9080704@oracle.com> <5667244F.50101@oracle.com> Message-ID: <3BE9CFDA-A2D6-4D51-ADB5-20F85226F850@oracle.com> On Dec 8, 2015, at 1:41 PM, Jon Masamitsu wrote: > > Latest delta on the patch is at > > http://cr.openjdk.java.net/~jmasa/8133023/delta.06/ > > It contains a name change from the original patch > vm_init_before_ergo() -> init_before_ergo() and some > additional comments. > > Full patch is at > > http://cr.openjdk.java.net/~jmasa/8133023/webrev.06/ A couple minor things. I don't need another webrev for these. Looks good otherwise. ------------------------------------------------------------------------------ src/share/vm/runtime/vm_version.hpp 59 // Called as part of the runtime services initialization 60 // called from the management module initialization (via init_globals()) Need period at end of line 59, and line 60 should start capitalized. ------------------------------------------------------------------------------ src/share/vm/runtime/vm_version.hpp 72 static void early_initialize() { } 73 // Called to initialize VM variables needing initialization 74 // after command line parsing 75 static void init_before_ergo(void) {} Missing period at end of sentence. I'd prefer there be a blank line between lines 72 and 73. Maybe the description here should have a similar sentence to the preceding description for early_initialize, e.g. add Platforms that need to specialize this define VM_Version::init_before_ergo(). ------------------------------------------------------------------------------ From jon.masamitsu at oracle.com Tue Dec 8 21:12:21 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 8 Dec 2015 13:12:21 -0800 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <3BE9CFDA-A2D6-4D51-ADB5-20F85226F850@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> <56626EC7.4050202@oracle.com> <5665BA58.3050606@oracle.com> <566667EF.9080704@oracle.com> <5667244F.50101@oracle.com> <3BE9CFDA-A2D6-4D51-ADB5-20F85226F850@oracle.com> Message-ID: <566747B5.7030108@oracle.com> On 12/8/2015 11:37 AM, Kim Barrett wrote: > On Dec 8, 2015, at 1:41 PM, Jon Masamitsu wrote: >> Latest delta on the patch is at >> >> http://cr.openjdk.java.net/~jmasa/8133023/delta.06/ >> >> It contains a name change from the original patch >> vm_init_before_ergo() -> init_before_ergo() and some >> additional comments. >> >> Full patch is at >> >> http://cr.openjdk.java.net/~jmasa/8133023/webrev.06/ > A couple minor things. I don't need another webrev for these. Looks > good otherwise. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/vm_version.hpp > 59 // Called as part of the runtime services initialization > 60 // called from the management module initialization (via init_globals()) > > Need period at end of line 59, and line 60 should start capitalized. My intent was that it be a single sentence. I've added a "which is" to the end of the line to make it more clear. 59 // Called as part of the runtime services initialization which is 60 // called from the management module initialization (via init_globals()) > > ------------------------------------------------------------------------------ > src/share/vm/runtime/vm_version.hpp > 72 static void early_initialize() { } > 73 // Called to initialize VM variables needing initialization > 74 // after command line parsing > 75 static void init_before_ergo(void) {} > > Missing period at end of sentence. Fixed. > > I'd prefer there be a blank line between lines 72 and 73. > > Maybe the description here should have a similar sentence to the > preceding description for early_initialize, e.g. add > > Platforms that need to specialize this define VM_Version::init_before_ergo(). I added it. Thanks. Jon > > ------------------------------------------------------------------------------ > > From david.holmes at oracle.com Wed Dec 9 01:28:48 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Dec 2015 11:28:48 +1000 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <566747B5.7030108@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> <56626EC7.4050202@oracle.com> <5665BA58.3050606@oracle.com> <566667EF.9080704@oracle.com> <5667244F.50101@oracle.com> <3BE9CFDA-A2D6-4D51-ADB5-20F85226F850@oracle.com> <566747B5.7030108@oracle.com> Message-ID: <566783D0.4080205@oracle.com> On 9/12/2015 7:12 AM, Jon Masamitsu wrote: > > > On 12/8/2015 11:37 AM, Kim Barrett wrote: >> On Dec 8, 2015, at 1:41 PM, Jon Masamitsu >> wrote: >>> Latest delta on the patch is at >>> >>> http://cr.openjdk.java.net/~jmasa/8133023/delta.06/ >>> >>> It contains a name change from the original patch >>> vm_init_before_ergo() -> init_before_ergo() and some >>> additional comments. >>> >>> Full patch is at >>> >>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.06/ >> A couple minor things. I don't need another webrev for these. Looks >> good otherwise. >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/runtime/vm_version.hpp >> 59 // Called as part of the runtime services initialization >> 60 // called from the management module initialization (via >> init_globals()) >> >> Need period at end of line 59, and line 60 should start capitalized. > My intent was that it be a single sentence. I've added a "which is" to > the end of the > line to make it more clear. > > 59 // Called as part of the runtime services initialization which is > 60 // called from the management module initialization (via > init_globals()) That's why I suggested just saying "via init_globals" because the details are complex as it is either initialized from management, if management support is being built, else from runtime services. But ok. Thanks, David >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/runtime/vm_version.hpp >> 72 static void early_initialize() { } >> 73 // Called to initialize VM variables needing initialization >> 74 // after command line parsing >> 75 static void init_before_ergo(void) {} >> >> Missing period at end of sentence. > > Fixed. > >> >> I'd prefer there be a blank line between lines 72 and 73. >> >> Maybe the description here should have a similar sentence to the >> preceding description for early_initialize, e.g. add >> >> Platforms that need to specialize this define >> VM_Version::init_before_ergo(). > > I added it. > > Thanks. > > Jon > >> >> ------------------------------------------------------------------------------ >> >> >> > From david.holmes at oracle.com Wed Dec 9 03:10:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Dec 2015 13:10:23 +1000 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> <5664DBF9.7010708@oracle.com> <566660B2.4030100@oracle.com> Message-ID: <56679B9F.8030105@oracle.com> I can sponsor for you Sasha. Just email me the changeset, or a link thereto. Thanks, David On 9/12/2015 3:44 AM, Alexander Smundak wrote: > Thank you for the review. > If everyone involved is satisfied with the patch, I need a sponsor. > > Sasha > > On Mon, Dec 7, 2015 at 8:46 PM, David Holmes wrote: >> On 8/12/2015 1:44 PM, Alexander Smundak wrote: >>> >>> It is achievable by adding a small ppc-specific check to the >>> common/autoconf/platform.m4: >>> >>> @@ -282,6 +282,8 @@ >>> elif test "x$OPENJDK_TARGET_OS" != xmacosx && test >>> "x$OPENJDK_TARGET_CPU" = xx86_64; then >>> # On all platforms except MacOSX replace x86_64 with amd64. >>> OPENJDK_TARGET_CPU_LEGACY="amd64" >>> + elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then >>> + OPENJDK_TARGET_CPU_LEGACY="ppc64" >>> fi >>> AC_SUBST(OPENJDK_TARGET_CPU_LEGACY) >>> >>> However, there is a code in make/Images.gmk using >>> OPENJDK_TARGET_CPU_LEGACY >>> $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)") >>> so that the 'release' file in the image directory will now have >>> JAVA_VERSION="9" >>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt" >>> OS_NAME="Linux" >>> OS_VERSION="2.6" >>> OS_ARCH="ppc64" >>> ^^^^^^^^ >>> SOURCE=.., >>> >>> instead of "ppc64le". >>> >>> If someone can tell me which other variable I should use to achieve >>> that without changing the contents of the 'release' file on other >>> platforms, I'll be grateful. >> >> >> Okay never mind - and thanks for looking into this. I see now this is set >> via: >> >> ./autoconf/flags.m4: COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK >> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY" >> >> so there is no way to add a second value without introducing some additional >> variable. At the hotspot level it could be handled differently if we had a >> platform_ppc64le file, as it could just be added to the SYSDEFS. >> >> Thanks, >> David From david.holmes at oracle.com Wed Dec 9 04:47:08 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Dec 2015 14:47:08 +1000 Subject: RFR (XS) 8144853: Print the names of callees in PrintAssembly/PrintInterprete In-Reply-To: <5665DED7.3000204@oracle.com> References: <5665CD82.4070909@oracle.com> <5665D6EB.1030207@oracle.com> <5665DED7.3000204@oracle.com> Message-ID: <5667B24C.1070101@oracle.com> Hi Ioi, src/share/vm/code/nmethod.cpp Your use of the static buffer seems not thread-safe. Minor nit: 3057 bool found; 3058 found = os::dll_address_to_function_name(dest, buf, sizeof(buf), &offset); could be: 3057 bool found = os::dll_address_to_function_name(dest, buf, sizeof(buf), &offset); --- src/share/vm/compiler/disassembler.cpp Your use of the static buffer seems not thread-safe. 366 bool found; This variable seems unused. Typo: 369 // Don't do this for native methods, as the function name will be printed in 370 // by nmethod::reloc_string_for(). delete 'in' or 'by'. Thanks, David ----- On 8/12/2015 5:32 AM, Ioi Lam wrote: > Hi Vladimir, > > Thanks for the suggestion. I've changed the patch to handle the nmethods > differently than PrintInterpreter: > > http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names.v2/ > > > The nmethod dump now looks like this: > > 0x00007f607940c657: callq 0x00007f607186bb60 ; > ImmutableOopMap{[0]=Oop } > ;*ifeq {reexecute=1 > rethrow=0 return_oop=0} > ; - > java.lang.String::charAt at 4 (line 685) > ; {runtime_call > UncommonTrapBlob} > 0x00007f607940c65c: callq 0x00007f608b05eb00 ;*ifeq {reexecute=0 > rethrow=0 return_oop=0} > ; - > java.lang.String::charAt at 4 (line 685) > ; {runtime_call > os::breakpoint()} > > > Thanks > - Ioi > > > On 12/7/15 10:58 AM, Vladimir Ivanov wrote: >> Ioi, >> >> Nice improvement! >> >> Why don't you print "{runtime_call os::breakpoint()}" for >> -XX:+PrintAssemble instead? It looks more natural w.r.t. current format. >> >> Best regards, >> Vladimir Ivanov >> >> On 12/7/15 9:18 PM, Ioi Lam wrote: >>> Please review a very small fix: >>> >>> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names/ >>> >>> >>> >>> Bug: Print the names of callees in PrintAssembly/PrintInterprete >>> >>> https://bugs.openjdk.java.net/browse/JDK-8144853 >>> >>> Summary of fix: >>> >>> In -XX:+PrintAssembly and -XX:+PrintInterpreter, sometimes only >>> the address of a callee is printed, and the name is missing. >>> >>> The fix is to use os::dll_address_to_function_name() to find the >>> names of such functions and print them out if possible. >>> >>> EXAMPLES: >>> -XX:+PrintInterpreter: >>> 0x00007f1b018447c3: callq 0x00007f1b19b9bba0 = >>> InterpreterRuntime::newarray(JavaThread*, BasicType, int) >>> >>> -XX:+PrintAssembly >>> <....> >>> 0x00007f75d87b9629: xchg %ax,%ax >>> 0x00007f75d87b962b: callq 0x00007f75d0c11b60 ; >>> ImmutableOopMap{rbp=Oop } >>> ;*iflt {reexecute=1 >>> rethrow=0 return_oop=0} >>> ; - >>> java.lang.StringLatin1::charAt at 1 (line 43) >>> ; {runtime_call >>> UncommonTrapBlob} >>> 0x00007f75d87b9630: callq 0x00007f75e8e41370 = os::breakpoint() >>> ;*iflt {reexecute=0 >>> rethrow=0 return_oop=0} >>> ; - >>> java.lang.StringLatin1::charAt at 1 (line 43) >>> ; {runtime_call} >>> >>> >>> TESTS: >>> RBT hotspot/test/:hotspot_all (this includes tests cases with >>> -XX:+PrintAssembly) >>> >>> Thanks >>> - Ioi > From zoltan.majo at oracle.com Wed Dec 9 08:17:16 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 9 Dec 2015 09:17:16 +0100 Subject: [8u] Reguest for approval and review: 8129847: Compiling methods generated by Nashorn... Message-ID: <5667E38C.7090606@oracle.com> Hi, please approve and review the following backport to 8u. Original (9) bug: https://bugs.openjdk.java.net/browse/JDK-8129847 Original (9) webrev: http://cr.openjdk.java.net/~zmajo/8129847-9/webrev.06/ Changeset (9): http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/da497ea6c120 Unfortunately, the changeset does not apply cleanly to 8u. So here is the 8u webrev: http://cr.openjdk.java.net/~zmajo/8129847-8u/webrev.06/ Testing: - JPRT (testset hotspot), all tests pass; - Octane/Nashorn; - the patch for 9 passed a complete cycle of nightly testing without problems; - no performance regression (Octane/Nashorn, SPECjvm2008). Thank you and best regards, Zoltan From kim.barrett at oracle.com Wed Dec 9 08:24:34 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 9 Dec 2015 03:24:34 -0500 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <566747B5.7030108@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> <56626EC7.4050202@oracle.com> <5665BA58.3050606@oracle.com> <566667EF.9080704@oracle.com> <5667244F.50101@oracle.com> <3BE9CFDA-A2D6-4D51-ADB5-20F85226F850@oracle.com> <566747B5.7030108@oracle.com> Message-ID: On Dec 8, 2015, at 4:12 PM, Jon Masamitsu wrote: > > > > On 12/8/2015 11:37 AM, Kim Barrett wrote: >> On Dec 8, 2015, at 1:41 PM, Jon Masamitsu wrote: >>> Latest delta on the patch is at >>> >>> http://cr.openjdk.java.net/~jmasa/8133023/delta.06/ >>> >>> It contains a name change from the original patch >>> vm_init_before_ergo() -> init_before_ergo() and some >>> additional comments. >>> >>> Full patch is at >>> >>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.06/ >> A couple minor things. I don't need another webrev for these. Looks >> good otherwise. >> >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/vm_version.hpp >> 59 // Called as part of the runtime services initialization >> 60 // called from the management module initialization (via init_globals()) >> >> Need period at end of line 59, and line 60 should start capitalized. > My intent was that it be a single sentence. I've added a "which is" to the end of the > line to make it more clear. > > 59 // Called as part of the runtime services initialization which is > 60 // called from the management module initialization (via init_globals()) OK. > >> >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/vm_version.hpp >> 72 static void early_initialize() { } >> 73 // Called to initialize VM variables needing initialization >> 74 // after command line parsing >> 75 static void init_before_ergo(void) {} >> >> Missing period at end of sentence. > > Fixed. > >> >> I'd prefer there be a blank line between lines 72 and 73. >> >> Maybe the description here should have a similar sentence to the >> preceding description for early_initialize, e.g. add >> >> Platforms that need to specialize this define VM_Version::init_before_ergo(). > > I added it. > > Thanks. > > Jon > >> >> ------------------------------------------------------------------------------ From dmitry.dmitriev at oracle.com Wed Dec 9 08:38:01 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 9 Dec 2015 11:38:01 +0300 Subject: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework needs to handle VM error codes in some cases In-Reply-To: <56557442.2080408@oracle.com> References: <56557442.2080408@oracle.com> Message-ID: <5667E869.5070903@oracle.com> Hello, Please, can I get Review for that fix? Thank you! Dmitry On 25.11.2015 11:41, Dmitry Dmitriev wrote: > Hello, > > Please review this small enhancement to the command line options > validation test framework. This enhancement allow to specify allowed > exit code for flags. This is needed for CDS Shared flags, because in > some cases JVM can exit with error code 2 and this should not be > treated as error. Also, in this fix I refactor code which parse Shared > flags - specify explicit names of the flags in switch statement and > use only one CDS archive file. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8142874 > webrev: http://cr.openjdk.java.net/~ddmitriev/8142874/webrev.01/ > > Testing: tested on all platforms by RBT > > Thanks, > Dmitry From shafi.s.ahmad at oracle.com Wed Dec 9 08:43:35 2015 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 9 Dec 2015 00:43:35 -0800 (PST) Subject: RFR: JDK-8144464 : WB method to start G1 concurrent mark cycle should be introduced In-Reply-To: References: Message-ID: <32212a1d-dd5b-4ad4-839f-521b8b6001bf@default> Hi, Please, can I get review for that backport? Thank you! Regards, Shafi From: Shafi Ahmad Sent: Friday, December 04, 2015 11:40 AM To: hotspot-runtime-dev at openjdk.java.net Subject: RFR: JDK-8144464 : WB method to start G1 concurrent mark cycle should be introduced Hi, Please review the backport of bug: "JDK-8144464: WB method to start G1 concurrent mark cycle should be introduced" to jdk8u-dev Webrev: http://cr.openjdk.java.net/~poonam/8144464/webrev.00/ jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8065579 Backport bug: https://bugs.openjdk.java.net/browse/JDK-8144464 Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1c207cfc557b Test: Run jprt and relevant jtreg test. Regards, Shafi From sgehwolf at redhat.com Wed Dec 9 10:23:40 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 11:23:40 +0100 Subject: [JDK 9] hs-rt forest fails to build? Message-ID: <1449656620.3543.3.camel@redhat.com> Hi, I'm trying to build an OpenJDK 9, hs-rt tree which fails to build for me with: jdk/src/java.logging/share/classes/sun/util/logging/internal/LoggingProviderImpl.java:33: error: cannot find symbol import java.lang.System.LoggerFinder; ???????????????????????^ ? symbol:???class LoggerFinder ? location: class System $ hg paths default = http://hg.openjdk.java.net/jdk9/hs-rt/ Do I need to use a different tree these days? What am I missing? Thanks, Severin From mikael.gerdin at oracle.com Wed Dec 9 10:41:16 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 9 Dec 2015 11:41:16 +0100 Subject: [JDK 9] hs-rt forest fails to build? In-Reply-To: <1449656620.3543.3.camel@redhat.com> References: <1449656620.3543.3.camel@redhat.com> Message-ID: <5668054C.6030708@oracle.com> Hi Severin, On 2015-12-09 11:23, Severin Gehwolf wrote: > Hi, > > I'm trying to build an OpenJDK 9, hs-rt tree which fails to build for > me with: > > jdk/src/java.logging/share/classes/sun/util/logging/internal/LoggingProviderImpl.java:33: error: cannot find symbol > import java.lang.System.LoggerFinder; > ^ > symbol: class LoggerFinder > location: class System http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src/java.base/share/classes/java/lang/System.java#l1377 the LoggerFinder inner class appears to exist on the hg server at least. > > $ hg paths > default = http://hg.openjdk.java.net/jdk9/hs-rt/ > > Do I need to use a different tree these days? What am I missing? No, it should work. Are you sure you've updated all the sub-trees? http://hg.openjdk.java.net/code-tools/trees/ Is a helpful hg extension to keep track of things. I've noticed that sometimes "bash get_source.sh" does not correctly "hg update" the entire forest. /Mikael > > Thanks, > Severin > From thomas.schatzl at oracle.com Wed Dec 9 11:06:24 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 09 Dec 2015 12:06:24 +0100 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <5667244F.50101@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> <56626EC7.4050202@oracle.com> <5665BA58.3050606@oracle.com> <566667EF.9080704@oracle.com> <5667244F.50101@oracle.com> Message-ID: <1449659184.2195.8.camel@oracle.com> Hi, On Tue, 2015-12-08 at 10:41 -0800, Jon Masamitsu wrote: > Latest delta on the patch is at > > http://cr.openjdk.java.net/~jmasa/8133023/delta.06/ > > It contains a name change from the original patch > vm_init_before_ergo() -> init_before_ergo() and some > additional comments. > > Full patch is at > > http://cr.openjdk.java.net/~jmasa/8133023/webrev.06/ > http://cr.openjdk.java.net/~jmasa/8133023/webrev.06/src/share/vm/runtime/vm_version.hpp.frames.html 75 static void init_before_ergo(void) {} It's a bit odd to have an explicit void parameter list for this method. While it is completely legal, for uniformity I would like to prefer that removed. Other than that see the nits from Kim, which were already fixed. I do not need to see the change again. Thanks, Thomas From sgehwolf at redhat.com Wed Dec 9 11:15:38 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 12:15:38 +0100 Subject: [JDK 9] hs-rt forest fails to build? In-Reply-To: <5668054C.6030708@oracle.com> References: <1449656620.3543.3.camel@redhat.com> <5668054C.6030708@oracle.com> Message-ID: <1449659738.3543.28.camel@redhat.com> Hi Mikael, On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote: > Hi Severin, > > On 2015-12-09 11:23, Severin Gehwolf wrote: > > Hi, > > > > I'm trying to build an OpenJDK 9, hs-rt tree which fails to build for > > me with: > > > > jdk/src/java.logging/share/classes/sun/util/logging/internal/LoggingProviderImpl.java:33: error: cannot find symbol > > import java.lang.System.LoggerFinder; > > ????????????????????????^ > > ???symbol:???class LoggerFinder > > ???location: class System > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src/java.base/share/classes/java/lang/System.java#l1377 > the LoggerFinder inner class appears to exist on the hg server at least. I have it in the local copy too, yet I get: CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch' failed make/Main.gmk:150: recipe for target 'java.logging-java' failed With the above root-cause. I'll try with a fresh clone... > > > > $ hg paths > > default = http://hg.openjdk.java.net/jdk9/hs-rt/ > > > > Do I need to use a different tree these days? What am I missing? > > No, it should work. > Are you sure you've updated all the sub-trees? > > http://hg.openjdk.java.net/code-tools/trees/ > Is a helpful hg extension to keep track of things. > > I've noticed that sometimes "bash get_source.sh" does not correctly "hg? > update" the entire forest. I should have an updated tree, though I usually use: $ hg pull -u $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do pushd $i; hg pull -u; popd; done I've checked just now and all repos seem to have updated correctly. The CI builder for Zero seems to agree[1]. Note: The above build failure is for a regular server JVM. Not sure what's wrong. I keep looking, thanks! Cheers, Severin [1]?http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/191/console > /Mikael > > > > > Thanks, > > Severin > > > From david.holmes at oracle.com Wed Dec 9 11:23:31 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Dec 2015 21:23:31 +1000 Subject: [JDK 9] hs-rt forest fails to build? In-Reply-To: <1449656620.3543.3.camel@redhat.com> References: <1449656620.3543.3.camel@redhat.com> Message-ID: <56680F33.1040807@oracle.com> On 9/12/2015 8:23 PM, Severin Gehwolf wrote: > Hi, > > I'm trying to build an OpenJDK 9, hs-rt tree which fails to build for > me with: > > jdk/src/java.logging/share/classes/sun/util/logging/internal/LoggingProviderImpl.java:33: error: cannot find symbol > import java.lang.System.LoggerFinder; > ^ > symbol: class LoggerFinder > location: class System What boot JDK are you using? David ----- > $ hg paths > default = http://hg.openjdk.java.net/jdk9/hs-rt/ > > Do I need to use a different tree these days? What am I missing? > > Thanks, > Severin > From sgehwolf at redhat.com Wed Dec 9 11:26:43 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 12:26:43 +0100 Subject: [JDK 9] hs-rt forest fails to build? In-Reply-To: <56680F33.1040807@oracle.com> References: <1449656620.3543.3.camel@redhat.com> <56680F33.1040807@oracle.com> Message-ID: <1449660403.3543.33.camel@redhat.com> Hi David, On Wed, 2015-12-09 at 21:23 +1000, David Holmes wrote: > On 9/12/2015 8:23 PM, Severin Gehwolf wrote: > > Hi, > > > > I'm trying to build an OpenJDK 9, hs-rt tree which fails to build > > for > > me with: > > > > jdk/src/java.logging/share/classes/sun/util/logging/internal/Loggin > > gProviderImpl.java:33: error: cannot find symbol > > import java.lang.System.LoggerFinder; > > ????????????????????????^ > > ???symbol:???class LoggerFinder > > ???location: class System > > What boot JDK are you using? JDK 8 from stock Fedora 23: $ rpm -q java-1.8.0-openjdk java-1.8.0-openjdk-1.8.0.65-4.b17.fc23.x86_64 Thanks, Severin > David > ----- > > > > $ hg paths > > default = http://hg.openjdk.java.net/jdk9/hs-rt/ > > > > Do I need to use a different tree these days? What am I missing? > > > > Thanks, > > Severin > > From david.holmes at oracle.com Wed Dec 9 11:30:17 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Dec 2015 21:30:17 +1000 Subject: [JDK 9] hs-rt forest fails to build? In-Reply-To: <1449660403.3543.33.camel@redhat.com> References: <1449656620.3543.3.camel@redhat.com> <56680F33.1040807@oracle.com> <1449660403.3543.33.camel@redhat.com> Message-ID: <566810C9.2090003@oracle.com> On 9/12/2015 9:26 PM, Severin Gehwolf wrote: > Hi David, > > On Wed, 2015-12-09 at 21:23 +1000, David Holmes wrote: >> On 9/12/2015 8:23 PM, Severin Gehwolf wrote: >>> Hi, >>> >>> I'm trying to build an OpenJDK 9, hs-rt tree which fails to build >>> for >>> me with: >>> >>> jdk/src/java.logging/share/classes/sun/util/logging/internal/Loggin >>> gProviderImpl.java:33: error: cannot find symbol >>> import java.lang.System.LoggerFinder; >>> ^ >>> symbol: class LoggerFinder >>> location: class System >> >> What boot JDK are you using? > > JDK 8 from stock Fedora 23: > $ rpm -q java-1.8.0-openjdk > java-1.8.0-openjdk-1.8.0.65-4.b17.fc23.x86_64 Should be okay. Strange error ... cc'ing build folk :) David > Thanks, > Severin > >> David >> ----- >> >> >>> $ hg paths >>> default = http://hg.openjdk.java.net/jdk9/hs-rt/ >>> >>> Do I need to use a different tree these days? What am I missing? >>> >>> Thanks, >>> Severin >>> > From sgehwolf at redhat.com Wed Dec 9 12:33:42 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 13:33:42 +0100 Subject: [JDK 9] hs-rt forest fails to build? In-Reply-To: <1449659738.3543.28.camel@redhat.com> References: <1449656620.3543.3.camel@redhat.com> <5668054C.6030708@oracle.com> <1449659738.3543.28.camel@redhat.com> Message-ID: <1449664422.3543.37.camel@redhat.com> Hi, On Wed, 2015-12-09 at 12:15 +0100, Severin Gehwolf wrote: > Hi Mikael, > > On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote: > > Hi Severin, > > > > On 2015-12-09 11:23, Severin Gehwolf wrote: > > > Hi, > > > > > > I'm trying to build an OpenJDK 9, hs-rt tree which fails to build for > > > me with: > > > > > > jdk/src/java.logging/share/classes/sun/util/logging/internal/LoggingProviderImpl.java:33: error: cannot find symbol > > > import java.lang.System.LoggerFinder; > > > ????????????????????????^ > > > ???symbol:???class LoggerFinder > > > ???location: class System > > > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src/java.base/share/classes/java/lang/System.java#l1377 > > the LoggerFinder inner class appears to exist on the hg server at least. > > I have it in the local copy too, yet I get: > CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch' failed > make/Main.gmk:150: recipe for target 'java.logging-java' failed > > With the above root-cause. I'll try with a fresh clone... Same failure with fresh clone :( Here is how I configure and invoke make: bash configure \ ?--with-boot-jdk="$JDK_TO_BUILD_WITH" \ ?--with-debug-level="release" \ ?--disable-zip-debug-info \ ?--enable-unlimited-crypto \ ?--with-stdc++lib=dynamic \ ?--disable-warnings-as-errors \ ?--with-num-cores=8 make \ ?DEBUG_BINARIES=true \ ?JAVAC_FLAGS=-g \ ?STRIP_POLICY=no_strip \ ?STRIP="" \ ?DISABLE_INTREE_EC=true \ ?ALT_OBJCOPY=none \ ?LOG=debug \ ?images Thanks, Severin > > > > > > $ hg paths > > > default = http://hg.openjdk.java.net/jdk9/hs-rt/ > > > > > > Do I need to use a different tree these days? What am I missing? > > > > No, it should work. > > Are you sure you've updated all the sub-trees? > > > > http://hg.openjdk.java.net/code-tools/trees/ > > Is a helpful hg extension to keep track of things. > > > > I've noticed that sometimes "bash get_source.sh" does not correctly "hg? > > update" the entire forest. > > I should have an updated tree, though I usually use: > $ hg pull -u > $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do pushd $i; hg pull -u; popd; done > > I've checked just now and all repos seem to have updated correctly. The > CI builder for Zero seems to agree[1]. Note: The above build failure is > for a regular server JVM. Not sure what's wrong. I keep looking, > thanks! > > Cheers, > Severin > > [1]?http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/191/console > > > /Mikael > > > > > > > > Thanks, > > > Severin > > > > > > From thomas.schatzl at oracle.com Wed Dec 9 13:18:33 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 09 Dec 2015 14:18:33 +0100 Subject: RFR: JDK-8144464 : WB method to start G1 concurrent mark cycle should be introduced In-Reply-To: <32212a1d-dd5b-4ad4-839f-521b8b6001bf@default> References: <32212a1d-dd5b-4ad4-839f-521b8b6001bf@default> Message-ID: <1449667113.2195.12.camel@oracle.com> Hi, looks good. Actually it seems that this change applied without any problems apart from minor line number differences. On Wed, 2015-12-09 at 00:43 -0800, Shafi Ahmad wrote: > Hi, > > > > Please, can I get review for that backport? Thank you! > Thanks, Thomas From sgehwolf at redhat.com Wed Dec 9 13:55:02 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 14:55:02 +0100 Subject: [PING-2] RFR 6425769: jmx remote bind address In-Reply-To: <1448975945.4309.16.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> <1448975945.4309.16.camel@redhat.com> Message-ID: <1449669302.3543.62.camel@redhat.com> On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: > Hi Jaroslav, > > On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > > On 1.12.2015 11:17, Severin Gehwolf wrote: > > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Updated webrev with jtreg test in Java: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > > > > I believe this updated webrev addresses all concerns and > > > > > incorporates > > > > > suggestions brought up by Jaroslav and Daniel. > > > > > > > > > > I'm still looking for a sponsor and a hotspot/servicability- > > > > > dev > > > > > reviewer. Could somebody maintaining javax.rmi.ssl have a > > > > > look at > > > > > this > > > > > as well? Thank you! > > > > > > > > Ping? Friendly reminder that I still need reviewers and a > > > > sponsor for > > > > this. > > > > > > Anyone? > > > > I'm sorry for not spotting this earlier: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi- > > ssl-factory- > > changes/jdk/src/java.management/share/classes/sun/management/jmxrem > > ote/ConnectorBootstrap.java.sdiff.html > > * L442 - the log would contain 'com.sun.management.jmxremote.host > > =? > > null' if host is not specified; might be better not to print this > > out at all > > Updated webrev which does not print > 'com.sun.management.jmxremote.host = null' if unset: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ > > > Other than that the change looks good to me. If no one else is > > volunteering I may sponsor this change. > > Thank you! Jaroslav, are you still willing to sponsor this? There hasn't been much movement :-/ Thanks, Severin From jaroslav.bachorik at oracle.com Wed Dec 9 13:58:02 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 9 Dec 2015 14:58:02 +0100 Subject: [PING-2] RFR 6425769: jmx remote bind address In-Reply-To: <1449669302.3543.62.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> <1448975945.4309.16.camel@redhat.com> <1449669302.3543.62.camel@redhat.com> Message-ID: <5668336A.3010406@oracle.com> On 9.12.2015 14:55, Severin Gehwolf wrote: > On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: >> Hi Jaroslav, >> >> On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: >>> On 1.12.2015 11:17, Severin Gehwolf wrote: >>>> On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: >>>>> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: >>>>>> Hi, >>>>>> >>>>>> Updated webrev with jtreg test in Java: >>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6425769 >>>>>> >>>>>> I believe this updated webrev addresses all concerns and >>>>>> incorporates >>>>>> suggestions brought up by Jaroslav and Daniel. >>>>>> >>>>>> I'm still looking for a sponsor and a hotspot/servicability- >>>>>> dev >>>>>> reviewer. Could somebody maintaining javax.rmi.ssl have a >>>>>> look at >>>>>> this >>>>>> as well? Thank you! >>>>> >>>>> Ping? Friendly reminder that I still need reviewers and a >>>>> sponsor for >>>>> this. >>>> >>>> Anyone? >>> >>> I'm sorry for not spotting this earlier: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi- >>> ssl-factory- >>> changes/jdk/src/java.management/share/classes/sun/management/jmxrem >>> ote/ConnectorBootstrap.java.sdiff.html >>> * L442 - the log would contain 'com.sun.management.jmxremote.host >>> = >>> null' if host is not specified; might be better not to print this >>> out at all >> >> Updated webrev which does not print >> 'com.sun.management.jmxremote.host = null' if unset: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ >> >>> Other than that the change looks good to me. If no one else is >>> volunteering I may sponsor this change. >> >> Thank you! > > Jaroslav, are you still willing to sponsor this? There hasn't been much > movement :-/ Sure. I need to start the compatibility review process before integration and it might take some time. -JB- > > Thanks, > Severin > From sgehwolf at redhat.com Wed Dec 9 14:13:01 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 15:13:01 +0100 Subject: [PING-2] RFR 6425769: jmx remote bind address In-Reply-To: <5668336A.3010406@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> <1448975945.4309.16.camel@redhat.com> <1449669302.3543.62.camel@redhat.com> <5668336A.3010406@oracle.com> Message-ID: <1449670381.3543.63.camel@redhat.com> On Wed, 2015-12-09 at 14:58 +0100, Jaroslav Bachorik wrote: > On 9.12.2015 14:55, Severin Gehwolf wrote: > > On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: > > > Hi Jaroslav, > > > > > > On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > > > > On 1.12.2015 11:17, Severin Gehwolf wrote: > > > > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Updated webrev with jtreg test in Java: > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/ > > > > > > > 02/ > > > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > > > > > > > > I believe this updated webrev addresses all concerns and > > > > > > > incorporates > > > > > > > suggestions brought up by Jaroslav and Daniel. > > > > > > > > > > > > > > I'm still looking for a sponsor and a > > > > > > > hotspot/servicability- > > > > > > > dev > > > > > > > reviewer. Could somebody maintaining javax.rmi.ssl have a > > > > > > > look at > > > > > > > this > > > > > > > as well? Thank you! > > > > > > > > > > > > Ping? Friendly reminder that I still need reviewers and a > > > > > > sponsor for > > > > > > this. > > > > > > > > > > Anyone? > > > > > > > > I'm sorry for not spotting this earlier: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no- > > > > rmi- > > > > ssl-factory- > > > > changes/jdk/src/java.management/share/classes/sun/management/jm > > > > xrem > > > > ote/ConnectorBootstrap.java.sdiff.html > > > > * L442 - the log would contain > > > > 'com.sun.management.jmxremote.host > > > > = > > > > null' if host is not specified; might be better not to print > > > > this > > > > out at all > > > > > > Updated webrev which does not print > > > 'com.sun.management.jmxremote.host = null' if unset: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ > > > > > > > Other than that the change looks good to me. If no one else is > > > > volunteering I may sponsor this change. > > > > > > Thank you! > > > > Jaroslav, are you still willing to sponsor this? There hasn't been > > much > > movement :-/ > > Sure. I need to start the compatibility review process before > integration and it might take some time. OK. Thanks for the heads-up! Cheers, Severin > -JB- > > > > > Thanks, > > Severin > > > From sean.coffey at oracle.com Wed Dec 9 14:56:03 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 9 Dec 2015 14:56:03 +0000 Subject: [8u] Reguest for approval and review: 8129847: Compiling methods generated by Nashorn... In-Reply-To: <5667E38C.7090606@oracle.com> References: <5667E38C.7090606@oracle.com> Message-ID: <56684103.5050500@oracle.com> Approved for jdk8u-dev but subject to a peer code review first. Regards, Sean. On 09/12/15 08:17, Zolt?n Maj? wrote: > Hi, > > > please approve and review the following backport to 8u. > > Original (9) bug: https://bugs.openjdk.java.net/browse/JDK-8129847 > Original (9) webrev: > http://cr.openjdk.java.net/~zmajo/8129847-9/webrev.06/ > Changeset (9): > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/da497ea6c120 > > Unfortunately, the changeset does not apply cleanly to 8u. So here is > the 8u webrev: > http://cr.openjdk.java.net/~zmajo/8129847-8u/webrev.06/ > > Testing: > - JPRT (testset hotspot), all tests pass; > - Octane/Nashorn; > - the patch for 9 passed a complete cycle of nightly testing without > problems; > - no performance regression (Octane/Nashorn, SPECjvm2008). > > Thank you and best regards, > > > Zoltan > From gnu.andrew at redhat.com Wed Dec 9 16:12:05 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Dec 2015 11:12:05 -0500 (EST) Subject: [JDK 9] hs-rt forest fails to build? In-Reply-To: <1449656620.3543.3.camel@redhat.com> References: <1449656620.3543.3.camel@redhat.com> Message-ID: <33392206.26196729.1449677525958.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi, > > I'm trying to build an OpenJDK 9, hs-rt tree which fails to build for > me with: > > jdk/src/java.logging/share/classes/sun/util/logging/internal/LoggingProviderImpl.java:33: > error: cannot find symbol > import java.lang.System.LoggerFinder; > ???????????????????????^ > ? symbol:???class LoggerFinder > ? location: class System > > $ hg paths > default = http://hg.openjdk.java.net/jdk9/hs-rt/ > > Do I need to use a different tree these days? What am I missing? > > Thanks, > Severin > What's the context of this failure within the build? Could it be it's picking up the java.lang.System from the boot JDK before the just-built one? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From erik.joelsson at oracle.com Wed Dec 9 16:35:30 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 9 Dec 2015 17:35:30 +0100 Subject: [JDK 9] hs-rt forest fails to build? In-Reply-To: <1449664422.3543.37.camel@redhat.com> References: <1449656620.3543.3.camel@redhat.com> <5668054C.6030708@oracle.com> <1449659738.3543.28.camel@redhat.com> <1449664422.3543.37.camel@redhat.com> Message-ID: <56685852.80705@oracle.com> I'm not able to reproduce with either OracleJDK 8 or 8u66. /Erik On 2015-12-09 13:33, Severin Gehwolf wrote: > Hi, > > On Wed, 2015-12-09 at 12:15 +0100, Severin Gehwolf wrote: >> Hi Mikael, >> >> On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote: >>> Hi Severin, >>> >>> On 2015-12-09 11:23, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> I'm trying to build an OpenJDK 9, hs-rt tree which fails to build for >>>> me with: >>>> >>>> jdk/src/java.logging/share/classes/sun/util/logging/internal/LoggingProviderImpl.java:33: error: cannot find symbol >>>> import java.lang.System.LoggerFinder; >>>> ^ >>>> symbol: class LoggerFinder >>>> location: class System >>> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src/java.base/share/classes/java/lang/System.java#l1377 >>> the LoggerFinder inner class appears to exist on the hg server at least. >> I have it in the local copy too, yet I get: >> CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch' failed >> make/Main.gmk:150: recipe for target 'java.logging-java' failed >> >> With the above root-cause. I'll try with a fresh clone... > Same failure with fresh clone :( Here is how I configure and invoke > make: > bash configure \ > --with-boot-jdk="$JDK_TO_BUILD_WITH" \ > --with-debug-level="release" \ > --disable-zip-debug-info \ > --enable-unlimited-crypto \ > --with-stdc++lib=dynamic \ > --disable-warnings-as-errors \ > --with-num-cores=8 > > make \ > DEBUG_BINARIES=true \ > JAVAC_FLAGS=-g \ > STRIP_POLICY=no_strip \ > STRIP="" \ > DISABLE_INTREE_EC=true \ > ALT_OBJCOPY=none \ > LOG=debug \ > images > > Thanks, > Severin > >>>> $ hg paths >>>> default = http://hg.openjdk.java.net/jdk9/hs-rt/ >>>> >>>> Do I need to use a different tree these days? What am I missing? >>> No, it should work. >>> Are you sure you've updated all the sub-trees? >>> >>> http://hg.openjdk.java.net/code-tools/trees/ >>> Is a helpful hg extension to keep track of things. >>> >>> I've noticed that sometimes "bash get_source.sh" does not correctly "hg >>> update" the entire forest. >> I should have an updated tree, though I usually use: >> $ hg pull -u >> $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do pushd $i; hg pull -u; popd; done >> >> I've checked just now and all repos seem to have updated correctly. The >> CI builder for Zero seems to agree[1]. Note: The above build failure is >> for a regular server JVM. Not sure what's wrong. I keep looking, >> thanks! >> >> Cheers, >> Severin >> >> [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/191/console >> >>> /Mikael >>> >>>> Thanks, >>>> Severin >>>> From jon.masamitsu at oracle.com Wed Dec 9 16:40:05 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 9 Dec 2015 08:40:05 -0800 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <566783D0.4080205@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> <56626EC7.4050202@oracle.com> <5665BA58.3050606@oracle.com> <566667EF.9080704@oracle.com> <5667244F.50101@oracle.com> <3BE9CFDA-A2D6-4D51-ADB5-20F85226F850@oracle.com> <566747B5.7030108@oracle.com> <566783D0.4080205@oracle.com> Message-ID: <56685965.70305@oracle.com> On 12/08/2015 05:28 PM, David Holmes wrote: > On 9/12/2015 7:12 AM, Jon Masamitsu wrote: >> >> >> On 12/8/2015 11:37 AM, Kim Barrett wrote: >>> On Dec 8, 2015, at 1:41 PM, Jon Masamitsu >>> wrote: >>>> Latest delta on the patch is at >>>> >>>> http://cr.openjdk.java.net/~jmasa/8133023/delta.06/ >>>> >>>> It contains a name change from the original patch >>>> vm_init_before_ergo() -> init_before_ergo() and some >>>> additional comments. >>>> >>>> Full patch is at >>>> >>>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.06/ >>> A couple minor things. I don't need another webrev for these. Looks >>> good otherwise. >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> src/share/vm/runtime/vm_version.hpp >>> 59 // Called as part of the runtime services initialization >>> 60 // called from the management module initialization (via >>> init_globals()) >>> >>> Need period at end of line 59, and line 60 should start capitalized. >> My intent was that it be a single sentence. I've added a "which is" to >> the end of the >> line to make it more clear. >> >> 59 // Called as part of the runtime services initialization which is >> 60 // called from the management module initialization (via >> init_globals()) > > That's why I suggested just saying "via init_globals" because the > details are complex as it is either initialized from management, if > management support is being built, else from runtime services. I chose the "runtime services initialization which is called from the management modules ..." because being less precise (not calling out init_globals()) but more generic, would be true longer (than if the implementation changed and init_globals() mutated). > > But ok. Thanks. Jon > > Thanks, > David > > > >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> src/share/vm/runtime/vm_version.hpp >>> 72 static void early_initialize() { } >>> 73 // Called to initialize VM variables needing initialization >>> 74 // after command line parsing >>> 75 static void init_before_ergo(void) {} >>> >>> Missing period at end of sentence. >> >> Fixed. >> >>> >>> I'd prefer there be a blank line between lines 72 and 73. >>> >>> Maybe the description here should have a similar sentence to the >>> preceding description for early_initialize, e.g. add >>> >>> Platforms that need to specialize this define >>> VM_Version::init_before_ergo(). >> >> I added it. >> >> Thanks. >> >> Jon >> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> >>> >> From jon.masamitsu at oracle.com Wed Dec 9 16:48:05 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 9 Dec 2015 08:48:05 -0800 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <1449659184.2195.8.camel@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> <5661C1D6.4030901@oracle.com> <56626EC7.4050202@oracle.com> <5665BA58.3050606@oracle.com> <566667EF.9080704@oracle.com> <5667244F.50101@oracle.com> <1449659184.2195.8.camel@oracle.com> Message-ID: <56685B45.50709@oracle.com> On 12/09/2015 03:06 AM, Thomas Schatzl wrote: > Hi, > > On Tue, 2015-12-08 at 10:41 -0800, Jon Masamitsu wrote: >> Latest delta on the patch is at >> >> http://cr.openjdk.java.net/~jmasa/8133023/delta.06/ >> >> It contains a name change from the original patch >> vm_init_before_ergo() -> init_before_ergo() and some >> additional comments. >> >> Full patch is at >> >> http://cr.openjdk.java.net/~jmasa/8133023/webrev.06/ >> > > http://cr.openjdk.java.net/~jmasa/8133023/webrev.06/src/share/vm/runtime/vm_version.hpp.frames.html > > 75 static void init_before_ergo(void) {} > > It's a bit odd to have an explicit void parameter list for this method. > While it is completely legal, for uniformity I would like to prefer that > removed. I agree and have removed it. > > Other than that see the nits from Kim, which were already fixed. > > I do not need to see the change again. Thanks. Jon > > Thanks, > Thomas > > From sgehwolf at redhat.com Wed Dec 9 17:53:05 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 18:53:05 +0100 Subject: [JDK 9] hs-rt forest fails to build? In-Reply-To: <56685852.80705@oracle.com> References: <1449656620.3543.3.camel@redhat.com> <5668054C.6030708@oracle.com> <1449659738.3543.28.camel@redhat.com> <1449664422.3543.37.camel@redhat.com> <56685852.80705@oracle.com> Message-ID: <1449683585.3543.88.camel@redhat.com> Hi Erik, On Wed, 2015-12-09 at 17:35 +0100, Erik Joelsson wrote: > I'm not able to reproduce with either OracleJDK 8 or 8u66. The simplified reproducer is (extracted from build.log): ( (/usr/bin/bash /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/common/bin/logger.sh??/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /usr/lib/jvm/java-1.8.0-openjdk/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M "-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar" -cp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar com.sun.tools.sjavac.Main --server:portfile=/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/javacservers/server.port,id=java.logging,sjavac=/usr/lib/jvm/java-1.8.0-openjdk/bin/java%20-d64%20-Xms512M%20-Xmx2048M%20"-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar"%20-cp%20/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar%20com.sun.tools.sjavac.Main -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true -Xlint:all -Werror -g -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -g -cp "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.base:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging" -implicit:none -d /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging -h /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/support/headers/java.logging.java.logging.tmp @/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp && /usr/bin/rm -f??/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log) || (exitcode=$? && /usr/bin/mv??/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/failure-logs/java.logging.log && exit $exitcode) ) && /usr/bin/mv /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch I'm also attaching the failing command invocation as a file (Putting this into a file and re-executing it reproduces the problem for me. Of course, your paths may differ :) Cheers, Severin > /Erik > > On 2015-12-09 13:33, Severin Gehwolf wrote: > > Hi, > > > > On Wed, 2015-12-09 at 12:15 +0100, Severin Gehwolf wrote: > > > Hi Mikael, > > > > > > On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote: > > > > Hi Severin, > > > > > > > > On 2015-12-09 11:23, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > I'm trying to build an OpenJDK 9, hs-rt tree which fails to > > > > > build for > > > > > me with: > > > > > > > > > > jdk/src/java.logging/share/classes/sun/util/logging/internal/ > > > > > LoggingProviderImpl.java:33: error: cannot find symbol > > > > > import java.lang.System.LoggerFinder; > > > > > ?????????????????????????^ > > > > > ????symbol:???class LoggerFinder > > > > > ????location: class System > > > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src > > > > /java.base/share/classes/java/lang/System.java#l1377 > > > > the LoggerFinder inner class appears to exist on the hg server > > > > at least. > > > I have it in the local copy too, yet I get: > > > CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux- > > > x86_64-normal-server- > > > release/jdk/modules/java.logging/_the.java.logging_batch' failed > > > make/Main.gmk:150: recipe for target 'java.logging-java' failed > > > > > > With the above root-cause. I'll try with a fresh clone... > > Same failure with fresh clone :( Here is how I configure and invoke > > make: > > bash configure \ > > ? --with-boot-jdk="$JDK_TO_BUILD_WITH" \ > > ? --with-debug-level="release" \ > > ? --disable-zip-debug-info \ > > ? --enable-unlimited-crypto \ > > ? --with-stdc++lib=dynamic \ > > ? --disable-warnings-as-errors \ > > ? --with-num-cores=8 > > > > make \ > > ? DEBUG_BINARIES=true \ > > ? JAVAC_FLAGS=-g \ > > ? STRIP_POLICY=no_strip \ > > ? STRIP="" \ > > ? DISABLE_INTREE_EC=true \ > > ? ALT_OBJCOPY=none \ > > ? LOG=debug \ > > ? images > > > > Thanks, > > Severin > > > > > > > $ hg paths > > > > > default = http://hg.openjdk.java.net/jdk9/hs-rt/ > > > > > > > > > > Do I need to use a different tree these days? What am I > > > > > missing? > > > > No, it should work. > > > > Are you sure you've updated all the sub-trees? > > > > > > > > http://hg.openjdk.java.net/code-tools/trees/ > > > > Is a helpful hg extension to keep track of things. > > > > > > > > I've noticed that sometimes "bash get_source.sh" does not > > > > correctly "hg > > > > update" the entire forest. > > > I should have an updated tree, though I usually use: > > > $ hg pull -u > > > $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do > > > pushd $i; hg pull -u; popd; done > > > > > > I've checked just now and all repos seem to have updated > > > correctly. The > > > CI builder for Zero seems to agree[1]. Note: The above build > > > failure is > > > for a regular server JVM. Not sure what's wrong. I keep looking, > > > thanks! > > > > > > Cheers, > > > Severin > > > > > > [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/ > > > 191/console > > > > > > > /Mikael > > > > > > > > > Thanks, > > > > > Severin > > > > > > -------------- next part -------------- ( (/usr/bin/bash /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/common/bin/logger.sh /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /usr/lib/jvm/java-1.8.0-openjdk/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M "-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar" -cp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar com.sun.tools.sjavac.Main --server:portfile=/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/javacservers/server.port,id=java.logging,sjavac=/usr/lib/jvm/java-1.8.0-openjdk/bin/java%20-d64%20-Xms512M%20-Xmx2048M%20"-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar"%20-cp%20/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar%20com.sun.tools.sjavac.Main -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true -Xlint:all -Werror -g -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -g -cp "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.base:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging" -implicit:none -d /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging -h /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/support/headers/java.logging.java.logging.tmp @/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp && /usr/bin/rm -f /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log) || (exitcode=$? && /usr/bin/mv /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/failure-logs/java.logging.log && exit $exitcode) ) && /usr/bin/mv /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch From volker.simonis at gmail.com Wed Dec 9 17:53:29 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 9 Dec 2015 18:53:29 +0100 Subject: RFR(S): 8145015: jni_GetStringCritical asserts for empty strings Message-ID: Hi, can somebody please review and sponsor the following fix: http://cr.openjdk.java.net/~simonis/webrevs/2015/8145015/ https://bugs.openjdk.java.net/browse/JDK-8145015 The problem is that change "8141132: JEP 254: Compact Strings" removed the handling for empty strings from jni_GetStringCritical(). As a consequence, the functions will now assert with: assert(is_within_bounds(which)) failed: index 0 out of bounds 0 if called with a string of length zero (because it tries to access the zeroth element of a zero-length array). The fix is trivial, just use 's_value->base(T_CHAR)' instead of 's_value->char_at_addr(0)'. While doing this fix I also noticed that jni_GetStringCritical() doesn't handle out-of-memory situations when creating a new character array (before this wasn't necessary because it always returned the original character array, but now with compressed strings it may have to allocate a new array). So I've also added the new check by using NEW_C_HEAP_ARRAY_RETURN_NULL() instead of NEW_C_HEAP_ARRAY(). Notice that I also allocate one extra character for zero termination. While it seems that this is not strictly necessary, it is now the same code like in jni_GetStringChars(). And it again simplifies the handling of zero-length strings. Without the extra character it would be hard to distinguish out-of-memory errors from the allocation of zero bytes, because malloc() is free to return NULL if called with an allocation size of zero. Thank you and best regards, Volker From asmundak at google.com Wed Dec 9 18:16:30 2015 From: asmundak at google.com (Alexander Smundak) Date: Wed, 9 Dec 2015 10:16:30 -0800 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <56679B9F.8030105@oracle.com> References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> <5664DBF9.7010708@oracle.com> <566660B2.4030100@oracle.com> <56679B9F.8030105@oracle.com> Message-ID: I am confused -- is there anything you want me to change in the existing set: http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03 http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03 http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03 Sasha On Tue, Dec 8, 2015 at 7:10 PM, David Holmes wrote: > I can sponsor for you Sasha. Just email me the changeset, or a link thereto. > > Thanks, > David > > > On 9/12/2015 3:44 AM, Alexander Smundak wrote: >> >> Thank you for the review. >> If everyone involved is satisfied with the patch, I need a sponsor. >> >> Sasha >> >> On Mon, Dec 7, 2015 at 8:46 PM, David Holmes >> wrote: >>> >>> On 8/12/2015 1:44 PM, Alexander Smundak wrote: >>>> >>>> >>>> It is achievable by adding a small ppc-specific check to the >>>> common/autoconf/platform.m4: >>>> >>>> @@ -282,6 +282,8 @@ >>>> elif test "x$OPENJDK_TARGET_OS" != xmacosx && test >>>> "x$OPENJDK_TARGET_CPU" = xx86_64; then >>>> # On all platforms except MacOSX replace x86_64 with amd64. >>>> OPENJDK_TARGET_CPU_LEGACY="amd64" >>>> + elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then >>>> + OPENJDK_TARGET_CPU_LEGACY="ppc64" >>>> fi >>>> AC_SUBST(OPENJDK_TARGET_CPU_LEGACY) >>>> >>>> However, there is a code in make/Images.gmk using >>>> OPENJDK_TARGET_CPU_LEGACY >>>> $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)") >>>> so that the 'release' file in the image directory will now have >>>> JAVA_VERSION="9" >>>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt" >>>> OS_NAME="Linux" >>>> OS_VERSION="2.6" >>>> OS_ARCH="ppc64" >>>> ^^^^^^^^ >>>> SOURCE=.., >>>> >>>> instead of "ppc64le". >>>> >>>> If someone can tell me which other variable I should use to achieve >>>> that without changing the contents of the 'release' file on other >>>> platforms, I'll be grateful. >>> >>> >>> >>> Okay never mind - and thanks for looking into this. I see now this is set >>> via: >>> >>> ./autoconf/flags.m4: COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK >>> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY" >>> >>> so there is no way to add a second value without introducing some >>> additional >>> variable. At the hotspot level it could be handled differently if we had >>> a >>> platform_ppc64le file, as it could just be added to the SYSDEFS. >>> >>> Thanks, >>> David From sangheon.kim at oracle.com Wed Dec 9 19:11:18 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 9 Dec 2015 11:11:18 -0800 Subject: RFR(XS) 8145027: Exclude NUMAInterleaveGranularity from TestOptionsWithRanges.java Message-ID: <56687CD6.2020002@oracle.com> Hi all, Could I get some reviews to exclude 'NUMAInterleaveGranularity' from TestOptionsWithRanges.java? Recent patch for JDK-8142341 includes an implementation of range/constraint for NUMAInterleaveGranularity and this change enabled to test the flag by TestOptionsWithRanges.java. And this test found 2 bugs (JDK-8144949 and JDK-8145000) which are now integration blocker. JDK-8144949 occurs only under specific case(32bit binary + server mode) and allocation related routine is not safe. JDK-8145000 happened with valid value and I suspect that allocation related routine is not safe. JDK-8142341 has many other flags implemented. In this regard, I hope to exclude the flag from the test rather than back out JDK-8142341. And I will include this flag when I have stable range/constraint or related routines enhanced. CR: https://bugs.openjdk.java.net/browse/JDK-8145027 Webrev: http://cr.openjdk.java.net/~sangheki/8145027/webrev.00/ Thanks, Sangheon From jesper.wilhelmsson at oracle.com Wed Dec 9 19:22:11 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 9 Dec 2015 20:22:11 +0100 Subject: RFR(XS) 8145027: Exclude NUMAInterleaveGranularity from TestOptionsWithRanges.java In-Reply-To: <56687CD6.2020002@oracle.com> References: <56687CD6.2020002@oracle.com> Message-ID: <56687F63.5070908@oracle.com> Looks good! /Jesper Den 9/12/15 kl. 20:11, skrev sangheon.kim: > Hi all, > > Could I get some reviews to exclude 'NUMAInterleaveGranularity' from > TestOptionsWithRanges.java? > > Recent patch for JDK-8142341 includes an implementation of range/constraint for > NUMAInterleaveGranularity and this change enabled to test the flag by > TestOptionsWithRanges.java. And this test found 2 bugs (JDK-8144949 and > JDK-8145000) which are now integration blocker. > > JDK-8144949 occurs only under specific case(32bit binary + server mode) and > allocation related routine is not safe. > JDK-8145000 happened with valid value and I suspect that allocation related > routine is not safe. > JDK-8142341 has many other flags implemented. > > In this regard, I hope to exclude the flag from the test rather than back out > JDK-8142341. > And I will include this flag when I have stable range/constraint or related > routines enhanced. > > CR: https://bugs.openjdk.java.net/browse/JDK-8145027 > Webrev: http://cr.openjdk.java.net/~sangheki/8145027/webrev.00/ > > Thanks, > Sangheon > > > From sangheon.kim at oracle.com Wed Dec 9 19:37:15 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 9 Dec 2015 11:37:15 -0800 Subject: RFR(XS) 8145027: Exclude NUMAInterleaveGranularity from TestOptionsWithRanges.java In-Reply-To: <56687F63.5070908@oracle.com> References: <56687CD6.2020002@oracle.com> <56687F63.5070908@oracle.com> Message-ID: <566882EB.1080002@oracle.com> Hi Jesper, Thank you for the review! Sangheon On 12/09/2015 11:22 AM, Jesper Wilhelmsson wrote: > Looks good! > /Jesper > > Den 9/12/15 kl. 20:11, skrev sangheon.kim: >> Hi all, >> >> Could I get some reviews to exclude 'NUMAInterleaveGranularity' from >> TestOptionsWithRanges.java? >> >> Recent patch for JDK-8142341 includes an implementation of >> range/constraint for >> NUMAInterleaveGranularity and this change enabled to test the flag by >> TestOptionsWithRanges.java. And this test found 2 bugs (JDK-8144949 and >> JDK-8145000) which are now integration blocker. >> >> JDK-8144949 occurs only under specific case(32bit binary + server >> mode) and >> allocation related routine is not safe. >> JDK-8145000 happened with valid value and I suspect that allocation >> related >> routine is not safe. >> JDK-8142341 has many other flags implemented. >> >> In this regard, I hope to exclude the flag from the test rather than >> back out >> JDK-8142341. >> And I will include this flag when I have stable range/constraint or >> related >> routines enhanced. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8145027 >> Webrev: http://cr.openjdk.java.net/~sangheki/8145027/webrev.00/ >> >> Thanks, >> Sangheon >> >> >> From dmitry.dmitriev at oracle.com Wed Dec 9 19:46:48 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 9 Dec 2015 22:46:48 +0300 Subject: RFR(XS) 8145027: Exclude NUMAInterleaveGranularity from TestOptionsWithRanges.java In-Reply-To: <56687CD6.2020002@oracle.com> References: <56687CD6.2020002@oracle.com> Message-ID: <56688528.1080907@oracle.com> Hi Sangheon, Looks good to me. Just one small comment - can you please add a comment with the reason why this flag is excluded(with corresponding JBS numbers)? Not need a new webrev for that if you decide to implement my comment. Thanks, Dmitry On 09.12.2015 22:11, sangheon.kim wrote: > Hi all, > > Could I get some reviews to exclude 'NUMAInterleaveGranularity' from > TestOptionsWithRanges.java? > > Recent patch for JDK-8142341 includes an implementation of > range/constraint for NUMAInterleaveGranularity and this change enabled > to test the flag by TestOptionsWithRanges.java. And this test found 2 > bugs (JDK-8144949 and JDK-8145000) which are now integration blocker. > > JDK-8144949 occurs only under specific case(32bit binary + server > mode) and allocation related routine is not safe. > JDK-8145000 happened with valid value and I suspect that allocation > related routine is not safe. > JDK-8142341 has many other flags implemented. > > In this regard, I hope to exclude the flag from the test rather than > back out JDK-8142341. > And I will include this flag when I have stable range/constraint or > related routines enhanced. > > CR: https://bugs.openjdk.java.net/browse/JDK-8145027 > Webrev: http://cr.openjdk.java.net/~sangheki/8145027/webrev.00/ > > Thanks, > Sangheon > > > From sangheon.kim at oracle.com Wed Dec 9 20:06:43 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 9 Dec 2015 12:06:43 -0800 Subject: RFR(XS) 8145027: Exclude NUMAInterleaveGranularity from TestOptionsWithRanges.java In-Reply-To: <56688528.1080907@oracle.com> References: <56687CD6.2020002@oracle.com> <56688528.1080907@oracle.com> Message-ID: <566889D3.6080007@oracle.com> Hi Dmitry, Thank you for looking at this. How about a comment like below? /* + * JDK-8145027 + * Temporarily exclude as current range/constraint is not enough for some option combinations. + */ + excludeTestRange("NUMAInterleaveGranularity"); + + /* Thanks, Sangheon On 12/09/2015 11:46 AM, Dmitry Dmitriev wrote: > Hi Sangheon, > > Looks good to me. Just one small comment - can you please add a > comment with the reason why this flag is excluded(with corresponding > JBS numbers)? Not need a new webrev for that if you decide to > implement my comment. > > Thanks, > Dmitry > > On 09.12.2015 22:11, sangheon.kim wrote: >> Hi all, >> >> Could I get some reviews to exclude 'NUMAInterleaveGranularity' from >> TestOptionsWithRanges.java? >> >> Recent patch for JDK-8142341 includes an implementation of >> range/constraint for NUMAInterleaveGranularity and this change >> enabled to test the flag by TestOptionsWithRanges.java. And this test >> found 2 bugs (JDK-8144949 and JDK-8145000) which are now integration >> blocker. >> >> JDK-8144949 occurs only under specific case(32bit binary + server >> mode) and allocation related routine is not safe. >> JDK-8145000 happened with valid value and I suspect that allocation >> related routine is not safe. >> JDK-8142341 has many other flags implemented. >> >> In this regard, I hope to exclude the flag from the test rather than >> back out JDK-8142341. >> And I will include this flag when I have stable range/constraint or >> related routines enhanced. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8145027 >> Webrev: http://cr.openjdk.java.net/~sangheki/8145027/webrev.00/ >> >> Thanks, >> Sangheon >> >> >> > From dmitry.dmitriev at oracle.com Wed Dec 9 20:20:17 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 9 Dec 2015 23:20:17 +0300 Subject: RFR(XS) 8145027: Exclude NUMAInterleaveGranularity from TestOptionsWithRanges.java In-Reply-To: <566889D3.6080007@oracle.com> References: <56687CD6.2020002@oracle.com> <56688528.1080907@oracle.com> <566889D3.6080007@oracle.com> Message-ID: <56688D01.60606@oracle.com> Sangheon, yes, this looks good! Thanks, Dmitry On 09.12.2015 23:06, sangheon.kim wrote: > Hi Dmitry, > > Thank you for looking at this. > How about a comment like below? > /* > + * JDK-8145027 > + * Temporarily exclude as current range/constraint is not > enough for some option combinations. > + */ > + excludeTestRange("NUMAInterleaveGranularity"); > + > + /* > > Thanks, > Sangheon > > > On 12/09/2015 11:46 AM, Dmitry Dmitriev wrote: >> Hi Sangheon, >> >> Looks good to me. Just one small comment - can you please add a >> comment with the reason why this flag is excluded(with corresponding >> JBS numbers)? Not need a new webrev for that if you decide to >> implement my comment. >> >> Thanks, >> Dmitry >> >> On 09.12.2015 22:11, sangheon.kim wrote: >>> Hi all, >>> >>> Could I get some reviews to exclude 'NUMAInterleaveGranularity' from >>> TestOptionsWithRanges.java? >>> >>> Recent patch for JDK-8142341 includes an implementation of >>> range/constraint for NUMAInterleaveGranularity and this change >>> enabled to test the flag by TestOptionsWithRanges.java. And this >>> test found 2 bugs (JDK-8144949 and JDK-8145000) which are now >>> integration blocker. >>> >>> JDK-8144949 occurs only under specific case(32bit binary + server >>> mode) and allocation related routine is not safe. >>> JDK-8145000 happened with valid value and I suspect that allocation >>> related routine is not safe. >>> JDK-8142341 has many other flags implemented. >>> >>> In this regard, I hope to exclude the flag from the test rather than >>> back out JDK-8142341. >>> And I will include this flag when I have stable range/constraint or >>> related routines enhanced. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8145027 >>> Webrev: http://cr.openjdk.java.net/~sangheki/8145027/webrev.00/ >>> >>> Thanks, >>> Sangheon >>> >>> >>> >> > From sangheon.kim at oracle.com Wed Dec 9 20:25:01 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 9 Dec 2015 12:25:01 -0800 Subject: RFR(XS) 8145027: Exclude NUMAInterleaveGranularity from TestOptionsWithRanges.java In-Reply-To: <56688D01.60606@oracle.com> References: <56687CD6.2020002@oracle.com> <56688528.1080907@oracle.com> <566889D3.6080007@oracle.com> <56688D01.60606@oracle.com> Message-ID: <56688E1D.9030909@oracle.com> Dmitry, thank you for the answer. Sangheon On 12/09/2015 12:20 PM, Dmitry Dmitriev wrote: > Sangheon, yes, this looks good! > > Thanks, > Dmitry > > On 09.12.2015 23:06, sangheon.kim wrote: >> Hi Dmitry, >> >> Thank you for looking at this. >> How about a comment like below? >> /* >> + * JDK-8145027 >> + * Temporarily exclude as current range/constraint is not >> enough for some option combinations. >> + */ >> + excludeTestRange("NUMAInterleaveGranularity"); >> + >> + /* >> >> Thanks, >> Sangheon >> >> >> On 12/09/2015 11:46 AM, Dmitry Dmitriev wrote: >>> Hi Sangheon, >>> >>> Looks good to me. Just one small comment - can you please add a >>> comment with the reason why this flag is excluded(with corresponding >>> JBS numbers)? Not need a new webrev for that if you decide to >>> implement my comment. >>> >>> Thanks, >>> Dmitry >>> >>> On 09.12.2015 22:11, sangheon.kim wrote: >>>> Hi all, >>>> >>>> Could I get some reviews to exclude 'NUMAInterleaveGranularity' >>>> from TestOptionsWithRanges.java? >>>> >>>> Recent patch for JDK-8142341 includes an implementation of >>>> range/constraint for NUMAInterleaveGranularity and this change >>>> enabled to test the flag by TestOptionsWithRanges.java. And this >>>> test found 2 bugs (JDK-8144949 and JDK-8145000) which are now >>>> integration blocker. >>>> >>>> JDK-8144949 occurs only under specific case(32bit binary + server >>>> mode) and allocation related routine is not safe. >>>> JDK-8145000 happened with valid value and I suspect that allocation >>>> related routine is not safe. >>>> JDK-8142341 has many other flags implemented. >>>> >>>> In this regard, I hope to exclude the flag from the test rather >>>> than back out JDK-8142341. >>>> And I will include this flag when I have stable range/constraint or >>>> related routines enhanced. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8145027 >>>> Webrev: http://cr.openjdk.java.net/~sangheki/8145027/webrev.00/ >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> >>> >> > From christian.thalinger at oracle.com Wed Dec 9 22:16:11 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Dec 2015 12:16:11 -1000 Subject: RFR (L): 8134994: use separate VMStructs databases for SA and JVMCI Message-ID: <1D6BE603-E996-495C-94BB-C0A8697B07B3@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8134994 http://cr.openjdk.java.net/~twisti/8134994/webrev/ Currently JVMCI uses the existing VMStructs database which the SA also uses. In order to be more flexible with the future of the SA the JVMCI should use it's own database. From david.holmes at oracle.com Thu Dec 10 04:59:58 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Dec 2015 14:59:58 +1000 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> <5664DBF9.7010708@oracle.com> <566660B2.4030100@oracle.com> <56679B9F.8030105@oracle.com> Message-ID: <566906CE.2050101@oracle.com> On 10/12/2015 4:16 AM, Alexander Smundak wrote: > I am confused -- is there anything you want me to change in the existing set: > > http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03 > http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03 > http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03 Yes they need to be created using the correct, jcheck[1] compliant, commit messages: http://openjdk.java.net/guide/producingChangeset.html Mainly Reviewers seem to be missing - but I'm also not sure other details are jcheck compliant. Thanks, David [1] http://openjdk.java.net/projects/code-tools/jcheck/ > Sasha > > On Tue, Dec 8, 2015 at 7:10 PM, David Holmes wrote: >> I can sponsor for you Sasha. Just email me the changeset, or a link thereto. >> >> Thanks, >> David >> >> >> On 9/12/2015 3:44 AM, Alexander Smundak wrote: >>> >>> Thank you for the review. >>> If everyone involved is satisfied with the patch, I need a sponsor. >>> >>> Sasha >>> >>> On Mon, Dec 7, 2015 at 8:46 PM, David Holmes >>> wrote: >>>> >>>> On 8/12/2015 1:44 PM, Alexander Smundak wrote: >>>>> >>>>> >>>>> It is achievable by adding a small ppc-specific check to the >>>>> common/autoconf/platform.m4: >>>>> >>>>> @@ -282,6 +282,8 @@ >>>>> elif test "x$OPENJDK_TARGET_OS" != xmacosx && test >>>>> "x$OPENJDK_TARGET_CPU" = xx86_64; then >>>>> # On all platforms except MacOSX replace x86_64 with amd64. >>>>> OPENJDK_TARGET_CPU_LEGACY="amd64" >>>>> + elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then >>>>> + OPENJDK_TARGET_CPU_LEGACY="ppc64" >>>>> fi >>>>> AC_SUBST(OPENJDK_TARGET_CPU_LEGACY) >>>>> >>>>> However, there is a code in make/Images.gmk using >>>>> OPENJDK_TARGET_CPU_LEGACY >>>>> $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)") >>>>> so that the 'release' file in the image directory will now have >>>>> JAVA_VERSION="9" >>>>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt" >>>>> OS_NAME="Linux" >>>>> OS_VERSION="2.6" >>>>> OS_ARCH="ppc64" >>>>> ^^^^^^^^ >>>>> SOURCE=.., >>>>> >>>>> instead of "ppc64le". >>>>> >>>>> If someone can tell me which other variable I should use to achieve >>>>> that without changing the contents of the 'release' file on other >>>>> platforms, I'll be grateful. >>>> >>>> >>>> >>>> Okay never mind - and thanks for looking into this. I see now this is set >>>> via: >>>> >>>> ./autoconf/flags.m4: COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK >>>> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY" >>>> >>>> so there is no way to add a second value without introducing some >>>> additional >>>> variable. At the hotspot level it could be handled differently if we had >>>> a >>>> platform_ppc64le file, as it could just be added to the SYSDEFS. >>>> >>>> Thanks, >>>> David From sebastian.sickelmann at gmx.de Thu Dec 10 05:38:53 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Thu, 10 Dec 2015 06:38:53 +0100 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot) In-Reply-To: <5615798B.2080708@gmx.de> References: <5608201C.4020109@gmx.de> <560B5939.6010100@gmx.de> <118235E4-AD96-4666-8A63-58FB403324BC@oracle.com> <5615798B.2080708@gmx.de> Message-ID: <56690FED.8060401@gmx.de> @Adding hotspot-runtime-dev Hi, a want to restart a discussion/review-process for on old "bug" JDK-5108778. I created a webrev which is based on the jdk9/dev repo: http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ To enable a subrepo review/push-process I created a subtask for the hotspot part of the change which is JDK-8145061. The earlier mentioned jtreg-test(see below) was dropped due to some initial misunderstandings. @Christian: As you initially responded to my first post I want you to ask if you want to review / sponsor this fix? -- Sebastian On 10/07/2015 09:59 PM, Sebastian Sickelmann wrote: > Please find the webrev hosted on openjdk-infrastructure at: > > http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ > > For some general discussion on regression-tests for this please find the > thread in discuss[0][1] and for the general suggestion to make more > wrapper-type-constructors deprecated find [2] at core-libs-dev. > > [0] > http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html > [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html > > -- Sebastian > > On 09/30/2015 07:50 AM, Christian Thalinger wrote: >> Sounds good. If you have the final patch, let us know. >> >>> On Sep 29, 2015, at 5:38 PM, Sebastian Sickelmann wrote: >>> >>> Yes it is the only (non-test) source i could find in hotspot, but i want >>> to change it in all openjdk sources i can find it. >>> I thought i really must discuss it part by part in the mailing-lists. >>> Actually i am working on the issue to save against regression on this. >>> Thanks Alexandr for this input. So there will be something that >>> integrates into jtreg for this too. >>> >>> -- Sebastian >>> >>> >>> On 09/30/2015 01:11 AM, Christian Thalinger wrote: >>>> Thanks for volunteering to look into such old bugs! >>>> >>>> Is this the only occurrence of that pattern in the hotspot repository? If you want to fix this in hotspot only without the jdk changes described in the RFE (I just changed the type from Bug to Enhancement) then we have to file a new RFE because we can?t close the original one. >>>> >>>>> On Sep 27, 2015, at 6:58 AM, Sebastian Sickelmann wrote: >>>>> >>>>> Hello, >>>>> >>>>> my name is Sebastian Sickelmann and i signed the OCA. >>>>> >>>>> Actually I am searching through the JBS for low hanging fruits. >>>>> Right now i am looking through the openjdk-sources and try to evaluate >>>>> if i can make something about JDK-5108778. >>>>> >>>>> As I am not an author, I am actually not able to host webrevs on >>>>> cr.openjdk.java.net. >>>>> >>>>> Is there someone who would support at hosting the hotspot-part of >>>>> JDK-5108778 on cr.openjdk.java.net for reviewing? >>>>> >>>>> I placed the hotspot part in my dropbox at: >>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev/index.html >>>>> or as zip: >>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev.zip >>>>> >>>>> I executed all jtreg tests in hotspot/test and get no more errors than before the change. >>>>> >>>>> -- Sebastian >>>>> > From david.holmes at oracle.com Thu Dec 10 06:11:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Dec 2015 16:11:11 +1000 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot) In-Reply-To: <56690FED.8060401@gmx.de> References: <5608201C.4020109@gmx.de> <560B5939.6010100@gmx.de> <118235E4-AD96-4666-8A63-58FB403324BC@oracle.com> <5615798B.2080708@gmx.de> <56690FED.8060401@gmx.de> Message-ID: <5669177F.9060003@oracle.com> On 10/12/2015 3:38 PM, Sebastian Sickelmann wrote: > @Adding hotspot-runtime-dev > > Hi, > > a want to restart a discussion/review-process for on old "bug" JDK-5108778. > I created a webrev which is based on the jdk9/dev repo: > > http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ > > To enable a subrepo review/push-process I created a subtask for the > hotspot part of the change which is JDK-8145061. This simple improvement to the Java code seems fine to me. Thanks, David > The earlier mentioned jtreg-test(see below) was dropped due to some > initial misunderstandings. > > @Christian: As you initially responded to my first post I want you to > ask if you want to review / sponsor this fix? > > > -- > Sebastian > > > > On 10/07/2015 09:59 PM, Sebastian Sickelmann wrote: >> Please find the webrev hosted on openjdk-infrastructure at: >> >> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >> >> For some general discussion on regression-tests for this please find the >> thread in discuss[0][1] and for the general suggestion to make more >> wrapper-type-constructors deprecated find [2] at core-libs-dev. >> >> [0] >> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html >> [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html >> [2] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html >> >> -- Sebastian >> >> On 09/30/2015 07:50 AM, Christian Thalinger wrote: >>> Sounds good. If you have the final patch, let us know. >>> >>>> On Sep 29, 2015, at 5:38 PM, Sebastian Sickelmann wrote: >>>> >>>> Yes it is the only (non-test) source i could find in hotspot, but i want >>>> to change it in all openjdk sources i can find it. >>>> I thought i really must discuss it part by part in the mailing-lists. >>>> Actually i am working on the issue to save against regression on this. >>>> Thanks Alexandr for this input. So there will be something that >>>> integrates into jtreg for this too. >>>> >>>> -- Sebastian >>>> >>>> >>>> On 09/30/2015 01:11 AM, Christian Thalinger wrote: >>>>> Thanks for volunteering to look into such old bugs! >>>>> >>>>> Is this the only occurrence of that pattern in the hotspot repository? If you want to fix this in hotspot only without the jdk changes described in the RFE (I just changed the type from Bug to Enhancement) then we have to file a new RFE because we can?t close the original one. >>>>> >>>>>> On Sep 27, 2015, at 6:58 AM, Sebastian Sickelmann wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> my name is Sebastian Sickelmann and i signed the OCA. >>>>>> >>>>>> Actually I am searching through the JBS for low hanging fruits. >>>>>> Right now i am looking through the openjdk-sources and try to evaluate >>>>>> if i can make something about JDK-5108778. >>>>>> >>>>>> As I am not an author, I am actually not able to host webrevs on >>>>>> cr.openjdk.java.net. >>>>>> >>>>>> Is there someone who would support at hosting the hotspot-part of >>>>>> JDK-5108778 on cr.openjdk.java.net for reviewing? >>>>>> >>>>>> I placed the hotspot part in my dropbox at: >>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev/index.html >>>>>> or as zip: >>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev.zip >>>>>> >>>>>> I executed all jtreg tests in hotspot/test and get no more errors than before the change. >>>>>> >>>>>> -- Sebastian >>>>>> >> > From mattis.castegren at oracle.com Thu Dec 10 09:34:34 2015 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Thu, 10 Dec 2015 01:34:34 -0800 (PST) Subject: RFR: JDK-8144464 : WB method to start G1 concurrent mark cycle should be introduced In-Reply-To: <32212a1d-dd5b-4ad4-839f-521b8b6001bf@default> References: <32212a1d-dd5b-4ad4-839f-521b8b6001bf@default> Message-ID: Thomas, I believe you did the original fix of this. Could you take a quick look at the backport code review? There were only some very small conflicts in the backport Kind Regards /Mattis -----Original Message----- From: Shafi Ahmad Sent: den 9 december 2015 09:44 To: Shafi Ahmad; hotspot-dev at openjdk.java.net Subject: RE: RFR: JDK-8144464 : WB method to start G1 concurrent mark cycle should be introduced Hi, Please, can I get review for that backport? Thank you! Regards, Shafi From: Shafi Ahmad Sent: Friday, December 04, 2015 11:40 AM To: hotspot-runtime-dev at openjdk.java.net Subject: RFR: JDK-8144464 : WB method to start G1 concurrent mark cycle should be introduced Hi, Please review the backport of bug: "JDK-8144464: WB method to start G1 concurrent mark cycle should be introduced" to jdk8u-dev Webrev: http://cr.openjdk.java.net/~poonam/8144464/webrev.00/ jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8065579 Backport bug: https://bugs.openjdk.java.net/browse/JDK-8144464 Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1c207cfc557b Test: Run jprt and relevant jtreg test. Regards, Shafi From thomas.schatzl at oracle.com Thu Dec 10 10:12:54 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 10 Dec 2015 11:12:54 +0100 Subject: RFR: JDK-8144464 : WB method to start G1 concurrent mark cycle should be introduced In-Reply-To: References: <32212a1d-dd5b-4ad4-839f-521b8b6001bf@default> Message-ID: <1449742374.2249.13.camel@oracle.com> Hi, On Thu, 2015-12-10 at 01:34 -0800, Mattis Castegren wrote: > Thomas, I believe you did the original fix of this. Could you > take a quick look at the backport code review? There were only > some very small conflicts in the backport already did that yesterday, on the same mailing list, in the same thread, see http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021048.html Thanks, Thomas From aph at redhat.com Thu Dec 10 13:30:10 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 10 Dec 2015 13:30:10 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot Message-ID: <56697E62.9030306@redhat.com> I've been tracing through HotSpot with GCC's undefined behaviour sanitizer, which detects instances of undefined behaviour. There are many instances of UB we probably don't want to fix (e.g. unaliged accesses on x86) but some of them are serious. This patch fixes the signed integer overflow bugs in HotSpot which are certainly known to occur. There are surely many more such bugs but to begin with I want to concentrate on those. This patch introduces some functions which perform java-like arithmetic: java-add, etc. There is no perfectly portable way to do this in C++, but one way which is widely supported is known as the "union trick": put the signed integers in a union with their unsigned equivalents, do the arithmetic, and return the signed versions. The "obvious" way to do this via casts does not work with GCC and probably does not work with other compilers either. The union trick is well- supported by C++ compilers and generates efficient code. I believe that we should be able to use it everywhere. I have tried my utmost to change things as little as possible. There are certainly places where we could make things more efficient, but my goal was to limit the scope of this diff to fixing bugs. Apart from the undefined behaviour being fixed, this patch should cause no behavioural changes, except in one case. AdvancedThresholdPolicy::weight() grossly overflows, so much so that its result is substantially noise. That's fixed here. http://cr.openjdk.java.net/~aph/8145096-1/ Andrew. From coleen.phillimore at oracle.com Thu Dec 10 14:44:35 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Dec 2015 09:44:35 -0500 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot) In-Reply-To: <56690FED.8060401@gmx.de> References: <5608201C.4020109@gmx.de> <560B5939.6010100@gmx.de> <118235E4-AD96-4666-8A63-58FB403324BC@oracle.com> <5615798B.2080708@gmx.de> <56690FED.8060401@gmx.de> Message-ID: <56698FD3.9090707@oracle.com> Adding serviceability-dev. They work on this code. Coleen On 12/10/15 12:38 AM, Sebastian Sickelmann wrote: > @Adding hotspot-runtime-dev > > Hi, > > a want to restart a discussion/review-process for on old "bug" JDK-5108778. > I created a webrev which is based on the jdk9/dev repo: > > http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ > > To enable a subrepo review/push-process I created a subtask for the > hotspot part of the change which is JDK-8145061. > > The earlier mentioned jtreg-test(see below) was dropped due to some > initial misunderstandings. > > @Christian: As you initially responded to my first post I want you to > ask if you want to review / sponsor this fix? > > > -- > Sebastian > > > > On 10/07/2015 09:59 PM, Sebastian Sickelmann wrote: >> Please find the webrev hosted on openjdk-infrastructure at: >> >> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >> >> For some general discussion on regression-tests for this please find the >> thread in discuss[0][1] and for the general suggestion to make more >> wrapper-type-constructors deprecated find [2] at core-libs-dev. >> >> [0] >> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html >> [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html >> [2] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html >> >> -- Sebastian >> >> On 09/30/2015 07:50 AM, Christian Thalinger wrote: >>> Sounds good. If you have the final patch, let us know. >>> >>>> On Sep 29, 2015, at 5:38 PM, Sebastian Sickelmann wrote: >>>> >>>> Yes it is the only (non-test) source i could find in hotspot, but i want >>>> to change it in all openjdk sources i can find it. >>>> I thought i really must discuss it part by part in the mailing-lists. >>>> Actually i am working on the issue to save against regression on this. >>>> Thanks Alexandr for this input. So there will be something that >>>> integrates into jtreg for this too. >>>> >>>> -- Sebastian >>>> >>>> >>>> On 09/30/2015 01:11 AM, Christian Thalinger wrote: >>>>> Thanks for volunteering to look into such old bugs! >>>>> >>>>> Is this the only occurrence of that pattern in the hotspot repository? If you want to fix this in hotspot only without the jdk changes described in the RFE (I just changed the type from Bug to Enhancement) then we have to file a new RFE because we can?t close the original one. >>>>> >>>>>> On Sep 27, 2015, at 6:58 AM, Sebastian Sickelmann wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> my name is Sebastian Sickelmann and i signed the OCA. >>>>>> >>>>>> Actually I am searching through the JBS for low hanging fruits. >>>>>> Right now i am looking through the openjdk-sources and try to evaluate >>>>>> if i can make something about JDK-5108778. >>>>>> >>>>>> As I am not an author, I am actually not able to host webrevs on >>>>>> cr.openjdk.java.net. >>>>>> >>>>>> Is there someone who would support at hosting the hotspot-part of >>>>>> JDK-5108778 on cr.openjdk.java.net for reviewing? >>>>>> >>>>>> I placed the hotspot part in my dropbox at: >>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev/index.html >>>>>> or as zip: >>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev.zip >>>>>> >>>>>> I executed all jtreg tests in hotspot/test and get no more errors than before the change. >>>>>> >>>>>> -- Sebastian >>>>>> From erik.joelsson at oracle.com Thu Dec 10 14:49:42 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 Dec 2015 15:49:42 +0100 Subject: RFR: JDK-8145115: make JAVAC_FLAGS=-g no longer works In-Reply-To: <1449683585.3543.88.camel@redhat.com> References: <1449656620.3543.3.camel@redhat.com> <5668054C.6030708@oracle.com> <1449659738.3543.28.camel@redhat.com> <1449664422.3543.37.camel@redhat.com> <56685852.80705@oracle.com> <1449683585.3543.88.camel@redhat.com> Message-ID: <56699106.2000709@oracle.com> I looked closer at your actual command lines and managed to reproduce. The problem is JAVAC_FLAGS=-g. We have unfortunately used that name for a local variable in make/CompileJavaModules.gmk. Fix is pretty simple, just rename that local variable. In the longer term, we need to be able to enable -g for javac with a configure argument instead. Bug: https://bugs.openjdk.java.net/browse/JDK-8145115 Patch: diff -r a151b3ec17a1 make/CompileJavaModules.gmk --- a/make/CompileJavaModules.gmk +++ b/make/CompileJavaModules.gmk @@ -556,7 +556,7 @@ ifneq ($(BUILD_CRYPTO), true) CLASSPATH += $(JDK_OUTPUTDIR)/modules/$(MODULE) endif -JAVAC_FLAGS := -bootclasspath $(EMPTY_DIR) -extdirs $(EMPTY_DIR) \ +JAVAC_FLAGS_BOOTCLASSPATH := -bootclasspath $(EMPTY_DIR) -extdirs $(EMPTY_DIR) \ -endorseddirs $(EMPTY_DIR) $($(MODULE)_ADD_JAVAC_FLAGS) $(eval $(call SetupJavaCompilation, $(MODULE), \ @@ -566,7 +566,7 @@ BIN := $(if $($(MODULE)_BIN), $($(MODULE)_BIN), $(JDK_OUTPUTDIR)/modules/$(MODULE)), \ HEADERS := $(SUPPORT_OUTPUTDIR)/headers/$(MODULE), \ CLASSPATH := $(CLASSPATH), \ - ADD_JAVAC_FLAGS := $($(MODULE)_ADD_JAVAC_FLAGS) $(JAVAC_FLAGS) \ + ADD_JAVAC_FLAGS := $($(MODULE)_ADD_JAVAC_FLAGS) $(JAVAC_FLAGS_BOOTCLASSPATH) \ )) TARGETS += $($(MODULE)) $($(MODULE)_COPY_EXTRA) /Erik On 2015-12-09 18:53, Severin Gehwolf wrote: > Hi Erik, > > On Wed, 2015-12-09 at 17:35 +0100, Erik Joelsson wrote: >> I'm not able to reproduce with either OracleJDK 8 or 8u66. > The simplified reproducer is (extracted from build.log): > ( (/usr/bin/bash /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/common/bin/logger.sh /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /usr/lib/jvm/java-1.8.0-openjdk/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M "-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar" -cp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar com.sun.tools.sjavac.Main --server:portfile=/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/javacservers/server.port,id=java.logging,sjavac=/usr/lib/jvm/java-1.8.0-openjdk/bin/java%20-d64%20-Xms512M%20-Xmx2048M%20"-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar"%20-cp%20/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar%20com.sun.tools.sjavac.Main -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true -Xlint:all -Werror -g -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -g -cp "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.base:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging" -implicit:none -d /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging -h /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/support/headers/java.logging.java.logging.tmp @/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp && /usr/bin/rm -f /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log) || (exitcode=$? && /usr/bin/mv /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/failure-logs/java.logging.log && exit $exitcode) ) && /usr/bin/mv /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch > > I'm also attaching the failing command invocation as a file (Putting > this into a file and re-executing it reproduces the problem for me. Of > course, your paths may differ :) > > Cheers, > Severin > >> /Erik >> >> On 2015-12-09 13:33, Severin Gehwolf wrote: >>> Hi, >>> >>> On Wed, 2015-12-09 at 12:15 +0100, Severin Gehwolf wrote: >>>> Hi Mikael, >>>> >>>> On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote: >>>>> Hi Severin, >>>>> >>>>> On 2015-12-09 11:23, Severin Gehwolf wrote: >>>>>> Hi, >>>>>> >>>>>> I'm trying to build an OpenJDK 9, hs-rt tree which fails to >>>>>> build for >>>>>> me with: >>>>>> >>>>>> jdk/src/java.logging/share/classes/sun/util/logging/internal/ >>>>>> LoggingProviderImpl.java:33: error: cannot find symbol >>>>>> import java.lang.System.LoggerFinder; >>>>>> ^ >>>>>> symbol: class LoggerFinder >>>>>> location: class System >>>>> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src >>>>> /java.base/share/classes/java/lang/System.java#l1377 >>>>> the LoggerFinder inner class appears to exist on the hg server >>>>> at least. >>>> I have it in the local copy too, yet I get: >>>> CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux- >>>> x86_64-normal-server- >>>> release/jdk/modules/java.logging/_the.java.logging_batch' failed >>>> make/Main.gmk:150: recipe for target 'java.logging-java' failed >>>> >>>> With the above root-cause. I'll try with a fresh clone... >>> Same failure with fresh clone :( Here is how I configure and invoke >>> make: >>> bash configure \ >>> --with-boot-jdk="$JDK_TO_BUILD_WITH" \ >>> --with-debug-level="release" \ >>> --disable-zip-debug-info \ >>> --enable-unlimited-crypto \ >>> --with-stdc++lib=dynamic \ >>> --disable-warnings-as-errors \ >>> --with-num-cores=8 >>> >>> make \ >>> DEBUG_BINARIES=true \ >>> JAVAC_FLAGS=-g \ >>> STRIP_POLICY=no_strip \ >>> STRIP="" \ >>> DISABLE_INTREE_EC=true \ >>> ALT_OBJCOPY=none \ >>> LOG=debug \ >>> images >>> >>> Thanks, >>> Severin >>> >>>>>> $ hg paths >>>>>> default = http://hg.openjdk.java.net/jdk9/hs-rt/ >>>>>> >>>>>> Do I need to use a different tree these days? What am I >>>>>> missing? >>>>> No, it should work. >>>>> Are you sure you've updated all the sub-trees? >>>>> >>>>> http://hg.openjdk.java.net/code-tools/trees/ >>>>> Is a helpful hg extension to keep track of things. >>>>> >>>>> I've noticed that sometimes "bash get_source.sh" does not >>>>> correctly "hg >>>>> update" the entire forest. >>>> I should have an updated tree, though I usually use: >>>> $ hg pull -u >>>> $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do >>>> pushd $i; hg pull -u; popd; done >>>> >>>> I've checked just now and all repos seem to have updated >>>> correctly. The >>>> CI builder for Zero seems to agree[1]. Note: The above build >>>> failure is >>>> for a regular server JVM. Not sure what's wrong. I keep looking, >>>> thanks! >>>> >>>> Cheers, >>>> Severin >>>> >>>> [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/ >>>> 191/console >>>> >>>>> /Mikael >>>>> >>>>>> Thanks, >>>>>> Severin >>>>>> From staffan.larsen at oracle.com Thu Dec 10 14:56:19 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Dec 2015 15:56:19 +0100 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot) In-Reply-To: <56698FD3.9090707@oracle.com> References: <5608201C.4020109@gmx.de> <560B5939.6010100@gmx.de> <118235E4-AD96-4666-8A63-58FB403324BC@oracle.com> <5615798B.2080708@gmx.de> <56690FED.8060401@gmx.de> <56698FD3.9090707@oracle.com> Message-ID: <104B9ADF-89BB-4B88-A9F7-AD8CC53EDA7A@oracle.com> Looks good! Thanks, /Staffan > On 10 dec. 2015, at 15:44, Coleen Phillimore wrote: > > > Adding serviceability-dev. They work on this code. > Coleen > > > On 12/10/15 12:38 AM, Sebastian Sickelmann wrote: >> @Adding hotspot-runtime-dev >> >> Hi, >> >> a want to restart a discussion/review-process for on old "bug" JDK-5108778. >> I created a webrev which is based on the jdk9/dev repo: >> >> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >> >> To enable a subrepo review/push-process I created a subtask for the >> hotspot part of the change which is JDK-8145061. >> >> The earlier mentioned jtreg-test(see below) was dropped due to some >> initial misunderstandings. >> >> @Christian: As you initially responded to my first post I want you to >> ask if you want to review / sponsor this fix? >> >> >> -- >> Sebastian >> >> >> >> On 10/07/2015 09:59 PM, Sebastian Sickelmann wrote: >>> Please find the webrev hosted on openjdk-infrastructure at: >>> >>> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >>> >>> For some general discussion on regression-tests for this please find the >>> thread in discuss[0][1] and for the general suggestion to make more >>> wrapper-type-constructors deprecated find [2] at core-libs-dev. >>> >>> [0] >>> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html >>> [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html >>> [2] >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html >>> >>> -- Sebastian >>> >>> On 09/30/2015 07:50 AM, Christian Thalinger wrote: >>>> Sounds good. If you have the final patch, let us know. >>>> >>>>> On Sep 29, 2015, at 5:38 PM, Sebastian Sickelmann wrote: >>>>> >>>>> Yes it is the only (non-test) source i could find in hotspot, but i want >>>>> to change it in all openjdk sources i can find it. >>>>> I thought i really must discuss it part by part in the mailing-lists. >>>>> Actually i am working on the issue to save against regression on this. >>>>> Thanks Alexandr for this input. So there will be something that >>>>> integrates into jtreg for this too. >>>>> >>>>> -- Sebastian >>>>> >>>>> >>>>> On 09/30/2015 01:11 AM, Christian Thalinger wrote: >>>>>> Thanks for volunteering to look into such old bugs! >>>>>> >>>>>> Is this the only occurrence of that pattern in the hotspot repository? If you want to fix this in hotspot only without the jdk changes described in the RFE (I just changed the type from Bug to Enhancement) then we have to file a new RFE because we can?t close the original one. >>>>>> >>>>>>> On Sep 27, 2015, at 6:58 AM, Sebastian Sickelmann wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> my name is Sebastian Sickelmann and i signed the OCA. >>>>>>> >>>>>>> Actually I am searching through the JBS for low hanging fruits. >>>>>>> Right now i am looking through the openjdk-sources and try to evaluate >>>>>>> if i can make something about JDK-5108778. >>>>>>> >>>>>>> As I am not an author, I am actually not able to host webrevs on >>>>>>> cr.openjdk.java.net. >>>>>>> >>>>>>> Is there someone who would support at hosting the hotspot-part of >>>>>>> JDK-5108778 on cr.openjdk.java.net for reviewing? >>>>>>> >>>>>>> I placed the hotspot part in my dropbox at: >>>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev/index.html >>>>>>> or as zip: >>>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev.zip >>>>>>> >>>>>>> I executed all jtreg tests in hotspot/test and get no more errors than before the change. >>>>>>> >>>>>>> -- Sebastian >>>>>>> > From sgehwolf at redhat.com Thu Dec 10 15:02:25 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 10 Dec 2015 16:02:25 +0100 Subject: RFR: JDK-8145115: make JAVAC_FLAGS=-g no longer works In-Reply-To: <56699106.2000709@oracle.com> References: <1449656620.3543.3.camel@redhat.com> <5668054C.6030708@oracle.com> <1449659738.3543.28.camel@redhat.com> <1449664422.3543.37.camel@redhat.com> <56685852.80705@oracle.com> <1449683585.3543.88.camel@redhat.com> <56699106.2000709@oracle.com> Message-ID: <1449759745.3577.22.camel@redhat.com> On Thu, 2015-12-10 at 15:49 +0100, Erik Joelsson wrote: > I looked closer at your actual command lines and managed to reproduce.? > The problem is JAVAC_FLAGS=-g. We have unfortunately used that name for? > a local variable in make/CompileJavaModules.gmk. Fix is pretty simple,? > just rename that local variable. OK thanks. > In the longer term, we need to be able? > to enable -g for javac with a configure argument instead. Yes, pretty please :) This is a long standing issue (not just java class debug info, but debug info in general). See JDK-8036003 with review thread: http://mail.openjdk.java.net/pipermail/build-dev/2015-December/016155.html Once JDK-8036003 is fixed we'd need something similar for Java classes and we can get rid of invoking make with build internal variables. Thanks, Severin > Bug: https://bugs.openjdk.java.net/browse/JDK-8145115 > Patch: > diff -r a151b3ec17a1 make/CompileJavaModules.gmk > --- a/make/CompileJavaModules.gmk > +++ b/make/CompileJavaModules.gmk > @@ -556,7 +556,7 @@ > ????ifneq ($(BUILD_CRYPTO), true) > ????CLASSPATH += $(JDK_OUTPUTDIR)/modules/$(MODULE) > ????endif > -JAVAC_FLAGS := -bootclasspath $(EMPTY_DIR) -extdirs $(EMPTY_DIR) \ > +JAVAC_FLAGS_BOOTCLASSPATH := -bootclasspath $(EMPTY_DIR) -extdirs? > $(EMPTY_DIR) \ > ??????-endorseddirs $(EMPTY_DIR) $($(MODULE)_ADD_JAVAC_FLAGS) > > ? $(eval $(call SetupJavaCompilation, $(MODULE), \ > @@ -566,7 +566,7 @@ > ??????BIN := $(if $($(MODULE)_BIN), $($(MODULE)_BIN),? > $(JDK_OUTPUTDIR)/modules/$(MODULE)), \ > ??????HEADERS := $(SUPPORT_OUTPUTDIR)/headers/$(MODULE), \ > ??????CLASSPATH := $(CLASSPATH), \ > -????ADD_JAVAC_FLAGS := $($(MODULE)_ADD_JAVAC_FLAGS) $(JAVAC_FLAGS) \ > +????ADD_JAVAC_FLAGS := $($(MODULE)_ADD_JAVAC_FLAGS)? > $(JAVAC_FLAGS_BOOTCLASSPATH) \ > ? )) > ? TARGETS += $($(MODULE)) $($(MODULE)_COPY_EXTRA) > > /Erik > > On 2015-12-09 18:53, Severin Gehwolf wrote: > > Hi Erik, > > > > On Wed, 2015-12-09 at 17:35 +0100, Erik Joelsson wrote: > > > I'm not able to reproduce with either OracleJDK 8 or 8u66. > > The simplified reproducer is (extracted from build.log): > > ( (/usr/bin/bash /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/common/bin/logger.sh??/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /usr/lib/jvm/java-1.8.0-openjdk/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M "-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar" -cp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar com.sun.tools.sjavac.Main --server:portfile=/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/javacservers/server.port,id=java.logging,sjavac=/usr/lib/jvm/java-1.8.0-openjdk/bin/java%20-d64%20-Xms512M%20-Xmx2048M%20"-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar"%20-cp%20/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar%20com.sun.tools.sjavac.Main -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true -Xlint:all -Werror -g -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -g -cp "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.base:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging" -implicit:none -d /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging -h /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/support/headers/java.logging.java.logging.tmp @/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp && /usr/bin/rm -f??/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log) || (exitcode=$? && /usr/bin/mv??/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/failure-logs/java.logging.log && exit $exitcode) ) && /usr/bin/mv /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch > > > > I'm also attaching the failing command invocation as a file (Putting > > this into a file and re-executing it reproduces the problem for me. Of > > course, your paths may differ :) > > > > Cheers, > > Severin > > > > > /Erik > > > > > > On 2015-12-09 13:33, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > On Wed, 2015-12-09 at 12:15 +0100, Severin Gehwolf wrote: > > > > > Hi Mikael, > > > > > > > > > > On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote: > > > > > > Hi Severin, > > > > > > > > > > > > On 2015-12-09 11:23, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'm trying to build an OpenJDK 9, hs-rt tree which fails to > > > > > > > build for > > > > > > > me with: > > > > > > > > > > > > > > jdk/src/java.logging/share/classes/sun/util/logging/internal/ > > > > > > > LoggingProviderImpl.java:33: error: cannot find symbol > > > > > > > import java.lang.System.LoggerFinder; > > > > > > > ??????????????????????????^ > > > > > > > ?????symbol:???class LoggerFinder > > > > > > > ?????location: class System > > > > > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src > > > > > > /java.base/share/classes/java/lang/System.java#l1377 > > > > > > the LoggerFinder inner class appears to exist on the hg server > > > > > > at least. > > > > > I have it in the local copy too, yet I get: > > > > > CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux- > > > > > x86_64-normal-server- > > > > > release/jdk/modules/java.logging/_the.java.logging_batch' failed > > > > > make/Main.gmk:150: recipe for target 'java.logging-java' failed > > > > > > > > > > With the above root-cause. I'll try with a fresh clone... > > > > Same failure with fresh clone :( Here is how I configure and invoke > > > > make: > > > > bash configure \ > > > > ???--with-boot-jdk="$JDK_TO_BUILD_WITH" \ > > > > ???--with-debug-level="release" \ > > > > ???--disable-zip-debug-info \ > > > > ???--enable-unlimited-crypto \ > > > > ???--with-stdc++lib=dynamic \ > > > > ???--disable-warnings-as-errors \ > > > > ???--with-num-cores=8 > > > > > > > > make \ > > > > ???DEBUG_BINARIES=true \ > > > > ???JAVAC_FLAGS=-g \ > > > > ???STRIP_POLICY=no_strip \ > > > > ???STRIP="" \ > > > > ???DISABLE_INTREE_EC=true \ > > > > ???ALT_OBJCOPY=none \ > > > > ???LOG=debug \ > > > > ???images > > > > > > > > Thanks, > > > > Severin > > > > > > > > > > > $ hg paths > > > > > > > default = http://hg.openjdk.java.net/jdk9/hs-rt/ > > > > > > > > > > > > > > Do I need to use a different tree these days? What am I > > > > > > > missing? > > > > > > No, it should work. > > > > > > Are you sure you've updated all the sub-trees? > > > > > > > > > > > > http://hg.openjdk.java.net/code-tools/trees/ > > > > > > Is a helpful hg extension to keep track of things. > > > > > > > > > > > > I've noticed that sometimes "bash get_source.sh" does not > > > > > > correctly "hg > > > > > > update" the entire forest. > > > > > I should have an updated tree, though I usually use: > > > > > $ hg pull -u > > > > > $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do > > > > > pushd $i; hg pull -u; popd; done > > > > > > > > > > I've checked just now and all repos seem to have updated > > > > > correctly. The > > > > > CI builder for Zero seems to agree[1]. Note: The above build > > > > > failure is > > > > > for a regular server JVM. Not sure what's wrong. I keep looking, > > > > > thanks! > > > > > > > > > > Cheers, > > > > > Severin > > > > > > > > > > [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/ > > > > > 191/console > > > > > > > > > > > /Mikael > > > > > > > > > > > > > Thanks, > > > > > > > Severin > > > > > > > > > From sebastian.sickelmann at gmx.de Thu Dec 10 16:58:36 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Thu, 10 Dec 2015 17:58:36 +0100 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot) In-Reply-To: <104B9ADF-89BB-4B88-A9F7-AD8CC53EDA7A@oracle.com> References: <5608201C.4020109@gmx.de> <560B5939.6010100@gmx.de> <118235E4-AD96-4666-8A63-58FB403324BC@oracle.com> <5615798B.2080708@gmx.de> <56690FED.8060401@gmx.de> <56698FD3.9090707@oracle.com> <104B9ADF-89BB-4B88-A9F7-AD8CC53EDA7A@oracle.com> Message-ID: <5669AF3C.1000205@gmx.de> Thanks for the reviews so far. I am not sure how the serviceability thing need to be handled. Should there be a review-result of a serviceability-member? I think nether david or staffan are members of the serviceability-group. If it is not the case here would be the changeset so far. As I am not a committer I would need some support to push this. http://cr.openjdk.java.net/~sebastian/8145061/webrev.00/ Don't be confused i have used the sub-task issue-number for the hotspot sub-patch for this webrev and commit-message, to not sideeffect-close the main-issue in the JBS. -- Sebastian On 12/10/2015 03:56 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 10 dec. 2015, at 15:44, Coleen Phillimore wrote: >> >> >> Adding serviceability-dev. They work on this code. >> Coleen >> >> >> On 12/10/15 12:38 AM, Sebastian Sickelmann wrote: >>> @Adding hotspot-runtime-dev >>> >>> Hi, >>> >>> a want to restart a discussion/review-process for on old "bug" JDK-5108778. >>> I created a webrev which is based on the jdk9/dev repo: >>> >>> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >>> >>> To enable a subrepo review/push-process I created a subtask for the >>> hotspot part of the change which is JDK-8145061. >>> >>> The earlier mentioned jtreg-test(see below) was dropped due to some >>> initial misunderstandings. >>> >>> @Christian: As you initially responded to my first post I want you to >>> ask if you want to review / sponsor this fix? >>> >>> >>> -- >>> Sebastian >>> >>> >>> >>> On 10/07/2015 09:59 PM, Sebastian Sickelmann wrote: >>>> Please find the webrev hosted on openjdk-infrastructure at: >>>> >>>> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >>>> >>>> For some general discussion on regression-tests for this please find the >>>> thread in discuss[0][1] and for the general suggestion to make more >>>> wrapper-type-constructors deprecated find [2] at core-libs-dev. >>>> >>>> [0] >>>> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html >>>> [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html >>>> >>>> -- Sebastian >>>> >>>> On 09/30/2015 07:50 AM, Christian Thalinger wrote: >>>>> Sounds good. If you have the final patch, let us know. >>>>> >>>>>> On Sep 29, 2015, at 5:38 PM, Sebastian Sickelmann wrote: >>>>>> >>>>>> Yes it is the only (non-test) source i could find in hotspot, but i want >>>>>> to change it in all openjdk sources i can find it. >>>>>> I thought i really must discuss it part by part in the mailing-lists. >>>>>> Actually i am working on the issue to save against regression on this. >>>>>> Thanks Alexandr for this input. So there will be something that >>>>>> integrates into jtreg for this too. >>>>>> >>>>>> -- Sebastian >>>>>> >>>>>> >>>>>> On 09/30/2015 01:11 AM, Christian Thalinger wrote: >>>>>>> Thanks for volunteering to look into such old bugs! >>>>>>> >>>>>>> Is this the only occurrence of that pattern in the hotspot repository? If you want to fix this in hotspot only without the jdk changes described in the RFE (I just changed the type from Bug to Enhancement) then we have to file a new RFE because we can?t close the original one. >>>>>>> >>>>>>>> On Sep 27, 2015, at 6:58 AM, Sebastian Sickelmann wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> my name is Sebastian Sickelmann and i signed the OCA. >>>>>>>> >>>>>>>> Actually I am searching through the JBS for low hanging fruits. >>>>>>>> Right now i am looking through the openjdk-sources and try to evaluate >>>>>>>> if i can make something about JDK-5108778. >>>>>>>> >>>>>>>> As I am not an author, I am actually not able to host webrevs on >>>>>>>> cr.openjdk.java.net. >>>>>>>> >>>>>>>> Is there someone who would support at hosting the hotspot-part of >>>>>>>> JDK-5108778 on cr.openjdk.java.net for reviewing? >>>>>>>> >>>>>>>> I placed the hotspot part in my dropbox at: >>>>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev/index.html >>>>>>>> or as zip: >>>>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev.zip >>>>>>>> >>>>>>>> I executed all jtreg tests in hotspot/test and get no more errors than before the change. >>>>>>>> >>>>>>>> -- Sebastian >>>>>>>> > From staffan.larsen at oracle.com Thu Dec 10 19:51:06 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Dec 2015 20:51:06 +0100 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot) In-Reply-To: <5669AF3C.1000205@gmx.de> References: <5608201C.4020109@gmx.de> <560B5939.6010100@gmx.de> <118235E4-AD96-4666-8A63-58FB403324BC@oracle.com> <5615798B.2080708@gmx.de> <56690FED.8060401@gmx.de> <56698FD3.9090707@oracle.com> <104B9ADF-89BB-4B88-A9F7-AD8CC53EDA7A@oracle.com> <5669AF3C.1000205@gmx.de> Message-ID: <5ED98454-9384-4613-846B-484A9644D57C@oracle.com> > On 10 dec. 2015, at 17:58, Sebastian Sickelmann wrote: > > Thanks for the reviews so far. > > I am not sure how the serviceability thing need to be handled. Should > there be a review-result of a serviceability-member? > I think nether david or staffan are members of the serviceability-group. You need reviews from at least one Reviewer and from someone who works in the serviceability area (it can be the same person). You now have two reviews from two Reviewers one of whom (me) works in the serviceability area, so you are good to go. > If it is not the case here would be the changeset so far. As I am not a > committer I would need some support to push this. > > http://cr.openjdk.java.net/~sebastian/8145061/webrev.00/ If you send me (privately) the ?hg export? output of your patch, with the correct commit message (http://openjdk.java.net/guide/producingChangeset.html#create ), I can push it for you. Thanks, /Staffan > > Don't be confused i have used the sub-task issue-number for the hotspot sub-patch for this webrev and commit-message, to not sideeffect-close the main-issue in the JBS. > > -- > Sebastian > > > On 12/10/2015 03:56 PM, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >>> On 10 dec. 2015, at 15:44, Coleen Phillimore wrote: >>> >>> >>> Adding serviceability-dev. They work on this code. >>> Coleen >>> >>> >>> On 12/10/15 12:38 AM, Sebastian Sickelmann wrote: >>>> @Adding hotspot-runtime-dev >>>> >>>> Hi, >>>> >>>> a want to restart a discussion/review-process for on old "bug" JDK-5108778. >>>> I created a webrev which is based on the jdk9/dev repo: >>>> >>>> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >>>> >>>> To enable a subrepo review/push-process I created a subtask for the >>>> hotspot part of the change which is JDK-8145061. >>>> >>>> The earlier mentioned jtreg-test(see below) was dropped due to some >>>> initial misunderstandings. >>>> >>>> @Christian: As you initially responded to my first post I want you to >>>> ask if you want to review / sponsor this fix? >>>> >>>> >>>> -- >>>> Sebastian >>>> >>>> >>>> >>>> On 10/07/2015 09:59 PM, Sebastian Sickelmann wrote: >>>>> Please find the webrev hosted on openjdk-infrastructure at: >>>>> >>>>> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >>>>> >>>>> For some general discussion on regression-tests for this please find the >>>>> thread in discuss[0][1] and for the general suggestion to make more >>>>> wrapper-type-constructors deprecated find [2] at core-libs-dev. >>>>> >>>>> [0] >>>>> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html >>>>> [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html >>>>> >>>>> -- Sebastian >>>>> >>>>> On 09/30/2015 07:50 AM, Christian Thalinger wrote: >>>>>> Sounds good. If you have the final patch, let us know. >>>>>> >>>>>>> On Sep 29, 2015, at 5:38 PM, Sebastian Sickelmann wrote: >>>>>>> >>>>>>> Yes it is the only (non-test) source i could find in hotspot, but i want >>>>>>> to change it in all openjdk sources i can find it. >>>>>>> I thought i really must discuss it part by part in the mailing-lists. >>>>>>> Actually i am working on the issue to save against regression on this. >>>>>>> Thanks Alexandr for this input. So there will be something that >>>>>>> integrates into jtreg for this too. >>>>>>> >>>>>>> -- Sebastian >>>>>>> >>>>>>> >>>>>>> On 09/30/2015 01:11 AM, Christian Thalinger wrote: >>>>>>>> Thanks for volunteering to look into such old bugs! >>>>>>>> >>>>>>>> Is this the only occurrence of that pattern in the hotspot repository? If you want to fix this in hotspot only without the jdk changes described in the RFE (I just changed the type from Bug to Enhancement) then we have to file a new RFE because we can?t close the original one. >>>>>>>> >>>>>>>>> On Sep 27, 2015, at 6:58 AM, Sebastian Sickelmann wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> my name is Sebastian Sickelmann and i signed the OCA. >>>>>>>>> >>>>>>>>> Actually I am searching through the JBS for low hanging fruits. >>>>>>>>> Right now i am looking through the openjdk-sources and try to evaluate >>>>>>>>> if i can make something about JDK-5108778. >>>>>>>>> >>>>>>>>> As I am not an author, I am actually not able to host webrevs on >>>>>>>>> cr.openjdk.java.net. >>>>>>>>> >>>>>>>>> Is there someone who would support at hosting the hotspot-part of >>>>>>>>> JDK-5108778 on cr.openjdk.java.net for reviewing? >>>>>>>>> >>>>>>>>> I placed the hotspot part in my dropbox at: >>>>>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev/index.html >>>>>>>>> or as zip: >>>>>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev.zip >>>>>>>>> >>>>>>>>> I executed all jtreg tests in hotspot/test and get no more errors than before the change. >>>>>>>>> >>>>>>>>> -- Sebastian >>>>>>>>> >> > From kim.barrett at oracle.com Thu Dec 10 21:44:39 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Dec 2015 16:44:39 -0500 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <56697E62.9030306@redhat.com> References: <56697E62.9030306@redhat.com> Message-ID: On Dec 10, 2015, at 8:30 AM, Andrew Haley wrote: > > I've been tracing through HotSpot with GCC's undefined behaviour > sanitizer Nice! I've only skimmed the changes in the opto directory. You should get compiler people to review those changes. > This patch introduces some functions which perform java-like > arithmetic: java-add, etc. There is no perfectly portable way to do > this in C++, I disagree; see below. > but one way which is widely supported is known as the > "union trick": put the signed integers in a union with their unsigned > equivalents, do the arithmetic, and return the signed versions. The > "obvious" way to do this via casts does not work with GCC and probably > does not work with other compilers either. The union trick is well- > supported by C++ compilers and generates efficient code. I believe > that we should be able to use it everywhere. > > Apart from the undefined behaviour being fixed, this patch should > cause no behavioural changes, except in one case. > AdvancedThresholdPolicy::weight() grossly overflows, so much so that > its result is substantially noise. That's fixed here. Nice find. > http://cr.openjdk.java.net/~aph/8145096-1/ > ------------------------------------------------------------------------------ src/os/posix/vm/os_posix.cpp 756 unsigned int i; I'm not sure what the purpose of changing this to unsigned might be. The sa_flags member of struct sigaction is of type int. ------------------------------------------------------------------------------ 136 return (double)(method->rate() + 1) * ((double)(method->invocation_count() + 1) * (method->backedge_count() + 1)); I suspect the problem encountered here is that the multiplication of the two count values can overflow. If that multiplication was not grouped, but instead the rate term and invocation count were multiplied, then multiplied by the backedge count (e.g. use the natural grouping for operator*), the result should be mathematically the same, and I think should not run into overflow problems. Recall that method->rate() returns float. So I think a simpler change here might be return (method->rate() + 1) * (method->invocation_count() + 1) * (method->backedge_count() + 1); i.e. remove the parens that group the count multiplication before multiplying by the rate. ------------------------------------------------------------------------------ src/share/vm/utilities/globalDefinitions.hpp 1425 #define JAVA_INTEGER_OP(OP, NAME, TYPE, UNSIGNED_TYPE) \ 1426 static inline TYPE NAME (TYPE in1, TYPE in2) { \ 1427 union { TYPE n1; UNSIGNED_TYPE u1; }; \ 1428 union { TYPE n2; UNSIGNED_TYPE u2; }; \ 1429 n1 = in1; n2 = in2; \ 1430 u1 OP ## = u2; \ 1431 return n1; \ 1432 } e.g. using the "union trick" for type punning. To me, this seems to be trading one form of undefined behavior for another. Since there *is* a portable solution, which I understand is also well supported / optimized by compilers, I'd prefer that. #define JAVA_INTEGER_OP(OP, NAME, TYPE, UNSIGNED_TYPE) \ inline TYPE NAME (TYPE in1, TYPE in2) { \ STATIC_ASSERT(sizeof(TYPE) == sizeof(UNSIGNED_TYPE)); \ UNSIGNED_TYPE ures = static_cast(in1); \ ures OP ## = static_cast(in2); \ TYPE res; \ memcpy(&res, &ures, sizeof(res)); \ return res; \ } gcc4.8 with -O generates exactly the code one would like for this. (And unsurprisingly generates pretty horrible code with -O0.) I'm collecting information about other platforms that I have access to or know someone who does. The casts to the unsigned type here are portable. What would not be portable is a cast of ures to the signed type, which has implementation-defined behavior (and *not* undefined behavior) for some values. So I was surprised by the statement The "obvious" way to do this via casts does not work with GCC ... when the gcc documentation says https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Integers-implementation.html#Integers-implementation 4.5 Integers For conversion to a type of width N, the value is reduced modulo 2^N to be within range of the type; no signal is raised. Of course, one shouldn't rely on this in portable code. Note that I would not like to see these java_xxx functions used as a general "solution" to overflow problems. Most cases of signed integer arithmetic overflow are actual bugs, and papering over them with these functions would be a mistake. I haven't reviewed them carefully, but the way these are being used in the various changes in the opto directory look appropriate, in order to match Java's defined behavior. But I wouldn't be surprised if there were other places (like the problem found in advancedThresholdPolicy.cpp) where I would not want these operations used. In fact, I'd like the comment describing these operations to say something along that line. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Thu Dec 10 23:13:18 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Dec 2015 18:13:18 -0500 Subject: RFR (L): 8134994: use separate VMStructs databases for SA and JVMCI In-Reply-To: <1D6BE603-E996-495C-94BB-C0A8697B07B3@oracle.com> References: <1D6BE603-E996-495C-94BB-C0A8697B07B3@oracle.com> Message-ID: On Dec 9, 2015, at 5:16 PM, Christian Thalinger wrote: > > https://bugs.openjdk.java.net/browse/JDK-8134994 > http://cr.openjdk.java.net/~twisti/8134994/webrev/ > > Currently JVMCI uses the existing VMStructs database which the SA also uses. In order to be more flexible with the future of the SA the JVMCI should use it's own database. Thanks for doing this. My hope is that, eventually, all the friendship with JVMCIVMStructs will be eliminated, and JVMCI will only be relying on public APIs that the various components provide for that purpose. But this is a good start, giving much better visibility into what JVMCI is using. ------------------------------------------------------------------------------ src/share/vm/gc/g1/ptrQueue.hpp 41 class PtrQueue VALUE_OBJ_CLASS_SPEC { 42 friend class VMStructs; 43 friend class JVMCIVMStructs; I thought I'd fixed things so JVMCI shouldn't need PtrQueue friendship. I think the APIs it needs and uses are public in SATBMarkQueue and DirtyCardQueue. Oh, but some of the relevant code has been removed from src/share/vm/gc/g1/vmStructs_g1.hpp, and I don't (yet) see it having been relocated. Indeed, it looks like at least part of my change has been lost, since we are back to src/share/vm/jvmci/vmStructs_jvmci.cpp 207 nonstatic_field(PtrQueue, _active, bool) \ 208 nonstatic_field(PtrQueue, _buf, void**) \ 209 nonstatic_field(PtrQueue, _index, size_t) \ Here's the change that seems to have been (partially?) undone: https://bugs.openjdk.java.net/browse/JDK-8143014 Access PtrQueue member offsets through derived classes But searching through vmStructs_jvmci.cpp, it looks like the only problem might be that the PtrQueue friendship and the PtrQueue field access in vmStructs_jvmci.cpp are not needed and should be removed. ------------------------------------------------------------------------------ src/share/vm/gc/shared/cardTableModRefBS.hpp 43 class CardTableModRefBS: public ModRefBarrierSet { 44 // Some classes get to look at some private stuff. 45 friend class VMStructs; 46 friend class JVMCIVMStructs; I thought we'd eliminated the need for this friendship for JVMCI too, though I'm less certain in this case. Maybe its just been discussed how it could be done, but hasn't been done yet? ------------------------------------------------------------------------------ src/share/vm/jvmci/jvmciCompilerToVM.cpp 186 jbyte* base = ((CardTableModRefBS*)bs)->byte_map_base; Use barrier_set_cast(bs), so that when we refactor the barrier set hierarchy (which we plan to do), this will break in an obvious way. And instead of the switch on bs->kind(), maybe use if (bs->is_a(BarrierSet::CardTableModRefBS)) { ... ; } else { ShouldNotReachHere(); } All current implementations of BarrierSet are CTMRBS. If/when that's no longer true, this will break in an obvious way. ------------------------------------------------------------------------------ From coleen.phillimore at oracle.com Fri Dec 11 02:54:09 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Dec 2015 21:54:09 -0500 Subject: RFR(L): 8145117: PPC64: Remove cpp interpreter implementation In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDDB64@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41EDDB64@DEWDFEMB12A.global.corp.sap> Message-ID: <566A3AD1.10402@oracle.com> Also, I wonder if someone from RedHat would like to do the same with the AARCH64 platform? thanks, Coleen On 12/10/15 10:35 AM, Lindenmaier, Goetz wrote: > Hi, > > This change removed the cpp interpreter form the ppc sources. > It's broken anyways. The change is ppc only. > http://cr.openjdk.java.net/~goetz/webrevs/8145117-ccInterp/webrev.00/ > > Best regards, > Goetz. > > From asmundak at google.com Fri Dec 11 04:15:35 2015 From: asmundak at google.com (Alexander Smundak) Date: Thu, 10 Dec 2015 20:15:35 -0800 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <566906CE.2050101@oracle.com> References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> <5664DBF9.7010708@oracle.com> <566660B2.4030100@oracle.com> <56679B9F.8030105@oracle.com> <566906CE.2050101@oracle.com> Message-ID: I have jcheck enabled, so I am surprised that the absence of the Reviewed-by: field was not flagged. Anyways, here's the new set: http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.04 http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.04 http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.04 Note that I don't have access to the big-endian PowerPC64. The original patch was verified by goetz.lindenmaier at sap.com, but it has changed since. Goetz, can you verify that the new patch still works? Sasha On Wed, Dec 9, 2015 at 8:59 PM, David Holmes wrote: > On 10/12/2015 4:16 AM, Alexander Smundak wrote: >> >> I am confused -- is there anything you want me to change in the existing >> set: >> >> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03 >> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03 >> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03 > > > Yes they need to be created using the correct, jcheck[1] compliant, commit > messages: > > http://openjdk.java.net/guide/producingChangeset.html > > Mainly Reviewers seem to be missing - but I'm also not sure other details > are jcheck compliant. > > Thanks, > David > > [1] http://openjdk.java.net/projects/code-tools/jcheck/ > > >> Sasha >> >> On Tue, Dec 8, 2015 at 7:10 PM, David Holmes >> wrote: >>> >>> I can sponsor for you Sasha. Just email me the changeset, or a link >>> thereto. >>> >>> Thanks, >>> David >>> >>> >>> On 9/12/2015 3:44 AM, Alexander Smundak wrote: >>>> >>>> >>>> Thank you for the review. >>>> If everyone involved is satisfied with the patch, I need a sponsor. >>>> >>>> Sasha >>>> >>>> On Mon, Dec 7, 2015 at 8:46 PM, David Holmes >>>> wrote: >>>>> >>>>> >>>>> On 8/12/2015 1:44 PM, Alexander Smundak wrote: >>>>>> >>>>>> >>>>>> >>>>>> It is achievable by adding a small ppc-specific check to the >>>>>> common/autoconf/platform.m4: >>>>>> >>>>>> @@ -282,6 +282,8 @@ >>>>>> elif test "x$OPENJDK_TARGET_OS" != xmacosx && test >>>>>> "x$OPENJDK_TARGET_CPU" = xx86_64; then >>>>>> # On all platforms except MacOSX replace x86_64 with amd64. >>>>>> OPENJDK_TARGET_CPU_LEGACY="amd64" >>>>>> + elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then >>>>>> + OPENJDK_TARGET_CPU_LEGACY="ppc64" >>>>>> fi >>>>>> AC_SUBST(OPENJDK_TARGET_CPU_LEGACY) >>>>>> >>>>>> However, there is a code in make/Images.gmk using >>>>>> OPENJDK_TARGET_CPU_LEGACY >>>>>> $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)") >>>>>> so that the 'release' file in the image directory will now have >>>>>> JAVA_VERSION="9" >>>>>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt" >>>>>> OS_NAME="Linux" >>>>>> OS_VERSION="2.6" >>>>>> OS_ARCH="ppc64" >>>>>> ^^^^^^^^ >>>>>> SOURCE=.., >>>>>> >>>>>> instead of "ppc64le". >>>>>> >>>>>> If someone can tell me which other variable I should use to achieve >>>>>> that without changing the contents of the 'release' file on other >>>>>> platforms, I'll be grateful. >>>>> >>>>> >>>>> >>>>> >>>>> Okay never mind - and thanks for looking into this. I see now this is >>>>> set >>>>> via: >>>>> >>>>> ./autoconf/flags.m4: COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK >>>>> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY" >>>>> >>>>> so there is no way to add a second value without introducing some >>>>> additional >>>>> variable. At the hotspot level it could be handled differently if we >>>>> had >>>>> a >>>>> platform_ppc64le file, as it could just be added to the SYSDEFS. >>>>> >>>>> Thanks, >>>>> David From david.holmes at oracle.com Fri Dec 11 04:47:49 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Dec 2015 14:47:49 +1000 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> <5664DBF9.7010708@oracle.com> <566660B2.4030100@oracle.com> <56679B9F.8030105@oracle.com> <566906CE.2050101@oracle.com> Message-ID: <566A5575.3020908@oracle.com> On 11/12/2015 2:15 PM, Alexander Smundak wrote: > I have jcheck enabled, so I am surprised that the absence of the > Reviewed-by: field was not flagged. Anyways, here's the new set: Not sure what is going on with your jcheck setup but the formatting is still wrong: - the changeset "user" must be OpenJDK username not email address - reviewers must be OpenJDK user names not email addresses - contributed-by attribution should be simple email address or the following is also allowed: Andrew Hughes Sorry. David ----- > http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.04 > http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.04 > http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.04 > > Note that I don't have access to the big-endian PowerPC64. The > original patch was verified by goetz.lindenmaier at sap.com, but it has > changed since. Goetz, can you verify that the new patch still works? > > Sasha > > On Wed, Dec 9, 2015 at 8:59 PM, David Holmes wrote: >> On 10/12/2015 4:16 AM, Alexander Smundak wrote: >>> >>> I am confused -- is there anything you want me to change in the existing >>> set: >>> >>> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03 >>> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03 >>> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03 >> >> >> Yes they need to be created using the correct, jcheck[1] compliant, commit >> messages: >> >> http://openjdk.java.net/guide/producingChangeset.html >> >> Mainly Reviewers seem to be missing - but I'm also not sure other details >> are jcheck compliant. >> >> Thanks, >> David >> >> [1] http://openjdk.java.net/projects/code-tools/jcheck/ >> >> >>> Sasha >>> >>> On Tue, Dec 8, 2015 at 7:10 PM, David Holmes >>> wrote: >>>> >>>> I can sponsor for you Sasha. Just email me the changeset, or a link >>>> thereto. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> On 9/12/2015 3:44 AM, Alexander Smundak wrote: >>>>> >>>>> >>>>> Thank you for the review. >>>>> If everyone involved is satisfied with the patch, I need a sponsor. >>>>> >>>>> Sasha >>>>> >>>>> On Mon, Dec 7, 2015 at 8:46 PM, David Holmes >>>>> wrote: >>>>>> >>>>>> >>>>>> On 8/12/2015 1:44 PM, Alexander Smundak wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> It is achievable by adding a small ppc-specific check to the >>>>>>> common/autoconf/platform.m4: >>>>>>> >>>>>>> @@ -282,6 +282,8 @@ >>>>>>> elif test "x$OPENJDK_TARGET_OS" != xmacosx && test >>>>>>> "x$OPENJDK_TARGET_CPU" = xx86_64; then >>>>>>> # On all platforms except MacOSX replace x86_64 with amd64. >>>>>>> OPENJDK_TARGET_CPU_LEGACY="amd64" >>>>>>> + elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then >>>>>>> + OPENJDK_TARGET_CPU_LEGACY="ppc64" >>>>>>> fi >>>>>>> AC_SUBST(OPENJDK_TARGET_CPU_LEGACY) >>>>>>> >>>>>>> However, there is a code in make/Images.gmk using >>>>>>> OPENJDK_TARGET_CPU_LEGACY >>>>>>> $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)") >>>>>>> so that the 'release' file in the image directory will now have >>>>>>> JAVA_VERSION="9" >>>>>>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt" >>>>>>> OS_NAME="Linux" >>>>>>> OS_VERSION="2.6" >>>>>>> OS_ARCH="ppc64" >>>>>>> ^^^^^^^^ >>>>>>> SOURCE=.., >>>>>>> >>>>>>> instead of "ppc64le". >>>>>>> >>>>>>> If someone can tell me which other variable I should use to achieve >>>>>>> that without changing the contents of the 'release' file on other >>>>>>> platforms, I'll be grateful. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Okay never mind - and thanks for looking into this. I see now this is >>>>>> set >>>>>> via: >>>>>> >>>>>> ./autoconf/flags.m4: COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK >>>>>> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY" >>>>>> >>>>>> so there is no way to add a second value without introducing some >>>>>> additional >>>>>> variable. At the hotspot level it could be handled differently if we >>>>>> had >>>>>> a >>>>>> platform_ppc64le file, as it could just be added to the SYSDEFS. >>>>>> >>>>>> Thanks, >>>>>> David From aph at redhat.com Fri Dec 11 09:58:07 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Dec 2015 09:58:07 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: References: <56697E62.9030306@redhat.com> Message-ID: <566A9E2F.2000606@redhat.com> On 12/10/2015 09:44 PM, Kim Barrett wrote: > To me, this seems to be trading one form of undefined behavior for > another. Since there *is* a portable solution, which I understand is > also well supported / optimized by compilers, I'd prefer that. OK. I'm not convinced that a memcpy is into a signed int is really more perfectly portable than a union, but I'm certain it will work for the machines we care about. I'm not going to argue about it if that's what you prefer: I just want the bugs to be fixed! > Note that I would not like to see these java_xxx functions used as a > general "solution" to overflow problems. Most cases of signed integer > arithmetic overflow are actual bugs, and papering over them with these > functions would be a mistake. I haven't reviewed them carefully, but > the way these are being used in the various changes in the opto > directory look appropriate, in order to match Java's defined behavior. > But I wouldn't be surprised if there were other places (like the > problem found in advancedThresholdPolicy.cpp) where I would not want > these operations used. In fact, I'd like the comment describing these > operations to say something along that line. Okay, I'll do that. For the hash index computation it might make more sense to do the whole thing unsigned. Andrew. From rbonifacio123 at gmail.com Fri Dec 11 10:05:28 2015 From: rbonifacio123 at gmail.com (Rodrigo Bonifacio) Date: Fri, 11 Dec 2015 08:05:28 -0200 Subject: C++ Exception Handling Message-ID: Dear all, (apologies if you receive multiple copies) We are investigating the use of C++ exception handling constructs in well known open-source C++ systems, and have published some results in the last International Conference on Source Code Analysis and Manipulation [1] We are expanding this to a broader community, so I kindly invite you to answer our new version of the survey at: https://www.surveymonkey.com/r/SXCB7WJ There will be a prize draw for participants, and we thank you in advance. Sincerely, Rodrigo Bonif?cio (on behalf of the authors of this research effort). [1] "The use of C++ exception handling constructs: A comprehensive study" http://dx.doi.org/10.1109/SCAM.2015.7335398 From david.holmes at oracle.com Fri Dec 11 10:40:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Dec 2015 20:40:52 +1000 Subject: C++ Exception Handling In-Reply-To: References: Message-ID: <566AA834.8080703@oracle.com> On 11/12/2015 8:05 PM, Rodrigo Bonifacio wrote: > Dear all, (apologies if you receive multiple copies) > > We are investigating the use of C++ exception handling constructs in well > known open-source C++ systems, and have published some results in the last > International Conference on Source Code Analysis and Manipulation [1] > > We are expanding this to a broader community, so I kindly invite you to > answer our new version of the survey at: Hotspot doesn't use C++ exceptions in general. David > https://www.surveymonkey.com/r/SXCB7WJ > > There will be a prize draw for participants, and we thank you in advance. > > Sincerely, > > Rodrigo Bonif?cio (on behalf of the authors of this research effort). > > [1] "The use of C++ exception handling constructs: A comprehensive study" > http://dx.doi.org/10.1109/SCAM.2015.7335398 > From konstantin.shefov at oracle.com Fri Dec 11 11:54:00 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Fri, 11 Dec 2015 14:54:00 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <56588950.7050101@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> Message-ID: <566AB958.8010901@oracle.com> Hello Please review the new version on the patch. New webrev: Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 What has been changed: 1. Added tests for the new added methods. 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). Thanks -Konstantin On 11/27/2015 07:48 PM, Konstantin Shefov wrote: > Coleen, > Thanks for review > > On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >> >> I have a couple preliminary comments. First, there are no tests >> added with all this new functionality. Tests should be added with >> the functionality changeset, not promised afterward. > I will add tests. >> Secondly, I do not like that JDK code knows the implementation >> details of the JVM's constant pool tags. These should be only for >> internal use. > The package "sun.reflect" is for internal use only, so it shouldn?t be > a problem. >> My third comment is that I haven't looked carefully at this constant >> pool implementation but it seems very unsafe if the class is >> redefined and relies on an implementation detail in the JVM that can >> change. I will have more comments once I look more at the jvmti >> specification. >> >> thanks, >> Coleen >> >> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>> Hello >>> >>> Please, review modified webrev. >>> >>> I have added methods >>> getNameAndTypeRefIndexAt(int index) - to get name and type entry >>> index from a method, field or indy entry index; >>> getClassRefIndexAt(int index) - to get class entry index from a >>> method or field entry index; >>> >>> I removed previously added method >>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>> >>> New webrev: >>> Webrev hotspot: >>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>> >>> Thanks >>> -Konstantin >>> >>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>> Remi, >>>> >>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>> May be it also has sense to make a method >>>> "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type >>>> entry index for methods also. >>>> >>>> -Konstantin >>>> >>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>> Hi Konstantin, >>>>> Technically, getInvokedynamicRefInfoAt should be >>>>> getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the >>>>> nameAndType value of the InvokeDynamicRef. >>>>> >>>>> In term of API, I think it's better to decompose the API, i.e. to >>>>> have a method >>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>> that returns the nameAndType index and to reuse >>>>> getNameAndTypeRefInfoAt(index) to get the corresponding array of >>>>> Strings. >>>>> >>>>> cheers, >>>>> R?mi >>>>> >>>>> ----- Mail original ----- >>>>>> De: "Christian Thalinger" >>>>>> ?: "Konstantin Shefov" >>>>>> Cc: "hotspot-dev developers" , >>>>>> core-libs-dev at openjdk.java.net >>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to >>>>>> sun.reflect.ConstantPool >>>>>> >>>>>> [CC'ing core-libs-dev] >>>>>> >>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>> wrote: >>>>>>> >>>>>>> Hello >>>>>>> >>>>>>> Please review an enhancement to add three new methods to >>>>>>> sun.reflect.ConstantPool class. >>>>>>> The following methods are suggested: >>>>>>> >>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>> representation of name and type from a NameAndType constant pool >>>>>>> entry >>>>>>> with the specified index >>>>>>> >>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns >>>>>>> string >>>>>>> representation of name and type from an InvokeDynamic constant >>>>>>> pool entry >>>>>>> with the specified index >>>>>>> >>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of >>>>>>> a constant >>>>>>> pool entry with the specified index >>>>>>> >>>>>>> These three methods could be used for testing API working with >>>>>>> constant >>>>>>> pool, e.g. JVMCI. >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>> Webrev hotspot: >>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>> Webrev jdk: >>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>> >>>>>>> Thanks >>>>>>> -Konstantin >>>>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Fri Dec 11 13:03:28 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 11 Dec 2015 14:03:28 +0100 Subject: RFR: JDK-8145115: make JAVAC_FLAGS=-g no longer works In-Reply-To: <56699106.2000709@oracle.com> References: <1449656620.3543.3.camel@redhat.com> <5668054C.6030708@oracle.com> <1449659738.3543.28.camel@redhat.com> <1449664422.3543.37.camel@redhat.com> <56685852.80705@oracle.com> <1449683585.3543.88.camel@redhat.com> <56699106.2000709@oracle.com> Message-ID: <566AC9A0.1010103@oracle.com> On 2015-12-10 15:49, Erik Joelsson wrote: > I looked closer at your actual command lines and managed to reproduce. > The problem is JAVAC_FLAGS=-g. We have unfortunately used that name > for a local variable in make/CompileJavaModules.gmk. Fix is pretty > simple, just rename that local variable. In the longer term, we need > to be able to enable -g for javac with a configure argument instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145115 > Patch: > diff -r a151b3ec17a1 make/CompileJavaModules.gmk > --- a/make/CompileJavaModules.gmk > +++ b/make/CompileJavaModules.gmk > @@ -556,7 +556,7 @@ > ifneq ($(BUILD_CRYPTO), true) > CLASSPATH += $(JDK_OUTPUTDIR)/modules/$(MODULE) > endif > -JAVAC_FLAGS := -bootclasspath $(EMPTY_DIR) -extdirs $(EMPTY_DIR) \ > +JAVAC_FLAGS_BOOTCLASSPATH := -bootclasspath $(EMPTY_DIR) -extdirs > $(EMPTY_DIR) \ > -endorseddirs $(EMPTY_DIR) $($(MODULE)_ADD_JAVAC_FLAGS) > > $(eval $(call SetupJavaCompilation, $(MODULE), \ > @@ -566,7 +566,7 @@ > BIN := $(if $($(MODULE)_BIN), $($(MODULE)_BIN), > $(JDK_OUTPUTDIR)/modules/$(MODULE)), \ > HEADERS := $(SUPPORT_OUTPUTDIR)/headers/$(MODULE), \ > CLASSPATH := $(CLASSPATH), \ > - ADD_JAVAC_FLAGS := $($(MODULE)_ADD_JAVAC_FLAGS) $(JAVAC_FLAGS) \ > + ADD_JAVAC_FLAGS := $($(MODULE)_ADD_JAVAC_FLAGS) > $(JAVAC_FLAGS_BOOTCLASSPATH) \ > )) > TARGETS += $($(MODULE)) $($(MODULE)_COPY_EXTRA) > Patch looks good to me. /Magnus > /Erik > > On 2015-12-09 18:53, Severin Gehwolf wrote: >> Hi Erik, >> >> On Wed, 2015-12-09 at 17:35 +0100, Erik Joelsson wrote: >>> I'm not able to reproduce with either OracleJDK 8 or 8u66. >> The simplified reproducer is (extracted from build.log): >> ( (/usr/bin/bash >> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/common/bin/logger.sh >> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log >> /usr/lib/jvm/java-1.8.0-openjdk/bin/java -XX:+UseSerialGC -Xms32M >> -Xmx512M >> "-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar" >> -cp >> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar >> com.sun.tools.sjavac.Main >> --server:portfile=/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/javacservers/server.port,id=java.logging,sjavac=/usr/lib/jvm/java-1.8.0-openjdk/bin/java%20-d64%20-Xms512M%20-Xmx2048M%20"-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar"%20-cp%20/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar%20com.sun.tools.sjavac.Main >> -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true >> -Xlint:all -Werror -g -Xdoclint:all/protected,-reference >> '-Xdoclint/package:java.*,javax.*' -g -cp >> "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.base:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging" >> -implicit:none -d >> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging >> -h >> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/support/headers/java.logging.java.logging.tmp >> @/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp >> && /usr/bin/rm -f >> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log) >> || (exitcode=$? && /usr/bin/mv >> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log >> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/failure-logs/java.logging.log >> && exit $exitcode) ) && /usr/bin/mv >> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp >> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch >> >> >> I'm also attaching the failing command invocation as a file (Putting >> this into a file and re-executing it reproduces the problem for me. Of >> course, your paths may differ :) >> >> Cheers, >> Severin >> >>> /Erik >>> >>> On 2015-12-09 13:33, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> On Wed, 2015-12-09 at 12:15 +0100, Severin Gehwolf wrote: >>>>> Hi Mikael, >>>>> >>>>> On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote: >>>>>> Hi Severin, >>>>>> >>>>>> On 2015-12-09 11:23, Severin Gehwolf wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm trying to build an OpenJDK 9, hs-rt tree which fails to >>>>>>> build for >>>>>>> me with: >>>>>>> >>>>>>> jdk/src/java.logging/share/classes/sun/util/logging/internal/ >>>>>>> LoggingProviderImpl.java:33: error: cannot find symbol >>>>>>> import java.lang.System.LoggerFinder; >>>>>>> ^ >>>>>>> symbol: class LoggerFinder >>>>>>> location: class System >>>>>> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src >>>>>> /java.base/share/classes/java/lang/System.java#l1377 >>>>>> the LoggerFinder inner class appears to exist on the hg server >>>>>> at least. >>>>> I have it in the local copy too, yet I get: >>>>> CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux- >>>>> x86_64-normal-server- >>>>> release/jdk/modules/java.logging/_the.java.logging_batch' failed >>>>> make/Main.gmk:150: recipe for target 'java.logging-java' failed >>>>> >>>>> With the above root-cause. I'll try with a fresh clone... >>>> Same failure with fresh clone :( Here is how I configure and invoke >>>> make: >>>> bash configure \ >>>> --with-boot-jdk="$JDK_TO_BUILD_WITH" \ >>>> --with-debug-level="release" \ >>>> --disable-zip-debug-info \ >>>> --enable-unlimited-crypto \ >>>> --with-stdc++lib=dynamic \ >>>> --disable-warnings-as-errors \ >>>> --with-num-cores=8 >>>> >>>> make \ >>>> DEBUG_BINARIES=true \ >>>> JAVAC_FLAGS=-g \ >>>> STRIP_POLICY=no_strip \ >>>> STRIP="" \ >>>> DISABLE_INTREE_EC=true \ >>>> ALT_OBJCOPY=none \ >>>> LOG=debug \ >>>> images >>>> >>>> Thanks, >>>> Severin >>>> >>>>>>> $ hg paths >>>>>>> default = http://hg.openjdk.java.net/jdk9/hs-rt/ >>>>>>> >>>>>>> Do I need to use a different tree these days? What am I >>>>>>> missing? >>>>>> No, it should work. >>>>>> Are you sure you've updated all the sub-trees? >>>>>> >>>>>> http://hg.openjdk.java.net/code-tools/trees/ >>>>>> Is a helpful hg extension to keep track of things. >>>>>> >>>>>> I've noticed that sometimes "bash get_source.sh" does not >>>>>> correctly "hg >>>>>> update" the entire forest. >>>>> I should have an updated tree, though I usually use: >>>>> $ hg pull -u >>>>> $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do >>>>> pushd $i; hg pull -u; popd; done >>>>> >>>>> I've checked just now and all repos seem to have updated >>>>> correctly. The >>>>> CI builder for Zero seems to agree[1]. Note: The above build >>>>> failure is >>>>> for a regular server JVM. Not sure what's wrong. I keep looking, >>>>> thanks! >>>>> >>>>> Cheers, >>>>> Severin >>>>> >>>>> [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/ >>>>> 191/console >>>>> >>>>>> /Mikael >>>>>> >>>>>>> Thanks, >>>>>>> Severin >>>>>>> > > From volker.simonis at gmail.com Fri Dec 11 13:57:47 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Dec 2015 14:57:47 +0100 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <566A5575.3020908@oracle.com> References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> <5664DBF9.7010708@oracle.com> <566660B2.4030100@oracle.com> <56679B9F.8030105@oracle.com> <566906CE.2050101@oracle.com> <566A5575.3020908@oracle.com> Message-ID: Hi Sasha, David, I've just verified that your patch still works for linux/ppc64. I've built and smoke-tested both linux/ppc64 and ppc64le and everything looks good. So from my side this is ready to push. Thanks for finally getting this ready! Volker On Fri, Dec 11, 2015 at 5:47 AM, David Holmes wrote: > On 11/12/2015 2:15 PM, Alexander Smundak wrote: >> >> I have jcheck enabled, so I am surprised that the absence of the >> Reviewed-by: field was not flagged. Anyways, here's the new set: > > > Not sure what is going on with your jcheck setup but the formatting is still > wrong: > > - the changeset "user" must be OpenJDK username not email address > - reviewers must be OpenJDK user names not email addresses > - contributed-by attribution should be simple email address or the following > is also allowed: > Andrew Hughes > > Sorry. > > David > ----- > > >> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.04 >> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.04 >> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.04 >> >> Note that I don't have access to the big-endian PowerPC64. The >> original patch was verified by goetz.lindenmaier at sap.com, but it has >> changed since. Goetz, can you verify that the new patch still works? >> >> Sasha >> >> On Wed, Dec 9, 2015 at 8:59 PM, David Holmes >> wrote: >>> >>> On 10/12/2015 4:16 AM, Alexander Smundak wrote: >>>> >>>> >>>> I am confused -- is there anything you want me to change in the existing >>>> set: >>>> >>>> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03 >>>> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03 >>>> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03 >>> >>> >>> >>> Yes they need to be created using the correct, jcheck[1] compliant, >>> commit >>> messages: >>> >>> http://openjdk.java.net/guide/producingChangeset.html >>> >>> Mainly Reviewers seem to be missing - but I'm also not sure other details >>> are jcheck compliant. >>> >>> Thanks, >>> David >>> >>> [1] http://openjdk.java.net/projects/code-tools/jcheck/ >>> >>> >>>> Sasha >>>> >>>> On Tue, Dec 8, 2015 at 7:10 PM, David Holmes >>>> wrote: >>>>> >>>>> >>>>> I can sponsor for you Sasha. Just email me the changeset, or a link >>>>> thereto. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>> On 9/12/2015 3:44 AM, Alexander Smundak wrote: >>>>>> >>>>>> >>>>>> >>>>>> Thank you for the review. >>>>>> If everyone involved is satisfied with the patch, I need a sponsor. >>>>>> >>>>>> Sasha >>>>>> >>>>>> On Mon, Dec 7, 2015 at 8:46 PM, David Holmes >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 8/12/2015 1:44 PM, Alexander Smundak wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It is achievable by adding a small ppc-specific check to the >>>>>>>> common/autoconf/platform.m4: >>>>>>>> >>>>>>>> @@ -282,6 +282,8 @@ >>>>>>>> elif test "x$OPENJDK_TARGET_OS" != xmacosx && test >>>>>>>> "x$OPENJDK_TARGET_CPU" = xx86_64; then >>>>>>>> # On all platforms except MacOSX replace x86_64 with amd64. >>>>>>>> OPENJDK_TARGET_CPU_LEGACY="amd64" >>>>>>>> + elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then >>>>>>>> + OPENJDK_TARGET_CPU_LEGACY="ppc64" >>>>>>>> fi >>>>>>>> AC_SUBST(OPENJDK_TARGET_CPU_LEGACY) >>>>>>>> >>>>>>>> However, there is a code in make/Images.gmk using >>>>>>>> OPENJDK_TARGET_CPU_LEGACY >>>>>>>> $(call info-file-item, "OS_ARCH", >>>>>>>> "$(OPENJDK_TARGET_CPU_LEGACY)") >>>>>>>> so that the 'release' file in the image directory will now have >>>>>>>> JAVA_VERSION="9" >>>>>>>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt" >>>>>>>> OS_NAME="Linux" >>>>>>>> OS_VERSION="2.6" >>>>>>>> OS_ARCH="ppc64" >>>>>>>> ^^^^^^^^ >>>>>>>> SOURCE=.., >>>>>>>> >>>>>>>> instead of "ppc64le". >>>>>>>> >>>>>>>> If someone can tell me which other variable I should use to achieve >>>>>>>> that without changing the contents of the 'release' file on other >>>>>>>> platforms, I'll be grateful. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Okay never mind - and thanks for looking into this. I see now this is >>>>>>> set >>>>>>> via: >>>>>>> >>>>>>> ./autoconf/flags.m4: COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK >>>>>>> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY" >>>>>>> >>>>>>> so there is no way to add a second value without introducing some >>>>>>> additional >>>>>>> variable. At the hotspot level it could be handled differently if we >>>>>>> had >>>>>>> a >>>>>>> platform_ppc64le file, as it could just be added to the SYSDEFS. >>>>>>> >>>>>>> Thanks, >>>>>>> David From christian.tornqvist at oracle.com Fri Dec 11 15:38:58 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 11 Dec 2015 10:38:58 -0500 Subject: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework needs to handle VM error codes in some cases In-Reply-To: <5667E869.5070903@oracle.com> References: <56557442.2080408@oracle.com> <5667E869.5070903@oracle.com> Message-ID: <0f7c01d1342a$0d8f4920$28addb60$@oracle.com> Hi Dmitry, Sorry for the delay, this looks good! Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Dmitry Dmitriev Sent: Wednesday, December 9, 2015 3:38 AM To: hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework needs to handle VM error codes in some cases Hello, Please, can I get Review for that fix? Thank you! Dmitry On 25.11.2015 11:41, Dmitry Dmitriev wrote: > Hello, > > Please review this small enhancement to the command line options > validation test framework. This enhancement allow to specify allowed > exit code for flags. This is needed for CDS Shared flags, because in > some cases JVM can exit with error code 2 and this should not be > treated as error. Also, in this fix I refactor code which parse Shared > flags - specify explicit names of the flags in switch statement and > use only one CDS archive file. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8142874 > webrev: http://cr.openjdk.java.net/~ddmitriev/8142874/webrev.01/ > > Testing: tested on all platforms by RBT > > Thanks, > Dmitry From dmitry.dmitriev at oracle.com Fri Dec 11 15:45:11 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 11 Dec 2015 18:45:11 +0300 Subject: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework needs to handle VM error codes in some cases In-Reply-To: <0f7c01d1342a$0d8f4920$28addb60$@oracle.com> References: <56557442.2080408@oracle.com> <5667E869.5070903@oracle.com> <0f7c01d1342a$0d8f4920$28addb60$@oracle.com> Message-ID: <566AEF87.6030308@oracle.com> Hi Christian, Thank you for the review! Dmitry On 11.12.2015 18:38, Christian Tornqvist wrote: > Hi Dmitry, > > Sorry for the delay, this looks good! > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Dmitry Dmitriev > Sent: Wednesday, December 9, 2015 3:38 AM > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework needs to handle VM error codes in some cases > > Hello, > > Please, can I get Review for that fix? Thank you! > > Dmitry > > On 25.11.2015 11:41, Dmitry Dmitriev wrote: >> Hello, >> >> Please review this small enhancement to the command line options >> validation test framework. This enhancement allow to specify allowed >> exit code for flags. This is needed for CDS Shared flags, because in >> some cases JVM can exit with error code 2 and this should not be >> treated as error. Also, in this fix I refactor code which parse Shared >> flags - specify explicit names of the flags in switch statement and >> use only one CDS archive file. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8142874 >> webrev: http://cr.openjdk.java.net/~ddmitriev/8142874/webrev.01/ >> >> Testing: tested on all platforms by RBT >> >> Thanks, >> Dmitry > From gerard.ziemski at oracle.com Fri Dec 11 16:24:07 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Fri, 11 Dec 2015 10:24:07 -0600 Subject: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework needs to handle VM error codes in some cases In-Reply-To: <5667E869.5070903@oracle.com> References: <56557442.2080408@oracle.com> <5667E869.5070903@oracle.com> Message-ID: <566AF8A7.1050402@oracle.com> Looks good, though I am just a (r)eviewer. cheers On 12/09/2015 02:38 AM, Dmitry Dmitriev wrote: > Hello, > > Please, can I get Review for that fix? Thank you! > > Dmitry > > On 25.11.2015 11:41, Dmitry Dmitriev wrote: >> Hello, >> >> Please review this small enhancement to the command line options validation test framework. This enhancement allow to >> specify allowed exit code for flags. This is needed for CDS Shared flags, because in some cases JVM can exit with >> error code 2 and this should not be treated as error. Also, in this fix I refactor code which parse Shared flags - >> specify explicit names of the flags in switch statement and use only one CDS archive file. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8142874 >> webrev: http://cr.openjdk.java.net/~ddmitriev/8142874/webrev.01/ >> >> Testing: tested on all platforms by RBT >> >> Thanks, >> Dmitry > > From john.r.rose at oracle.com Fri Dec 11 18:17:18 2015 From: john.r.rose at oracle.com (John Rose) Date: Fri, 11 Dec 2015 10:17:18 -0800 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <566A9E2F.2000606@redhat.com> References: <56697E62.9030306@redhat.com> <566A9E2F.2000606@redhat.com> Message-ID: <5C36B6CF-7098-4568-AA79-05F624580995@oracle.com> On Dec 11, 2015, at 1:58 AM, Andrew Haley wrote: > > On 12/10/2015 09:44 PM, Kim Barrett wrote: >> To me, this seems to be trading one form of undefined behavior for >> another. Since there *is* a portable solution, which I understand is >> also well supported / optimized by compilers, I'd prefer that. > > OK. I'm not convinced that a memcpy is into a signed int is really > more perfectly portable than a union, but I'm certain it will work for > the machines we care about. I'm not going to argue about it if that's > what you prefer: I just want the bugs to be fixed! C++ has several flavors of cast; is there not one that will reinterpret the bits, leaving them unchanged? The union and memcpy guys are (AFAIK) equally awkward ways to express that intention, but I thought reinterpret_cast was the most direct way to do the job. http://en.cppreference.com/w/cpp/language/reinterpret_cast ? John From john.r.rose at oracle.com Fri Dec 11 18:39:19 2015 From: john.r.rose at oracle.com (John Rose) Date: Fri, 11 Dec 2015 10:39:19 -0800 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <5C36B6CF-7098-4568-AA79-05F624580995@oracle.com> References: <56697E62.9030306@redhat.com> <566A9E2F.2000606@redhat.com> <5C36B6CF-7098-4568-AA79-05F624580995@oracle.com> Message-ID: <07E5A6CA-1259-4CB6-B34B-B42442C820E5@oracle.com> P.S. On Dec 11, 2015, at 10:17 AM, John Rose wrote: > > http://en.cppreference.com/w/cpp/language/reinterpret_cast After reading the fine print, I see that integral-to-integral reinterpretations are not part of the portfolio of reinterpret_cast. But you can reinterpret an lvalue of type unsigned int as a reference to type signed int, which activates type aliasing rules that allow the intended conversion: > ? AliasedType is the (possibly cv-qualified) signed or unsigned variant of DynamicType These rules (or similar rules elsewhere in the spec) may (or may not) imply that the union trick, and/or memcpy trick, gets the desired result. So, the lvalue cast makes the following macro definition plausible: #define JAVA_INTEGER_OP(OP, NAME, TYPE, UNSIGNED_TYPE) \ inline TYPE NAME (TYPE in1, TYPE in2) { \ STATIC_ASSERT(sizeof(TYPE) == sizeof(UNSIGNED_TYPE)); \ UNSIGNED_TYPE ures = static_cast(in1); \ ures OP ## = static_cast(in2); \ return reinterpret_cast(ures); \ } From asmundak at google.com Fri Dec 11 19:05:19 2015 From: asmundak at google.com (Alexander Smundak) Date: Fri, 11 Dec 2015 11:05:19 -0800 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> <5664DBF9.7010708@oracle.com> <566660B2.4030100@oracle.com> <56679B9F.8030105@oracle.com> <566906CE.2050101@oracle.com> <566A5575.3020908@oracle.com> Message-ID: On Fri, Dec 11, 2015 at 5:57 AM, Volker Simonis wrote: > I've just verified that your patch still works for linux/ppc64. I've > built and smoke-tested both linux/ppc64 and ppc64le and everything > looks good. So from my side this is ready to push. Thanks. Here's the new revision, with headers verified by jcheck: http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.05 http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.05 http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.05 Sasha From kim.barrett at oracle.com Fri Dec 11 19:33:34 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Dec 2015 14:33:34 -0500 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <07E5A6CA-1259-4CB6-B34B-B42442C820E5@oracle.com> References: <56697E62.9030306@redhat.com> <566A9E2F.2000606@redhat.com> <5C36B6CF-7098-4568-AA79-05F624580995@oracle.com> <07E5A6CA-1259-4CB6-B34B-B42442C820E5@oracle.com> Message-ID: On Dec 11, 2015, at 1:39 PM, John Rose wrote: > > P.S. > > On Dec 11, 2015, at 10:17 AM, John Rose wrote: >> >> http://en.cppreference.com/w/cpp/language/reinterpret_cast > > After reading the fine print, I see that integral-to-integral reinterpretations > are not part of the portfolio of reinterpret_cast. But you can reinterpret > an lvalue of type unsigned int as a reference to type signed int, which > activates type aliasing rules that allow the intended conversion: > >> ? AliasedType is the (possibly cv-qualified) signed or unsigned variant of DynamicType > > These rules (or similar rules elsewhere in the spec) may (or may not) > imply that the union trick, and/or memcpy trick, gets the desired result. > > So, the lvalue cast makes the following macro definition plausible: > > #define JAVA_INTEGER_OP(OP, NAME, TYPE, UNSIGNED_TYPE) \ > inline TYPE NAME (TYPE in1, TYPE in2) { \ > STATIC_ASSERT(sizeof(TYPE) == sizeof(UNSIGNED_TYPE)); \ > UNSIGNED_TYPE ures = static_cast(in1); \ > ures OP ## = static_cast(in2); \ > return reinterpret_cast(ures); \ > } You beat me to this. Yes, I think this works. The lvalue to reference conversion has the desired meaning: C++03 5.2.10 p10. And while this is a form of pointer type punning, it is one of the few cases of such that are permitted: C++03 3.10 p15 3rd bullet. Recent gcc -O1 generates the desired code. Recent SunStudios with -O1 generates the desired code, unlike for the memcpy method where -O4 was needed. I'll collect information on other platforms. ps. The memcpy approach is applicable to more cases, such as converting an integer to a float having the same bit pattern. Fortunately we have this reinterpret_cast approach available for the case at hand, since the memcpy idiom seems to be poorly handled by a lot of compilers. pps. The union trick is undefined behavior because it reads a union member other than the last one written. gcc explicitly permits the union trick; see the documentation for the -fstrict-aliasing option. I know I've heard of a compiler which did not permit it and could generate "wrong" code, but I've not yet tracked down the discussion where I read about that. From dmitry.dmitriev at oracle.com Fri Dec 11 19:43:34 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 11 Dec 2015 22:43:34 +0300 Subject: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework needs to handle VM error codes in some cases In-Reply-To: <566AF8A7.1050402@oracle.com> References: <56557442.2080408@oracle.com> <5667E869.5070903@oracle.com> <566AF8A7.1050402@oracle.com> Message-ID: <566B2766.4030004@oracle.com> Gerard, thank you for the review! Dmitry On 11.12.2015 19:24, gerard ziemski wrote: > Looks good, though I am just a (r)eviewer. > > > cheers > > > On 12/09/2015 02:38 AM, Dmitry Dmitriev wrote: >> Hello, >> >> Please, can I get Review for that fix? Thank you! >> >> Dmitry >> >> On 25.11.2015 11:41, Dmitry Dmitriev wrote: >>> Hello, >>> >>> Please review this small enhancement to the command line options >>> validation test framework. This enhancement allow to >>> specify allowed exit code for flags. This is needed for CDS Shared >>> flags, because in some cases JVM can exit with >>> error code 2 and this should not be treated as error. Also, in this >>> fix I refactor code which parse Shared flags - >>> specify explicit names of the flags in switch statement and use only >>> one CDS archive file. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8142874 >>> webrev: http://cr.openjdk.java.net/~ddmitriev/8142874/webrev.01/ >>> >>> Testing: tested on all platforms by RBT >>> >>> Thanks, >>> Dmitry >> >> From magnus.ihse.bursie at oracle.com Fri Dec 11 20:20:15 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 11 Dec 2015 21:20:15 +0100 Subject: RFR (S): JDK-8142909 Integration of minor fixes from the build-infra project In-Reply-To: <564A897D.7010707@oracle.com> References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com> <5645CA9E.4060205@oracle.com> <56493B10.6040207@oracle.com> <5649923E.8010707@oracle.com> <5649B9DB.2030507@oracle.com> <5649C8B8.2000707@oracle.com> <564A897D.7010707@oracle.com> Message-ID: <566B2FFF.3090109@oracle.com> I'm trying to resurrect this review. Here is a new version: http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.03 I have dropped all the changes related to -g and OPT_CFLAGS. I'm not interested in that kind of large scale operations on the old build system, I just wanted to transfer the small patches we have in the build-infra forest to mainline to facilitate comparison between old and new build. If that was too problematic, let's skip it. Remaining changes are: * Making adlc more quiet * Sorting the windows build Also, in the meantime, a new difference has surfaced. In the first push of the new hotspot build system, the rewrite of SA, the file make/bsd/makefiles/saproc.make unfortunately was not deleted in mainline. I added the deletion of this file. I intend to push this through hs-rt. David and Erik, please confirm that these changes are OK for you. /Magnus On 2015-11-17 02:57, David Holmes wrote: > On 16/11/2015 10:14 PM, Erik Joelsson wrote: >> On 2015-11-16 12:11, David Holmes wrote: >>> On 16/11/2015 6:22 PM, Erik Joelsson wrote: >>>> On 2015-11-16 03:10, David Holmes wrote: >>>>> Hi Magnus, >>>>> >>>>> On 13/11/2015 9:33 PM, Magnus Ihse Bursie wrote: >>>>>> On 2015-11-13 09:13, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> make/bsd/makefiles/amd64.make: >>>>>>> make/bsd/makefiles/gcc.make: >>>>>>> Perhaps the order of "$(OPT_CFLAGS/NOOPT) >>>>>>> $(OPT_CFLAGS/$(BUILDARCH))" >>>>>>> should be reversed to guarantee that NOOPT is the one used in case >>>>>>> BUILDARCH contains something that conflicts? The solaris file >>>>>>> does it >>>>>>> this way. >>>>>> You know you wrote that code originally? ;-) >>>>>> >>>>>> Yeah, I agree, it's more reasonable. Updated webrev: >>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02 >>>>>> >>>>>> >>>>>> >>>>> >>>>> I don't like this particular change as it is too generic. It gives >>>>> the >>>>> appearance of being apply to apply whatever the BUILDARCH specific >>>>> optflags are, which makes no sense if the whole point here is to not >>>>> optimize these files. If all this is intended to do is include -g >>>>> then >>>>> I think that should be done explicitly. >>>>> >>>> The -g flag is added to OPT_CFLAGS/$(BUILDARCH) and I can only assume >>>> the intention was to have it added to all compilation command lines. >>>> However, the OPT_CFLAGS/ variable overrides >>>> CFLAGS/$(BUILDARCH), effectively removing the -g flag from the files >>>> where we explicitly change the optimization level. The patch >>>> intends to >>>> make sure -g is used on those files too. >>> >>> I understand that, but it is far from obvious that OPT_FLAGS/BUILDARCH >>> means -g (why???), or that putting other things in that variable might >>> break files that should not be optimized. >>> >>>> A cleaner solution would be to not have -g be part of the OPT flags at >>>> all but its own set of DEBUG_CFLAGS. >>> >>> I thought -g was in the DEBUG_CFLAGS ?? Or maybe it used to be. Anyway >>> if all we are interested in is adding -g then I agree it should have >>> its own variable. >>> >> I looked some more at this. There is a DEBUG_CFLAGS, FASTDEBUG_CFLAGS >> and OPT_CFLAGS. These get picked depending on the debug level of the >> build. For example in product.make, $(OPT_CFLAGS/BYFILE) gets added to >> CFLAGS. >> >> I can't really see a better way of making sure the -g does not fall off >> for some files than what is proposed here. At least not without >> completely reworking the flags handling in the current hotspot >> makefiles, something I'm very uninterested in doing. > > In the -g case what we are handling is the addition of -g to product > builds (it is already on fastdebug, debug) when > ENABLE_FULL_DEBUG_SYMBOLS is selected, on a subset of architectures. > As a convenience we define it thus (BSD version): > > OPT_CFLAGS/ia64 = -g > OPT_CFLAGS/amd64 = -g > OPT_CFLAGS/arm = -g > OPT_CFLAGS/ppc = -g > OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH)) > > so $(OPT_CFLAGS/$(BUILDARCH)) happens to contain -g. I would be happy > if the above were changed to: > > FDS_CFLAGS/ia64 = -g > FDS_CFLAGS/amd64 = -g > FDS_CFLAGS/arm = -g > FDS_CFLAGS/ppc = -g > OPT_CFLAGS += $(FDS_CFLAGS/$(BUILDARCH)) > > and then you could use $(FDS_CFLAGS/$(BUILDARCH) on the "by-file" > definitions, where it would be much clearer what kind of flag is > actually being applied. However this needs to be done everywhere, and > I don't see this fix attempting to do that. We set > OPT_CFLAGS/ in numerous places (open and closed) to regain > control over the "opt" flags applied to that file. Sometimes we use > predefined opt flags, like NOOPT or SPEED, and sometimes we don't eg: > > linux/makefiles/amd64.make > > OPT_CFLAGS/compactingPermGenGen.o = -O1 > > This would need to be applied to every occurrence of the "byfile" > definitions in all the makefiles. Or else ascertained on a > case-by-case basis that we don't want -g for a specific file. > > Further, on architectures where $(FDS_CFLAGS/$(BUILDARCH) is not set > you still have to somehow handle the rest of the above logic: > > 507 ifeq ($(OPT_CFLAGS/$(BUILDARCH)),) > 508 ifeq ($(USE_CLANG), true) > 509 # Clang doesn't understand -gstabs > 510 OPT_CFLAGS += -g > 511 else > 512 OPT_CFLAGS += -gstabs > 513 endif > 514 endif > > else you again fail to set -g or -gstabs on the "by-file" definitions. > > Also looking at the change in make/solaris/makefiles/amd64.make you > have taken the file specific flags: > > OPT_CFLAGS/generateOptoStub.o = -xO2 > > and added the generic OPT_CFLAGS value: > > OPT_CFLAGS/generateOptoStub.o = $(OPT_CFLAGS) -xO2 > > which seems extremely dubious from a correctness perspective. > > Thanks, > David > ----- > >>>>> --- >>>>> >>>>> make/bsd/makefiles/saproc.make >>>>> >>>>> ! # Order src files alfabetically >>>>> >>>>> That would be "alphabetically". But that list doesn't seem alphabetic >>>>> anyway: MacosxDebuggerLocal.m would come after libproc_impl.c; and >>>>> $(AGENTDIR) should come first. I really see no point in forcing such >>>>> lists to be in alphabetic order. >>>>> >>>> This is to make comparison of binaries between the old hotspot >>>> build and >>>> the new hotspot build easier. In build-infra, we $(sort ) the object >>>> files before linking to get a reproducible order. The linker output is >>>> affected by the order of the object files. By making sure the old and >>>> the new build sorts them the same way, we get cleaner comparisons and >>>> can more easily detect other types of differences through those >>>> comparisons. The sort order isn't strictly alphabetical, it's on byte >>>> order so upper case goes before lower case. >>> >>> I saw the change for the ordered object files on Windows, but this >>> simply orders source files in a list. Not sure how that has any affect >>> on the linking ?? >>> >> It has an effect on the linking because that list is used verbatim on >> the combined compile/link command line. >> >> /Erik >>> Cheers, >>> David >>> >>>> /Erik >>>>> make/linux/makefiles/saproc.make doesn't have the comment that was >>>>> added for bsd. >>>>> >>>>> ---- >>>>> >>>>> make/solaris/makefiles/amd64.make >>>>> >>>>> Similar issue with bsd amd64.make. Not sure what you are trying to >>>>> achieve here - is it some kind of last option wins situation ? >>>>> >>>>> --- >>>>> >>>>> make/windows/create_obj_files.sh >>>>> >>>>> Harmless I guess but not sure about relevance of sort order here. >>>>> >>>>> ---- >>>>> >>>>> src/share/vm/adlc/adlparse.cpp >>>>> >>>>> So that's where that comes from! :) >>>>> >>>>> --- >>>>> >>>>> src/share/vm/gc/g1/g1EvacStats.cpp >>>>> >>>>> I don't see anything in the cpp files that uses anything from the >>>>> atomic class ??? >>>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> Otherwise looks good. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2015-11-13 03:34, Magnus Ihse Bursie wrote: >>>>>>>> In the new hotspot build project, we have made a few changes to >>>>>>>> the >>>>>>>> existing build. In preparation for the new build, I'd like to >>>>>>>> integrate these into mainline. >>>>>>>> >>>>>>>> These changes are: >>>>>>>> * When overriding optimization, do not lose current debug (-g) >>>>>>>> setting (!) >>>>>>>> * Make adlc actually quiet in quiet mode >>>>>>>> * Make g1EvacStats.cpp compile in all cases without precompiled >>>>>>>> headers >>>>>>>> * Sort saproc object files when linking (facilitates comparison to >>>>>>>> new build) >>>>>>>> >>>>>>>> Unless someone suggests otherwise, I intend to push this (using >>>>>>>> JPRT) >>>>>>>> to hs-rt. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909 >>>>>>>> WebRev: >>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> /Magnus >>>>>>> >>>>>> >>>> >> From jon.masamitsu at oracle.com Fri Dec 11 21:49:09 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 11 Dec 2015 13:49:09 -0800 Subject: max heap size for compressed oops In-Reply-To: <566AE80B.8090404@m7w3.de> References: <5668512B.4070908@m7w3.de> <566860DB.3040304@redhat.com> <566AE80B.8090404@m7w3.de> Message-ID: <566B44D5.6010707@oracle.com> Matthias, Switched the the mailing list over to hotspot-dev. Before jdk8 the perm gen occupied the same block of memory as the heap (Java heap and perm gen were contiguous but the size of the perm gen was not counted as part of the Java heap). Some space needed to be taken out of the 32 GB for the perm gen. 1.5 GB was probably a safe amount to be allowed for the perm gen. Jon On 12/11/2015 7:13 AM, Matthias Wahl wrote: > Thanks for your quick reply. > > This makes complete sense. > > It sheds some light on how compressed oops work. > Unfortunately it does not answer my initial question. > > In the mean time i was able to figure out that we actually have > compressed oops up to 32 GB: > > > $ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode > -Xmx32g -Xms32g -XX:+UseCompressedOops -version > Java HotSpot(TM) 64-Bit Server VM warning: Max heap size too large for > Compressed Oops > java version "1.8.0_60" > Java(TM) SE Runtime Environment (build 1.8.0_60-b27) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) > > ---- > > $ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode > -Xmx31999m -Xms31999m -XX:+UseCompressedOops -version > > Protected page at the reserved heap base: 0x000000011e000000 / 2097152 bytes > > heap address: 0x000000011e200000, size: 30502 MB, Compressed Oops with > base: 0x000000011e1ff000 > > Narrow klass base: 0x00000008d6263000, Narrow klass shift: 0 > Compressed class space size: 1073741824 Address: 0x00000008d6263000 Req > Addr: 0x0000000890800000 > java version "1.8.0_60" > Java(TM) SE Runtime Environment (build 1.8.0_60-b27) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) > > ---- > > So I am still searching for a reason for the 30.5GB suggestion. > But I think we can narrow it down to some GC (G1) performance hint. > > Does anybody have a clue on why heaps > 30.5 GB may induce really worse > performance characteristics? Be it G1 or CMS Garbage Collector. > > Thank you! > > Just ignore this mail if you think it's not the right place for such > questions. > > > Matthias > > > Am 12/9/15 um 6:11 PM schrieb Andrew Haley: >> On 12/09/2015 04:04 PM, Matthias Wahl wrote: >>> Do you know any reason for limiting the heap size to 30.5 GB instead of >>> 32 GB? >> The interesting thing you can do is use -XX:+PrintAssembly and have a >> look. My guess is that it has to do with zero-based compressed OOPs: >> if you can use zero as the base pointer you don't have to dedicate a >> register to the job and the compressing/decompressing code is faster. >> >> A narrow OOP is computed by >> >> oop_address == 0 ? 0 : (oop_address - heap_base) >> shift >> >> The OOP at 0 is a null, of course. >> >> If the heap base is zero, you can encode an OOP with a single >> shift instruction: >> >> lsr x0, x0, #3 >> >> But if the heap base is not zero, encoding an OOP gets nasty: >> >> subs x0, x0, xheapbase >> csel x0, x0, xzr, cs >> lsr x0, x0, #3 >> >> Here there are three instructions, one of them conditional. In the >> commonest case most modern processors can do the shifting in parallel >> with some other operation, so the cost of compressed OOPs is often >> zero as long as the heap base is zero. But there's no way that the >> three instructions used encoding an OOP with a nonzero heap base are >> gong to cost nothing. >> >> So why is there a difference between 30.5G and 32G? Because in >> practice the JVM sits in the bottom 1.5G or so of memory and the heap >> is immediately above it, so the heap base for compressed OOPs can be >> zero. >> >> Does that make sense? >> >> Andrew. >> From aph at redhat.com Fri Dec 11 23:19:53 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Dec 2015 23:19:53 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: References: <56697E62.9030306@redhat.com> <566A9E2F.2000606@redhat.com> <5C36B6CF-7098-4568-AA79-05F624580995@oracle.com> <07E5A6CA-1259-4CB6-B34B-B42442C820E5@oracle.com> Message-ID: <566B5A19.6010301@redhat.com> On 11/12/15 19:33, Kim Barrett wrote: > pps. The union trick is undefined behavior because it reads a union > member other than the last one written. Hmm. The members are certainly in the same memory locations, and I suspect that the language in 3.10 (Lvalues and rvalues) about signed and unsigned types allows it too. But never mind: we only need one way to do this, and if we can agree that it works we're done. Andrew. From igor.ignatyev at oracle.com Sat Dec 12 02:10:30 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sat, 12 Dec 2015 05:10:30 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <566AB958.8010901@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> Message-ID: <936BAB55-5004-440C-A980-E7F9D2DBBF13@oracle.com> Hi Konstantin, the fix and tests look good to me, but I think you have to wait for OK from Coleen. One minor thing ?it looks like there are no tests for other s.r.CP methods, could you please file an RFE against core-libs/j.l.reflect to cover them? Thanks, ? Igor > On Dec 11, 2015, at 2:54 PM, Konstantin Shefov wrote: > > Hello > > Please review the new version on the patch. > > New webrev: > Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 > Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 > > What has been changed: > 1. Added tests for the new added methods. > 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). > > Thanks > -Konstantin > > On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >> Coleen, >> Thanks for review >> >> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>> >>> I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be added with the functionality changeset, not promised afterward. >> I will add tests. >>> Secondly, I do not like that JDK code knows the implementation details of the JVM's constant pool tags. These should be only for internal use. >> The package "sun.reflect" is for internal use only, so it shouldn?t be a problem. >>> My third comment is that I haven't looked carefully at this constant pool implementation but it seems very unsafe if the class is redefined and relies on an implementation detail in the JVM that can change. I will have more comments once I look more at the jvmti specification. >>> >>> thanks, >>> Coleen >>> >>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>> Hello >>>> >>>> Please, review modified webrev. >>>> >>>> I have added methods >>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; >>>> getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; >>>> >>>> I removed previously added method >>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>> >>>> New webrev: >>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>> >>>> Thanks >>>> -Konstantin >>>> >>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>> Remi, >>>>> >>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>> May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. >>>>> >>>>> -Konstantin >>>>> >>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>> Hi Konstantin, >>>>>> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef. >>>>>> >>>>>> In term of API, I think it's better to decompose the API, i.e. to have a method >>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. >>>>>> >>>>>> cheers, >>>>>> R?mi >>>>>> >>>>>> ----- Mail original ----- >>>>>>> De: "Christian Thalinger" >>>>>>> ?: "Konstantin Shefov" >>>>>>> Cc: "hotspot-dev developers" , core-libs-dev at openjdk.java.net >>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool >>>>>>> >>>>>>> [CC'ing core-libs-dev] >>>>>>> >>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello >>>>>>>> >>>>>>>> Please review an enhancement to add three new methods to >>>>>>>> sun.reflect.ConstantPool class. >>>>>>>> The following methods are suggested: >>>>>>>> >>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>>> representation of name and type from a NameAndType constant pool entry >>>>>>>> with the specified index >>>>>>>> >>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string >>>>>>>> representation of name and type from an InvokeDynamic constant pool entry >>>>>>>> with the specified index >>>>>>>> >>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant >>>>>>>> pool entry with the specified index >>>>>>>> >>>>>>>> These three methods could be used for testing API working with constant >>>>>>>> pool, e.g. JVMCI. >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>> Webrev hotspot: >>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Konstantin >>>>>>> >>>>> >>>> >>> >> > From ioi.lam at oracle.com Sun Dec 13 23:48:51 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 13 Dec 2015 15:48:51 -0800 Subject: RFR (XS) 8144853: Print the names of callees in PrintAssembly/PrintInterprete In-Reply-To: <5667B24C.1070101@oracle.com> References: <5665CD82.4070909@oracle.com> <5665D6EB.1030207@oracle.com> <5665DED7.3000204@oracle.com> <5667B24C.1070101@oracle.com> Message-ID: <566E03E3.4020403@oracle.com> Hi David, I have updated the patch according to your feedback: http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names.v3/ The buf[] variable is now allocated using NEW_RESOURCE_ARRAY, and the useless 'found' variable has been removed. The comment is also fixed. Thanks - Ioi On 12/8/15 8:47 PM, David Holmes wrote: > Hi Ioi, > > src/share/vm/code/nmethod.cpp > > Your use of the static buffer seems not thread-safe. > > Minor nit: > > 3057 bool found; > 3058 found = os::dll_address_to_function_name(dest, buf, > sizeof(buf), &offset); > > could be: > > 3057 bool found = os::dll_address_to_function_name(dest, > buf, sizeof(buf), &offset); > > > --- > > src/share/vm/compiler/disassembler.cpp > > Your use of the static buffer seems not thread-safe. > > 366 bool found; > > This variable seems unused. > > Typo: > > 369 // Don't do this for native methods, as the function name will > be printed in > 370 // by nmethod::reloc_string_for(). > > delete 'in' or 'by'. > > Thanks, > David > ----- > > > On 8/12/2015 5:32 AM, Ioi Lam wrote: >> Hi Vladimir, >> >> Thanks for the suggestion. I've changed the patch to handle the nmethods >> differently than PrintInterpreter: >> >> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names.v2/ >> >> >> >> The nmethod dump now looks like this: >> >> 0x00007f607940c657: callq 0x00007f607186bb60 ; >> ImmutableOopMap{[0]=Oop } >> ;*ifeq {reexecute=1 >> rethrow=0 return_oop=0} >> ; - >> java.lang.String::charAt at 4 (line 685) >> ; {runtime_call >> UncommonTrapBlob} >> 0x00007f607940c65c: callq 0x00007f608b05eb00 ;*ifeq {reexecute=0 >> rethrow=0 return_oop=0} >> ; - >> java.lang.String::charAt at 4 (line 685) >> ; {runtime_call >> os::breakpoint()} >> >> >> Thanks >> - Ioi >> >> >> On 12/7/15 10:58 AM, Vladimir Ivanov wrote: >>> Ioi, >>> >>> Nice improvement! >>> >>> Why don't you print "{runtime_call os::breakpoint()}" for >>> -XX:+PrintAssemble instead? It looks more natural w.r.t. current >>> format. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 12/7/15 9:18 PM, Ioi Lam wrote: >>>> Please review a very small fix: >>>> >>>> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names/ >>>> >>>> >>>> >>>> >>>> Bug: Print the names of callees in PrintAssembly/PrintInterprete >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8144853 >>>> >>>> Summary of fix: >>>> >>>> In -XX:+PrintAssembly and -XX:+PrintInterpreter, sometimes only >>>> the address of a callee is printed, and the name is missing. >>>> >>>> The fix is to use os::dll_address_to_function_name() to find the >>>> names of such functions and print them out if possible. >>>> >>>> EXAMPLES: >>>> -XX:+PrintInterpreter: >>>> 0x00007f1b018447c3: callq 0x00007f1b19b9bba0 = >>>> InterpreterRuntime::newarray(JavaThread*, BasicType, int) >>>> >>>> -XX:+PrintAssembly >>>> <....> >>>> 0x00007f75d87b9629: xchg %ax,%ax >>>> 0x00007f75d87b962b: callq 0x00007f75d0c11b60 ; >>>> ImmutableOopMap{rbp=Oop } >>>> ;*iflt {reexecute=1 >>>> rethrow=0 return_oop=0} >>>> ; - >>>> java.lang.StringLatin1::charAt at 1 (line 43) >>>> ; {runtime_call >>>> UncommonTrapBlob} >>>> 0x00007f75d87b9630: callq 0x00007f75e8e41370 = os::breakpoint() >>>> ;*iflt {reexecute=0 >>>> rethrow=0 return_oop=0} >>>> ; - >>>> java.lang.StringLatin1::charAt at 1 (line 43) >>>> ; {runtime_call} >>>> >>>> >>>> TESTS: >>>> RBT hotspot/test/:hotspot_all (this includes tests cases with >>>> -XX:+PrintAssembly) >>>> >>>> Thanks >>>> - Ioi >> From david.holmes at oracle.com Mon Dec 14 03:49:56 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Dec 2015 13:49:56 +1000 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> <5664DBF9.7010708@oracle.com> <566660B2.4030100@oracle.com> <56679B9F.8030105@oracle.com> <566906CE.2050101@oracle.com> <566A5575.3020908@oracle.com> Message-ID: <566E3C64.2030506@oracle.com> On 12/12/2015 5:05 AM, Alexander Smundak wrote: > On Fri, Dec 11, 2015 at 5:57 AM, Volker Simonis > wrote: >> I've just verified that your patch still works for linux/ppc64. I've >> built and smoke-tested both linux/ppc64 and ppc64le and everything >> looks good. So from my side this is ready to push. > Thanks. > > Here's the new revision, with headers verified by jcheck: > > http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.05 > http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.05 > http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.05 Thanks for your patience Sasha! Hopefully this will all be trivial next time round. I had to rebase the changeset to accommodate the change from: 8144885: agent/src/os/linux/libproc.h needs to support Linux/SPARC builds but otherwise all okay. (I didn't want to send it back to you again :) ). Cheers, David > Sasha > From tobias.hartmann at oracle.com Mon Dec 14 07:11:51 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 14 Dec 2015 08:11:51 +0100 Subject: RFR(S): 8145015: jni_GetStringCritical asserts for empty strings In-Reply-To: References: Message-ID: <566E6BB7.4030602@oracle.com> Hi Volker, thanks for taking care of this! Your fix looks good to me (not a reviewer). Best, Tobias On 09.12.2015 18:53, Volker Simonis wrote: > Hi, > > can somebody please review and sponsor the following fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8145015/ > https://bugs.openjdk.java.net/browse/JDK-8145015 > > The problem is that change "8141132: JEP 254: Compact Strings" removed > the handling for empty strings from jni_GetStringCritical(). As a > consequence, the functions will now assert with: > > assert(is_within_bounds(which)) failed: index 0 out of bounds 0 > > if called with a string of length zero (because it tries to access the > zeroth element of a zero-length array). > > The fix is trivial, just use 's_value->base(T_CHAR)' instead of > 's_value->char_at_addr(0)'. > > While doing this fix I also noticed that jni_GetStringCritical() > doesn't handle out-of-memory situations when creating a new character > array (before this wasn't necessary because it always returned the > original character array, but now with compressed strings it may have > to allocate a new array). So I've also added the new check by using > NEW_C_HEAP_ARRAY_RETURN_NULL() instead of NEW_C_HEAP_ARRAY(). > > Notice that I also allocate one extra character for zero termination. > While it seems that this is not strictly necessary, it is now the same > code like in jni_GetStringChars(). And it again simplifies the > handling of zero-length strings. Without the extra character it would > be hard to distinguish out-of-memory errors from the allocation of > zero bytes, because malloc() is free to return NULL if called with an > allocation size of zero. > > Thank you and best regards, > Volker > From david.holmes at oracle.com Mon Dec 14 07:17:36 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Dec 2015 17:17:36 +1000 Subject: RFR (S): JDK-8142909 Integration of minor fixes from the build-infra project In-Reply-To: <566B2FFF.3090109@oracle.com> References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com> <5645CA9E.4060205@oracle.com> <56493B10.6040207@oracle.com> <5649923E.8010707@oracle.com> <5649B9DB.2030507@oracle.com> <5649C8B8.2000707@oracle.com> <564A897D.7010707@oracle.com> <566B2FFF.3090109@oracle.com> Message-ID: <566E6D10.3050502@oracle.com> Looks trivially fine to me :) Thanks, David On 12/12/2015 6:20 AM, Magnus Ihse Bursie wrote: > I'm trying to resurrect this review. > > Here is a new version: > http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.03 > > > I have dropped all the changes related to -g and OPT_CFLAGS. I'm not > interested in that kind of large scale operations on the old build > system, I just wanted to transfer the small patches we have in the > build-infra forest to mainline to facilitate comparison between old and > new build. If that was too problematic, let's skip it. > > Remaining changes are: > * Making adlc more quiet > * Sorting the windows build > > Also, in the meantime, a new difference has surfaced. In the first push > of the new hotspot build system, the rewrite of SA, the file > make/bsd/makefiles/saproc.make unfortunately was not deleted in > mainline. I added the deletion of this file. > > I intend to push this through hs-rt. David and Erik, please confirm that > these changes are OK for you. > > /Magnus > > > On 2015-11-17 02:57, David Holmes wrote: >> On 16/11/2015 10:14 PM, Erik Joelsson wrote: >>> On 2015-11-16 12:11, David Holmes wrote: >>>> On 16/11/2015 6:22 PM, Erik Joelsson wrote: >>>>> On 2015-11-16 03:10, David Holmes wrote: >>>>>> Hi Magnus, >>>>>> >>>>>> On 13/11/2015 9:33 PM, Magnus Ihse Bursie wrote: >>>>>>> On 2015-11-13 09:13, Erik Joelsson wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> make/bsd/makefiles/amd64.make: >>>>>>>> make/bsd/makefiles/gcc.make: >>>>>>>> Perhaps the order of "$(OPT_CFLAGS/NOOPT) >>>>>>>> $(OPT_CFLAGS/$(BUILDARCH))" >>>>>>>> should be reversed to guarantee that NOOPT is the one used in case >>>>>>>> BUILDARCH contains something that conflicts? The solaris file >>>>>>>> does it >>>>>>>> this way. >>>>>>> You know you wrote that code originally? ;-) >>>>>>> >>>>>>> Yeah, I agree, it's more reasonable. Updated webrev: >>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I don't like this particular change as it is too generic. It gives >>>>>> the >>>>>> appearance of being apply to apply whatever the BUILDARCH specific >>>>>> optflags are, which makes no sense if the whole point here is to not >>>>>> optimize these files. If all this is intended to do is include -g >>>>>> then >>>>>> I think that should be done explicitly. >>>>>> >>>>> The -g flag is added to OPT_CFLAGS/$(BUILDARCH) and I can only assume >>>>> the intention was to have it added to all compilation command lines. >>>>> However, the OPT_CFLAGS/ variable overrides >>>>> CFLAGS/$(BUILDARCH), effectively removing the -g flag from the files >>>>> where we explicitly change the optimization level. The patch >>>>> intends to >>>>> make sure -g is used on those files too. >>>> >>>> I understand that, but it is far from obvious that OPT_FLAGS/BUILDARCH >>>> means -g (why???), or that putting other things in that variable might >>>> break files that should not be optimized. >>>> >>>>> A cleaner solution would be to not have -g be part of the OPT flags at >>>>> all but its own set of DEBUG_CFLAGS. >>>> >>>> I thought -g was in the DEBUG_CFLAGS ?? Or maybe it used to be. Anyway >>>> if all we are interested in is adding -g then I agree it should have >>>> its own variable. >>>> >>> I looked some more at this. There is a DEBUG_CFLAGS, FASTDEBUG_CFLAGS >>> and OPT_CFLAGS. These get picked depending on the debug level of the >>> build. For example in product.make, $(OPT_CFLAGS/BYFILE) gets added to >>> CFLAGS. >>> >>> I can't really see a better way of making sure the -g does not fall off >>> for some files than what is proposed here. At least not without >>> completely reworking the flags handling in the current hotspot >>> makefiles, something I'm very uninterested in doing. >> >> In the -g case what we are handling is the addition of -g to product >> builds (it is already on fastdebug, debug) when >> ENABLE_FULL_DEBUG_SYMBOLS is selected, on a subset of architectures. >> As a convenience we define it thus (BSD version): >> >> OPT_CFLAGS/ia64 = -g >> OPT_CFLAGS/amd64 = -g >> OPT_CFLAGS/arm = -g >> OPT_CFLAGS/ppc = -g >> OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH)) >> >> so $(OPT_CFLAGS/$(BUILDARCH)) happens to contain -g. I would be happy >> if the above were changed to: >> >> FDS_CFLAGS/ia64 = -g >> FDS_CFLAGS/amd64 = -g >> FDS_CFLAGS/arm = -g >> FDS_CFLAGS/ppc = -g >> OPT_CFLAGS += $(FDS_CFLAGS/$(BUILDARCH)) >> >> and then you could use $(FDS_CFLAGS/$(BUILDARCH) on the "by-file" >> definitions, where it would be much clearer what kind of flag is >> actually being applied. However this needs to be done everywhere, and >> I don't see this fix attempting to do that. We set >> OPT_CFLAGS/ in numerous places (open and closed) to regain >> control over the "opt" flags applied to that file. Sometimes we use >> predefined opt flags, like NOOPT or SPEED, and sometimes we don't eg: >> >> linux/makefiles/amd64.make >> >> OPT_CFLAGS/compactingPermGenGen.o = -O1 >> >> This would need to be applied to every occurrence of the "byfile" >> definitions in all the makefiles. Or else ascertained on a >> case-by-case basis that we don't want -g for a specific file. >> >> Further, on architectures where $(FDS_CFLAGS/$(BUILDARCH) is not set >> you still have to somehow handle the rest of the above logic: >> >> 507 ifeq ($(OPT_CFLAGS/$(BUILDARCH)),) >> 508 ifeq ($(USE_CLANG), true) >> 509 # Clang doesn't understand -gstabs >> 510 OPT_CFLAGS += -g >> 511 else >> 512 OPT_CFLAGS += -gstabs >> 513 endif >> 514 endif >> >> else you again fail to set -g or -gstabs on the "by-file" definitions. >> >> Also looking at the change in make/solaris/makefiles/amd64.make you >> have taken the file specific flags: >> >> OPT_CFLAGS/generateOptoStub.o = -xO2 >> >> and added the generic OPT_CFLAGS value: >> >> OPT_CFLAGS/generateOptoStub.o = $(OPT_CFLAGS) -xO2 >> >> which seems extremely dubious from a correctness perspective. >> >> Thanks, >> David >> ----- >> >>>>>> --- >>>>>> >>>>>> make/bsd/makefiles/saproc.make >>>>>> >>>>>> ! # Order src files alfabetically >>>>>> >>>>>> That would be "alphabetically". But that list doesn't seem alphabetic >>>>>> anyway: MacosxDebuggerLocal.m would come after libproc_impl.c; and >>>>>> $(AGENTDIR) should come first. I really see no point in forcing such >>>>>> lists to be in alphabetic order. >>>>>> >>>>> This is to make comparison of binaries between the old hotspot >>>>> build and >>>>> the new hotspot build easier. In build-infra, we $(sort ) the object >>>>> files before linking to get a reproducible order. The linker output is >>>>> affected by the order of the object files. By making sure the old and >>>>> the new build sorts them the same way, we get cleaner comparisons and >>>>> can more easily detect other types of differences through those >>>>> comparisons. The sort order isn't strictly alphabetical, it's on byte >>>>> order so upper case goes before lower case. >>>> >>>> I saw the change for the ordered object files on Windows, but this >>>> simply orders source files in a list. Not sure how that has any affect >>>> on the linking ?? >>>> >>> It has an effect on the linking because that list is used verbatim on >>> the combined compile/link command line. >>> >>> /Erik >>>> Cheers, >>>> David >>>> >>>>> /Erik >>>>>> make/linux/makefiles/saproc.make doesn't have the comment that was >>>>>> added for bsd. >>>>>> >>>>>> ---- >>>>>> >>>>>> make/solaris/makefiles/amd64.make >>>>>> >>>>>> Similar issue with bsd amd64.make. Not sure what you are trying to >>>>>> achieve here - is it some kind of last option wins situation ? >>>>>> >>>>>> --- >>>>>> >>>>>> make/windows/create_obj_files.sh >>>>>> >>>>>> Harmless I guess but not sure about relevance of sort order here. >>>>>> >>>>>> ---- >>>>>> >>>>>> src/share/vm/adlc/adlparse.cpp >>>>>> >>>>>> So that's where that comes from! :) >>>>>> >>>>>> --- >>>>>> >>>>>> src/share/vm/gc/g1/g1EvacStats.cpp >>>>>> >>>>>> I don't see anything in the cpp files that uses anything from the >>>>>> atomic class ??? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> >>>>>>>> Otherwise looks good. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> On 2015-11-13 03:34, Magnus Ihse Bursie wrote: >>>>>>>>> In the new hotspot build project, we have made a few changes to >>>>>>>>> the >>>>>>>>> existing build. In preparation for the new build, I'd like to >>>>>>>>> integrate these into mainline. >>>>>>>>> >>>>>>>>> These changes are: >>>>>>>>> * When overriding optimization, do not lose current debug (-g) >>>>>>>>> setting (!) >>>>>>>>> * Make adlc actually quiet in quiet mode >>>>>>>>> * Make g1EvacStats.cpp compile in all cases without precompiled >>>>>>>>> headers >>>>>>>>> * Sort saproc object files when linking (facilitates comparison to >>>>>>>>> new build) >>>>>>>>> >>>>>>>>> Unless someone suggests otherwise, I intend to push this (using >>>>>>>>> JPRT) >>>>>>>>> to hs-rt. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909 >>>>>>>>> WebRev: >>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>> >>>>>>> >>>>> >>> > From david.holmes at oracle.com Mon Dec 14 07:25:59 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Dec 2015 17:25:59 +1000 Subject: RFR(S): 8145015: jni_GetStringCritical asserts for empty strings In-Reply-To: <566E6BB7.4030602@oracle.com> References: <566E6BB7.4030602@oracle.com> Message-ID: <566E6F07.9030606@oracle.com> +1 from me. My only query is whether: 3194 jchar* ret; should retain the const, as the return type is "const jchar *"? Thanks, David On 14/12/2015 5:11 PM, Tobias Hartmann wrote: > Hi Volker, > > thanks for taking care of this! Your fix looks good to me (not a reviewer). > > Best, > Tobias > > On 09.12.2015 18:53, Volker Simonis wrote: >> Hi, >> >> can somebody please review and sponsor the following fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145015/ >> https://bugs.openjdk.java.net/browse/JDK-8145015 >> >> The problem is that change "8141132: JEP 254: Compact Strings" removed >> the handling for empty strings from jni_GetStringCritical(). As a >> consequence, the functions will now assert with: >> >> assert(is_within_bounds(which)) failed: index 0 out of bounds 0 >> >> if called with a string of length zero (because it tries to access the >> zeroth element of a zero-length array). >> >> The fix is trivial, just use 's_value->base(T_CHAR)' instead of >> 's_value->char_at_addr(0)'. >> >> While doing this fix I also noticed that jni_GetStringCritical() >> doesn't handle out-of-memory situations when creating a new character >> array (before this wasn't necessary because it always returned the >> original character array, but now with compressed strings it may have >> to allocate a new array). So I've also added the new check by using >> NEW_C_HEAP_ARRAY_RETURN_NULL() instead of NEW_C_HEAP_ARRAY(). >> >> Notice that I also allocate one extra character for zero termination. >> While it seems that this is not strictly necessary, it is now the same >> code like in jni_GetStringChars(). And it again simplifies the >> handling of zero-length strings. Without the extra character it would >> be hard to distinguish out-of-memory errors from the allocation of >> zero bytes, because malloc() is free to return NULL if called with an >> allocation size of zero. >> >> Thank you and best regards, >> Volker >> From volker.simonis at gmail.com Mon Dec 14 08:27:48 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 14 Dec 2015 09:27:48 +0100 Subject: RFR(S): 8145015: jni_GetStringCritical asserts for empty strings In-Reply-To: <566E6F07.9030606@oracle.com> References: <566E6BB7.4030602@oracle.com> <566E6F07.9030606@oracle.com> Message-ID: Hi David, thanks for the review. "const jchar*" means a pointer to a constant character. I removed the 'const' because that way I could get rid of the extra 'buf' variable which was previously used to allocate and fill the temporary string. With "const jchar * ret" it wouldn't be possible to change the characters pointed to by 'ret'. Returning "jachr *ret" as "const jchar * ret" on the other hand is no problem - it is just a narrowing conversion saying that once we return "ret" the characters it points to can not be changed any more. So I think the code is correct. I'd need a sponsor though, because this is a shared changed and unfortunately we still can not push shared code changes (I'll put this sentence in every mail now although I have little to no hope that it will change something :( Thank you and best regards, Volker On Mon, Dec 14, 2015 at 8:25 AM, David Holmes wrote: > +1 from me. My only query is whether: > > 3194 jchar* ret; > > should retain the const, as the return type is "const jchar *"? > > Thanks, > David > > > On 14/12/2015 5:11 PM, Tobias Hartmann wrote: >> >> Hi Volker, >> >> thanks for taking care of this! Your fix looks good to me (not a >> reviewer). >> >> Best, >> Tobias >> >> On 09.12.2015 18:53, Volker Simonis wrote: >>> >>> Hi, >>> >>> can somebody please review and sponsor the following fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145015/ >>> https://bugs.openjdk.java.net/browse/JDK-8145015 >>> >>> The problem is that change "8141132: JEP 254: Compact Strings" removed >>> the handling for empty strings from jni_GetStringCritical(). As a >>> consequence, the functions will now assert with: >>> >>> assert(is_within_bounds(which)) failed: index 0 out of bounds 0 >>> >>> if called with a string of length zero (because it tries to access the >>> zeroth element of a zero-length array). >>> >>> The fix is trivial, just use 's_value->base(T_CHAR)' instead of >>> 's_value->char_at_addr(0)'. >>> >>> While doing this fix I also noticed that jni_GetStringCritical() >>> doesn't handle out-of-memory situations when creating a new character >>> array (before this wasn't necessary because it always returned the >>> original character array, but now with compressed strings it may have >>> to allocate a new array). So I've also added the new check by using >>> NEW_C_HEAP_ARRAY_RETURN_NULL() instead of NEW_C_HEAP_ARRAY(). >>> >>> Notice that I also allocate one extra character for zero termination. >>> While it seems that this is not strictly necessary, it is now the same >>> code like in jni_GetStringChars(). And it again simplifies the >>> handling of zero-length strings. Without the extra character it would >>> be hard to distinguish out-of-memory errors from the allocation of >>> zero bytes, because malloc() is free to return NULL if called with an >>> allocation size of zero. >>> >>> Thank you and best regards, >>> Volker >>> > From erik.joelsson at oracle.com Mon Dec 14 08:32:31 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 14 Dec 2015 09:32:31 +0100 Subject: RFR (S): JDK-8142909 Integration of minor fixes from the build-infra project In-Reply-To: <566B2FFF.3090109@oracle.com> References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com> <5645CA9E.4060205@oracle.com> <56493B10.6040207@oracle.com> <5649923E.8010707@oracle.com> <5649B9DB.2030507@oracle.com> <5649C8B8.2000707@oracle.com> <564A897D.7010707@oracle.com> <566B2FFF.3090109@oracle.com> Message-ID: <566E7E9F.8090904@oracle.com> Looks good to me. /Erik On 2015-12-11 21:20, Magnus Ihse Bursie wrote: > I'm trying to resurrect this review. > > Here is a new version: > http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.03 > > > I have dropped all the changes related to -g and OPT_CFLAGS. I'm not > interested in that kind of large scale operations on the old build > system, I just wanted to transfer the small patches we have in the > build-infra forest to mainline to facilitate comparison between old > and new build. If that was too problematic, let's skip it. > > Remaining changes are: > * Making adlc more quiet > * Sorting the windows build > > Also, in the meantime, a new difference has surfaced. In the first > push of the new hotspot build system, the rewrite of SA, the file > make/bsd/makefiles/saproc.make unfortunately was not deleted in > mainline. I added the deletion of this file. > > I intend to push this through hs-rt. David and Erik, please confirm > that these changes are OK for you. > > /Magnus > > > On 2015-11-17 02:57, David Holmes wrote: >> On 16/11/2015 10:14 PM, Erik Joelsson wrote: >>> On 2015-11-16 12:11, David Holmes wrote: >>>> On 16/11/2015 6:22 PM, Erik Joelsson wrote: >>>>> On 2015-11-16 03:10, David Holmes wrote: >>>>>> Hi Magnus, >>>>>> >>>>>> On 13/11/2015 9:33 PM, Magnus Ihse Bursie wrote: >>>>>>> On 2015-11-13 09:13, Erik Joelsson wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> make/bsd/makefiles/amd64.make: >>>>>>>> make/bsd/makefiles/gcc.make: >>>>>>>> Perhaps the order of "$(OPT_CFLAGS/NOOPT) >>>>>>>> $(OPT_CFLAGS/$(BUILDARCH))" >>>>>>>> should be reversed to guarantee that NOOPT is the one used in case >>>>>>>> BUILDARCH contains something that conflicts? The solaris file >>>>>>>> does it >>>>>>>> this way. >>>>>>> You know you wrote that code originally? ;-) >>>>>>> >>>>>>> Yeah, I agree, it's more reasonable. Updated webrev: >>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I don't like this particular change as it is too generic. It >>>>>> gives the >>>>>> appearance of being apply to apply whatever the BUILDARCH specific >>>>>> optflags are, which makes no sense if the whole point here is to not >>>>>> optimize these files. If all this is intended to do is include -g >>>>>> then >>>>>> I think that should be done explicitly. >>>>>> >>>>> The -g flag is added to OPT_CFLAGS/$(BUILDARCH) and I can only assume >>>>> the intention was to have it added to all compilation command lines. >>>>> However, the OPT_CFLAGS/ variable overrides >>>>> CFLAGS/$(BUILDARCH), effectively removing the -g flag from the files >>>>> where we explicitly change the optimization level. The patch >>>>> intends to >>>>> make sure -g is used on those files too. >>>> >>>> I understand that, but it is far from obvious that OPT_FLAGS/BUILDARCH >>>> means -g (why???), or that putting other things in that variable might >>>> break files that should not be optimized. >>>> >>>>> A cleaner solution would be to not have -g be part of the OPT >>>>> flags at >>>>> all but its own set of DEBUG_CFLAGS. >>>> >>>> I thought -g was in the DEBUG_CFLAGS ?? Or maybe it used to be. Anyway >>>> if all we are interested in is adding -g then I agree it should have >>>> its own variable. >>>> >>> I looked some more at this. There is a DEBUG_CFLAGS, FASTDEBUG_CFLAGS >>> and OPT_CFLAGS. These get picked depending on the debug level of the >>> build. For example in product.make, $(OPT_CFLAGS/BYFILE) gets added to >>> CFLAGS. >>> >>> I can't really see a better way of making sure the -g does not fall off >>> for some files than what is proposed here. At least not without >>> completely reworking the flags handling in the current hotspot >>> makefiles, something I'm very uninterested in doing. >> >> In the -g case what we are handling is the addition of -g to product >> builds (it is already on fastdebug, debug) when >> ENABLE_FULL_DEBUG_SYMBOLS is selected, on a subset of architectures. >> As a convenience we define it thus (BSD version): >> >> OPT_CFLAGS/ia64 = -g >> OPT_CFLAGS/amd64 = -g >> OPT_CFLAGS/arm = -g >> OPT_CFLAGS/ppc = -g >> OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH)) >> >> so $(OPT_CFLAGS/$(BUILDARCH)) happens to contain -g. I would be happy >> if the above were changed to: >> >> FDS_CFLAGS/ia64 = -g >> FDS_CFLAGS/amd64 = -g >> FDS_CFLAGS/arm = -g >> FDS_CFLAGS/ppc = -g >> OPT_CFLAGS += $(FDS_CFLAGS/$(BUILDARCH)) >> >> and then you could use $(FDS_CFLAGS/$(BUILDARCH) on the "by-file" >> definitions, where it would be much clearer what kind of flag is >> actually being applied. However this needs to be done everywhere, and >> I don't see this fix attempting to do that. We set >> OPT_CFLAGS/ in numerous places (open and closed) to regain >> control over the "opt" flags applied to that file. Sometimes we use >> predefined opt flags, like NOOPT or SPEED, and sometimes we don't eg: >> >> linux/makefiles/amd64.make >> >> OPT_CFLAGS/compactingPermGenGen.o = -O1 >> >> This would need to be applied to every occurrence of the "byfile" >> definitions in all the makefiles. Or else ascertained on a >> case-by-case basis that we don't want -g for a specific file. >> >> Further, on architectures where $(FDS_CFLAGS/$(BUILDARCH) is not set >> you still have to somehow handle the rest of the above logic: >> >> 507 ifeq ($(OPT_CFLAGS/$(BUILDARCH)),) >> 508 ifeq ($(USE_CLANG), true) >> 509 # Clang doesn't understand -gstabs >> 510 OPT_CFLAGS += -g >> 511 else >> 512 OPT_CFLAGS += -gstabs >> 513 endif >> 514 endif >> >> else you again fail to set -g or -gstabs on the "by-file" definitions. >> >> Also looking at the change in make/solaris/makefiles/amd64.make you >> have taken the file specific flags: >> >> OPT_CFLAGS/generateOptoStub.o = -xO2 >> >> and added the generic OPT_CFLAGS value: >> >> OPT_CFLAGS/generateOptoStub.o = $(OPT_CFLAGS) -xO2 >> >> which seems extremely dubious from a correctness perspective. >> >> Thanks, >> David >> ----- >> >>>>>> --- >>>>>> >>>>>> make/bsd/makefiles/saproc.make >>>>>> >>>>>> ! # Order src files alfabetically >>>>>> >>>>>> That would be "alphabetically". But that list doesn't seem >>>>>> alphabetic >>>>>> anyway: MacosxDebuggerLocal.m would come after libproc_impl.c; and >>>>>> $(AGENTDIR) should come first. I really see no point in forcing such >>>>>> lists to be in alphabetic order. >>>>>> >>>>> This is to make comparison of binaries between the old hotspot >>>>> build and >>>>> the new hotspot build easier. In build-infra, we $(sort ) the object >>>>> files before linking to get a reproducible order. The linker >>>>> output is >>>>> affected by the order of the object files. By making sure the old and >>>>> the new build sorts them the same way, we get cleaner comparisons and >>>>> can more easily detect other types of differences through those >>>>> comparisons. The sort order isn't strictly alphabetical, it's on byte >>>>> order so upper case goes before lower case. >>>> >>>> I saw the change for the ordered object files on Windows, but this >>>> simply orders source files in a list. Not sure how that has any affect >>>> on the linking ?? >>>> >>> It has an effect on the linking because that list is used verbatim on >>> the combined compile/link command line. >>> >>> /Erik >>>> Cheers, >>>> David >>>> >>>>> /Erik >>>>>> make/linux/makefiles/saproc.make doesn't have the comment that was >>>>>> added for bsd. >>>>>> >>>>>> ---- >>>>>> >>>>>> make/solaris/makefiles/amd64.make >>>>>> >>>>>> Similar issue with bsd amd64.make. Not sure what you are trying to >>>>>> achieve here - is it some kind of last option wins situation ? >>>>>> >>>>>> --- >>>>>> >>>>>> make/windows/create_obj_files.sh >>>>>> >>>>>> Harmless I guess but not sure about relevance of sort order here. >>>>>> >>>>>> ---- >>>>>> >>>>>> src/share/vm/adlc/adlparse.cpp >>>>>> >>>>>> So that's where that comes from! :) >>>>>> >>>>>> --- >>>>>> >>>>>> src/share/vm/gc/g1/g1EvacStats.cpp >>>>>> >>>>>> I don't see anything in the cpp files that uses anything from the >>>>>> atomic class ??? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> >>>>>>>> Otherwise looks good. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> On 2015-11-13 03:34, Magnus Ihse Bursie wrote: >>>>>>>>> In the new hotspot build project, we have made a few changes >>>>>>>>> to the >>>>>>>>> existing build. In preparation for the new build, I'd like to >>>>>>>>> integrate these into mainline. >>>>>>>>> >>>>>>>>> These changes are: >>>>>>>>> * When overriding optimization, do not lose current debug (-g) >>>>>>>>> setting (!) >>>>>>>>> * Make adlc actually quiet in quiet mode >>>>>>>>> * Make g1EvacStats.cpp compile in all cases without precompiled >>>>>>>>> headers >>>>>>>>> * Sort saproc object files when linking (facilitates >>>>>>>>> comparison to >>>>>>>>> new build) >>>>>>>>> >>>>>>>>> Unless someone suggests otherwise, I intend to push this (using >>>>>>>>> JPRT) >>>>>>>>> to hs-rt. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909 >>>>>>>>> WebRev: >>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>> >>>>>>> >>>>> >>> > From konstantin.shefov at oracle.com Mon Dec 14 08:58:20 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 14 Dec 2015 11:58:20 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <936BAB55-5004-440C-A980-E7F9D2DBBF13@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <936BAB55-5004-440C-A980-E7F9D2DBBF13@oracle.com> Message-ID: <566E84AC.8010204@oracle.com> Hi Igor I have filed an RFE you asked about https://bugs.openjdk.java.net/browse/JDK-8145297. -Konstantin On 12/12/2015 05:10 AM, Igor Ignatyev wrote: > Hi Konstantin, > > the fix and tests look good to me, but I think you have to wait for OK from Coleen. > > One minor thing ?it looks like there are no tests for other s.r.CP methods, could you please file an RFE against core-libs/j.l.reflect to cover them? > > Thanks, > ? Igor > >> On Dec 11, 2015, at 2:54 PM, Konstantin Shefov wrote: >> >> Hello >> >> Please review the new version on the patch. >> >> New webrev: >> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >> >> What has been changed: >> 1. Added tests for the new added methods. >> 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). >> >> Thanks >> -Konstantin >> >> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>> Coleen, >>> Thanks for review >>> >>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>> I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be added with the functionality changeset, not promised afterward. >>> I will add tests. >>>> Secondly, I do not like that JDK code knows the implementation details of the JVM's constant pool tags. These should be only for internal use. >>> The package "sun.reflect" is for internal use only, so it shouldn?t be a problem. >>>> My third comment is that I haven't looked carefully at this constant pool implementation but it seems very unsafe if the class is redefined and relies on an implementation detail in the JVM that can change. I will have more comments once I look more at the jvmti specification. >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>> Hello >>>>> >>>>> Please, review modified webrev. >>>>> >>>>> I have added methods >>>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; >>>>> getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; >>>>> >>>>> I removed previously added method >>>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>>> >>>>> New webrev: >>>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>> >>>>> Thanks >>>>> -Konstantin >>>>> >>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>> Remi, >>>>>> >>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>> May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. >>>>>> >>>>>> -Konstantin >>>>>> >>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>> Hi Konstantin, >>>>>>> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef. >>>>>>> >>>>>>> In term of API, I think it's better to decompose the API, i.e. to have a method >>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. >>>>>>> >>>>>>> cheers, >>>>>>> R?mi >>>>>>> >>>>>>> ----- Mail original ----- >>>>>>>> De: "Christian Thalinger" >>>>>>>> ?: "Konstantin Shefov" >>>>>>>> Cc: "hotspot-dev developers" , core-libs-dev at openjdk.java.net >>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool >>>>>>>> >>>>>>>> [CC'ing core-libs-dev] >>>>>>>> >>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello >>>>>>>>> >>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>> The following methods are suggested: >>>>>>>>> >>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>>>> representation of name and type from a NameAndType constant pool entry >>>>>>>>> with the specified index >>>>>>>>> >>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string >>>>>>>>> representation of name and type from an InvokeDynamic constant pool entry >>>>>>>>> with the specified index >>>>>>>>> >>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant >>>>>>>>> pool entry with the specified index >>>>>>>>> >>>>>>>>> These three methods could be used for testing API working with constant >>>>>>>>> pool, e.g. JVMCI. >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>> Webrev hotspot: >>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Konstantin From david.holmes at oracle.com Mon Dec 14 12:31:37 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Dec 2015 22:31:37 +1000 Subject: RFR(S): 8145015: jni_GetStringCritical asserts for empty strings In-Reply-To: References: <566E6BB7.4030602@oracle.com> <566E6F07.9030606@oracle.com> Message-ID: <566EB6A9.10903@oracle.com> Hi Volker, On 14/12/2015 6:27 PM, Volker Simonis wrote: > Hi David, > > thanks for the review. > > "const jchar*" means a pointer to a constant character. I removed the > 'const' because that way I could get rid of the extra 'buf' variable > which was previously used to allocate and fill the temporary string. > With "const jchar * ret" it wouldn't be possible to change the > characters pointed to by 'ret'. > > Returning "jachr *ret" as "const jchar * ret" on the other hand is no > problem - it is just a narrowing conversion saying that once we return > "ret" the characters it points to can not be changed any more. > > So I think the code is correct. Okay. I keep forgetting that const isn't saying something about the object at the end of the pointer, but about what you're allowed to do to the object through the pointer. > I'd need a sponsor though, because this is a shared changed and I'm pushing this to hs-rt for you now. Cheers, David > unfortunately we still can not push shared code changes (I'll put this > sentence in every mail now although I have little to no hope that it > will change something :( > > Thank you and best regards, > Volker > > > > On Mon, Dec 14, 2015 at 8:25 AM, David Holmes wrote: >> +1 from me. My only query is whether: >> >> 3194 jchar* ret; >> >> should retain the const, as the return type is "const jchar *"? >> >> Thanks, >> David >> >> >> On 14/12/2015 5:11 PM, Tobias Hartmann wrote: >>> >>> Hi Volker, >>> >>> thanks for taking care of this! Your fix looks good to me (not a >>> reviewer). >>> >>> Best, >>> Tobias >>> >>> On 09.12.2015 18:53, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> can somebody please review and sponsor the following fix: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145015/ >>>> https://bugs.openjdk.java.net/browse/JDK-8145015 >>>> >>>> The problem is that change "8141132: JEP 254: Compact Strings" removed >>>> the handling for empty strings from jni_GetStringCritical(). As a >>>> consequence, the functions will now assert with: >>>> >>>> assert(is_within_bounds(which)) failed: index 0 out of bounds 0 >>>> >>>> if called with a string of length zero (because it tries to access the >>>> zeroth element of a zero-length array). >>>> >>>> The fix is trivial, just use 's_value->base(T_CHAR)' instead of >>>> 's_value->char_at_addr(0)'. >>>> >>>> While doing this fix I also noticed that jni_GetStringCritical() >>>> doesn't handle out-of-memory situations when creating a new character >>>> array (before this wasn't necessary because it always returned the >>>> original character array, but now with compressed strings it may have >>>> to allocate a new array). So I've also added the new check by using >>>> NEW_C_HEAP_ARRAY_RETURN_NULL() instead of NEW_C_HEAP_ARRAY(). >>>> >>>> Notice that I also allocate one extra character for zero termination. >>>> While it seems that this is not strictly necessary, it is now the same >>>> code like in jni_GetStringChars(). And it again simplifies the >>>> handling of zero-length strings. Without the extra character it would >>>> be hard to distinguish out-of-memory errors from the allocation of >>>> zero bytes, because malloc() is free to return NULL if called with an >>>> allocation size of zero. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >> From frederic.parain at oracle.com Mon Dec 14 13:23:41 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 14 Dec 2015 14:23:41 +0100 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> Message-ID: <566EC2DD.5000404@oracle.com> Karen, Thank you for your review. Fred On 23/11/2015 20:10, Karen Kinnear wrote: > Frederic, > > Looks good. > > Many thanks. > Karen > >> On Nov 23, 2015, at 12:44 PM, Frederic Parain >> > wrote: >> >> Karen, >> >> Thank you for your review, my answers are in-lined below. >> >> New Webrevs (including some fixes suggested by Paul Sandoz): >> >> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ >> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/ >> >> On 20/11/2015 19:44, Karen Kinnear wrote: >>> Frederic, >>> >>> Code review for web revs you sent out. >>> Code looks good. I am not as familiar with the compiler code. >>> >>> I realize you need to check in at least a subset of the >>> java.util.concurrent changes for >>> the test to work, so maybe I should not have asked Doug about his >>> preference there. >>> Sorry. >>> >>> I am impressed you found a way to make a reproducible test! >>> >>> Comments/questions: >>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >> >> Fixed >> >>> 2. IIRC, due to another bug with windows handling of our guard pages, >>> this >>> is disabled for Windows. Would it be worth putting a comment in the >>> bug , 8067946, that once this is fixed, the reserved stack logic on >>> windows >>> will need testing before enabling? >> >> More than testing, the implementation would have to be completed on >> Windows. I've added a comment to JDK-8067946. >> >>> 3. In get_frame_at_stack_banging_point on Linux, BSD and solaris_x86 if >>> this is in interpreter code, you explicitly return the Java sender >>> of the current frame. I was expecting to see that on Solaris_sparc >>> and Windows >>> as well? I do see the assertion in caller that you do have a java frame. >> >> It doesn't make sense to check the current frame (no bytecode has been >> executed yet, so risk of partially executed critical section). I did the >> change but not for all platforms. This is now fixed for Solaris_SPARC >> and Windows too. >> >>> 4. test line 83 ?writtent? -> ?written? >> >> Fixed >> >>> 5. I like the way you set up the preallocated exception and then set >>> the message - we may >>> try that for default methods in future. >>> >>> 6. I had a memory that you had found a bug in safe_for_sender - did >>> you already check that in? >> >> I've fixed x86 platforms in JDK-8068655. >> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >> I had hoped it would have been silently accepted :-) >> >> >>> 7. I see the change in trace.xml, and I see an include added to >>> SharedRuntime.cpp, >>> but I didn?t see where it was used - did I just miss it? >> >> trace.xml changes define a new event. >> This event is created at sharedRuntime.cpp::3006 and it is used >> in the next 3 lines. > Thanks. I must have mistyped when I searched for it. >> >> Thanks, >> >> Fred >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> Email:Frederic.Parain at oracle.com > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From goetz.lindenmaier at sap.com Mon Dec 14 13:59:31 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Dec 2015 13:59:31 +0000 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <566EC2DD.5000404@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <566EC2DD.5000404@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDE813@DEWDFEMB12A.global.corp.sap> Hi Frederic, I'm now again working on my change "8139864: Improve handling of stack protection zones." Coleen had asked me to wait until this change of yours is submitted. You changed the stack_yellow_zone accessor functions in thread.hpp to handle both zones, yellow and reserved. Therefore, reading the code, the reserved zone seems to be part of the yellow zone. In the description of the bug, it says "The new zone defined by the proposed solution is placed just before the yellow zone." This reads as if the zones are separate. Would you mind if I rename the stack_yellow_zone accessor functions to stack_yellow_reserved_zone? This would make clear in the code that this are two separate zones. I anyways have to adapt most of the calls to these accessors. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Frederic Parain > Sent: Montag, 14. Dezember 2015 14:24 > To: Karen Kinnear > Cc: hotspot-dev at openjdk.java.net; core-libs-dev dev at openjdk.java.net> > Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical > Sections > > Karen, > > Thank you for your review. > > Fred > > On 23/11/2015 20:10, Karen Kinnear wrote: > > Frederic, > > > > Looks good. > > > > Many thanks. > > Karen > > > >> On Nov 23, 2015, at 12:44 PM, Frederic Parain > >> > > wrote: > >> > >> Karen, > >> > >> Thank you for your review, my answers are in-lined below. > >> > >> New Webrevs (including some fixes suggested by Paul Sandoz): > >> > >> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ > >> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/ > >> > >> On 20/11/2015 19:44, Karen Kinnear wrote: > >>> Frederic, > >>> > >>> Code review for web revs you sent out. > >>> Code looks good. I am not as familiar with the compiler code. > >>> > >>> I realize you need to check in at least a subset of the > >>> java.util.concurrent changes for > >>> the test to work, so maybe I should not have asked Doug about his > >>> preference there. > >>> Sorry. > >>> > >>> I am impressed you found a way to make a reproducible test! > >>> > >>> Comments/questions: > >>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? > >> > >> Fixed > >> > >>> 2. IIRC, due to another bug with windows handling of our guard pages, > >>> this > >>> is disabled for Windows. Would it be worth putting a comment in the > >>> bug , 8067946, that once this is fixed, the reserved stack logic on > >>> windows > >>> will need testing before enabling? > >> > >> More than testing, the implementation would have to be completed on > >> Windows. I've added a comment to JDK-8067946. > >> > >>> 3. In get_frame_at_stack_banging_point on Linux, BSD and solaris_x86 if > >>> this is in interpreter code, you explicitly return the Java sender > >>> of the current frame. I was expecting to see that on Solaris_sparc > >>> and Windows > >>> as well? I do see the assertion in caller that you do have a java frame. > >> > >> It doesn't make sense to check the current frame (no bytecode has been > >> executed yet, so risk of partially executed critical section). I did the > >> change but not for all platforms. This is now fixed for Solaris_SPARC > >> and Windows too. > >> > >>> 4. test line 83 ?writtent? -> ?written? > >> > >> Fixed > >> > >>> 5. I like the way you set up the preallocated exception and then set > >>> the message - we may > >>> try that for default methods in future. > >>> > >>> 6. I had a memory that you had found a bug in safe_for_sender - did > >>> you already check that in? > >> > >> I've fixed x86 platforms in JDK-8068655. > >> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), > >> I had hoped it would have been silently accepted :-) > >> > >> > >>> 7. I see the change in trace.xml, and I see an include added to > >>> SharedRuntime.cpp, > >>> but I didn?t see where it was used - did I just miss it? > >> > >> trace.xml changes define a new event. > >> This event is created at sharedRuntime.cpp::3006 and it is used > >> in the next 3 lines. > > Thanks. I must have mistyped when I searched for it. > >> > >> Thanks, > >> > >> Fred > >> > >> -- > >> Frederic Parain - Oracle > >> Grenoble Engineering Center - France > >> Phone: +33 4 76 18 81 17 > >> Email:Frederic.Parain at oracle.com > > > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com From frederic.parain at oracle.com Mon Dec 14 14:44:25 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 14 Dec 2015 15:44:25 +0100 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDE813@DEWDFEMB12A.global.corp.sap> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <566EC2DD.5000404@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE813@DEWDFEMB12A.global.corp.sap> Message-ID: <566ED5C9.60108@oracle.com> Goetz, The reserved zone is sometime considered as a subpart of the yellow zone, and sometime as an independent entity. Technically the reserved zone is placed just before the yellow zone, but the way it is managed depends on the context. In most cases, there's no specially annotated methods on the thread's call stack. In this configuration the reserved zone is considered as being part of the yellow zone. This means that the protection of the reserved zone is always the same as the protection of the yellow zone. In some cases, a thread could have one or more methods on its call stack with the ReservedStackAccess annotation. In this configuration, the reserved zone is managed as a separate entity. Initially protected like the yellow zone, access to the reserved zone can be temporary granted for the execution of some critical sections. This means that the protection of the reserved zone can be removed while the yellow zone is still protected. The take over is that the VM code should be able to manage the reserved zone alone or the reserved zone and the yellow zone together. I've already renamed a method because of this change: stack_yellow_zone_enabled() -> stack_guards_enabled() Here, "guards" refers to the two guard zones: reserved + yellow. If you want to change it for a better name, more explicit, I'm fine with that. We just have to preserve the different operations required for stack overflow management. Let's say R(x) and Y(x) represent the protection of the reserved zone and the yellow zone respectively. And let's say that x = P means "zone protected" and x = G means "access granted" The different configurations are: (1) R(P) Y(P) => initial configuration (2) R(G) Y(P) => first stack overflow with annotated method on stack (3) R(G) Y(G) => stack overflow without annotated method on stack, or second stack overflow with annotated method on stack And the transitions are: (1) -> (3) -> (1) or (1) -> (2) -> (1) or (1) -> (2) -> (3) -> (1) I hope this would clarify the semantic of the reserved zone. If it doesn't, let me know, I'll try to explain it differently. Thanks, Fred On 14/12/2015 14:59, Lindenmaier, Goetz wrote: > Hi Frederic, > > I'm now again working on my change "8139864: Improve handling of stack protection zones." > Coleen had asked me to wait until this change of yours is submitted. > > You changed the stack_yellow_zone accessor functions in thread.hpp to > handle both zones, yellow and reserved. > Therefore, reading the code, the reserved zone seems to be part of the yellow zone. > > In the description of the bug, it says "The new zone defined by the proposed > solution is placed just before the yellow zone." This reads as if the zones are > separate. > > Would you mind if I rename the stack_yellow_zone accessor functions to > stack_yellow_reserved_zone? This would make clear in the code that this > are two separate zones. > > I anyways have to adapt most of the calls to these accessors. > > Best regards, > Goetz. > > > > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Frederic Parain >> Sent: Montag, 14. Dezember 2015 14:24 >> To: Karen Kinnear >> Cc: hotspot-dev at openjdk.java.net; core-libs-dev > dev at openjdk.java.net> >> Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical >> Sections >> >> Karen, >> >> Thank you for your review. >> >> Fred >> >> On 23/11/2015 20:10, Karen Kinnear wrote: >>> Frederic, >>> >>> Looks good. >>> >>> Many thanks. >>> Karen >>> >>>> On Nov 23, 2015, at 12:44 PM, Frederic Parain >>>> > >> wrote: >>>> >>>> Karen, >>>> >>>> Thank you for your review, my answers are in-lined below. >>>> >>>> New Webrevs (including some fixes suggested by Paul Sandoz): >>>> >>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ >>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/ >>>> >>>> On 20/11/2015 19:44, Karen Kinnear wrote: >>>>> Frederic, >>>>> >>>>> Code review for web revs you sent out. >>>>> Code looks good. I am not as familiar with the compiler code. >>>>> >>>>> I realize you need to check in at least a subset of the >>>>> java.util.concurrent changes for >>>>> the test to work, so maybe I should not have asked Doug about his >>>>> preference there. >>>>> Sorry. >>>>> >>>>> I am impressed you found a way to make a reproducible test! >>>>> >>>>> Comments/questions: >>>>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >>>> >>>> Fixed >>>> >>>>> 2. IIRC, due to another bug with windows handling of our guard pages, >>>>> this >>>>> is disabled for Windows. Would it be worth putting a comment in the >>>>> bug , 8067946, that once this is fixed, the reserved stack logic on >>>>> windows >>>>> will need testing before enabling? >>>> >>>> More than testing, the implementation would have to be completed on >>>> Windows. I've added a comment to JDK-8067946. >>>> >>>>> 3. In get_frame_at_stack_banging_point on Linux, BSD and solaris_x86 if >>>>> this is in interpreter code, you explicitly return the Java sender >>>>> of the current frame. I was expecting to see that on Solaris_sparc >>>>> and Windows >>>>> as well? I do see the assertion in caller that you do have a java frame. >>>> >>>> It doesn't make sense to check the current frame (no bytecode has been >>>> executed yet, so risk of partially executed critical section). I did the >>>> change but not for all platforms. This is now fixed for Solaris_SPARC >>>> and Windows too. >>>> >>>>> 4. test line 83 ?writtent? -> ?written? >>>> >>>> Fixed >>>> >>>>> 5. I like the way you set up the preallocated exception and then set >>>>> the message - we may >>>>> try that for default methods in future. >>>>> >>>>> 6. I had a memory that you had found a bug in safe_for_sender - did >>>>> you already check that in? >>>> >>>> I've fixed x86 platforms in JDK-8068655. >>>> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >>>> I had hoped it would have been silently accepted :-) >>>> >>>> >>>>> 7. I see the change in trace.xml, and I see an include added to >>>>> SharedRuntime.cpp, >>>>> but I didn?t see where it was used - did I just miss it? >>>> >>>> trace.xml changes define a new event. >>>> This event is created at sharedRuntime.cpp::3006 and it is used >>>> in the next 3 lines. >>> Thanks. I must have mistyped when I searched for it. >>>> >>>> Thanks, >>>> >>>> Fred >>>> >>>> -- >>>> Frederic Parain - Oracle >>>> Grenoble Engineering Center - France >>>> Phone: +33 4 76 18 81 17 >>>> Email:Frederic.Parain at oracle.com >>> >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> Email: Frederic.Parain at oracle.com -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From marcus at lagergren.net Mon Dec 14 14:51:35 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 14 Dec 2015 15:51:35 +0100 Subject: JFokus VM Tech Day 2016 In-Reply-To: References: <809E0327-271A-4985-B7E1-F02004500F34@lagergren.net> Message-ID: Guys. Sadly Paul couldn?t make it, but we have replaced him with Simon Ritter, who will be wearing his new Azul hat. You are all welcome to attend! https://www.jfokus.se/jfokus/jvmtech.jsp /M /M > On 19 Nov 2015, at 17:17, Marcus Lagergren wrote: > > And all talks have now been finalized: https://www.jfokus.se/jfokus/jvmtech.jsp > > A VM tech day without Martin Thompson is no VM tech day! > > Regards > Marcus > >> On 11 Nov 2015, at 09:35, Marcus Lagergren wrote: >> >> Greetings community members! >> >> I am coordinator for the JFokus VM Tech Day at the JFokus conference in February 2016. This is the second year running we have this event, and it was a great success last year. This year we have received significantly more contributions, and the hardest part was sifting through all quality material that we were given. >> >> We are in the process of finalizing the speaker list, but 5 out of 6 slots are now filled and the current agenda looks like this: https://www.jfokus.se/jfokus/jvmtech.jsp >> >> This year, Brian Goetz, Java Language Architect from Oracle opens the tech day, and talks about project Valhalla and how the OpenJDK is getting there. >> >> Brian is followed by Charlie Gracie, IBM, who will cover what is some of the most exciting news in the runtime world for a very long time: The open sourcing of the J9 JVM and its APIs, and example applications in the dynamic language space. >> >> We are also proud (as always) to host the formidable Mr. Aleksey Shipilev, performance czar extraordinare, always balancing on the fine line between brilliant and crazy. Aleksey's presentation is about String compaction, and String optimisations with invokedynamic in Java 9. Hopefully we have room for him at the ordinary JFokus conference as well, as the man spouts excellent tech presentations like a fountain. >> >> Charlie Nutter also joins us to discuss JRuby 9000, which was released this summer, and about using the JVM as a platform for multi language development. >> >> Paul Sandoz, a man who can do anything from REST services down to bare silicone magic in his job, will tell us about how VarHandles are implemented in the JVM, performance aspects and why no one should miss sun.misc.Unsafe. >> >> Our sixth and final speaker slot is being allocated real soon now. Watch this space. >> >> As usual there is time allocated for breakout sessions, improvised unscheduled lightning talks and discussions / Q&A. >> >> Join the best VM internals conference initiative since JVMLS, and the first of its kind in the old world. >> >> Regards >> Marcus Lagergren >> > From goetz.lindenmaier at sap.com Mon Dec 14 15:11:38 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Dec 2015 15:11:38 +0000 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <566ED5C9.60108@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <566EC2DD.5000404@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE813@DEWDFEMB12A.global.corp.sap> <566ED5C9.60108@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDE889@DEWDFEMB12A.global.corp.sap> Hi Frederic, thanks for your fast reply. From reading the code I guessed about what you explained, now I understood more details, thanks! I will not fiddle with handling the zones. My change is only about handling larger pages, i.e. the sizes of the zones, so there is no danger I will break the mechanism you implemented. > The take over is that the VM code should be able to manage > the reserved zone alone or the reserved zone and the yellow > zone together. > If you want to change it for a better name, more explicit, > I'm fine with that. Yes, I would like to change it to 'yellow_reserved' wherever both are handled at the same time. There's places where red+yellow+reserved are handled as one, here I will use 'guard_zone'. That's aliged with create_stack_guard_pages() which guards all (red, yellow, reserved) of them. > stack_yellow_zone_enabled() -> stack_guards_enabled() > > Here, "guards" refers to the two guard zones: reserved > + yellow. Actually, it also includes that the red page is enabled, right? One question, in os_linux.cpp, you meant AMD64, not Itanium, right? 27.18+#if defined(IA32) || defined(IA64) I'll move that functionality to another place, so no need to fix it. Best regards, Goetz. > -----Original Message----- > From: Frederic Parain [mailto:frederic.parain at oracle.com] > Sent: Montag, 14. Dezember 2015 15:44 > To: Lindenmaier, Goetz ; Karen Kinnear > > Cc: hotspot-dev at openjdk.java.net; core-libs-dev dev at openjdk.java.net> > Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical > Sections > > Goetz, > > The reserved zone is sometime considered as a subpart of > the yellow zone, and sometime as an independent entity. > Technically the reserved zone is placed just before the > yellow zone, but the way it is managed depends on the > context. > > In most cases, there's no specially annotated methods on > the thread's call stack. In this configuration the > reserved zone is considered as being part of the yellow > zone. This means that the protection of the reserved > zone is always the same as the protection of the yellow > zone. > > In some cases, a thread could have one or more methods > on its call stack with the ReservedStackAccess annotation. > In this configuration, the reserved zone is managed as > a separate entity. Initially protected like the yellow > zone, access to the reserved zone can be temporary granted > for the execution of some critical sections. This means > that the protection of the reserved zone can be removed > while the yellow zone is still protected. > > The take over is that the VM code should be able to manage > the reserved zone alone or the reserved zone and the yellow > zone together. I've already renamed a method because of > this change: > stack_yellow_zone_enabled() -> stack_guards_enabled() > > Here, "guards" refers to the two guard zones: reserved > + yellow. > > If you want to change it for a better name, more explicit, > I'm fine with that. We just have to preserve the different > operations required for stack overflow management. > > Let's say R(x) and Y(x) represent the protection of > the reserved zone and the yellow zone respectively. > And let's say that x = P means "zone protected" > and x = G means "access granted" > > The different configurations are: > > (1) R(P) Y(P) => initial configuration > (2) R(G) Y(P) => first stack overflow with annotated > method on stack > (3) R(G) Y(G) => stack overflow without annotated > method on stack, or second stack > overflow with annotated method > on stack > > And the transitions are: > > (1) -> (3) -> (1) > or > (1) -> (2) -> (1) > or > (1) -> (2) -> (3) -> (1) > > I hope this would clarify the semantic of the reserved zone. > If it doesn't, let me know, I'll try to explain it differently. > > Thanks, > > Fred > > On 14/12/2015 14:59, Lindenmaier, Goetz wrote: > > Hi Frederic, > > > > I'm now again working on my change "8139864: Improve handling of stack > protection zones." > > Coleen had asked me to wait until this change of yours is submitted. > > > > You changed the stack_yellow_zone accessor functions in thread.hpp to > > handle both zones, yellow and reserved. > > Therefore, reading the code, the reserved zone seems to be part of the > yellow zone. > > > > In the description of the bug, it says "The new zone defined by the > proposed > > solution is placed just before the yellow zone." This reads as if the zones > are > > separate. > > > > Would you mind if I rename the stack_yellow_zone accessor functions to > > stack_yellow_reserved_zone? This would make clear in the code that this > > are two separate zones. > > > > I anyways have to adapt most of the calls to these accessors. > > > > Best regards, > > Goetz. > > > > > > > > > >> -----Original Message----- > >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > >> Behalf Of Frederic Parain > >> Sent: Montag, 14. Dezember 2015 14:24 > >> To: Karen Kinnear > >> Cc: hotspot-dev at openjdk.java.net; core-libs-dev >> dev at openjdk.java.net> > >> Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for > Critical > >> Sections > >> > >> Karen, > >> > >> Thank you for your review. > >> > >> Fred > >> > >> On 23/11/2015 20:10, Karen Kinnear wrote: > >>> Frederic, > >>> > >>> Looks good. > >>> > >>> Many thanks. > >>> Karen > >>> > >>>> On Nov 23, 2015, at 12:44 PM, Frederic Parain > >>>> > > >> wrote: > >>>> > >>>> Karen, > >>>> > >>>> Thank you for your review, my answers are in-lined below. > >>>> > >>>> New Webrevs (including some fixes suggested by Paul Sandoz): > >>>> > >>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ > >>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/ > >>>> > >>>> On 20/11/2015 19:44, Karen Kinnear wrote: > >>>>> Frederic, > >>>>> > >>>>> Code review for web revs you sent out. > >>>>> Code looks good. I am not as familiar with the compiler code. > >>>>> > >>>>> I realize you need to check in at least a subset of the > >>>>> java.util.concurrent changes for > >>>>> the test to work, so maybe I should not have asked Doug about his > >>>>> preference there. > >>>>> Sorry. > >>>>> > >>>>> I am impressed you found a way to make a reproducible test! > >>>>> > >>>>> Comments/questions: > >>>>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? > >>>> > >>>> Fixed > >>>> > >>>>> 2. IIRC, due to another bug with windows handling of our guard pages, > >>>>> this > >>>>> is disabled for Windows. Would it be worth putting a comment in the > >>>>> bug , 8067946, that once this is fixed, the reserved stack logic on > >>>>> windows > >>>>> will need testing before enabling? > >>>> > >>>> More than testing, the implementation would have to be completed > on > >>>> Windows. I've added a comment to JDK-8067946. > >>>> > >>>>> 3. In get_frame_at_stack_banging_point on Linux, BSD and > solaris_x86 if > >>>>> this is in interpreter code, you explicitly return the Java sender > >>>>> of the current frame. I was expecting to see that on Solaris_sparc > >>>>> and Windows > >>>>> as well? I do see the assertion in caller that you do have a java frame. > >>>> > >>>> It doesn't make sense to check the current frame (no bytecode has > been > >>>> executed yet, so risk of partially executed critical section). I did the > >>>> change but not for all platforms. This is now fixed for Solaris_SPARC > >>>> and Windows too. > >>>> > >>>>> 4. test line 83 ?writtent? -> ?written? > >>>> > >>>> Fixed > >>>> > >>>>> 5. I like the way you set up the preallocated exception and then set > >>>>> the message - we may > >>>>> try that for default methods in future. > >>>>> > >>>>> 6. I had a memory that you had found a bug in safe_for_sender - did > >>>>> you already check that in? > >>>> > >>>> I've fixed x86 platforms in JDK-8068655. > >>>> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), > >>>> I had hoped it would have been silently accepted :-) > >>>> > >>>> > >>>>> 7. I see the change in trace.xml, and I see an include added to > >>>>> SharedRuntime.cpp, > >>>>> but I didn?t see where it was used - did I just miss it? > >>>> > >>>> trace.xml changes define a new event. > >>>> This event is created at sharedRuntime.cpp::3006 and it is used > >>>> in the next 3 lines. > >>> Thanks. I must have mistyped when I searched for it. > >>>> > >>>> Thanks, > >>>> > >>>> Fred > >>>> > >>>> -- > >>>> Frederic Parain - Oracle > >>>> Grenoble Engineering Center - France > >>>> Phone: +33 4 76 18 81 17 > >>>> Email:Frederic.Parain at oracle.com > > >>> > >> > >> -- > >> Frederic Parain - Oracle > >> Grenoble Engineering Center - France > >> Phone: +33 4 76 18 81 17 > >> Email: Frederic.Parain at oracle.com > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com From frederic.parain at oracle.com Mon Dec 14 15:19:41 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 14 Dec 2015 16:19:41 +0100 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDE889@DEWDFEMB12A.global.corp.sap> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <566EC2DD.5000404@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE813@DEWDFEMB12A.global.corp.sap> <566ED5C9.60108@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE889@DEWDFEMB12A.global.corp.sap> Message-ID: <566EDE0D.7090004@oracle.com> Goetz, On 14/12/2015 16:11, Lindenmaier, Goetz wrote: > Hi Frederic, > > thanks for your fast reply. > From reading the code I guessed about what you explained, now > I understood more details, thanks! > > I will not fiddle with handling the zones. My change is only about > handling larger pages, i.e. the sizes of the zones, so there is no > danger I will break the mechanism you implemented. > >> The take over is that the VM code should be able to manage >> the reserved zone alone or the reserved zone and the yellow >> zone together. >> If you want to change it for a better name, more explicit, >> I'm fine with that. > Yes, I would like to change it to 'yellow_reserved' wherever > both are handled at the same time. > There's places where red+yellow+reserved are handled as > one, here I will use 'guard_zone'. That's aliged with > create_stack_guard_pages() which guards all (red, yellow, > reserved) of them. I believe that red+yellow+reserved are handled as one only during stack initialization. Once configured, the only moment when the red zone protection is changed is when the VM is about to generate a crash dump. Anyway, 'yellow_reserved' sounds good to me. >> stack_yellow_zone_enabled() -> stack_guards_enabled() >> >> Here, "guards" refers to the two guard zones: reserved >> + yellow. > Actually, it also includes that the red page is enabled, right? > > One question, in os_linux.cpp, you meant AMD64, not Itanium, right? > 27.18+#if defined(IA32) || defined(IA64) > I'll move that functionality to another place, so no need to fix it. You're right, I meant AMD64. Thanks, Fred >> -----Original Message----- >> From: Frederic Parain [mailto:frederic.parain at oracle.com] >> Sent: Montag, 14. Dezember 2015 15:44 >> To: Lindenmaier, Goetz ; Karen Kinnear >> >> Cc: hotspot-dev at openjdk.java.net; core-libs-dev > dev at openjdk.java.net> >> Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical >> Sections >> >> Goetz, >> >> The reserved zone is sometime considered as a subpart of >> the yellow zone, and sometime as an independent entity. >> Technically the reserved zone is placed just before the >> yellow zone, but the way it is managed depends on the >> context. >> >> In most cases, there's no specially annotated methods on >> the thread's call stack. In this configuration the >> reserved zone is considered as being part of the yellow >> zone. This means that the protection of the reserved >> zone is always the same as the protection of the yellow >> zone. >> >> In some cases, a thread could have one or more methods >> on its call stack with the ReservedStackAccess annotation. >> In this configuration, the reserved zone is managed as >> a separate entity. Initially protected like the yellow >> zone, access to the reserved zone can be temporary granted >> for the execution of some critical sections. This means >> that the protection of the reserved zone can be removed >> while the yellow zone is still protected. >> >> The take over is that the VM code should be able to manage >> the reserved zone alone or the reserved zone and the yellow >> zone together. I've already renamed a method because of >> this change: >> stack_yellow_zone_enabled() -> stack_guards_enabled() >> >> Here, "guards" refers to the two guard zones: reserved >> + yellow. >> >> If you want to change it for a better name, more explicit, >> I'm fine with that. We just have to preserve the different >> operations required for stack overflow management. >> >> Let's say R(x) and Y(x) represent the protection of >> the reserved zone and the yellow zone respectively. >> And let's say that x = P means "zone protected" >> and x = G means "access granted" >> >> The different configurations are: >> >> (1) R(P) Y(P) => initial configuration >> (2) R(G) Y(P) => first stack overflow with annotated >> method on stack >> (3) R(G) Y(G) => stack overflow without annotated >> method on stack, or second stack >> overflow with annotated method >> on stack >> >> And the transitions are: >> >> (1) -> (3) -> (1) >> or >> (1) -> (2) -> (1) >> or >> (1) -> (2) -> (3) -> (1) >> >> I hope this would clarify the semantic of the reserved zone. >> If it doesn't, let me know, I'll try to explain it differently. >> >> Thanks, >> >> Fred >> >> On 14/12/2015 14:59, Lindenmaier, Goetz wrote: >>> Hi Frederic, >>> >>> I'm now again working on my change "8139864: Improve handling of stack >> protection zones." >>> Coleen had asked me to wait until this change of yours is submitted. >>> >>> You changed the stack_yellow_zone accessor functions in thread.hpp to >>> handle both zones, yellow and reserved. >>> Therefore, reading the code, the reserved zone seems to be part of the >> yellow zone. >>> >>> In the description of the bug, it says "The new zone defined by the >> proposed >>> solution is placed just before the yellow zone." This reads as if the zones >> are >>> separate. >>> >>> Would you mind if I rename the stack_yellow_zone accessor functions to >>> stack_yellow_reserved_zone? This would make clear in the code that this >>> are two separate zones. >>> >>> I anyways have to adapt most of the calls to these accessors. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Frederic Parain >>>> Sent: Montag, 14. Dezember 2015 14:24 >>>> To: Karen Kinnear >>>> Cc: hotspot-dev at openjdk.java.net; core-libs-dev >>> dev at openjdk.java.net> >>>> Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for >> Critical >>>> Sections >>>> >>>> Karen, >>>> >>>> Thank you for your review. >>>> >>>> Fred >>>> >>>> On 23/11/2015 20:10, Karen Kinnear wrote: >>>>> Frederic, >>>>> >>>>> Looks good. >>>>> >>>>> Many thanks. >>>>> Karen >>>>> >>>>>> On Nov 23, 2015, at 12:44 PM, Frederic Parain >>>>>> > >>>> wrote: >>>>>> >>>>>> Karen, >>>>>> >>>>>> Thank you for your review, my answers are in-lined below. >>>>>> >>>>>> New Webrevs (including some fixes suggested by Paul Sandoz): >>>>>> >>>>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ >>>>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/ >>>>>> >>>>>> On 20/11/2015 19:44, Karen Kinnear wrote: >>>>>>> Frederic, >>>>>>> >>>>>>> Code review for web revs you sent out. >>>>>>> Code looks good. I am not as familiar with the compiler code. >>>>>>> >>>>>>> I realize you need to check in at least a subset of the >>>>>>> java.util.concurrent changes for >>>>>>> the test to work, so maybe I should not have asked Doug about his >>>>>>> preference there. >>>>>>> Sorry. >>>>>>> >>>>>>> I am impressed you found a way to make a reproducible test! >>>>>>> >>>>>>> Comments/questions: >>>>>>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >>>>>> >>>>>> Fixed >>>>>> >>>>>>> 2. IIRC, due to another bug with windows handling of our guard pages, >>>>>>> this >>>>>>> is disabled for Windows. Would it be worth putting a comment in the >>>>>>> bug , 8067946, that once this is fixed, the reserved stack logic on >>>>>>> windows >>>>>>> will need testing before enabling? >>>>>> >>>>>> More than testing, the implementation would have to be completed >> on >>>>>> Windows. I've added a comment to JDK-8067946. >>>>>> >>>>>>> 3. In get_frame_at_stack_banging_point on Linux, BSD and >> solaris_x86 if >>>>>>> this is in interpreter code, you explicitly return the Java sender >>>>>>> of the current frame. I was expecting to see that on Solaris_sparc >>>>>>> and Windows >>>>>>> as well? I do see the assertion in caller that you do have a java frame. >>>>>> >>>>>> It doesn't make sense to check the current frame (no bytecode has >> been >>>>>> executed yet, so risk of partially executed critical section). I did the >>>>>> change but not for all platforms. This is now fixed for Solaris_SPARC >>>>>> and Windows too. >>>>>> >>>>>>> 4. test line 83 ?writtent? -> ?written? >>>>>> >>>>>> Fixed >>>>>> >>>>>>> 5. I like the way you set up the preallocated exception and then set >>>>>>> the message - we may >>>>>>> try that for default methods in future. >>>>>>> >>>>>>> 6. I had a memory that you had found a bug in safe_for_sender - did >>>>>>> you already check that in? >>>>>> >>>>>> I've fixed x86 platforms in JDK-8068655. >>>>>> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >>>>>> I had hoped it would have been silently accepted :-) >>>>>> >>>>>> >>>>>>> 7. I see the change in trace.xml, and I see an include added to >>>>>>> SharedRuntime.cpp, >>>>>>> but I didn?t see where it was used - did I just miss it? >>>>>> >>>>>> trace.xml changes define a new event. >>>>>> This event is created at sharedRuntime.cpp::3006 and it is used >>>>>> in the next 3 lines. >>>>> Thanks. I must have mistyped when I searched for it. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Fred >>>>>> >>>>>> -- >>>>>> Frederic Parain - Oracle >>>>>> Grenoble Engineering Center - France >>>>>> Phone: +33 4 76 18 81 17 >>>>>> Email:Frederic.Parain at oracle.com >> >>>>> >>>> >>>> -- >>>> Frederic Parain - Oracle >>>> Grenoble Engineering Center - France >>>> Phone: +33 4 76 18 81 17 >>>> Email: Frederic.Parain at oracle.com >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> Email: Frederic.Parain at oracle.com -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From aph at redhat.com Mon Dec 14 15:59:23 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Dec 2015 15:59:23 +0000 Subject: RFR: 8145320: Create unsafe_arraycopy and generic_arraycopy for AArch64 Message-ID: <566EE75B.70107@redhat.com> http://cr.openjdk.java.net/~aph/8145320-1/ Andrew. From ivan.gerasimov at oracle.com Mon Dec 14 14:09:42 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Dec 2015 17:09:42 +0300 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... Message-ID: <566ECDA6.1030404@oracle.com> Hello! There was a timeout observed in os_windows.cpp at the line 3945 res = WaitForMultipleObjects(MAXIMUM_WAIT_OBJECTS, handles, FALSE, EXIT_TIMEOUT); This means there were more than 64 threads exiting at the same time and none of the first 64 threads could make any progress during 5 minutes. Sigh. To address this issue I suggest two things: 1) Increase the size of the queue of exiting threads. We'll still have to wait for only the first 64 threads, if the queue is exhausted. But the chances we hit this condition are greatly reduced. 2) Raise process_exiting flag earlier, i.e. before trying to enter the critical section. This should decrease the number of threads, contending for a slot in the 'handles' array during the process exit. Additionally, it is proposed to suspend all the threads, but the one which raised the flag 'process_exiting'. It would be important in a case, when two threads are about to call exit() concurrently. Otherwise, a race could be faced, if the first thread is waiting for all the registered handles, while the second one skips the critical section altogether and calls ::exit(). Build went fine on all platforms. The JTREG tests from 'hotspot' subset all pass. Would you please help review the proposed fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8145127 WEBREV: http://cr.openjdk.java.net/~igerasim/8145127/00/webrev/ Sincerely yours, Ivan From asmundak at google.com Mon Dec 14 18:04:43 2015 From: asmundak at google.com (Alexander Smundak) Date: Mon, 14 Dec 2015 18:04:43 +0000 Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <566E3C64.2030506@oracle.com> References: <565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com> <565FE186.7090508@oracle.com> <566147EF.4000109@oracle.com> <5664DBF9.7010708@oracle.com> <566660B2.4030100@oracle.com> <56679B9F.8030105@oracle.com> <566906CE.2050101@oracle.com> <566A5575.3020908@oracle.com> <566E3C64.2030506@oracle.com> Message-ID: Thanks for your patience, too:-). I saw that patch and verified it works for the PPC64LE, but it wasn't committed yet. Sasha On Sun, Dec 13, 2015 at 7:50 PM David Holmes wrote: > On 12/12/2015 5:05 AM, Alexander Smundak wrote: > > On Fri, Dec 11, 2015 at 5:57 AM, Volker Simonis > > wrote: > >> I've just verified that your patch still works for linux/ppc64. I've > >> built and smoke-tested both linux/ppc64 and ppc64le and everything > >> looks good. So from my side this is ready to push. > > Thanks. > > > > Here's the new revision, with headers verified by jcheck: > > > > http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.05 > > http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.05 > > http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.05 > > Thanks for your patience Sasha! Hopefully this will all be trivial next > time round. I had to rebase the changeset to accommodate the change from: > > 8144885: agent/src/os/linux/libproc.h needs to support Linux/SPARC builds > > but otherwise all okay. (I didn't want to send it back to you again :) ). > > Cheers, > David > > > Sasha > > > From christian.thalinger at oracle.com Mon Dec 14 19:46:45 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Dec 2015 09:46:45 -1000 Subject: RFR (L): 8134994: use separate VMStructs databases for SA and JVMCI In-Reply-To: References: <1D6BE603-E996-495C-94BB-C0A8697B07B3@oracle.com> Message-ID: > On Dec 10, 2015, at 1:13 PM, Kim Barrett wrote: > > On Dec 9, 2015, at 5:16 PM, Christian Thalinger wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8134994 >> http://cr.openjdk.java.net/~twisti/8134994/webrev/ >> >> Currently JVMCI uses the existing VMStructs database which the SA also uses. In order to be more flexible with the future of the SA the JVMCI should use it's own database. > > Thanks for doing this. > > My hope is that, eventually, all the friendship with JVMCIVMStructs will > be eliminated, and JVMCI will only be relying on public APIs that the > various components provide for that purpose. But this is a good > start, giving much better visibility into what JVMCI is using. > > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/ptrQueue.hpp > 41 class PtrQueue VALUE_OBJ_CLASS_SPEC { > 42 friend class VMStructs; > 43 friend class JVMCIVMStructs; > > I thought I'd fixed things so JVMCI shouldn't need PtrQueue > friendship. I think the APIs it needs and uses are public in > SATBMarkQueue and DirtyCardQueue. > > Oh, but some of the relevant code has been removed from > src/share/vm/gc/g1/vmStructs_g1.hpp, and I don't (yet) see it having > been relocated. Indeed, it looks like at least part of my change has > been lost, since we are back to > > src/share/vm/jvmci/vmStructs_jvmci.cpp > 207 nonstatic_field(PtrQueue, _active, bool) \ > 208 nonstatic_field(PtrQueue, _buf, void**) \ > 209 nonstatic_field(PtrQueue, _index, size_t) \ > > Here's the change that seems to have been (partially?) undone: > https://bugs.openjdk.java.net/browse/JDK-8143014 > Access PtrQueue member offsets through derived classes > > But searching through vmStructs_jvmci.cpp, it looks like the only > problem might be that the PtrQueue friendship and the PtrQueue field > access in vmStructs_jvmci.cpp are not needed and should be removed. Correct. I?ve had this working copy with the new file for a while and so it was still around. Thanks for catching that. > > ------------------------------------------------------------------------------ > src/share/vm/gc/shared/cardTableModRefBS.hpp > 43 class CardTableModRefBS: public ModRefBarrierSet { > 44 // Some classes get to look at some private stuff. > 45 friend class VMStructs; > 46 friend class JVMCIVMStructs; > > I thought we'd eliminated the need for this friendship for JVMCI too, > though I'm less certain in this case. Maybe its just been discussed > how it could be done, but hasn't been done yet? The friendship exists because of dirty_card which is protected but I can fix that with declare_constant_with_value. I got rid of the friendship in G1SATBCardTableModRefBS also. > > ------------------------------------------------------------------------------ > src/share/vm/jvmci/jvmciCompilerToVM.cpp > 186 jbyte* base = ((CardTableModRefBS*)bs)->byte_map_base; > > Use barrier_set_cast(bs), so that when we refactor > the barrier set hierarchy (which we plan to do), this will break in an > obvious way. Done. > > And instead of the switch on bs->kind(), maybe use > > if (bs->is_a(BarrierSet::CardTableModRefBS)) { > ... ; > } else { > ShouldNotReachHere(); > } > > All current implementations of BarrierSet are CTMRBS. If/when that's > no longer true, this will break in an obvious way. What about: case BarrierSet::ModRef: ? http://cr.openjdk.java.net/~twisti/8134994/webrev.02/ (the previous version is now under: http://cr.openjdk.java.net/~twisti/8134994/webrev.01/ ) > > ------------------------------------------------------------------------------ > From christian.thalinger at oracle.com Mon Dec 14 20:00:45 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Dec 2015 10:00:45 -1000 Subject: RFR (L): 8134994: use separate VMStructs databases for SA and JVMCI In-Reply-To: References: <1D6BE603-E996-495C-94BB-C0A8697B07B3@oracle.com> Message-ID: <06B364D8-5A66-47AE-AEDD-97A56ACE398D@oracle.com> > On Dec 10, 2015, at 1:13 PM, Kim Barrett wrote: > > On Dec 9, 2015, at 5:16 PM, Christian Thalinger wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8134994 >> http://cr.openjdk.java.net/~twisti/8134994/webrev/ >> >> Currently JVMCI uses the existing VMStructs database which the SA also uses. In order to be more flexible with the future of the SA the JVMCI should use it's own database. > > Thanks for doing this. > > My hope is that, eventually, all the friendship with JVMCIVMStructs will > be eliminated, and JVMCI will only be relying on public APIs that the > various components provide for that purpose. But this is a good > start, giving much better visibility into what JVMCI is using. I have said this before but not sure if I did publicly. The usage of VMStructs is only temporary until Project Panama is available. Most data we need are constants, field offsets and type sizes. These can be provided easily by Panama in a much nicer way. For other data we need (like function addresses) it?s not clear yet how or if Panama can provide us that. We?ll have to see. > > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/ptrQueue.hpp > 41 class PtrQueue VALUE_OBJ_CLASS_SPEC { > 42 friend class VMStructs; > 43 friend class JVMCIVMStructs; > > I thought I'd fixed things so JVMCI shouldn't need PtrQueue > friendship. I think the APIs it needs and uses are public in > SATBMarkQueue and DirtyCardQueue. > > Oh, but some of the relevant code has been removed from > src/share/vm/gc/g1/vmStructs_g1.hpp, and I don't (yet) see it having > been relocated. Indeed, it looks like at least part of my change has > been lost, since we are back to > > src/share/vm/jvmci/vmStructs_jvmci.cpp > 207 nonstatic_field(PtrQueue, _active, bool) \ > 208 nonstatic_field(PtrQueue, _buf, void**) \ > 209 nonstatic_field(PtrQueue, _index, size_t) \ > > Here's the change that seems to have been (partially?) undone: > https://bugs.openjdk.java.net/browse/JDK-8143014 > Access PtrQueue member offsets through derived classes > > But searching through vmStructs_jvmci.cpp, it looks like the only > problem might be that the PtrQueue friendship and the PtrQueue field > access in vmStructs_jvmci.cpp are not needed and should be removed. > > ------------------------------------------------------------------------------ > src/share/vm/gc/shared/cardTableModRefBS.hpp > 43 class CardTableModRefBS: public ModRefBarrierSet { > 44 // Some classes get to look at some private stuff. > 45 friend class VMStructs; > 46 friend class JVMCIVMStructs; > > I thought we'd eliminated the need for this friendship for JVMCI too, > though I'm less certain in this case. Maybe its just been discussed > how it could be done, but hasn't been done yet? > > ------------------------------------------------------------------------------ > src/share/vm/jvmci/jvmciCompilerToVM.cpp > 186 jbyte* base = ((CardTableModRefBS*)bs)->byte_map_base; > > Use barrier_set_cast(bs), so that when we refactor > the barrier set hierarchy (which we plan to do), this will break in an > obvious way. > > And instead of the switch on bs->kind(), maybe use > > if (bs->is_a(BarrierSet::CardTableModRefBS)) { > ... ; > } else { > ShouldNotReachHere(); > } > > All current implementations of BarrierSet are CTMRBS. If/when that's > no longer true, this will break in an obvious way. > > ------------------------------------------------------------------------------ > From vladimir.kozlov at oracle.com Mon Dec 14 20:23:59 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Dec 2015 12:23:59 -0800 Subject: [8u] Reguest for approval and review: 8129847: Compiling methods generated by Nashorn... In-Reply-To: <5667E38C.7090606@oracle.com> References: <5667E38C.7090606@oracle.com> Message-ID: <566F255F.3000505@oracle.com> 8u changes looks good. Thanks, Vladimir On 12/9/15 12:17 AM, Zolt?n Maj? wrote: > Hi, > > > please approve and review the following backport to 8u. > > Original (9) bug: https://bugs.openjdk.java.net/browse/JDK-8129847 > Original (9) webrev: http://cr.openjdk.java.net/~zmajo/8129847-9/webrev.06/ > Changeset (9): > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/da497ea6c120 > > Unfortunately, the changeset does not apply cleanly to 8u. So here is > the 8u webrev: > http://cr.openjdk.java.net/~zmajo/8129847-8u/webrev.06/ > > Testing: > - JPRT (testset hotspot), all tests pass; > - Octane/Nashorn; > - the patch for 9 passed a complete cycle of nightly testing without > problems; > - no performance regression (Octane/Nashorn, SPECjvm2008). > > Thank you and best regards, > > > Zoltan > From david.holmes at oracle.com Mon Dec 14 20:43:45 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 06:43:45 +1000 Subject: RFR(S): 8145015: jni_GetStringCritical asserts for empty strings In-Reply-To: <566EB6A9.10903@oracle.com> References: <566E6BB7.4030602@oracle.com> <566E6F07.9030606@oracle.com> <566EB6A9.10903@oracle.com> Message-ID: <566F2A01.6030205@oracle.com> Hi Volker, This didn't get through last night due to an internal technical problem. I will be resubmitting it today. Sorry about the delay. JPRT is quite busy at the moment. David On 14/12/2015 10:31 PM, David Holmes wrote: > Hi Volker, > > On 14/12/2015 6:27 PM, Volker Simonis wrote: >> Hi David, >> >> thanks for the review. >> >> "const jchar*" means a pointer to a constant character. I removed the >> 'const' because that way I could get rid of the extra 'buf' variable >> which was previously used to allocate and fill the temporary string. >> With "const jchar * ret" it wouldn't be possible to change the >> characters pointed to by 'ret'. >> >> Returning "jachr *ret" as "const jchar * ret" on the other hand is no >> problem - it is just a narrowing conversion saying that once we return >> "ret" the characters it points to can not be changed any more. >> >> So I think the code is correct. > > Okay. I keep forgetting that const isn't saying something about the > object at the end of the pointer, but about what you're allowed to do to > the object through the pointer. > >> I'd need a sponsor though, because this is a shared changed and > > I'm pushing this to hs-rt for you now. > > Cheers, > David > >> unfortunately we still can not push shared code changes (I'll put this >> sentence in every mail now although I have little to no hope that it >> will change something :( >> >> Thank you and best regards, >> Volker >> >> >> >> On Mon, Dec 14, 2015 at 8:25 AM, David Holmes >> wrote: >>> +1 from me. My only query is whether: >>> >>> 3194 jchar* ret; >>> >>> should retain the const, as the return type is "const jchar *"? >>> >>> Thanks, >>> David >>> >>> >>> On 14/12/2015 5:11 PM, Tobias Hartmann wrote: >>>> >>>> Hi Volker, >>>> >>>> thanks for taking care of this! Your fix looks good to me (not a >>>> reviewer). >>>> >>>> Best, >>>> Tobias >>>> >>>> On 09.12.2015 18:53, Volker Simonis wrote: >>>>> >>>>> Hi, >>>>> >>>>> can somebody please review and sponsor the following fix: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145015/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8145015 >>>>> >>>>> The problem is that change "8141132: JEP 254: Compact Strings" removed >>>>> the handling for empty strings from jni_GetStringCritical(). As a >>>>> consequence, the functions will now assert with: >>>>> >>>>> assert(is_within_bounds(which)) failed: index 0 out of bounds 0 >>>>> >>>>> if called with a string of length zero (because it tries to access the >>>>> zeroth element of a zero-length array). >>>>> >>>>> The fix is trivial, just use 's_value->base(T_CHAR)' instead of >>>>> 's_value->char_at_addr(0)'. >>>>> >>>>> While doing this fix I also noticed that jni_GetStringCritical() >>>>> doesn't handle out-of-memory situations when creating a new character >>>>> array (before this wasn't necessary because it always returned the >>>>> original character array, but now with compressed strings it may have >>>>> to allocate a new array). So I've also added the new check by using >>>>> NEW_C_HEAP_ARRAY_RETURN_NULL() instead of NEW_C_HEAP_ARRAY(). >>>>> >>>>> Notice that I also allocate one extra character for zero termination. >>>>> While it seems that this is not strictly necessary, it is now the same >>>>> code like in jni_GetStringChars(). And it again simplifies the >>>>> handling of zero-length strings. Without the extra character it would >>>>> be hard to distinguish out-of-memory errors from the allocation of >>>>> zero bytes, because malloc() is free to return NULL if called with an >>>>> allocation size of zero. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>> From vladimir.kozlov at oracle.com Mon Dec 14 23:07:03 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Dec 2015 15:07:03 -0800 Subject: RFR: 8145320: Create unsafe_arraycopy and generic_arraycopy for AArch64 In-Reply-To: <566EE75B.70107@redhat.com> References: <566EE75B.70107@redhat.com> Message-ID: <566F4B97.5050605@oracle.com> Looks fine to me. Thanks, Vladimir On 12/14/15 7:59 AM, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8145320-1/ > > Andrew. > From kim.barrett at oracle.com Tue Dec 15 00:31:10 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Dec 2015 19:31:10 -0500 Subject: RFR (L): 8134994: use separate VMStructs databases for SA and JVMCI In-Reply-To: References: <1D6BE603-E996-495C-94BB-C0A8697B07B3@oracle.com> Message-ID: On Dec 14, 2015, at 2:46 PM, Christian Thalinger wrote: > >> ------------------------------------------------------------------------------ >> src/share/vm/gc/shared/cardTableModRefBS.hpp >> 43 class CardTableModRefBS: public ModRefBarrierSet { >> 44 // Some classes get to look at some private stuff. >> 45 friend class VMStructs; >> 46 friend class JVMCIVMStructs; >> >> I thought we'd eliminated the need for this friendship for JVMCI too, >> though I'm less certain in this case. Maybe its just been discussed >> how it could be done, but hasn't been done yet? > > The friendship exists because of dirty_card which is protected but I can fix that with declare_constant_with_value. I got rid of the friendship in G1SATBCardTableModRefBS also. Thanks. That looks good. >> ------------------------------------------------------------------------------ >> src/share/vm/jvmci/jvmciCompilerToVM.cpp >> 186 jbyte* base = ((CardTableModRefBS*)bs)->byte_map_base; >> >> Use barrier_set_cast(bs), so that when we refactor >> the barrier set hierarchy (which we plan to do), this will break in an >> obvious way. > > Done. > >> >> And instead of the switch on bs->kind(), maybe use >> >> if (bs->is_a(BarrierSet::CardTableModRefBS)) { >> ... ; >> } else { >> ShouldNotReachHere(); >> } >> >> All current implementations of BarrierSet are CTMRBS. If/when that's >> no longer true, this will break in an obvious way. > > What about: > > case BarrierSet::ModRef: > > ? That case never arises with the known set of barriers. Let?s not pretend we know what code should go there. Better to break in an obvious way if the situation changes, when we?ll know what needs to be done, rather than unintentionally covering a case incorrectly. But on further consideration, I?m inclined to leave this as is in webrev.02, for consistency with all of the other similar switch statements in other code processors. They can be cleaned up together as a separate RFE. > > http://cr.openjdk.java.net/~twisti/8134994/webrev.02/ Looks good. From christian.thalinger at oracle.com Tue Dec 15 03:00:31 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Dec 2015 17:00:31 -1000 Subject: RFR (L): 8134994: use separate VMStructs databases for SA and JVMCI In-Reply-To: References: <1D6BE603-E996-495C-94BB-C0A8697B07B3@oracle.com> Message-ID: > On Dec 14, 2015, at 2:31 PM, Kim Barrett wrote: > > On Dec 14, 2015, at 2:46 PM, Christian Thalinger wrote: >> >>> ------------------------------------------------------------------------------ >>> src/share/vm/gc/shared/cardTableModRefBS.hpp >>> 43 class CardTableModRefBS: public ModRefBarrierSet { >>> 44 // Some classes get to look at some private stuff. >>> 45 friend class VMStructs; >>> 46 friend class JVMCIVMStructs; >>> >>> I thought we'd eliminated the need for this friendship for JVMCI too, >>> though I'm less certain in this case. Maybe its just been discussed >>> how it could be done, but hasn't been done yet? >> >> The friendship exists because of dirty_card which is protected but I can fix that with declare_constant_with_value. I got rid of the friendship in G1SATBCardTableModRefBS also. > > Thanks. That looks good. > >>> ------------------------------------------------------------------------------ >>> src/share/vm/jvmci/jvmciCompilerToVM.cpp >>> 186 jbyte* base = ((CardTableModRefBS*)bs)->byte_map_base; >>> >>> Use barrier_set_cast(bs), so that when we refactor >>> the barrier set hierarchy (which we plan to do), this will break in an >>> obvious way. >> >> Done. >> >>> >>> And instead of the switch on bs->kind(), maybe use >>> >>> if (bs->is_a(BarrierSet::CardTableModRefBS)) { >>> ... ; >>> } else { >>> ShouldNotReachHere(); >>> } >>> >>> All current implementations of BarrierSet are CTMRBS. If/when that's >>> no longer true, this will break in an obvious way. >> >> What about: >> >> case BarrierSet::ModRef: >> >> ? > > That case never arises with the known set of barriers. Let?s not pretend we know what code > should go there. Better to break in an obvious way if the situation changes, when we?ll know > what needs to be done, rather than unintentionally covering a case incorrectly. > > But on further consideration, I?m inclined to leave this as is in webrev.02, for consistency with > all of the other similar switch statements in other code processors. They can be cleaned up > together as a separate RFE. Sounds good. > >> >> http://cr.openjdk.java.net/~twisti/8134994/webrev.02/ > > Looks good. Thanks. From christian.thalinger at oracle.com Tue Dec 15 03:23:36 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Dec 2015 17:23:36 -1000 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <566AB958.8010901@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> Message-ID: <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> > On Dec 11, 2015, at 1:54 AM, Konstantin Shefov wrote: > > Hello > > Please review the new version on the patch. > > New webrev: > Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 > Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 These newlines look ridiculous especially when it?s not even needed: + // Returns a class reference index for a method or a field. + public int getClassRefIndexAt + (int index) { return getClassRefIndexAt0 (constantPoolOop, index); } Either fix the indent or just add them like regular methods should look like. > > What has been changed: > 1. Added tests for the new added methods. > 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). > > Thanks > -Konstantin > > On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >> Coleen, >> Thanks for review >> >> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>> >>> I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be added with the functionality changeset, not promised afterward. >> I will add tests. >>> Secondly, I do not like that JDK code knows the implementation details of the JVM's constant pool tags. These should be only for internal use. >> The package "sun.reflect" is for internal use only, so it shouldn?t be a problem. >>> My third comment is that I haven't looked carefully at this constant pool implementation but it seems very unsafe if the class is redefined and relies on an implementation detail in the JVM that can change. I will have more comments once I look more at the jvmti specification. >>> >>> thanks, >>> Coleen >>> >>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>> Hello >>>> >>>> Please, review modified webrev. >>>> >>>> I have added methods >>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; >>>> getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; >>>> >>>> I removed previously added method >>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>> >>>> New webrev: >>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>> >>>> Thanks >>>> -Konstantin >>>> >>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>> Remi, >>>>> >>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>> May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. >>>>> >>>>> -Konstantin >>>>> >>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>> Hi Konstantin, >>>>>> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef. >>>>>> >>>>>> In term of API, I think it's better to decompose the API, i.e. to have a method >>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. >>>>>> >>>>>> cheers, >>>>>> R?mi >>>>>> >>>>>> ----- Mail original ----- >>>>>>> De: "Christian Thalinger" >>>>>>> ?: "Konstantin Shefov" >>>>>>> Cc: "hotspot-dev developers" , core-libs-dev at openjdk.java.net >>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool >>>>>>> >>>>>>> [CC'ing core-libs-dev] >>>>>>> >>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello >>>>>>>> >>>>>>>> Please review an enhancement to add three new methods to >>>>>>>> sun.reflect.ConstantPool class. >>>>>>>> The following methods are suggested: >>>>>>>> >>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>>> representation of name and type from a NameAndType constant pool entry >>>>>>>> with the specified index >>>>>>>> >>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string >>>>>>>> representation of name and type from an InvokeDynamic constant pool entry >>>>>>>> with the specified index >>>>>>>> >>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant >>>>>>>> pool entry with the specified index >>>>>>>> >>>>>>>> These three methods could be used for testing API working with constant >>>>>>>> pool, e.g. JVMCI. >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>> Webrev hotspot: >>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Konstantin >>>>>>> >>>>> >>>> >>> >> > From kim.barrett at oracle.com Tue Dec 15 04:58:36 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Dec 2015 23:58:36 -0500 Subject: RFR (L): 8134994: use separate VMStructs databases for SA and JVMCI In-Reply-To: References: <1D6BE603-E996-495C-94BB-C0A8697B07B3@oracle.com> Message-ID: <2BC701A4-8F8F-464A-98CE-8592AD223FFF@oracle.com> On Dec 14, 2015, at 10:00 PM, Christian Thalinger wrote: > >>> What about: >>> >>> case BarrierSet::ModRef: >>> >>> ? >> >> That case never arises with the known set of barriers. Let?s not pretend we know what code >> should go there. Better to break in an obvious way if the situation changes, when we?ll know >> what needs to be done, rather than unintentionally covering a case incorrectly. >> >> But on further consideration, I?m inclined to leave this as is in webrev.02, for consistency with >> all of the other similar switch statements in other code processors. They can be cleaned up >> together as a separate RFE. > > Sounds good. Filed https://bugs.openjdk.java.net/browse/JDK-8145362 From david.holmes at oracle.com Tue Dec 15 05:14:42 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 15:14:42 +1000 Subject: RFR (XS) 8144853: Print the names of callees in PrintAssembly/PrintInterprete In-Reply-To: <566E03E3.4020403@oracle.com> References: <5665CD82.4070909@oracle.com> <5665D6EB.1030207@oracle.com> <5665DED7.3000204@oracle.com> <5667B24C.1070101@oracle.com> <566E03E3.4020403@oracle.com> Message-ID: <566FA1C2.9080302@oracle.com> Sorry for the delay. This looks fine to me. Thanks, David On 14/12/2015 9:48 AM, Ioi Lam wrote: > Hi David, > > I have updated the patch according to your feedback: > > http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names.v3/ > > > The buf[] variable is now allocated using NEW_RESOURCE_ARRAY, and the > useless 'found' variable has been removed. The comment is also fixed. > > Thanks > - Ioi > > On 12/8/15 8:47 PM, David Holmes wrote: >> Hi Ioi, >> >> src/share/vm/code/nmethod.cpp >> >> Your use of the static buffer seems not thread-safe. >> >> Minor nit: >> >> 3057 bool found; >> 3058 found = os::dll_address_to_function_name(dest, buf, >> sizeof(buf), &offset); >> >> could be: >> >> 3057 bool found = os::dll_address_to_function_name(dest, >> buf, sizeof(buf), &offset); >> >> >> --- >> >> src/share/vm/compiler/disassembler.cpp >> >> Your use of the static buffer seems not thread-safe. >> >> 366 bool found; >> >> This variable seems unused. >> >> Typo: >> >> 369 // Don't do this for native methods, as the function name will >> be printed in >> 370 // by nmethod::reloc_string_for(). >> >> delete 'in' or 'by'. >> >> Thanks, >> David >> ----- >> >> >> On 8/12/2015 5:32 AM, Ioi Lam wrote: >>> Hi Vladimir, >>> >>> Thanks for the suggestion. I've changed the patch to handle the nmethods >>> differently than PrintInterpreter: >>> >>> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names.v2/ >>> >>> >>> >>> The nmethod dump now looks like this: >>> >>> 0x00007f607940c657: callq 0x00007f607186bb60 ; >>> ImmutableOopMap{[0]=Oop } >>> ;*ifeq {reexecute=1 >>> rethrow=0 return_oop=0} >>> ; - >>> java.lang.String::charAt at 4 (line 685) >>> ; {runtime_call >>> UncommonTrapBlob} >>> 0x00007f607940c65c: callq 0x00007f608b05eb00 ;*ifeq {reexecute=0 >>> rethrow=0 return_oop=0} >>> ; - >>> java.lang.String::charAt at 4 (line 685) >>> ; {runtime_call >>> os::breakpoint()} >>> >>> >>> Thanks >>> - Ioi >>> >>> >>> On 12/7/15 10:58 AM, Vladimir Ivanov wrote: >>>> Ioi, >>>> >>>> Nice improvement! >>>> >>>> Why don't you print "{runtime_call os::breakpoint()}" for >>>> -XX:+PrintAssemble instead? It looks more natural w.r.t. current >>>> format. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 12/7/15 9:18 PM, Ioi Lam wrote: >>>>> Please review a very small fix: >>>>> >>>>> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names/ >>>>> >>>>> >>>>> >>>>> >>>>> Bug: Print the names of callees in PrintAssembly/PrintInterprete >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8144853 >>>>> >>>>> Summary of fix: >>>>> >>>>> In -XX:+PrintAssembly and -XX:+PrintInterpreter, sometimes only >>>>> the address of a callee is printed, and the name is missing. >>>>> >>>>> The fix is to use os::dll_address_to_function_name() to find the >>>>> names of such functions and print them out if possible. >>>>> >>>>> EXAMPLES: >>>>> -XX:+PrintInterpreter: >>>>> 0x00007f1b018447c3: callq 0x00007f1b19b9bba0 = >>>>> InterpreterRuntime::newarray(JavaThread*, BasicType, int) >>>>> >>>>> -XX:+PrintAssembly >>>>> <....> >>>>> 0x00007f75d87b9629: xchg %ax,%ax >>>>> 0x00007f75d87b962b: callq 0x00007f75d0c11b60 ; >>>>> ImmutableOopMap{rbp=Oop } >>>>> ;*iflt {reexecute=1 >>>>> rethrow=0 return_oop=0} >>>>> ; - >>>>> java.lang.StringLatin1::charAt at 1 (line 43) >>>>> ; {runtime_call >>>>> UncommonTrapBlob} >>>>> 0x00007f75d87b9630: callq 0x00007f75e8e41370 = os::breakpoint() >>>>> ;*iflt {reexecute=0 >>>>> rethrow=0 return_oop=0} >>>>> ; - >>>>> java.lang.StringLatin1::charAt at 1 (line 43) >>>>> ; {runtime_call} >>>>> >>>>> >>>>> TESTS: >>>>> RBT hotspot/test/:hotspot_all (this includes tests cases with >>>>> -XX:+PrintAssembly) >>>>> >>>>> Thanks >>>>> - Ioi >>> > From david.holmes at oracle.com Tue Dec 15 06:31:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 16:31:23 +1000 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <566ECDA6.1030404@oracle.com> References: <566ECDA6.1030404@oracle.com> Message-ID: <566FB3BB.4050709@oracle.com> I really wish we had some view inside windows to see exactly what is going wrong here. :( On 15/12/2015 12:09 AM, Ivan Gerasimov wrote: > Hello! > > There was a timeout observed in os_windows.cpp at the line > 3945 res = WaitForMultipleObjects(MAXIMUM_WAIT_OBJECTS, > handles, FALSE, EXIT_TIMEOUT); > > This means there were more than 64 threads exiting at the same time and > none of the first 64 threads could make any progress during 5 minutes. > Sigh. > > To address this issue I suggest two things: > 1) > Increase the size of the queue of exiting threads. > We'll still have to wait for only the first 64 threads, if the queue is > exhausted. > But the chances we hit this condition are greatly reduced. > > 2) > Raise process_exiting flag earlier, i.e. before trying to enter the > critical section. > This should decrease the number of threads, contending for a slot in the > 'handles' array during the process exit. > > Additionally, it is proposed to suspend all the threads, but the one > which raised the flag 'process_exiting'. > It would be important in a case, when two threads are about to call > exit() concurrently. > Otherwise, a race could be faced, if the first thread is waiting for all > the registered handles, while the second one skips the critical section > altogether and calls ::exit(). > > Build went fine on all platforms. The JTREG tests from 'hotspot' subset > all pass. > > Would you please help review the proposed fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8145127 > WEBREV: http://cr.openjdk.java.net/~igerasim/8145127/00/webrev/ Can't quite get my head round the whole strategy, but in this loop: 4033 while (pr_ex != curr_id) { pr_ex is never updated! David ----- > Sincerely yours, > Ivan > From volker.simonis at gmail.com Tue Dec 15 08:03:00 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 15 Dec 2015 09:03:00 +0100 Subject: RFR(S): 8145015: jni_GetStringCritical asserts for empty strings In-Reply-To: <566F2A01.6030205@oracle.com> References: <566E6BB7.4030602@oracle.com> <566E6F07.9030606@oracle.com> <566EB6A9.10903@oracle.com> <566F2A01.6030205@oracle.com> Message-ID: Hi David, no problem. I saw it just went trough. Thanks for your support, Volker On Mon, Dec 14, 2015 at 9:43 PM, David Holmes wrote: > Hi Volker, > > This didn't get through last night due to an internal technical problem. I > will be resubmitting it today. Sorry about the delay. JPRT is quite busy at > the moment. > > David > > > On 14/12/2015 10:31 PM, David Holmes wrote: >> >> Hi Volker, >> >> On 14/12/2015 6:27 PM, Volker Simonis wrote: >>> >>> Hi David, >>> >>> thanks for the review. >>> >>> "const jchar*" means a pointer to a constant character. I removed the >>> 'const' because that way I could get rid of the extra 'buf' variable >>> which was previously used to allocate and fill the temporary string. >>> With "const jchar * ret" it wouldn't be possible to change the >>> characters pointed to by 'ret'. >>> >>> Returning "jachr *ret" as "const jchar * ret" on the other hand is no >>> problem - it is just a narrowing conversion saying that once we return >>> "ret" the characters it points to can not be changed any more. >>> >>> So I think the code is correct. >> >> >> Okay. I keep forgetting that const isn't saying something about the >> object at the end of the pointer, but about what you're allowed to do to >> the object through the pointer. >> >>> I'd need a sponsor though, because this is a shared changed and >> >> >> I'm pushing this to hs-rt for you now. >> >> Cheers, >> David >> >>> unfortunately we still can not push shared code changes (I'll put this >>> sentence in every mail now although I have little to no hope that it >>> will change something :( >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> >>> On Mon, Dec 14, 2015 at 8:25 AM, David Holmes >>> wrote: >>>> >>>> +1 from me. My only query is whether: >>>> >>>> 3194 jchar* ret; >>>> >>>> should retain the const, as the return type is "const jchar *"? >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> On 14/12/2015 5:11 PM, Tobias Hartmann wrote: >>>>> >>>>> >>>>> Hi Volker, >>>>> >>>>> thanks for taking care of this! Your fix looks good to me (not a >>>>> reviewer). >>>>> >>>>> Best, >>>>> Tobias >>>>> >>>>> On 09.12.2015 18:53, Volker Simonis wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> can somebody please review and sponsor the following fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145015/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8145015 >>>>>> >>>>>> The problem is that change "8141132: JEP 254: Compact Strings" removed >>>>>> the handling for empty strings from jni_GetStringCritical(). As a >>>>>> consequence, the functions will now assert with: >>>>>> >>>>>> assert(is_within_bounds(which)) failed: index 0 out of bounds 0 >>>>>> >>>>>> if called with a string of length zero (because it tries to access the >>>>>> zeroth element of a zero-length array). >>>>>> >>>>>> The fix is trivial, just use 's_value->base(T_CHAR)' instead of >>>>>> 's_value->char_at_addr(0)'. >>>>>> >>>>>> While doing this fix I also noticed that jni_GetStringCritical() >>>>>> doesn't handle out-of-memory situations when creating a new character >>>>>> array (before this wasn't necessary because it always returned the >>>>>> original character array, but now with compressed strings it may have >>>>>> to allocate a new array). So I've also added the new check by using >>>>>> NEW_C_HEAP_ARRAY_RETURN_NULL() instead of NEW_C_HEAP_ARRAY(). >>>>>> >>>>>> Notice that I also allocate one extra character for zero termination. >>>>>> While it seems that this is not strictly necessary, it is now the same >>>>>> code like in jni_GetStringChars(). And it again simplifies the >>>>>> handling of zero-length strings. Without the extra character it would >>>>>> be hard to distinguish out-of-memory errors from the allocation of >>>>>> zero bytes, because malloc() is free to return NULL if called with an >>>>>> allocation size of zero. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>> > From zoltan.majo at oracle.com Tue Dec 15 08:37:55 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 15 Dec 2015 09:37:55 +0100 Subject: [8u] Reguest for approval and review: 8129847: Compiling methods generated by Nashorn... In-Reply-To: <566F255F.3000505@oracle.com> References: <5667E38C.7090606@oracle.com> <566F255F.3000505@oracle.com> Message-ID: <566FD163.7000909@oracle.com> Thank you, Vladimir and Se?n, for the review and approval! Best regards, Zolt?n On 12/14/2015 09:23 PM, Vladimir Kozlov wrote: > 8u changes looks good. > > Thanks, > Vladimir > > On 12/9/15 12:17 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please approve and review the following backport to 8u. >> >> Original (9) bug: https://bugs.openjdk.java.net/browse/JDK-8129847 >> Original (9) webrev: >> http://cr.openjdk.java.net/~zmajo/8129847-9/webrev.06/ >> Changeset (9): >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/da497ea6c120 >> >> Unfortunately, the changeset does not apply cleanly to 8u. So here is >> the 8u webrev: >> http://cr.openjdk.java.net/~zmajo/8129847-8u/webrev.06/ >> >> Testing: >> - JPRT (testset hotspot), all tests pass; >> - Octane/Nashorn; >> - the patch for 9 passed a complete cycle of nightly testing without >> problems; >> - no performance regression (Octane/Nashorn, SPECjvm2008). >> >> Thank you and best regards, >> >> >> Zoltan >> From konstantin.shefov at oracle.com Tue Dec 15 09:11:28 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 15 Dec 2015 12:11:28 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> Message-ID: <566FD940.4090608@oracle.com> Hi Christian Thanks for reviewing, I have changed indents as you asked: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.03 -Konstantin On 12/15/2015 06:23 AM, Christian Thalinger wrote: > >> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov >> > >> wrote: >> >> Hello >> >> Please review the new version on the patch. >> >> New webrev: >> Webrev hotspot: >> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >> >> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >> > > These newlines look ridiculous especially when it?s not even needed: > > + // Returns a class reference index for a method or a field. > + public int getClassRefIndexAt > + (int index) { return > getClassRefIndexAt0 (constantPoolOop, index); } > > Either fix the indent or just add them like regular methods should > look like. > >> >> What has been changed: >> 1. Added tests for the new added methods. >> 2. Removed CP tag codes 100 - 105 from being passed to java and left >> only codes from the open JVM spec >> (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). >> >> Thanks >> -Konstantin >> >> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>> Coleen, >>> Thanks for review >>> >>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>> >>>> I have a couple preliminary comments. First, there are no tests >>>> added with all this new functionality. Tests should be added with >>>> the functionality changeset, not promised afterward. >>> I will add tests. >>>> Secondly, I do not like that JDK code knows the implementation >>>> details of the JVM's constant pool tags. These should be only for >>>> internal use. >>> The package "sun.reflect" is for internal use only, so it shouldn?t >>> be a problem. >>>> My third comment is that I haven't looked carefully at this >>>> constant pool implementation but it seems very unsafe if the class >>>> is redefined and relies on an implementation detail in the JVM that >>>> can change. I will have more comments once I look more at the >>>> jvmti specification. >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>> Hello >>>>> >>>>> Please, review modified webrev. >>>>> >>>>> I have added methods >>>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry >>>>> index from a method, field or indy entry index; >>>>> getClassRefIndexAt(int index) - to get class entry index from a >>>>> method or field entry index; >>>>> >>>>> I removed previously added method >>>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>>> >>>>> New webrev: >>>>> Webrev hotspot: >>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>> >>>>> Webrev jdk: >>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>> >>>>> >>>>> Thanks >>>>> -Konstantin >>>>> >>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>> Remi, >>>>>> >>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>> May be it also has sense to make a method >>>>>> "getMethodRefNameAndTypeIndex(int index)" to acquire >>>>>> name-and-type entry index for methods also. >>>>>> >>>>>> -Konstantin >>>>>> >>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>> Hi Konstantin, >>>>>>> Technically, getInvokedynamicRefInfoAt should be >>>>>>> getNameAndTypeOfInvokedynamicRefInfoAt because it only extract >>>>>>> the nameAndType value of the InvokeDynamicRef. >>>>>>> >>>>>>> In term of API, I think it's better to decompose the API, i.e. >>>>>>> to have a method >>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>> that returns the nameAndType index and to reuse >>>>>>> getNameAndTypeRefInfoAt(index) to get the corresponding array of >>>>>>> Strings. >>>>>>> >>>>>>> cheers, >>>>>>> R?mi >>>>>>> >>>>>>> ----- Mail original ----- >>>>>>>> De: "Christian Thalinger" >>>>>>> > >>>>>>>> ?: "Konstantin Shefov" >>>>>>> > >>>>>>>> Cc: "hotspot-dev developers" >>>>>>> >, >>>>>>>> core-libs-dev at openjdk.java.net >>>>>>>> >>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to >>>>>>>> sun.reflect.ConstantPool >>>>>>>> >>>>>>>> [CC'ing core-libs-dev] >>>>>>>> >>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hello >>>>>>>>> >>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>> The following methods are suggested: >>>>>>>>> >>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns >>>>>>>>> string >>>>>>>>> representation of name and type from a NameAndType constant >>>>>>>>> pool entry >>>>>>>>> with the specified index >>>>>>>>> >>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns >>>>>>>>> string >>>>>>>>> representation of name and type from an InvokeDynamic constant >>>>>>>>> pool entry >>>>>>>>> with the specified index >>>>>>>>> >>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance >>>>>>>>> of a constant >>>>>>>>> pool entry with the specified index >>>>>>>>> >>>>>>>>> These three methods could be used for testing API working with >>>>>>>>> constant >>>>>>>>> pool, e.g. JVMCI. >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>> Webrev hotspot: >>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>> >>>>>>>>> Webrev jdk: >>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Konstantin >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From marcus at lagergren.net Tue Dec 15 11:43:10 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Tue, 15 Dec 2015 12:43:10 +0100 Subject: VM Tech Summit 2016 update Message-ID: <996AC2DB-DB8F-4484-9A16-8583F0AEB3AC@lagergren.net> Hi guys! I just wanted to inform you that Paul Sandoz sadly couldn?t make it to JFokus and the VM Tech Summit in February. Luckily we have found Simon Ritter to replace him. Simon will be wearing his Azul hat, and will talk about the Object Layout project (objectlayout.org). The speaker list has been updated. https://www.jfokus.se/jfokus/jvmtech.jsp Hope to see you there! /Marcus (VM Tech summit chair and coordinator) From matthias.baesken at sap.com Tue Dec 15 14:39:45 2015 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 15 Dec 2015 14:39:45 +0000 Subject: src/share/vm/utilities/growableArray.hpp : VisualStudio pragmas in shared code Message-ID: <98C2119538350A4E92B3DD08E7B4146801E207C7F4@DEWDFEMB14B.global.corp.sap> Hello, while Visual Studio pragmas in shared code are usually guarded with _MSC_VER in the hotspot codebase ( see for example taskqueue.hpp or compressedStream.cpp ) , the guarding is missing in src/share/vm/utilities/growableArray.hpp , which is not really a "good thing" for other compilers . So I suggest to add the guarding _MSC_VER - check in src/share/vm/utilities/growableArray.hpp too : @@ -170,5 +170,7 @@ _data = (E*)raw_allocate(sizeof(E)); // Needed for Visual Studio 2012 and older +#ifdef _MSC_VER #pragma warning(suppress: 4345) +#endif for (int i = 0; i < _max; i++) ::new ((void*)&_data[i]) E(); } @@ -423,5 +425,7 @@ for ( ; i < _len; i++) ::new ((void*)&newData[i]) E(_data[i]); // Needed for Visual Studio 2012 and older +#ifdef _MSC_VER #pragma warning(suppress: 4345) +#endif for ( ; i < _max; i++) ::new ((void*)&newData[i]) E(); for (i = 0; i < old_max; i++) _data[i].~E(); Regards, Matthias From thomas.schatzl at oracle.com Tue Dec 15 14:46:53 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 15 Dec 2015 15:46:53 +0100 Subject: RFR: 8144913: Add extension point to execute_internal_vm_tests In-Reply-To: <20151208153617.GA28216@ehelin.jrpg.bea.com> References: <20151208153617.GA28216@ehelin.jrpg.bea.com> Message-ID: <1450190813.2296.81.camel@oracle.com> Hi, On Tue, 2015-12-08 at 16:36 +0100, Erik Helin wrote: > Hi all, > > this small patch adds an extension point to execute_internal_vm_tests. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8144913 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8144913/webrev.00/ > > Testing: > - JPRT looks good. Thanks, Thomas From aph at redhat.com Tue Dec 15 15:14:15 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Dec 2015 15:14:15 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: References: <56697E62.9030306@redhat.com> Message-ID: <56702E47.9090003@redhat.com> On 12/10/2015 09:44 PM, Kim Barrett wrote: > On Dec 10, 2015, at 8:30 AM, Andrew Haley wrote: > > >> http://cr.openjdk.java.net/~aph/8145096-1/ >> > > ------------------------------------------------------------------------------ > src/os/posix/vm/os_posix.cpp > 756 unsigned int i; > > I'm not sure what the purpose of changing this to unsigned might be. > The sa_flags member of struct sigaction is of type int. There are assignments into this field that overflow: SA_RESETHAND (0x80000000) is implicitly unsigned, so assigning it to an int field is at best implementation-define. I suppose that this is really a bug in the Linux headers. I'll take it out. > ------------------------------------------------------------------------------ > 136 return (double)(method->rate() + 1) * ((double)(method->invocation_count() + 1) * (method->backedge_count() + 1)); > > I suspect the problem encountered here is that the multiplication of > the two count values can overflow. If that multiplication was not > grouped, but instead the rate term and invocation count were > multiplied, then multiplied by the backedge count (e.g. use the > natural grouping for operator*), the result should be mathematically > the same, and I think should not run into overflow problems. Recall > that method->rate() returns float. I guess this would be okay, but it seems prudent to use a double. Is there some special performance optimization we have to care about? The return type of AdvancedThresholdPolicy::weight() is double, so I really can't think of any good reason not to do the arithmetic as double. > So I think a simpler change here might be > > return (method->rate() + 1) * (method->invocation_count() + 1) * (method->backedge_count() + 1); > > i.e. remove the parens that group the count multiplication before > multiplying by the rate. > Note that I would not like to see these java_xxx functions used as a > general "solution" to overflow problems. Most cases of signed > integer arithmetic overflow are actual bugs, and papering over them > with these functions would be a mistake. I haven't reviewed them > carefully, but the way these are being used in the various changes > in the opto directory look appropriate, in order to match Java's > defined behavior. But I wouldn't be surprised if there were other > places (like the problem found in advancedThresholdPolicy.cpp) where > I would not want these operations used. In fact, I'd like the > comment describing these operations to say something along that > line. OK. Andrew. From aph at redhat.com Tue Dec 15 16:41:13 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Dec 2015 16:41:13 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <07E5A6CA-1259-4CB6-B34B-B42442C820E5@oracle.com> References: <56697E62.9030306@redhat.com> <566A9E2F.2000606@redhat.com> <5C36B6CF-7098-4568-AA79-05F624580995@oracle.com> <07E5A6CA-1259-4CB6-B34B-B42442C820E5@oracle.com> Message-ID: <567042A9.8020706@redhat.com> On 12/11/2015 06:39 PM, John Rose wrote: > #define JAVA_INTEGER_OP(OP, NAME, TYPE, UNSIGNED_TYPE) \ > inline TYPE NAME (TYPE in1, TYPE in2) { \ > STATIC_ASSERT(sizeof(TYPE) == sizeof(UNSIGNED_TYPE)); \ > UNSIGNED_TYPE ures = static_cast(in1); \ > ures OP ## = static_cast(in2); \ > return reinterpret_cast(ures); \ > } I had to take out the STATIC_ASSERT because globalDefinitions.hpp is included before STATIC_ASSERT is defined in debug.hpp. Andrew. From aph at redhat.com Tue Dec 15 16:44:30 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Dec 2015 16:44:30 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot, Take 2 In-Reply-To: References: <56697E62.9030306@redhat.com> Message-ID: <5670436E.8060606@redhat.com> To recap: I've been tracing through HotSpot with GCC's undefined behaviour sanitizer, which detects instances of undefined behaviour. There are many instances of UB we probably don't want to fix (e.g. unaliged accesses on x86) but some of them are serious. This patch fixes some signed integer overflow bugs in HotSpot which are certainly known to occur. These mostly occur in C2. There are surely many more such bugs but to begin with I want to concentrate on those. This patch introduces some functions which perform java-like arithmetic: java-add, etc. We think we've found a portable way to do this. I have tried my utmost to change things as little as possible. There are certainly places where we could make things more efficient, but my goal was to limit the scope of this diff to fixing bugs. Apart from the undefined behaviour being fixed, this patch should cause no behavioural changes, except in one case. AdvancedThresholdPolicy::weight() grossly overflows, so much so that its result is substantially noise. That's fixed here. It might be that the hashing functions for C2 types really should have unsigned type rather than using java_add; I can make that change but (as I said) I'm trying to change things as little as possible. http://cr.openjdk.java.net/~aph/8145096-2/ Andrew. From christian.thalinger at oracle.com Tue Dec 15 17:36:45 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Dec 2015 07:36:45 -1000 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <566FD940.4090608@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> <566FD940.4090608@oracle.com> Message-ID: <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> > On Dec 14, 2015, at 11:11 PM, Konstantin Shefov wrote: > > Hi Christian > > Thanks for reviewing, I have changed indents as you asked: > > http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.03 Thanks. I?m still not comfortable with the enum. It would be great if we could get the values from the VM like in JVMCI: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#l101 but that would be overkill here. But I would like to see the enum entries take the integer values as arguments, like here: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARCKind.java#l27 and either do a simple linear search to find the entry or build up a table like the HotSpotConstantPool example above. > > -Konstantin > > On 12/15/2015 06:23 AM, Christian Thalinger wrote: >> >>> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov > wrote: >>> >>> Hello >>> >>> Please review the new version on the patch. >>> >>> New webrev: >>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >> >> These newlines look ridiculous especially when it?s not even needed: >> >> + // Returns a class reference index for a method or a field. >> + public int getClassRefIndexAt >> + (int index) { return getClassRefIndexAt0 (constantPoolOop, index); } >> >> Either fix the indent or just add them like regular methods should look like. >> >>> >>> What has been changed: >>> 1. Added tests for the new added methods. >>> 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec ( https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140 ). >>> >>> Thanks >>> -Konstantin >>> >>> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>>> Coleen, >>>> Thanks for review >>>> >>>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>>> >>>>> I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be added with the functionality changeset, not promised afterward. >>>> I will add tests. >>>>> Secondly, I do not like that JDK code knows the implementation details of the JVM's constant pool tags. These should be only for internal use. >>>> The package "sun.reflect" is for internal use only, so it shouldn?t be a problem. >>>>> My third comment is that I haven't looked carefully at this constant pool implementation but it seems very unsafe if the class is redefined and relies on an implementation detail in the JVM that can change. I will have more comments once I look more at the jvmti specification. >>>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>>> Hello >>>>>> >>>>>> Please, review modified webrev. >>>>>> >>>>>> I have added methods >>>>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; >>>>>> getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; >>>>>> >>>>>> I removed previously added method >>>>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>>>> >>>>>> New webrev: >>>>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>>> >>>>>> Thanks >>>>>> -Konstantin >>>>>> >>>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>>> Remi, >>>>>>> >>>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>>> May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. >>>>>>> >>>>>>> -Konstantin >>>>>>> >>>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>>> Hi Konstantin, >>>>>>>> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef. >>>>>>>> >>>>>>>> In term of API, I think it's better to decompose the API, i.e. to have a method >>>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>>> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. >>>>>>>> >>>>>>>> cheers, >>>>>>>> R?mi >>>>>>>> >>>>>>>> ----- Mail original ----- >>>>>>>>> De: "Christian Thalinger" > >>>>>>>>> ?: "Konstantin Shefov" < konstantin.shefov at oracle.com > >>>>>>>>> Cc: "hotspot-dev developers" < hotspot-dev at openjdk.java.net >, core-libs-dev at openjdk.java.net >>>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool >>>>>>>>> >>>>>>>>> [CC'ing core-libs-dev] >>>>>>>>> >>>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> Hello >>>>>>>>>> >>>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>>> The following methods are suggested: >>>>>>>>>> >>>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>>>>> representation of name and type from a NameAndType constant pool entry >>>>>>>>>> with the specified index >>>>>>>>>> >>>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string >>>>>>>>>> representation of name and type from an InvokeDynamic constant pool entry >>>>>>>>>> with the specified index >>>>>>>>>> >>>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant >>>>>>>>>> pool entry with the specified index >>>>>>>>>> >>>>>>>>>> These three methods could be used for testing API working with constant >>>>>>>>>> pool, e.g. JVMCI. >>>>>>>>>> >>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>>> Webrev hotspot: >>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> -Konstantin >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From kim.barrett at oracle.com Tue Dec 15 19:08:28 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Dec 2015 14:08:28 -0500 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: References: <56697E62.9030306@redhat.com> <566A9E2F.2000606@redhat.com> <5C36B6CF-7098-4568-AA79-05F624580995@oracle.com> <07E5A6CA-1259-4CB6-B34B-B42442C820E5@oracle.com> Message-ID: <5B408991-20D5-44A4-A4D6-60E53FABD4C3@oracle.com> On Dec 11, 2015, at 2:33 PM, Kim Barrett wrote: > >> So, the lvalue cast makes the following macro definition plausible: >> >> #define JAVA_INTEGER_OP(OP, NAME, TYPE, UNSIGNED_TYPE) \ >> inline TYPE NAME (TYPE in1, TYPE in2) { \ >> STATIC_ASSERT(sizeof(TYPE) == sizeof(UNSIGNED_TYPE)); \ >> UNSIGNED_TYPE ures = static_cast(in1); \ >> ures OP ## = static_cast(in2); \ >> return reinterpret_cast(ures); \ >> } > > [?] > I'll collect information on other platforms. I've reviewed the generated code for a bunch of platforms, and this approach is well supported across the full set when using optimization levels used to build hotspot. Thanks to Goetz Lindenmaier from SAP for providing results for many platforms I can't easily access. From christian.thalinger at oracle.com Tue Dec 15 20:54:56 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Dec 2015 10:54:56 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread Message-ID: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8145435 http://cr.openjdk.java.net/~twisti/8145435/webrev/ The actual fix for the problem is passing true to os::sleep: + const bool interruptible = true; + os::sleep(THREAD, 200, interruptible); since compiler threads are Java threads but I fixed a couple more things... First, I?ve added the same assert to os_posix.cpp: http://cr.openjdk.java.net/~twisti/8145435/webrev/src/os/posix/vm/os_posix.cpp.udiff.html because it?s odd to only hit this assert on Windows: Additionally I?ve changed the way we handle an exception in before_exit: http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html and moved abort_on_pending_exception into JVMCICompiler and made it private. It?s used for one thing only now. Finally I replaced JVMCIRuntime::call_printStackTrace with calls to java_lang_Throwable::print_stack_trace. From christian.thalinger at oracle.com Tue Dec 15 21:44:34 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Dec 2015 11:44:34 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> Message-ID: <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> [Adding Tom] > On Dec 15, 2015, at 10:54 AM, Christian Thalinger wrote: > > https://bugs.openjdk.java.net/browse/JDK-8145435 > http://cr.openjdk.java.net/~twisti/8145435/webrev/ > > The actual fix for the problem is passing true to os::sleep: > > + const bool interruptible = true; > + os::sleep(THREAD, 200, interruptible); > > since compiler threads are Java threads but I fixed a couple more things... > > First, I?ve added the same assert to os_posix.cpp: > > http://cr.openjdk.java.net/~twisti/8145435/webrev/src/os/posix/vm/os_posix.cpp.udiff.html > > because it?s odd to only hit this assert on Windows: > > Additionally I?ve changed the way we handle an exception in before_exit: > > http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html > > and moved abort_on_pending_exception into JVMCICompiler and made it private. It?s used for one thing only now. > > Finally I replaced JVMCIRuntime::call_printStackTrace with calls to java_lang_Throwable::print_stack_trace. From vladimir.kozlov at oracle.com Tue Dec 15 23:34:41 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Dec 2015 15:34:41 -0800 Subject: RFR: 8145096: Undefined behaviour in HotSpot, Take 2 In-Reply-To: <5670436E.8060606@redhat.com> References: <56697E62.9030306@redhat.com> <5670436E.8060606@redhat.com> Message-ID: <5670A391.8020000@oracle.com> Changes are good and implemented what was suggested during previous review. I will wait what Kim will say. Thanks, Vladimir On 12/15/15 8:44 AM, Andrew Haley wrote: > To recap: > > I've been tracing through HotSpot with GCC's undefined behaviour > sanitizer, which detects instances of undefined behaviour. There are > many instances of UB we probably don't want to fix (e.g. unaliged > accesses on x86) but some of them are serious. > > This patch fixes some signed integer overflow bugs in HotSpot which > are certainly known to occur. These mostly occur in C2. There are > surely many more such bugs but to begin with I want to concentrate on > those. > > This patch introduces some functions which perform java-like > arithmetic: java-add, etc. We think we've found a portable way to do > this. > > I have tried my utmost to change things as little as possible. There > are certainly places where we could make things more efficient, but my > goal was to limit the scope of this diff to fixing bugs. > > Apart from the undefined behaviour being fixed, this patch should > cause no behavioural changes, except in one case. > AdvancedThresholdPolicy::weight() grossly overflows, so much so that > its result is substantially noise. That's fixed here. > > It might be that the hashing functions for C2 types really should have > unsigned type rather than using java_add; I can make that change but > (as I said) I'm trying to change things as little as possible. > > http://cr.openjdk.java.net/~aph/8145096-2/ > > Andrew. > From ioi.lam at oracle.com Wed Dec 16 00:02:08 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 15 Dec 2015 16:02:08 -0800 Subject: RFR: 8145096: Undefined behaviour in HotSpot, Take 2 In-Reply-To: <5670436E.8060606@redhat.com> References: <56697E62.9030306@redhat.com> <5670436E.8060606@redhat.com> Message-ID: <5670AA00.7050508@oracle.com> Is it possible to change things like 1373 juint nrange = (juint)_hi - _lo; to 1373 juint nrange = juint(_hi) - _lo; or 1373 juint nrange = ((juint)_hi) - _lo; I found the first kind of casting difficult to read -- I constantly need to think, "does the cast apply to the first operand only, or the whole expression". Thanks - Ioi On 12/15/15 8:44 AM, Andrew Haley wrote: > To recap: > > I've been tracing through HotSpot with GCC's undefined behaviour > sanitizer, which detects instances of undefined behaviour. There are > many instances of UB we probably don't want to fix (e.g. unaliged > accesses on x86) but some of them are serious. > > This patch fixes some signed integer overflow bugs in HotSpot which > are certainly known to occur. These mostly occur in C2. There are > surely many more such bugs but to begin with I want to concentrate on > those. > > This patch introduces some functions which perform java-like > arithmetic: java-add, etc. We think we've found a portable way to do > this. > > I have tried my utmost to change things as little as possible. There > are certainly places where we could make things more efficient, but my > goal was to limit the scope of this diff to fixing bugs. > > Apart from the undefined behaviour being fixed, this patch should > cause no behavioural changes, except in one case. > AdvancedThresholdPolicy::weight() grossly overflows, so much so that > its result is substantially noise. That's fixed here. > > It might be that the hashing functions for C2 types really should have > unsigned type rather than using java_add; I can make that change but > (as I said) I'm trying to change things as little as possible. > > http://cr.openjdk.java.net/~aph/8145096-2/ > > Andrew. From david.holmes at oracle.com Wed Dec 16 00:54:49 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Dec 2015 10:54:49 +1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> Message-ID: <5670B659.7040000@oracle.com> Hi Christian, os_posix.cpp: tl;dr: the new assert is wrong, don't add it. os::sleep has two paths: 1. interruptible sleeps This is the implementation of java.lang.Thread.sleep and should only be called by JavaThreads using that API (but see below) 2. non-interruptible sleep Used for 'incidental' sleeps within the VM, primarily by non-JavaThreads. If a JavaThread uses this it will delay safepoints, so the sleep should be very small. As you have discovered the Windows implementation of os::sleep actually asserts that JavaThreads don't take the second path. That's not correct. There are two existing cases where this will trigger today. The first is a historical usage of ConvertYieldToSleep: JVM_ENTRY(void, JVM_Yield(JNIEnv *env, jclass threadClass)) JVMWrapper("JVM_Yield"); if (os::dont_yield()) return; HOTSPOT_THREAD_YIELD(); // When ConvertYieldToSleep is off (default), this matches the classic VM use of yield. // Critical for similar threading behaviour if (ConvertYieldToSleep) { os::sleep(thread, MinSleepInterval, false); } else { os::naked_yield(); } JVM_END Then in JVM_Sleep itself: if (millis == 0) { if (ConvertSleepToYield) { os::naked_yield(); } else { ThreadState old_state = thread->osthread()->get_state(); thread->osthread()->set_state(SLEEPING); os::sleep(thread, MinSleepInterval, false); thread->osthread()->set_state(old_state); } This would also blow up on Windows - if ConvertSleepToYield is turned off (it is on by default on x86 - in fact all platforms except sparc - which really should be a Solaris setting as it will now affect the Linux/sparc port (which would then crash with your proposed additional assert in os_posix.cpp!). So adding the assert to os::sleep on Posix is not correct, and arguably the assertion should be removed from the windows code. -- os_windows.cpp: runtime/os.hpp" If you grep you will find about a 50-50 split between interruptible and interruptable through the codebase, so unless you want to file a cleanup bug to make it consistent I would just drop this change. --- java.cpp It is not at all clear to me will be in a position to print the exception information correctly at this stage of the termination logic. I would argue that any errors during JVMCIRuntime::shutdown should be handled internally and logged using the logging mechanism, not via exceptions and exception printing. --- src/share/vm/jvmci/jvmciCompiler.cpp typo: + // Give other aborting threads to also print their stack traces. should be: + // Give other aborting threads a chance to also print their stack traces. though I am dubious about the need for this and the use of the os::sleep that seemed to trigger this whole issue. Why aren't you using a normal vmError-based termination path for such fatal errors? Cheers, David On 16/12/2015 6:54 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8145435 > http://cr.openjdk.java.net/~twisti/8145435/webrev/ > > The actual fix for the problem is passing true to os::sleep: > > + const bool interruptible = true; > + os::sleep(THREAD, 200, interruptible); > > since compiler threads are Java threads but I fixed a couple more things... > > First, I?ve added the same assert to os_posix.cpp: > > http://cr.openjdk.java.net/~twisti/8145435/webrev/src/os/posix/vm/os_posix.cpp.udiff.html > > because it?s odd to only hit this assert on Windows: > > Additionally I?ve changed the way we handle an exception in before_exit: > > http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html > > and moved abort_on_pending_exception into JVMCICompiler and made it private. It?s used for one thing only now. > > Finally I replaced JVMCIRuntime::call_printStackTrace with calls to java_lang_Throwable::print_stack_trace. > From tom.rodriguez at oracle.com Wed Dec 16 01:08:36 2015 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 15 Dec 2015 17:08:36 -0800 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> Message-ID: <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> >> >> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html >> >> and moved abort_on_pending_exception into JVMCICompiler and made it private. It?s used for one thing only now. That all seems ok to me. >> >> Finally I replaced JVMCIRuntime::call_printStackTrace with calls to java_lang_Throwable::print_stack_trace. > I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? tom From david.holmes at oracle.com Wed Dec 16 05:49:03 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Dec 2015 15:49:03 +1000 Subject: RFR (XS) 8144853: Print the names of callees in PrintAssembly/PrintInterprete In-Reply-To: <566FA1C2.9080302@oracle.com> References: <5665CD82.4070909@oracle.com> <5665D6EB.1030207@oracle.com> <5665DED7.3000204@oracle.com> <5667B24C.1070101@oracle.com> <566E03E3.4020403@oracle.com> <566FA1C2.9080302@oracle.com> Message-ID: <5670FB4F.40208@oracle.com> As per IM - ResourceMark needed to be added. Thanks, David On 15/12/2015 3:14 PM, David Holmes wrote: > Sorry for the delay. This looks fine to me. > > Thanks, > David > > On 14/12/2015 9:48 AM, Ioi Lam wrote: >> Hi David, >> >> I have updated the patch according to your feedback: >> >> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names.v3/ >> >> >> >> The buf[] variable is now allocated using NEW_RESOURCE_ARRAY, and the >> useless 'found' variable has been removed. The comment is also fixed. >> >> Thanks >> - Ioi >> >> On 12/8/15 8:47 PM, David Holmes wrote: >>> Hi Ioi, >>> >>> src/share/vm/code/nmethod.cpp >>> >>> Your use of the static buffer seems not thread-safe. >>> >>> Minor nit: >>> >>> 3057 bool found; >>> 3058 found = os::dll_address_to_function_name(dest, buf, >>> sizeof(buf), &offset); >>> >>> could be: >>> >>> 3057 bool found = os::dll_address_to_function_name(dest, >>> buf, sizeof(buf), &offset); >>> >>> >>> --- >>> >>> src/share/vm/compiler/disassembler.cpp >>> >>> Your use of the static buffer seems not thread-safe. >>> >>> 366 bool found; >>> >>> This variable seems unused. >>> >>> Typo: >>> >>> 369 // Don't do this for native methods, as the function name will >>> be printed in >>> 370 // by nmethod::reloc_string_for(). >>> >>> delete 'in' or 'by'. >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> On 8/12/2015 5:32 AM, Ioi Lam wrote: >>>> Hi Vladimir, >>>> >>>> Thanks for the suggestion. I've changed the patch to handle the >>>> nmethods >>>> differently than PrintInterpreter: >>>> >>>> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names.v2/ >>>> >>>> >>>> >>>> >>>> The nmethod dump now looks like this: >>>> >>>> 0x00007f607940c657: callq 0x00007f607186bb60 ; >>>> ImmutableOopMap{[0]=Oop } >>>> ;*ifeq {reexecute=1 >>>> rethrow=0 return_oop=0} >>>> ; - >>>> java.lang.String::charAt at 4 (line 685) >>>> ; {runtime_call >>>> UncommonTrapBlob} >>>> 0x00007f607940c65c: callq 0x00007f608b05eb00 ;*ifeq {reexecute=0 >>>> rethrow=0 return_oop=0} >>>> ; - >>>> java.lang.String::charAt at 4 (line 685) >>>> ; {runtime_call >>>> os::breakpoint()} >>>> >>>> >>>> Thanks >>>> - Ioi >>>> >>>> >>>> On 12/7/15 10:58 AM, Vladimir Ivanov wrote: >>>>> Ioi, >>>>> >>>>> Nice improvement! >>>>> >>>>> Why don't you print "{runtime_call os::breakpoint()}" for >>>>> -XX:+PrintAssemble instead? It looks more natural w.r.t. current >>>>> format. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 12/7/15 9:18 PM, Ioi Lam wrote: >>>>>> Please review a very small fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Bug: Print the names of callees in PrintAssembly/PrintInterprete >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8144853 >>>>>> >>>>>> Summary of fix: >>>>>> >>>>>> In -XX:+PrintAssembly and -XX:+PrintInterpreter, sometimes only >>>>>> the address of a callee is printed, and the name is missing. >>>>>> >>>>>> The fix is to use os::dll_address_to_function_name() to find the >>>>>> names of such functions and print them out if possible. >>>>>> >>>>>> EXAMPLES: >>>>>> -XX:+PrintInterpreter: >>>>>> 0x00007f1b018447c3: callq 0x00007f1b19b9bba0 = >>>>>> InterpreterRuntime::newarray(JavaThread*, BasicType, int) >>>>>> >>>>>> -XX:+PrintAssembly >>>>>> <....> >>>>>> 0x00007f75d87b9629: xchg %ax,%ax >>>>>> 0x00007f75d87b962b: callq 0x00007f75d0c11b60 ; >>>>>> ImmutableOopMap{rbp=Oop } >>>>>> ;*iflt >>>>>> {reexecute=1 >>>>>> rethrow=0 return_oop=0} >>>>>> ; - >>>>>> java.lang.StringLatin1::charAt at 1 (line 43) >>>>>> ; {runtime_call >>>>>> UncommonTrapBlob} >>>>>> 0x00007f75d87b9630: callq 0x00007f75e8e41370 = os::breakpoint() >>>>>> ;*iflt >>>>>> {reexecute=0 >>>>>> rethrow=0 return_oop=0} >>>>>> ; - >>>>>> java.lang.StringLatin1::charAt at 1 (line 43) >>>>>> ; {runtime_call} >>>>>> >>>>>> >>>>>> TESTS: >>>>>> RBT hotspot/test/:hotspot_all (this includes tests cases with >>>>>> -XX:+PrintAssembly) >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>> >> From aph at redhat.com Wed Dec 16 09:23:36 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 16 Dec 2015 09:23:36 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot, Take 2 In-Reply-To: <5670AA00.7050508@oracle.com> References: <56697E62.9030306@redhat.com> <5670436E.8060606@redhat.com> <5670AA00.7050508@oracle.com> Message-ID: <56712D98.7020506@redhat.com> On 16/12/15 00:02, Ioi Lam wrote: > Is it possible to change things like > > 1373 juint nrange = (juint)_hi - _lo; > > to > > 1373 juint nrange = juint(_hi) - _lo; > > or > > 1373 juint nrange = ((juint)_hi) - _lo; > > I found the first kind of casting difficult to read -- I constantly need > to think, "does the cast apply to the first operand only, or the whole > expression". Well, type casts bind very strongly. But I do sometimes add parens for clarity, even when technically unnecessary, just not in this case. I'm reluctant to make such a non-standard change. I am always willing to listen, though, and I'll wait to see what others say. Andrew. From konstantin.shefov at oracle.com Wed Dec 16 11:13:41 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 16 Dec 2015 14:13:41 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> <566FD940.4090608@oracle.com> <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> Message-ID: <56714765.5010009@oracle.com> Christian I have fixed the enum so it uses "ENUMENTRY(int)" format now and does linear search. http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04/ -Konstantin On 12/15/2015 08:36 PM, Christian Thalinger wrote: > >> On Dec 14, 2015, at 11:11 PM, Konstantin Shefov >> > >> wrote: >> >> Hi Christian >> >> Thanks for reviewing, I have changed indents as you asked: >> >> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.03 >> > > Thanks. I?m still not comfortable with the enum. It would be great > if we could get the values from the VM like in JVMCI: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#l101 > > but that would be overkill here. But I would like to see the enum > entries take the integer values as arguments, like here: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARCKind.java#l27 > > and either do a simple linear search to find the entry or build up a > table like the HotSpotConstantPool example above. > >> >> -Konstantin >> >> On 12/15/2015 06:23 AM, Christian Thalinger wrote: >>> >>>> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov >>>> >>> > wrote: >>>> >>>> Hello >>>> >>>> Please review the new version on the patch. >>>> >>>> New webrev: >>>> Webrev hotspot: >>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >>>> >>>> Webrev jdk: >>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >>>> >>> >>> These newlines look ridiculous especially when it?s not even needed: >>> >>> + // Returns a class reference index for a method or a field. >>> + public int getClassRefIndexAt >>> + (int index) { return >>> getClassRefIndexAt0 (constantPoolOop, index); } >>> >>> Either fix the indent or just add them like regular methods should >>> look like. >>> >>>> >>>> What has been changed: >>>> 1. Added tests for the new added methods. >>>> 2. Removed CP tag codes 100 - 105 from being passed to java and >>>> left only codes from the open JVM spec >>>> (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). >>>> >>>> Thanks >>>> -Konstantin >>>> >>>> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>>>> Coleen, >>>>> Thanks for review >>>>> >>>>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>>>> >>>>>> I have a couple preliminary comments. First, there are no tests >>>>>> added with all this new functionality. Tests should be added >>>>>> with the functionality changeset, not promised afterward. >>>>> I will add tests. >>>>>> Secondly, I do not like that JDK code knows the implementation >>>>>> details of the JVM's constant pool tags. These should be only >>>>>> for internal use. >>>>> The package "sun.reflect" is for internal use only, so it >>>>> shouldn?t be a problem. >>>>>> My third comment is that I haven't looked carefully at this >>>>>> constant pool implementation but it seems very unsafe if the >>>>>> class is redefined and relies on an implementation detail in the >>>>>> JVM that can change. I will have more comments once I look more >>>>>> at the jvmti specification. >>>>>> >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>>>> Hello >>>>>>> >>>>>>> Please, review modified webrev. >>>>>>> >>>>>>> I have added methods >>>>>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry >>>>>>> index from a method, field or indy entry index; >>>>>>> getClassRefIndexAt(int index) - to get class entry index from a >>>>>>> method or field entry index; >>>>>>> >>>>>>> I removed previously added method >>>>>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>>>>> >>>>>>> New webrev: >>>>>>> Webrev hotspot: >>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>>>> >>>>>>> Webrev jdk: >>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> -Konstantin >>>>>>> >>>>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>>>> Remi, >>>>>>>> >>>>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>>>> May be it also has sense to make a method >>>>>>>> "getMethodRefNameAndTypeIndex(int index)" to acquire >>>>>>>> name-and-type entry index for methods also. >>>>>>>> >>>>>>>> -Konstantin >>>>>>>> >>>>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>>>> Hi Konstantin, >>>>>>>>> Technically, getInvokedynamicRefInfoAt should be >>>>>>>>> getNameAndTypeOfInvokedynamicRefInfoAt because it only extract >>>>>>>>> the nameAndType value of the InvokeDynamicRef. >>>>>>>>> >>>>>>>>> In term of API, I think it's better to decompose the API, i.e. >>>>>>>>> to have a method >>>>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>>>> that returns the nameAndType index and to reuse >>>>>>>>> getNameAndTypeRefInfoAt(index) to get the corresponding array >>>>>>>>> of Strings. >>>>>>>>> >>>>>>>>> cheers, >>>>>>>>> R?mi >>>>>>>>> >>>>>>>>> ----- Mail original ----- >>>>>>>>>> De: "Christian Thalinger" >>>>>>>>> > >>>>>>>>>> ?: "Konstantin Shefov" >>>>>>>>>> Cc: "hotspot-dev developers" , >>>>>>>>>> core-libs-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to >>>>>>>>>> sun.reflect.ConstantPool >>>>>>>>>> >>>>>>>>>> [CC'ing core-libs-dev] >>>>>>>>>> >>>>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> Hello >>>>>>>>>>> >>>>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>>>> The following methods are suggested: >>>>>>>>>>> >>>>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns >>>>>>>>>>> string >>>>>>>>>>> representation of name and type from a NameAndType constant >>>>>>>>>>> pool entry >>>>>>>>>>> with the specified index >>>>>>>>>>> >>>>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - >>>>>>>>>>> returns string >>>>>>>>>>> representation of name and type from an InvokeDynamic >>>>>>>>>>> constant pool entry >>>>>>>>>>> with the specified index >>>>>>>>>>> >>>>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance >>>>>>>>>>> of a constant >>>>>>>>>>> pool entry with the specified index >>>>>>>>>>> >>>>>>>>>>> These three methods could be used for testing API working >>>>>>>>>>> with constant >>>>>>>>>>> pool, e.g. JVMCI. >>>>>>>>>>> >>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>>>> Webrev hotspot: >>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>>>> Webrev jdk: >>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> -Konstantin >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mikael.gerdin at oracle.com Wed Dec 16 11:54:13 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 16 Dec 2015 12:54:13 +0100 Subject: Moving the _vtable_len into Klass Message-ID: <567150E5.9060308@oracle.com> Hi all, In order to reduce the number of virtual calls in the GC hot path I'd like to propose that the field _vtable_len be moved to class Klass. The reason for requiring access to the vtable length in the GC is that the "nonstatic oop maps" are packed after the v and itables after the actual C++ InstanceKlass. In its current form, the vtable_length() accesor is a pure virtual on Klass, and is implemented in ArrayKlass and InstanceKlass by returning a simple member variable _vtable_len which is present in both ArrayKlass and InstanceKlass. My suggestion is to move the _vtable_len member to Klass and move the accessor for it to Klass as well. This also brings up the issue of InstanceKlass::vtable_length_offset(), which is a very special beast. It returns the offset of the _vtable_len field, in words. This means that the int field _vtable_len must be on a word aligned address in order to work, otherwise we crash at startup in interesting ways. I should note that all callers of vtable_length_offset rectify the problem of it being a word offset by multiplying the value by wordSize in order to convert it to a byte offset. Does anyone know if there is a reason for vtable_length_offset to be a word offset? If the offset of the _vtable_len field could be accessed as a byte offset then one would not need to be so careful about the Klass field layout when attempting to fit _vtable_len while simultaneously not increasing the total size of the subclasses of Klass where the field is moved from. Regardless of the vtable_length_offset mess, are there any other concerns about making the vtable_length accessor nonvirtual? In order to keep the code consistent and reduce duplication the vtable() accessor could also be moved to Klass, together with start_of_vtable(). Unfortunately, there is a circular dependency with InstanceKlass for calculating the vtable start address because the calculation depends on the size of InstanceKlass. However I still think it might be workth consolidating the vtable related methods in Klass since they are in fact part of all subclasses of class. Questions/concerns about this suggested change are of course welcome! /Mikael From aph at redhat.com Wed Dec 16 13:29:52 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 16 Dec 2015 13:29:52 +0000 Subject: RFR: 8145553: Fix warnings in AArch64 directory Message-ID: <56716750.4030205@redhat.com> http://cr.openjdk.java.net/~aph/8145553/ These are mostly because ShouldNotReachHere() is not marked as noreturn. I understand that this has been discussed in the past and it was decided not to fix it because it broke stack traces. I've marked all of the bogus assignments as unreachable so that they can be removed if ever ShouldNotReachHere() is fixed. Andrew. From magnus.ihse.bursie at oracle.com Wed Dec 16 13:50:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Dec 2015 14:50:20 +0100 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition Message-ID: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. This patch is provided by Timo Kinnunen . I am sponsoring this patch. The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 /Magnus From goetz.lindenmaier at sap.com Wed Dec 16 13:51:32 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 16 Dec 2015 13:51:32 +0000 Subject: 8145553: Fix warnings in AArch64 directory In-Reply-To: <56716750.4030205@redhat.com> References: <56716750.4030205@redhat.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EE1726@DEWDFEMB12A.global.corp.sap> Hi Andrew, Looks good. Thanks for adding all these in the end. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Andrew Haley > Sent: Wednesday, December 16, 2015 2:30 PM > To: hotspot-dev Source Developers > Subject: RFR: 8145553: Fix warnings in AArch64 directory > > http://cr.openjdk.java.net/~aph/8145553/ > > These are mostly because ShouldNotReachHere() is not marked as > noreturn. I understand that this has been discussed in the past and > it was decided not to fix it because it broke stack traces. > > I've marked all of the bogus assignments as unreachable so that they > can be removed if ever ShouldNotReachHere() is fixed. > > Andrew. From erik.joelsson at oracle.com Wed Dec 16 14:37:02 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 Dec 2015 15:37:02 +0100 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> Message-ID: <5671770E.90001@oracle.com> The configure change looks good. Can't comment on the code changes. /Erik On 2015-12-16 14:50, Magnus Ihse Bursie wrote: > There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. > > This patch is provided by Timo Kinnunen . I am sponsoring this patch. > > The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. > > I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 > > /Magnus From sebastian.sickelmann at gmx.de Wed Dec 16 16:18:36 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Wed, 16 Dec 2015 17:18:36 +0100 Subject: CppInterpreter Message-ID: <56718EDC.40707@gmx.de> Hi, is it possible to compile openjdk with --with-jvm-interpreter=cpp but without --with-jvm-variants=zero ? I am getting the following error when i try it on the actual http://hg.openjdk.java.net/jdk9/hs-rt/hotspot sources. Building target 'images' in configuration 'linux-x86_64-normal-server-slowdebug' ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp: In member function ?bool frame::safe_for_sender(JavaThread*)?: ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:139:53: error: ?interpreter_frame_sender_sp_offset? is not a member of ?frame? sender_unextended_sp = (intptr_t*) this->fp()[frame::interpreter_frame_sender_sp_offset]; ^ ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp: In member function ?void frame::describe_pd(FrameValues&, int)?: ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:698:48: error: a function-definition is not allowed here before ?{? token intptr_t *frame::initial_deoptimization_info() { ^ ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:703:34: error: a function-definition is not allowed here before ?{? token intptr_t* frame::real_fp() const { ^ ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:720:1: error: expected ?}? at end of input } For the errors in line 698, 703 and 720 i think there is a problem with the #ifdefs and the curly braces. Maybe the following patch does the trick: diff -r f0141966004b src/cpu/x86/vm/frame_x86.cpp --- a/src/cpu/x86/vm/frame_x86.cpp Tue Dec 15 17:57:08 2015 +0000 +++ b/src/cpu/x86/vm/frame_x86.cpp Wed Dec 16 16:40:07 2015 +0100 @@ -690,8 +690,8 @@ values.describe(frame_no, fp() - i, err_msg("call_stub word fp - %d", i)); } #endif // AMD64 +#endif } -#endif } #endif // !PRODUCT But for the missing interpreter_frame_sender_sp_offset I have no idea how to fix it. I would love to create a ticket in JBS and start working on it, if the cppInterpreter (without zero) should be supported and there is not ticket yet. -- Sebastian From sgehwolf at redhat.com Wed Dec 16 16:28:25 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 16 Dec 2015 17:28:25 +0100 Subject: CppInterpreter In-Reply-To: <56718EDC.40707@gmx.de> References: <56718EDC.40707@gmx.de> Message-ID: <1450283305.3716.47.camel@redhat.com> Hi, On Wed, 2015-12-16 at 17:18 +0100, Sebastian Sickelmann wrote: > Hi, > > is it possible to compile openjdk with --with-jvm-interpreter=cpp but > without --with-jvm-variants=zero ? > > I am getting the following error when i try it on the actual > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot sources. > > Building target 'images' in configuration > 'linux-x86_64-normal-server-slowdebug' > ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp: In member function > ?bool frame::safe_for_sender(JavaThread*)?: > ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:139:53: error: > ?interpreter_frame_sender_sp_offset? is not a member of ?frame? > ???????sender_unextended_sp = (intptr_t*) > this->fp()[frame::interpreter_frame_sender_sp_offset]; > ?????????????????????????????????????????????????????^ > ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp: In member function > ?void frame::describe_pd(FrameValues&, int)?: > ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:698:48: error: a > function-definition is not allowed here before ?{? token > ?intptr_t *frame::initial_deoptimization_info() { > ????????????????????????????????????????????????^ > ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:703:34: error: a > function-definition is not allowed here before ?{? token > ?intptr_t* frame::real_fp() const { > ??????????????????????????????????^ > ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:720:1: error: > expected ?}? at end of input > ?} > > For the errors in line 698, 703 and 720 i think there is a problem with > the #ifdefs and the curly braces. > > Maybe the following patch does the trick: > > diff -r f0141966004b src/cpu/x86/vm/frame_x86.cpp > --- a/src/cpu/x86/vm/frame_x86.cpp????Tue Dec 15 17:57:08 2015 +0000 > +++ b/src/cpu/x86/vm/frame_x86.cpp????Wed Dec 16 16:40:07 2015 +0100 > @@ -690,8 +690,8 @@ > ???????values.describe(frame_no, fp() - i, err_msg("call_stub word fp - > %d", i)); > ?????} > ?#endif // AMD64 > +#endif > ???} > -#endif > ?} > ?#endif // !PRODUCT > > > But for the missing interpreter_frame_sender_sp_offset I have no idea > how to fix it. > > I would love to create a ticket in JBS and start working on it,??if the > cppInterpreter (without zero) should be supported and there is not > ticket yet. I believe?Zero is the only user of the C++ interpreter at this point. At least as far as I'm aware of. There is also plans to remove it entirely. See: https://bugs.openjdk.java.net/browse/JDK-8074457 Cheers, Severin From volker.simonis at gmail.com Wed Dec 16 16:33:46 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 16 Dec 2015 17:33:46 +0100 Subject: CppInterpreter In-Reply-To: <1450283305.3716.47.camel@redhat.com> References: <56718EDC.40707@gmx.de> <1450283305.3716.47.camel@redhat.com> Message-ID: Yes, that's right. It's currently being removed from all platforms except Zero. Regards, Volker On Wed, Dec 16, 2015 at 5:28 PM, Severin Gehwolf wrote: > Hi, > > On Wed, 2015-12-16 at 17:18 +0100, Sebastian Sickelmann wrote: >> Hi, >> >> is it possible to compile openjdk with --with-jvm-interpreter=cpp but >> without --with-jvm-variants=zero ? >> >> I am getting the following error when i try it on the actual >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot sources. >> >> Building target 'images' in configuration >> 'linux-x86_64-normal-server-slowdebug' >> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp: In member function >> ?bool frame::safe_for_sender(JavaThread*)?: >> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:139:53: error: >> ?interpreter_frame_sender_sp_offset? is not a member of ?frame? >> sender_unextended_sp = (intptr_t*) >> this->fp()[frame::interpreter_frame_sender_sp_offset]; >> ^ >> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp: In member function >> ?void frame::describe_pd(FrameValues&, int)?: >> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:698:48: error: a >> function-definition is not allowed here before ?{? token >> intptr_t *frame::initial_deoptimization_info() { >> ^ >> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:703:34: error: a >> function-definition is not allowed here before ?{? token >> intptr_t* frame::real_fp() const { >> ^ >> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:720:1: error: >> expected ?}? at end of input >> } >> >> For the errors in line 698, 703 and 720 i think there is a problem with >> the #ifdefs and the curly braces. >> >> Maybe the following patch does the trick: >> >> diff -r f0141966004b src/cpu/x86/vm/frame_x86.cpp >> --- a/src/cpu/x86/vm/frame_x86.cpp Tue Dec 15 17:57:08 2015 +0000 >> +++ b/src/cpu/x86/vm/frame_x86.cpp Wed Dec 16 16:40:07 2015 +0100 >> @@ -690,8 +690,8 @@ >> values.describe(frame_no, fp() - i, err_msg("call_stub word fp - >> %d", i)); >> } >> #endif // AMD64 >> +#endif >> } >> -#endif >> } >> #endif // !PRODUCT >> >> >> But for the missing interpreter_frame_sender_sp_offset I have no idea >> how to fix it. >> >> I would love to create a ticket in JBS and start working on it, if the >> cppInterpreter (without zero) should be supported and there is not >> ticket yet. > > I believe Zero is the only user of the C++ interpreter at this point. > At least as far as I'm aware of. There is also plans to remove it > entirely. See: > https://bugs.openjdk.java.net/browse/JDK-8074457 > > Cheers, > Severin > From coleen.phillimore at oracle.com Wed Dec 16 16:39:35 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Dec 2015 11:39:35 -0500 Subject: CppInterpreter In-Reply-To: <56718EDC.40707@gmx.de> References: <56718EDC.40707@gmx.de> Message-ID: <567193C7.8000606@oracle.com> Sebastian, We are actively in the process of removing the Cpp interpreter. It has been broken for years, does not have support for most features (jsr292), is missing important security bug fixes, and is needless duplication (but different and difficult to implement) in the source base. The only question is whether we should remove the aarch64 files or if RedHat wants to do that. The ticket to remove the cpp interpreter is: https://bugs.openjdk.java.net/browse/JDK-8074457 We are keeping Zero. Thanks, Coleen On 12/16/15 11:18 AM, Sebastian Sickelmann wrote: > Hi, > > is it possible to compile openjdk with --with-jvm-interpreter=cpp but > without --with-jvm-variants=zero ? > > I am getting the following error when i try it on the actual > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot sources. > > Building target 'images' in configuration > 'linux-x86_64-normal-server-slowdebug' > ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp: In member function > ?bool frame::safe_for_sender(JavaThread*)?: > ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:139:53: error: > ?interpreter_frame_sender_sp_offset? is not a member of ?frame? > sender_unextended_sp = (intptr_t*) > this->fp()[frame::interpreter_frame_sender_sp_offset]; > ^ > ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp: In member function > ?void frame::describe_pd(FrameValues&, int)?: > ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:698:48: error: a > function-definition is not allowed here before ?{? token > intptr_t *frame::initial_deoptimization_info() { > ^ > ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:703:34: error: a > function-definition is not allowed here before ?{? token > intptr_t* frame::real_fp() const { > ^ > ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:720:1: error: > expected ?}? at end of input > } > > For the errors in line 698, 703 and 720 i think there is a problem with > the #ifdefs and the curly braces. > > Maybe the following patch does the trick: > > diff -r f0141966004b src/cpu/x86/vm/frame_x86.cpp > --- a/src/cpu/x86/vm/frame_x86.cpp Tue Dec 15 17:57:08 2015 +0000 > +++ b/src/cpu/x86/vm/frame_x86.cpp Wed Dec 16 16:40:07 2015 +0100 > @@ -690,8 +690,8 @@ > values.describe(frame_no, fp() - i, err_msg("call_stub word fp - > %d", i)); > } > #endif // AMD64 > +#endif > } > -#endif > } > #endif // !PRODUCT > > > But for the missing interpreter_frame_sender_sp_offset I have no idea > how to fix it. > > I would love to create a ticket in JBS and start working on it, if the > cppInterpreter (without zero) should be supported and there is not > ticket yet. > > -- > Sebastian From coleen.phillimore at oracle.com Wed Dec 16 16:40:18 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Dec 2015 11:40:18 -0500 Subject: CppInterpreter In-Reply-To: References: <56718EDC.40707@gmx.de> <1450283305.3716.47.camel@redhat.com> Message-ID: <567193F2.9070802@oracle.com> On 12/16/15 11:33 AM, Volker Simonis wrote: > Yes, that's right. > > It's currently being removed from all platforms except Zero. Yes, I have a really nice changeset that I'm currently working on! Coleen > > Regards, > Volker > > > On Wed, Dec 16, 2015 at 5:28 PM, Severin Gehwolf wrote: >> Hi, >> >> On Wed, 2015-12-16 at 17:18 +0100, Sebastian Sickelmann wrote: >>> Hi, >>> >>> is it possible to compile openjdk with --with-jvm-interpreter=cpp but >>> without --with-jvm-variants=zero ? >>> >>> I am getting the following error when i try it on the actual >>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot sources. >>> >>> Building target 'images' in configuration >>> 'linux-x86_64-normal-server-slowdebug' >>> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp: In member function >>> ?bool frame::safe_for_sender(JavaThread*)?: >>> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:139:53: error: >>> ?interpreter_frame_sender_sp_offset? is not a member of ?frame? >>> sender_unextended_sp = (intptr_t*) >>> this->fp()[frame::interpreter_frame_sender_sp_offset]; >>> ^ >>> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp: In member function >>> ?void frame::describe_pd(FrameValues&, int)?: >>> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:698:48: error: a >>> function-definition is not allowed here before ?{? token >>> intptr_t *frame::initial_deoptimization_info() { >>> ^ >>> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:703:34: error: a >>> function-definition is not allowed here before ?{? token >>> intptr_t* frame::real_fp() const { >>> ^ >>> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:720:1: error: >>> expected ?}? at end of input >>> } >>> >>> For the errors in line 698, 703 and 720 i think there is a problem with >>> the #ifdefs and the curly braces. >>> >>> Maybe the following patch does the trick: >>> >>> diff -r f0141966004b src/cpu/x86/vm/frame_x86.cpp >>> --- a/src/cpu/x86/vm/frame_x86.cpp Tue Dec 15 17:57:08 2015 +0000 >>> +++ b/src/cpu/x86/vm/frame_x86.cpp Wed Dec 16 16:40:07 2015 +0100 >>> @@ -690,8 +690,8 @@ >>> values.describe(frame_no, fp() - i, err_msg("call_stub word fp - >>> %d", i)); >>> } >>> #endif // AMD64 >>> +#endif >>> } >>> -#endif >>> } >>> #endif // !PRODUCT >>> >>> >>> But for the missing interpreter_frame_sender_sp_offset I have no idea >>> how to fix it. >>> >>> I would love to create a ticket in JBS and start working on it, if the >>> cppInterpreter (without zero) should be supported and there is not >>> ticket yet. >> I believe Zero is the only user of the C++ interpreter at this point. >> At least as far as I'm aware of. There is also plans to remove it >> entirely. See: >> https://bugs.openjdk.java.net/browse/JDK-8074457 >> >> Cheers, >> Severin >> From christian.thalinger at oracle.com Wed Dec 16 16:42:49 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Dec 2015 06:42:49 -1000 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <56714765.5010009@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> <566FD940.4090608@oracle.com> <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> <56714765.5010009@oracle.com> Message-ID: <38C93A32-85EF-4B51-BADE-730A1C1CD656@oracle.com> Looks good. Thanks. > On Dec 16, 2015, at 1:13 AM, Konstantin Shefov wrote: > > Christian > > I have fixed the enum so it uses "ENUMENTRY(int)" format now and does linear search. > http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04/ > > -Konstantin > > On 12/15/2015 08:36 PM, Christian Thalinger wrote: >> >>> On Dec 14, 2015, at 11:11 PM, Konstantin Shefov > wrote: >>> >>> Hi Christian >>> >>> Thanks for reviewing, I have changed indents as you asked: >>> >>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.03 >> >> Thanks. I?m still not comfortable with the enum. It would be great if we could get the values from the VM like in JVMCI: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#l101 >> >> but that would be overkill here. But I would like to see the enum entries take the integer values as arguments, like here: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARCKind.java#l27 >> >> and either do a simple linear search to find the entry or build up a table like the HotSpotConstantPool example above. >> >>> >>> -Konstantin >>> >>> On 12/15/2015 06:23 AM, Christian Thalinger wrote: >>>> >>>>> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov > wrote: >>>>> >>>>> Hello >>>>> >>>>> Please review the new version on the patch. >>>>> >>>>> New webrev: >>>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >>>> >>>> These newlines look ridiculous especially when it?s not even needed: >>>> >>>> + // Returns a class reference index for a method or a field. >>>> + public int getClassRefIndexAt >>>> + (int index) { return getClassRefIndexAt0 (constantPoolOop, index); } >>>> >>>> Either fix the indent or just add them like regular methods should look like. >>>> >>>>> >>>>> What has been changed: >>>>> 1. Added tests for the new added methods. >>>>> 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). >>>>> >>>>> Thanks >>>>> -Konstantin >>>>> >>>>> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>>>>> Coleen, >>>>>> Thanks for review >>>>>> >>>>>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be added with the functionality changeset, not promised afterward. >>>>>> I will add tests. >>>>>>> Secondly, I do not like that JDK code knows the implementation details of the JVM's constant pool tags. These should be only for internal use. >>>>>> The package "sun.reflect" is for internal use only, so it shouldn?t be a problem. >>>>>>> My third comment is that I haven't looked carefully at this constant pool implementation but it seems very unsafe if the class is redefined and relies on an implementation detail in the JVM that can change. I will have more comments once I look more at the jvmti specification. >>>>>>> >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>>>>> Hello >>>>>>>> >>>>>>>> Please, review modified webrev. >>>>>>>> >>>>>>>> I have added methods >>>>>>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; >>>>>>>> getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; >>>>>>>> >>>>>>>> I removed previously added method >>>>>>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>>>>>> >>>>>>>> New webrev: >>>>>>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Konstantin >>>>>>>> >>>>>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>>>>> Remi, >>>>>>>>> >>>>>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>>>>> May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. >>>>>>>>> >>>>>>>>> -Konstantin >>>>>>>>> >>>>>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>>>>> Hi Konstantin, >>>>>>>>>> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef. >>>>>>>>>> >>>>>>>>>> In term of API, I think it's better to decompose the API, i.e. to have a method >>>>>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>>>>> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. >>>>>>>>>> >>>>>>>>>> cheers, >>>>>>>>>> R?mi >>>>>>>>>> >>>>>>>>>> ----- Mail original ----- >>>>>>>>>>> De: "Christian Thalinger" > >>>>>>>>>>> ?: "Konstantin Shefov" >>>>>>>>>>> Cc: "hotspot-dev developers" , core-libs-dev at openjdk.java.net >>>>>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool >>>>>>>>>>> >>>>>>>>>>> [CC'ing core-libs-dev] >>>>>>>>>>> >>>>>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello >>>>>>>>>>>> >>>>>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>>>>> The following methods are suggested: >>>>>>>>>>>> >>>>>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>>>>>>> representation of name and type from a NameAndType constant pool entry >>>>>>>>>>>> with the specified index >>>>>>>>>>>> >>>>>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string >>>>>>>>>>>> representation of name and type from an InvokeDynamic constant pool entry >>>>>>>>>>>> with the specified index >>>>>>>>>>>> >>>>>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant >>>>>>>>>>>> pool entry with the specified index >>>>>>>>>>>> >>>>>>>>>>>> These three methods could be used for testing API working with constant >>>>>>>>>>>> pool, e.g. JVMCI. >>>>>>>>>>>> >>>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>>>>> Webrev hotspot: >>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> -Konstantin >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From adinn at redhat.com Wed Dec 16 16:50:58 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 16 Dec 2015 16:50:58 +0000 Subject: CppInterpreter In-Reply-To: <567193C7.8000606@oracle.com> References: <56718EDC.40707@gmx.de> <567193C7.8000606@oracle.com> Message-ID: <56719672.10307@redhat.com> On 16/12/15 16:39, Coleen Phillimore wrote: > The only question is whether we should remove the aarch64 files or if > RedHat wants to do that. Do you mean file src/cpu/aarch64/vm/cppInterpreterGenerator_aarch64.hpp That looks to me to be the only relevant file. If so then please go ahead and delete it. regards, Andrew Dinn ----------- From coleen.phillimore at oracle.com Wed Dec 16 17:06:51 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Dec 2015 12:06:51 -0500 Subject: CppInterpreter In-Reply-To: <56719672.10307@redhat.com> References: <56718EDC.40707@gmx.de> <567193C7.8000606@oracle.com> <56719672.10307@redhat.com> Message-ID: <56719A2B.4050204@oracle.com> Andrew, Thank you! The relevant files are; R src/cpu/aarch64/vm/bytecodeInterpreter_aarch64.cpp R src/cpu/aarch64/vm/bytecodeInterpreter_aarch64.hpp R src/cpu/aarch64/vm/bytecodeInterpreter_aarch64.inline.hpp R src/cpu/aarch64/vm/cppInterpreterGenerator_aarch64.hpp My patch also consolidates these functions so these files are removed also (as well as the conditional inclusion in interpreter/templateInterpreterGenerator.hpp) R src/cpu/aarch64/vm/interpreterGenerator_aarch64.hpp R src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.hpp Coleen On 12/16/15 11:50 AM, Andrew Dinn wrote: > On 16/12/15 16:39, Coleen Phillimore wrote: >> The only question is whether we should remove the aarch64 files or if >> RedHat wants to do that. > Do you mean file > > src/cpu/aarch64/vm/cppInterpreterGenerator_aarch64.hpp > > That looks to me to be the only relevant file. If so then please go > ahead and delete it. > > regards, > > > Andrew Dinn > ----------- > From chris.plummer at oracle.com Wed Dec 16 17:26:08 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 16 Dec 2015 09:26:08 -0800 Subject: Moving the _vtable_len into Klass In-Reply-To: <567150E5.9060308@oracle.com> References: <567150E5.9060308@oracle.com> Message-ID: <56719EB0.6030504@oracle.com> Hi Mikael, On 12/16/15 3:54 AM, Mikael Gerdin wrote: > Hi all, > > In order to reduce the number of virtual calls in the GC hot path I'd > like to propose that the field _vtable_len be moved to class Klass. > The reason for requiring access to the vtable length in the GC is that > the "nonstatic oop maps" are packed after the v and itables after the > actual C++ InstanceKlass. > > In its current form, the vtable_length() accesor is a pure virtual on > Klass, and is implemented in ArrayKlass and InstanceKlass by returning > a simple member variable _vtable_len which is present in both > ArrayKlass and InstanceKlass. > My suggestion is to move the _vtable_len member to Klass and move the > accessor for it to Klass as well. > > This also brings up the issue of > InstanceKlass::vtable_length_offset(), which is a very special beast. > It returns the offset of the _vtable_len field, in words. This means > that the int field _vtable_len must be on a word aligned address in > order to work, otherwise we crash at startup in interesting ways. Well that seems like fragile programming. The only reason it works right now is because _vtable_len comes right after a pointer type. Insert another int field before it and it will crash. > I should note that all callers of vtable_length_offset rectify the > problem of it being a word offset by multiplying the value by wordSize > in order to convert it to a byte offset. Yep. I just grep'd and saw the same. > > Does anyone know if there is a reason for vtable_length_offset to be a > word offset? Sorry, I don't have any historical perspective here, other than saying that specifying size, lengths, and offsets for InstanceKlass related stuff seems to all be scaled to HeapWordSize. Just started looking in this area recently for the first time myself. BTW, I think it should be using wordSize instead of HeapWordSize, although they do both evaluate to the same thing. > > If the offset of the _vtable_len field could be accessed as a byte > offset then one would not need to be so careful about the Klass field > layout when attempting to fit _vtable_len while simultaneously not > increasing the total size of the subclasses of Klass where the field > is moved from. I'm assuming you've prototyped moving it to just after _accumulated_modified_oops, taking advantage of the wasted bytes in the word set aside for the jshort _shared_class_path_index field that follows. > > Regardless of the vtable_length_offset mess, are there any other > concerns about making the vtable_length accessor nonvirtual? > > In order to keep the code consistent and reduce duplication the > vtable() accessor could also be moved to Klass, together with > start_of_vtable(). > Unfortunately, there is a circular dependency with InstanceKlass for > calculating the vtable start address because the calculation depends > on the size of InstanceKlass. However I still think it might be workth > consolidating the vtable related methods in Klass since they are in > fact part of all subclasses of class. So how will you get around the circular dependency? Chris > > Questions/concerns about this suggested change are of course welcome! > > /Mikael From adinn at redhat.com Wed Dec 16 17:28:15 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 16 Dec 2015 17:28:15 +0000 Subject: CppInterpreter In-Reply-To: <56719A2B.4050204@oracle.com> References: <56718EDC.40707@gmx.de> <567193C7.8000606@oracle.com> <56719672.10307@redhat.com> <56719A2B.4050204@oracle.com> Message-ID: <56719F2F.1060701@redhat.com> On 16/12/15 17:06, Coleen Phillimore wrote: > Andrew, Thank you! The relevant files are; > > R src/cpu/aarch64/vm/bytecodeInterpreter_aarch64.cpp > R src/cpu/aarch64/vm/bytecodeInterpreter_aarch64.hpp > R src/cpu/aarch64/vm/bytecodeInterpreter_aarch64.inline.hpp > R src/cpu/aarch64/vm/cppInterpreterGenerator_aarch64.hpp Yes, removing those files is fine. > My patch also consolidates these functions so these files are removed > also (as well as the conditional inclusion in > interpreter/templateInterpreterGenerator.hpp) > > R src/cpu/aarch64/vm/interpreterGenerator_aarch64.hpp > R src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.hpp Do you mean that the declarations in the latter two files have all been moved up to generic headers? If so then that is also fine. regards, Andrew Dinn ----------- From christian.tornqvist at oracle.com Wed Dec 16 17:28:25 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 16 Dec 2015 12:28:25 -0500 Subject: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes Message-ID: <1cddb01d13827$2bb383c0$831a8b40$@oracle.com> Hi everyone, Please review this change that updates ProjectCreator to work with the new version string change in JEP 223. Tested the change locally, had to use a workaround for the issue described in JDK-8144716. Also cleaned up some old build targets that are not needed anymore. This is how the version string looks like when building in VS: Debug: Java HotSpot(TM) 64-Bit Server VM (debug build 9-internal+0.christian.vsbuild-debug, mixed mode) Fastdebug: Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0.christian.vsbuild-fastdebug, mixed mode) Product: Java HotSpot(TM) 64-Bit Server VM (product build 9-internal+0.christian.vsbuild, mixed mode) Using make system Fastdebug: Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2015-12-16-120539.christian.jdk9-rt, mixed mode) Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8145400 Thanks, Christian From christian.thalinger at oracle.com Wed Dec 16 17:45:54 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Dec 2015 07:45:54 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <5670B659.7040000@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5670B659.7040000@oracle.com> Message-ID: <0FC1E0E8-8F34-4199-A2DF-3F6911211F08@oracle.com> > On Dec 15, 2015, at 2:54 PM, David Holmes wrote: > > Hi Christian, > > os_posix.cpp: > > tl;dr: the new assert is wrong, don't add it. > > os::sleep has two paths: > > 1. interruptible sleeps > > This is the implementation of java.lang.Thread.sleep and should only be called by JavaThreads using that API (but see below) > > 2. non-interruptible sleep > > Used for 'incidental' sleeps within the VM, primarily by non-JavaThreads. If a JavaThread uses this it will delay safepoints, so the sleep should be very small. > > As you have discovered the Windows implementation of os::sleep actually asserts that JavaThreads don't take the second path. That's not correct. There are two existing cases where this will trigger today. > > The first is a historical usage of ConvertYieldToSleep: > > JVM_ENTRY(void, JVM_Yield(JNIEnv *env, jclass threadClass)) > JVMWrapper("JVM_Yield"); > if (os::dont_yield()) return; > HOTSPOT_THREAD_YIELD(); > > // When ConvertYieldToSleep is off (default), this matches the classic VM use of yield. > // Critical for similar threading behaviour > if (ConvertYieldToSleep) { > os::sleep(thread, MinSleepInterval, false); > } else { > os::naked_yield(); > } > JVM_END > > Then in JVM_Sleep itself: > > if (millis == 0) { > if (ConvertSleepToYield) { > os::naked_yield(); > } else { > ThreadState old_state = thread->osthread()->get_state(); > thread->osthread()->set_state(SLEEPING); > os::sleep(thread, MinSleepInterval, false); > thread->osthread()->set_state(old_state); > } > > This would also blow up on Windows - if ConvertSleepToYield is turned off (it is on by default on x86 - in fact all platforms except sparc - which really should be a Solaris setting as it will now affect the Linux/sparc port (which would then crash with your proposed additional assert in os_posix.cpp!). > > So adding the assert to os::sleep on Posix is not correct, and arguably the assertion should be removed from the windows code. I?ll let you guys take care of that. > > -- > > os_windows.cpp: > runtime/os.hpp" > > If you grep you will find about a 50-50 split between interruptible and interruptable through the codebase, so unless you want to file a cleanup bug to make it consistent I would just drop this change. It?s a cleanup and it?s already done but I?m not arguing for this. > > --- > > java.cpp > > It is not at all clear to me will be in a position to print the exception information correctly at this stage of the termination logic. I would argue that any errors during JVMCIRuntime::shutdown should be handled internally and logged using the logging mechanism, not via exceptions and exception printing. I disagree. We are shutting down the VM and while doing that we are running Java code. If the Java code throws an exception the user wants to see that exception. > > --- > > src/share/vm/jvmci/jvmciCompiler.cpp > > typo: > > + // Give other aborting threads to also print their stack traces. > > should be: > > + // Give other aborting threads a chance to also print their stack traces. > > though I am dubious about the need for this and the use of the os::sleep that seemed to trigger this whole issue. Why aren't you using a normal vmError-based termination path for such fatal errors? As the comment says: + // This can be very useful when debugging class initialization + // failures. Since multiple compiler threads can initialize the JVMCI subsystem we need to print all of the exceptions to see the root cause. Doug would know more about this but that?s the gist. > > Cheers, > David > > On 16/12/2015 6:54 AM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8145435 >> http://cr.openjdk.java.net/~twisti/8145435/webrev/ >> >> The actual fix for the problem is passing true to os::sleep: >> >> + const bool interruptible = true; >> + os::sleep(THREAD, 200, interruptible); >> >> since compiler threads are Java threads but I fixed a couple more things... >> >> First, I?ve added the same assert to os_posix.cpp: >> >> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/os/posix/vm/os_posix.cpp.udiff.html >> >> because it?s odd to only hit this assert on Windows: >> >> Additionally I?ve changed the way we handle an exception in before_exit: >> >> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html >> >> and moved abort_on_pending_exception into JVMCICompiler and made it private. It?s used for one thing only now. >> >> Finally I replaced JVMCIRuntime::call_printStackTrace with calls to java_lang_Throwable::print_stack_trace. >> From ioi.lam at oracle.com Wed Dec 16 18:30:10 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 16 Dec 2015 10:30:10 -0800 Subject: RFR (XS) 8144853: Print the names of callees in PrintAssembly/PrintInterprete In-Reply-To: <5670FB4F.40208@oracle.com> References: <5665CD82.4070909@oracle.com> <5665D6EB.1030207@oracle.com> <5665DED7.3000204@oracle.com> <5667B24C.1070101@oracle.com> <566E03E3.4020403@oracle.com> <566FA1C2.9080302@oracle.com> <5670FB4F.40208@oracle.com> Message-ID: <5671ADB2.4020801@oracle.com> The code pushed yesterday already had the ResourceMark: 3055>> ResourceMark rm; 3056 const int buflen = 1024; 3057 char* buf = NEW_RESOURCE_ARRAY(char, buflen); 3058 int offset; 3059 if (os::dll_address_to_function_name(dest, buf, buflen, &offset)) { 366>> ResourceMark rm; 367 const int buflen = 1024; 368 char* buf = NEW_RESOURCE_ARRAY(char, buflen); 369 int offset; 370 if (os::dll_address_to_function_name(adr, buf, buflen, &offset)) { Thanks - Ioi On 12/15/15 9:49 PM, David Holmes wrote: > As per IM - ResourceMark needed to be added. > > Thanks, > David > > On 15/12/2015 3:14 PM, David Holmes wrote: >> Sorry for the delay. This looks fine to me. >> >> Thanks, >> David >> >> On 14/12/2015 9:48 AM, Ioi Lam wrote: >>> Hi David, >>> >>> I have updated the patch according to your feedback: >>> >>> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names.v3/ >>> >>> >>> >>> >>> The buf[] variable is now allocated using NEW_RESOURCE_ARRAY, and the >>> useless 'found' variable has been removed. The comment is also fixed. >>> >>> Thanks >>> - Ioi >>> >>> On 12/8/15 8:47 PM, David Holmes wrote: >>>> Hi Ioi, >>>> >>>> src/share/vm/code/nmethod.cpp >>>> >>>> Your use of the static buffer seems not thread-safe. >>>> >>>> Minor nit: >>>> >>>> 3057 bool found; >>>> 3058 found = os::dll_address_to_function_name(dest, buf, >>>> sizeof(buf), &offset); >>>> >>>> could be: >>>> >>>> 3057 bool found = os::dll_address_to_function_name(dest, >>>> buf, sizeof(buf), &offset); >>>> >>>> >>>> --- >>>> >>>> src/share/vm/compiler/disassembler.cpp >>>> >>>> Your use of the static buffer seems not thread-safe. >>>> >>>> 366 bool found; >>>> >>>> This variable seems unused. >>>> >>>> Typo: >>>> >>>> 369 // Don't do this for native methods, as the function name will >>>> be printed in >>>> 370 // by nmethod::reloc_string_for(). >>>> >>>> delete 'in' or 'by'. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>> On 8/12/2015 5:32 AM, Ioi Lam wrote: >>>>> Hi Vladimir, >>>>> >>>>> Thanks for the suggestion. I've changed the patch to handle the >>>>> nmethods >>>>> differently than PrintInterpreter: >>>>> >>>>> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names.v2/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The nmethod dump now looks like this: >>>>> >>>>> 0x00007f607940c657: callq 0x00007f607186bb60 ; >>>>> ImmutableOopMap{[0]=Oop } >>>>> ;*ifeq {reexecute=1 >>>>> rethrow=0 return_oop=0} >>>>> ; - >>>>> java.lang.String::charAt at 4 (line 685) >>>>> ; {runtime_call >>>>> UncommonTrapBlob} >>>>> 0x00007f607940c65c: callq 0x00007f608b05eb00 ;*ifeq >>>>> {reexecute=0 >>>>> rethrow=0 return_oop=0} >>>>> ; - >>>>> java.lang.String::charAt at 4 (line 685) >>>>> ; {runtime_call >>>>> os::breakpoint()} >>>>> >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>> >>>>> On 12/7/15 10:58 AM, Vladimir Ivanov wrote: >>>>>> Ioi, >>>>>> >>>>>> Nice improvement! >>>>>> >>>>>> Why don't you print "{runtime_call os::breakpoint()}" for >>>>>> -XX:+PrintAssemble instead? It looks more natural w.r.t. current >>>>>> format. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 12/7/15 9:18 PM, Ioi Lam wrote: >>>>>>> Please review a very small fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iklam/jdk9/8144853-print-interpreter-callee-names/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bug: Print the names of callees in PrintAssembly/PrintInterprete >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8144853 >>>>>>> >>>>>>> Summary of fix: >>>>>>> >>>>>>> In -XX:+PrintAssembly and -XX:+PrintInterpreter, sometimes >>>>>>> only >>>>>>> the address of a callee is printed, and the name is missing. >>>>>>> >>>>>>> The fix is to use os::dll_address_to_function_name() to >>>>>>> find the >>>>>>> names of such functions and print them out if possible. >>>>>>> >>>>>>> EXAMPLES: >>>>>>> -XX:+PrintInterpreter: >>>>>>> 0x00007f1b018447c3: callq 0x00007f1b19b9bba0 = >>>>>>> InterpreterRuntime::newarray(JavaThread*, BasicType, int) >>>>>>> >>>>>>> -XX:+PrintAssembly >>>>>>> <....> >>>>>>> 0x00007f75d87b9629: xchg %ax,%ax >>>>>>> 0x00007f75d87b962b: callq 0x00007f75d0c11b60 ; >>>>>>> ImmutableOopMap{rbp=Oop } >>>>>>> ;*iflt >>>>>>> {reexecute=1 >>>>>>> rethrow=0 return_oop=0} >>>>>>> ; - >>>>>>> java.lang.StringLatin1::charAt at 1 (line 43) >>>>>>> ; {runtime_call >>>>>>> UncommonTrapBlob} >>>>>>> 0x00007f75d87b9630: callq 0x00007f75e8e41370 = >>>>>>> os::breakpoint() >>>>>>> ;*iflt >>>>>>> {reexecute=0 >>>>>>> rethrow=0 return_oop=0} >>>>>>> ; - >>>>>>> java.lang.StringLatin1::charAt at 1 (line 43) >>>>>>> ; {runtime_call} >>>>>>> >>>>>>> >>>>>>> TESTS: >>>>>>> RBT hotspot/test/:hotspot_all (this includes tests cases with >>>>>>> -XX:+PrintAssembly) >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>> >>> From markus.gronlund at oracle.com Wed Dec 16 18:46:36 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 16 Dec 2015 10:46:36 -0800 (PST) Subject: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes In-Reply-To: <1cddb01d13827$2bb383c0$831a8b40$@oracle.com> References: <1cddb01d13827$2bb383c0$831a8b40$@oracle.com> Message-ID: Hi Christian, Thanks for taking this on. Could you please retain the build targets please? I use debug C2 on my win32 laptop as a matter of course. There is no need to limit the amount of build targets, it allows for flexibility. Thanks Markus -----Original Message----- From: Christian Tornqvist Sent: den 16 december 2015 18:28 To: hotspot-dev at openjdk.java.net Subject: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes Hi everyone, Please review this change that updates ProjectCreator to work with the new version string change in JEP 223. Tested the change locally, had to use a workaround for the issue described in JDK-8144716. Also cleaned up some old build targets that are not needed anymore. This is how the version string looks like when building in VS: Debug: Java HotSpot(TM) 64-Bit Server VM (debug build 9-internal+0.christian.vsbuild-debug, mixed mode) Fastdebug: Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0.christian.vsbuild-fastdebug, mixed mode) Product: Java HotSpot(TM) 64-Bit Server VM (product build 9-internal+0.christian.vsbuild, mixed mode) Using make system Fastdebug: Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2015-12-16-120539.christian.jdk9-rt, mixed mode) Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8145400 Thanks, Christian From mikael.gerdin at oracle.com Wed Dec 16 19:35:02 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 16 Dec 2015 20:35:02 +0100 Subject: Moving the _vtable_len into Klass In-Reply-To: <56719EB0.6030504@oracle.com> References: <567150E5.9060308@oracle.com> <56719EB0.6030504@oracle.com> Message-ID: <5671BCE6.6070508@oracle.com> Hi Chris, On 2015-12-16 18:26, Chris Plummer wrote: > Hi Mikael, > > On 12/16/15 3:54 AM, Mikael Gerdin wrote: >> Hi all, >> >> In order to reduce the number of virtual calls in the GC hot path I'd >> like to propose that the field _vtable_len be moved to class Klass. >> The reason for requiring access to the vtable length in the GC is that >> the "nonstatic oop maps" are packed after the v and itables after the >> actual C++ InstanceKlass. >> >> In its current form, the vtable_length() accesor is a pure virtual on >> Klass, and is implemented in ArrayKlass and InstanceKlass by returning >> a simple member variable _vtable_len which is present in both >> ArrayKlass and InstanceKlass. >> My suggestion is to move the _vtable_len member to Klass and move the >> accessor for it to Klass as well. >> >> This also brings up the issue of >> InstanceKlass::vtable_length_offset(), which is a very special beast. >> It returns the offset of the _vtable_len field, in words. This means >> that the int field _vtable_len must be on a word aligned address in >> order to work, otherwise we crash at startup in interesting ways. > Well that seems like fragile programming. The only reason it works right > now is because _vtable_len comes right after a pointer type. Insert > another int field before it and it will crash. Yep, I'd say it's a bug that it's so fragile. >> I should note that all callers of vtable_length_offset rectify the >> problem of it being a word offset by multiplying the value by wordSize >> in order to convert it to a byte offset. > Yep. I just grep'd and saw the same. >> >> Does anyone know if there is a reason for vtable_length_offset to be a >> word offset? > Sorry, I don't have any historical perspective here, other than saying > that specifying size, lengths, and offsets for InstanceKlass related > stuff seems to all be scaled to HeapWordSize. Just started looking in > this area recently for the first time myself. BTW, I think it should be > using wordSize instead of HeapWordSize, although they do both evaluate > to the same thing. Yep, I noticed that too. >> >> If the offset of the _vtable_len field could be accessed as a byte >> offset then one would not need to be so careful about the Klass field >> layout when attempting to fit _vtable_len while simultaneously not >> increasing the total size of the subclasses of Klass where the field >> is moved from. > I'm assuming you've prototyped moving it to just after > _accumulated_modified_oops, taking advantage of the wasted bytes in the > word set aside for the jshort _shared_class_path_index field that follows. In my current variant I've experimented with moving some things around: diff --git a/src/share/vm/oops/klass.hpp b/src/share/vm/oops/klass.hpp --- a/src/share/vm/oops/klass.hpp +++ b/src/share/vm/oops/klass.hpp @@ -130,18 +130,18 @@ jint _modifier_flags; // Processed access flags, for use by Class.getModifiers. AccessFlags _access_flags; // Access flags. The class/interface distinction is stored here. + TRACE_DEFINE_KLASS_TRACE_ID; + // Biased locking implementation and statistics // (the 64-bit chunk goes first, to avoid some fragmentation) jlong _last_biased_lock_bulk_revocation_time; markOop _prototype_header; // Used when biased locking is both enabled and disabled for this type - jint _biased_lock_revocation_count; - - TRACE_DEFINE_KLASS_TRACE_ID; - // vtable length int _vtable_len; + jint _biased_lock_revocation_count; + // Remembered sets support for the oops in the klasses. jbyte _modified_oops; // Card Table Equivalent (YC/CMS support) jbyte _accumulated_modified_oops; // Mod Union Equivalent (CMS support) >> >> Regardless of the vtable_length_offset mess, are there any other >> concerns about making the vtable_length accessor nonvirtual? >> >> In order to keep the code consistent and reduce duplication the >> vtable() accessor could also be moved to Klass, together with >> start_of_vtable(). >> Unfortunately, there is a circular dependency with InstanceKlass for >> calculating the vtable start address because the calculation depends >> on the size of InstanceKlass. However I still think it might be workth >> consolidating the vtable related methods in Klass since they are in >> fact part of all subclasses of class. > So how will you get around the circular dependency? klass.cpp already includes instanceKlass.hpp (for better or worse) so I can simply make the vtable start getter a non-inline member function in Klass and it will work out. But I feel a little dirty adding another dependency from Klass to InstanceKlass. /Mikael > > Chris >> >> Questions/concerns about this suggested change are of course welcome! >> >> /Mikael > From sebastian.sickelmann at gmx.de Wed Dec 16 20:26:17 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Wed, 16 Dec 2015 21:26:17 +0100 Subject: CppInterpreter In-Reply-To: <567193C7.8000606@oracle.com> References: <56718EDC.40707@gmx.de> <567193C7.8000606@oracle.com> Message-ID: <5671C8E9.7090704@gmx.de> Hi, thanks for the clarification. I had hoped that I can do my experiment for removing "public fields in a binary compatible way" with the Cpp Interpreter. I thought it would be the next logical step after get it working in the zero build[0]. So it seems to be that I have to understand at least the x86 templateInterpreterGenerator to expand my experiment to the next level. I had hoped that i can learn some more with the cppInterpreter. -- Sebastian [0] http://mail.openjdk.java.net/pipermail/valhalla-dev/2015-December/001599.html On 12/16/2015 05:39 PM, Coleen Phillimore wrote: > > Sebastian, > > We are actively in the process of removing the Cpp interpreter. It > has been broken for years, does not have support for most features > (jsr292), is missing important security bug fixes, and is needless > duplication (but different and difficult to implement) in the source > base. > > The only question is whether we should remove the aarch64 files or if > RedHat wants to do that. > > The ticket to remove the cpp interpreter is: > https://bugs.openjdk.java.net/browse/JDK-8074457 > > We are keeping Zero. > > Thanks, > Coleen > > On 12/16/15 11:18 AM, Sebastian Sickelmann wrote: >> Hi, >> >> is it possible to compile openjdk with --with-jvm-interpreter=cpp but >> without --with-jvm-variants=zero ? >> >> I am getting the following error when i try it on the actual >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot sources. >> >> Building target 'images' in configuration >> 'linux-x86_64-normal-server-slowdebug' >> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp: In member function >> ?bool frame::safe_for_sender(JavaThread*)?: >> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:139:53: error: >> ?interpreter_frame_sender_sp_offset? is not a member of ?frame? >> sender_unextended_sp = (intptr_t*) >> this->fp()[frame::interpreter_frame_sender_sp_offset]; >> ^ >> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp: In member function >> ?void frame::describe_pd(FrameValues&, int)?: >> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:698:48: error: a >> function-definition is not allowed here before ?{? token >> intptr_t *frame::initial_deoptimization_info() { >> ^ >> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:703:34: error: a >> function-definition is not allowed here before ?{? token >> intptr_t* frame::real_fp() const { >> ^ >> ../../../../../hotspot/src/cpu/x86/vm/frame_x86.cpp:720:1: error: >> expected ?}? at end of input >> } >> >> For the errors in line 698, 703 and 720 i think there is a problem with >> the #ifdefs and the curly braces. >> >> Maybe the following patch does the trick: >> >> diff -r f0141966004b src/cpu/x86/vm/frame_x86.cpp >> --- a/src/cpu/x86/vm/frame_x86.cpp Tue Dec 15 17:57:08 2015 +0000 >> +++ b/src/cpu/x86/vm/frame_x86.cpp Wed Dec 16 16:40:07 2015 +0100 >> @@ -690,8 +690,8 @@ >> values.describe(frame_no, fp() - i, err_msg("call_stub word fp - >> %d", i)); >> } >> #endif // AMD64 >> +#endif >> } >> -#endif >> } >> #endif // !PRODUCT >> >> >> But for the missing interpreter_frame_sender_sp_offset I have no idea >> how to fix it. >> >> I would love to create a ticket in JBS and start working on it, if the >> cppInterpreter (without zero) should be supported and there is not >> ticket yet. >> >> -- >> Sebastian > > From john.r.rose at oracle.com Wed Dec 16 20:48:07 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 16 Dec 2015 12:48:07 -0800 Subject: Moving the _vtable_len into Klass In-Reply-To: <56719EB0.6030504@oracle.com> References: <567150E5.9060308@oracle.com> <56719EB0.6030504@oracle.com> Message-ID: On Dec 16, 2015, at 9:26 AM, Chris Plummer wrote: > >> Does anyone know if there is a reason for vtable_length_offset to be a word offset? > Sorry, I don't have any historical perspective here, other than saying that specifying size, lengths, and offsets for InstanceKlass related stuff seems to all be scaled to HeapWordSize. Just started looking in this area recently for the first time myself. BTW, I think it should be using wordSize instead of HeapWordSize, although they do both evaluate to the same thing. Basic facts: InstanceKlass and ArrayKlass are the only subclasses of Klass. Java objects can be instances or arrays, and both have v-tables. Array v-tables have uninteresting Object methods (only clone is special). In the A2.0 future, Array v-tables will (probably) have additional methods. Therefore the property of having a v-table is universal to all Klasses. Therefore this is a good refactoring. Here are some bits of ancient history, plus thoughts on scaled sizes: In the old days (metadata in perm-gen) some Klasses (method-klass, instance-klass-klass, etc.) did *not* have v-tables. The necessary alignment of v-table position between InstanceKlass and ArrayKlass had to be forced by a hack. We have inherited this hack, but should get rid of it. The original sizing logic for HotSpot was designed for 32-bit machines. Using 32-bit integers, sizing logic for some Java data structures is subject to embarrassing overflows. (Consider `new long[0x7FFFFFFE]`.) Even size_t (which is unsigned) doesn't quite have enough bits of dynamic range. And size_t itself was new (not so portable) when HotSpot was first written. Also, 64-bit integer arithmetic was more expensive in those days, on some platforms, so the original coders did not resort to uint64_t for sizing calculations. By working with ints scaled by wordSize (== sizeof(HeapWord)), we bought a couple more bits of dynamic range, to avoid overflows more easily. Having 32-bit ints stored in metadata is also a little more compact, although this sometimes comes with a risk of truncation when large values pass through small storage fields. Today's trade-offs: Nowadays, it would be reasonable to use unscaled sizes almost everywhere, passed as uint64_t values, and stored smaller where possible (using scaling or var-ints or whatever, as a local decision). (BTW, I think we should use more UNSIGNED5 var-ints for metadata sizes, to save footprint and provide safer dynamic range.) Even from the beginning, the JVM used a mix of scaled and unscaled size values, although there was an attempt to make the scaled ones predominate. At some point we tried to introduce some static typing help to avoid the obvious sort of bugs; see classes ByteSize and WordSize. These are helpful but also not universal. So we have a mix of conventions, not always clearly sorted out. The complexity and bug-worthiness of this setup is the biggest down-side to scaled size logic. An up-side of having scaled sizes is you get 2-3 more bits of dynamic range. A down-side of having scaled sizes is you have to decode scaled values by shifting them 2-3 bits. Sometimes x86 addressing modes help make this decoding happen "for free" as part of an address formation operation, but in practice I think this happens unreliably. (Using a tighter encoding like UNSIGNED5 could decode about as quickly as an explicit shift, but gain more footprint benefits. But that's a future conversation.) I personally don't regard the up-sides for scaled sizes as sufficient, now that 64-bit math is perfectly cheap. It will be will be hard to change to unscaled sizes everywhere, (and I've surely not given the full arguments both ways!) so we will be living in a mixed world for the foreseeable future. I do think, however, that it is reasonable to remove scaled sizes from JVM internal APIs, incrementally over time. Bottom line: My suggestion is that you make Klass admit that it always has a v-table, and don't feel bad about using unscaled sizes appearing in the JVM internal APIs, as long as you control footprint inside each class. ? John From erik.joelsson at oracle.com Wed Dec 16 21:34:03 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 Dec 2015 22:34:03 +0100 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds Message-ID: <5671D8CB.8080500@oracle.com> Hello, Please review this quick fix for the build issue introduced in Hotspot by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when building Hotspot fastdebug, you essentially get a slowdebug build. For an explanation of why, see comment in bug. This behavior is of course also a bug, but not something I will address in this quick fix. What happened in JDK-8036003 was that a new configure API for controlling debug symbols was introduced. The two main settings of this new parameter, --with-native-debug-symbols, that we use internally at Oracle are "external" and "zipped". It was important to us that the behavior of these did not change with JDK-8036003, but exactly that did happen, because both of these settings now cause DEBUG_BINARIES=true to be set. This variable has never been set by configure before and because of the above weird behavior in the Hotspot makefiles, we are having problems. My proposed quick fix is to not set DEBUG_BINARIES=true for "external" or "zipped". It can remain true for "internal" since Oracle never builds it that way, and I understand those that requested this new configure parameter were setting DEBUG_BINARIES=true as a workaround before this anyway, so they should be fine with the broken fastdebug behavior for a while more. I will file a follow up bug to properly clean up this mess, but it will take some more time. Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ /Erik From erik.joelsson at oracle.com Wed Dec 16 21:35:06 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 Dec 2015 22:35:06 +0100 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <5671D8CB.8080500@oracle.com> References: <5671D8CB.8080500@oracle.com> Message-ID: <5671D90A.5020208@oracle.com> One more thing, where should this fix be pushed? Do you need it urgently in hs-rt? /Erik On 2015-12-16 22:34, Erik Joelsson wrote: > Hello, > > Please review this quick fix for the build issue introduced in Hotspot > by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true > when building Hotspot fastdebug, you essentially get a slowdebug > build. For an explanation of why, see comment in bug. This behavior is > of course also a bug, but not something I will address in this quick fix. > > What happened in JDK-8036003 was that a new configure API for > controlling debug symbols was introduced. The two main settings of > this new parameter, --with-native-debug-symbols, that we use > internally at Oracle are "external" and "zipped". It was important to > us that the behavior of these did not change with JDK-8036003, but > exactly that did happen, because both of these settings now cause > DEBUG_BINARIES=true to be set. This variable has never been set by > configure before and because of the above weird behavior in the > Hotspot makefiles, we are having problems. > > My proposed quick fix is to not set DEBUG_BINARIES=true for "external" > or "zipped". It can remain true for "internal" since Oracle never > builds it that way, and I understand those that requested this new > configure parameter were setting DEBUG_BINARIES=true as a workaround > before this anyway, so they should be fine with the broken fastdebug > behavior for a while more. I will file a follow up bug to properly > clean up this mess, but it will take some more time. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 > Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ > > /Erik From magnus.ihse.bursie at oracle.com Wed Dec 16 21:38:15 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Dec 2015 22:38:15 +0100 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <5671D8CB.8080500@oracle.com> References: <5671D8CB.8080500@oracle.com> Message-ID: <5671D9C7.1030608@oracle.com> On 2015-12-16 22:34, Erik Joelsson wrote: > Hello, > > Please review this quick fix for the build issue introduced in Hotspot > by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true > when building Hotspot fastdebug, you essentially get a slowdebug > build. For an explanation of why, see comment in bug. This behavior is > of course also a bug, but not something I will address in this quick fix. > > What happened in JDK-8036003 was that a new configure API for > controlling debug symbols was introduced. The two main settings of > this new parameter, --with-native-debug-symbols, that we use > internally at Oracle are "external" and "zipped". It was important to > us that the behavior of these did not change with JDK-8036003, but > exactly that did happen, because both of these settings now cause > DEBUG_BINARIES=true to be set. This variable has never been set by > configure before and because of the above weird behavior in the > Hotspot makefiles, we are having problems. > > My proposed quick fix is to not set DEBUG_BINARIES=true for "external" > or "zipped". It can remain true for "internal" since Oracle never > builds it that way, and I understand those that requested this new > configure parameter were setting DEBUG_BINARIES=true as a workaround > before this anyway, so they should be fine with the broken fastdebug > behavior for a while more. I will file a follow up bug to properly > clean up this mess, but it will take some more time. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 > Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ Looks good to me. /Magnus From christian.tornqvist at oracle.com Wed Dec 16 21:52:32 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 16 Dec 2015 16:52:32 -0500 Subject: RFR(S): 8144716 - Unable to build in Visual Studio after JVMCI change Message-ID: <1cf4f01d1384c$11b26930$35173b90$@oracle.com> Hi everyone, Please review this fix to ProjectCreator that fixes build issues in Visual Studio caused by the JVMCI change. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8144716/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8144716 Thanks, Christian From igor.ignatyev at oracle.com Wed Dec 16 22:09:54 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 17 Dec 2015 01:09:54 +0300 Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build Message-ID: > http://cr.openjdk.java.net/~iignatyev/8144695/webrev.00/ 11 lines changed: 4 ins; 0 del; 7 mod; Hi, could you please review the fix for 8144695[1]? 8141543[1] propagated --disable-warnings-as-errors to hotspot build by setting WARNINGS_ARE_ERRORS to empty line. however in hotspot makefiles there are places where this variable is set explicitly. the fix changes = operator to ?= operator and updates adlc.make to use WARNINGS_ARE_ERRORS if it?s defined. [1] https://bugs.openjdk.java.net/browse/JDK-8144695 [2] https://bugs.openjdk.java.net/browse/JDK-8141543 Thanks, ? Igor From christian.thalinger at oracle.com Wed Dec 16 22:40:45 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Dec 2015 12:40:45 -1000 Subject: RFR(S): 8144716 - Unable to build in Visual Studio after JVMCI change In-Reply-To: <1cf4f01d1384c$11b26930$35173b90$@oracle.com> References: <1cf4f01d1384c$11b26930$35173b90$@oracle.com> Message-ID: Looks good. > On Dec 16, 2015, at 11:52 AM, Christian Tornqvist wrote: > > Hi everyone, > > > > Please review this fix to ProjectCreator that fixes build issues in Visual > Studio caused by the JVMCI change. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8144716/webrev.00/ > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8144716 > > > > Thanks, > > Christian > From christian.tornqvist at oracle.com Wed Dec 16 22:48:11 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 16 Dec 2015 17:48:11 -0500 Subject: RFR(S): 8145603 - Enable build.bat to use vcproj to build Message-ID: <1cfa801d13853$d774c490$865e4db0$@oracle.com> Hi everyone, Build.bat has not been working correctly for a couple of years and is now completely broken after the JDK Version change. Rewrote it to use the Visual Studio project files instead, examples of use: make\windows\build.bat tiered fastdebug This will generate the vcproj files using create.bat (if they haven't been generated before) and compile the JVM using msbuild. The whole process takes about a minute on my machine and less than that if the vcproj files are already there. Tested locally with x86 and x64 builds. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8145603/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8145603 Thanks, Christian From doug.simon at oracle.com Wed Dec 16 22:31:19 2015 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 16 Dec 2015 22:31:19 +0000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> Message-ID: <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> > On 16 Dec 2015, at 01:08, Tom Rodriguez wrote: > >>> >>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html >>> >>> and moved abort_on_pending_exception into JVMCICompiler and made it private. It?s used for one thing only now. > > That all seems ok to me. > >>> >>> Finally I replaced JVMCIRuntime::call_printStackTrace with calls to java_lang_Throwable::print_stack_trace. >> > > I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? There are two issues with java_lang_Throwable::print_stack_trace: 1. It doesn?t print the exception message, just the stack. 2. It doesn?t synchronize the printing on the stream object (in contrast to Throwable.printStackTrace()). Unless java_lang_Throwable::print_stack_trace is be modified to (optionally) include these 2 features, I think we should keep using JVMCIRuntime::call_printStackTrace and add a comment to it highlighting these differences. -Doug From igor.ignatyev at oracle.com Wed Dec 16 22:54:38 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 17 Dec 2015 01:54:38 +0300 Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build In-Reply-To: References: Message-ID: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com> as Mikael V correctly pointed out, there is missed $( ) in solaris/adlc. here is the new webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.01/ and diff comparing to the prev. iteration: > diff -r fe04b6ccb21a make/solaris/makefiles/adlc.make > --- a/make/solaris/makefiles/adlc.make Thu Dec 17 00:50:42 2015 +0300 > +++ b/make/solaris/makefiles/adlc.make Thu Dec 17 01:47:39 2015 +0300 > @@ -77,7 +77,7 @@ > WARNINGS_ARE_ERRORS ?= -w -xwe > endif > > -CFLAGS_WARN = WARNINGS_ARE_ERRORS > +CFLAGS_WARN = $(WARNINGS_ARE_ERRORS) > > # When using compiler version 5.13 (Solaris Studio 12.4), calls to explicitly > # instantiated template functions trigger this warning when +w is active. ? Igor > On Dec 17, 2015, at 1:09 AM, Igor Ignatyev wrote: > >> http://cr.openjdk.java.net/~iignatyev/8144695/webrev.00/ > 11 lines changed: 4 ins; 0 del; 7 mod; > > Hi, > > could you please review the fix for 8144695[1]? > > 8141543[1] propagated --disable-warnings-as-errors to hotspot build by setting WARNINGS_ARE_ERRORS to empty line. however in hotspot makefiles there are places where this variable is set explicitly. > the fix changes = operator to ?= operator and updates adlc.make to use WARNINGS_ARE_ERRORS if it?s defined. > > [1] https://bugs.openjdk.java.net/browse/JDK-8144695 > [2] https://bugs.openjdk.java.net/browse/JDK-8141543 > > Thanks, > ? Igor > > From mikael.vidstedt at oracle.com Wed Dec 16 23:07:07 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 16 Dec 2015 15:07:07 -0800 Subject: RFR(S): 8145603 - Enable build.bat to use vcproj to build In-Reply-To: <1cfa801d13853$d774c490$865e4db0$@oracle.com> References: <1cfa801d13853$d774c490$865e4db0$@oracle.com> Message-ID: <5671EE9B.7030503@oracle.com> On 2015-12-16 14:48, Christian Tornqvist wrote: > Hi everyone, > > > > Build.bat has not been working correctly for a couple of years and is now > completely broken after the JDK Version change. Rewrote it to use the Visual > Studio project files instead, examples of use: > > > > make\windows\build.bat tiered fastdebug > > > > This will generate the vcproj files using create.bat (if they haven't been > generated before) and compile the JVM using msbuild. The whole process takes > about a minute on my machine and less than that if the vcproj files are > already there. > > > > Tested locally with x86 and x64 builds. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8145603/webrev.00/ > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8145603 Not being fluent in .bat I could use a helpful comment on what line 26 (set HotSpotWorkSpace) actually does. Apart from that it looks good! Cheers, Mikael From magnus.ihse.bursie at oracle.com Wed Dec 16 23:09:57 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 17 Dec 2015 00:09:57 +0100 Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build In-Reply-To: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com> References: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com> Message-ID: <5671EF45.4090807@oracle.com> On 2015-12-16 23:54, Igor Ignatyev wrote: > as Mikael V correctly pointed out, there is missed $( ) in solaris/adlc. > here is the new webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.01/ > > and diff comparing to the prev. iteration: > >> diff -r fe04b6ccb21a make/solaris/makefiles/adlc.make >> --- a/make/solaris/makefiles/adlc.make Thu Dec 17 00:50:42 2015 +0300 >> +++ b/make/solaris/makefiles/adlc.make Thu Dec 17 01:47:39 2015 +0300 >> @@ -77,7 +77,7 @@ >> WARNINGS_ARE_ERRORS ?= -w -xwe >> endif >> >> -CFLAGS_WARN = WARNINGS_ARE_ERRORS >> +CFLAGS_WARN = $(WARNINGS_ARE_ERRORS) >> >> # When using compiler version 5.13 (Solaris Studio 12.4), calls to explicitly >> # instantiated template functions trigger this warning when +w is active. Have you tested that this achieves the correct thing, i.e. if introduce a warning in a file, you can still build successfully on all platforms with --disable-warnings-as-errors? /Magnus > ? Igor > >> On Dec 17, 2015, at 1:09 AM, Igor Ignatyev wrote: >> >>> http://cr.openjdk.java.net/~iignatyev/8144695/webrev.00/ >> 11 lines changed: 4 ins; 0 del; 7 mod; >> >> Hi, >> >> could you please review the fix for 8144695[1]? >> >> 8141543[1] propagated --disable-warnings-as-errors to hotspot build by setting WARNINGS_ARE_ERRORS to empty line. however in hotspot makefiles there are places where this variable is set explicitly. >> the fix changes = operator to ?= operator and updates adlc.make to use WARNINGS_ARE_ERRORS if it?s defined. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8144695 >> [2] https://bugs.openjdk.java.net/browse/JDK-8141543 >> >> Thanks, >> ? Igor >> >> From kim.barrett at oracle.com Wed Dec 16 23:10:46 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 16 Dec 2015 18:10:46 -0500 Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build In-Reply-To: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com> References: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com> Message-ID: On Dec 16, 2015, at 5:54 PM, Igor Ignatyev wrote: > > as Mikael V correctly pointed out, there is missed $( ) in solaris/adlc. > here is the new webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.01/ I wonder why the value for WARNINGS_ARE_ERRORS isn't obtained from the configure-provided variable CFLAGS_WARNINGS_ARE_ERRORS? E.g. something like WARNINGS_ARE_ERRORS ?= $(CFLAGS_WARNINGS_ARE_ERRORS) There may be a good reason for that, and thinking about it is probably better done as a separate RFE. Doing so might simplify things by allowing the assignment to be moved to some higher level common point. [The bsd conditionalization on $(COMPILER_WARNINGS_FATAL) might make that hard. Where does that variable come from? I haven't looked for anything similar elsewhere.] ------------------------------------------------------------------------------ make/solaris/makefiles/adlc.make 77 WARNINGS_ARE_ERRORS ?= -w -xwe I'm pretty sure "-w" is wrong here, and should be removed. And it's not clear why this assignment should be conditional on the compiler version. ------------------------------------------------------------------------------ From igor.ignatyev at oracle.com Wed Dec 16 23:14:44 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 17 Dec 2015 02:14:44 +0300 Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build In-Reply-To: <5671EF45.4090807@oracle.com> References: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com> <5671EF45.4090807@oracle.com> Message-ID: > On Dec 17, 2015, at 2:09 AM, Magnus Ihse Bursie wrote: > > On 2015-12-16 23:54, Igor Ignatyev wrote: >> as Mikael V correctly pointed out, there is missed $( ) in solaris/adlc. >> here is the new webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.01/ >> >> and diff comparing to the prev. iteration: >> >>> diff -r fe04b6ccb21a make/solaris/makefiles/adlc.make >>> --- a/make/solaris/makefiles/adlc.make Thu Dec 17 00:50:42 2015 +0300 >>> +++ b/make/solaris/makefiles/adlc.make Thu Dec 17 01:47:39 2015 +0300 >>> @@ -77,7 +77,7 @@ >>> WARNINGS_ARE_ERRORS ?= -w -xwe >>> endif >>> -CFLAGS_WARN = WARNINGS_ARE_ERRORS >>> +CFLAGS_WARN = $(WARNINGS_ARE_ERRORS) >>> # When using compiler version 5.13 (Solaris Studio 12.4), calls to explicitly >>> # instantiated template functions trigger this warning when +w is active. > Have you tested that this achieves the correct thing, i.e. if introduce a warning in a file, you can still build successfully on all platforms with --disable-warnings-as-errors? not on all platforms, but I checked that it fixes the problem from the description: > sh ./configure --disable-warnings-as-errors --enable-native-coverage --enable-debug > make all > ... > /home/dmitry/work/bugs/disable_warnings_as_errors/jdk9-hs-rt/hotspot/src/share/vm/gc/shared/genCollectedHeap.cpp: In function ?ScratchBlock* removeSmallestScratch(ScratchBlock**)?: > /home/dmitry/work/bugs/disable_warnings_as_errors/jdk9-hs-rt/hotspot/src/share/vm/gc/shared/genCollectedHeap.cpp:1032:33: error: ?smallest_ptr? may be used uninitialized in this function [-Werror=maybe-uninitialized] > *smallest_ptr = smallest->next; > ^ > cc1plus: all warnings being treated as errors > make[8]: *** [genCollectedHeap.o] Error 1 will double check other platforms. ? Igor > > /Magnus > >> ? Igor >> >>> On Dec 17, 2015, at 1:09 AM, Igor Ignatyev wrote: >>> >>>> http://cr.openjdk.java.net/~iignatyev/8144695/webrev.00/ >>> 11 lines changed: 4 ins; 0 del; 7 mod; >>> >>> Hi, >>> >>> could you please review the fix for 8144695[1]? >>> >>> 8141543[1] propagated --disable-warnings-as-errors to hotspot build by setting WARNINGS_ARE_ERRORS to empty line. however in hotspot makefiles there are places where this variable is set explicitly. >>> the fix changes = operator to ?= operator and updates adlc.make to use WARNINGS_ARE_ERRORS if it?s defined. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8144695 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8141543 >>> >>> Thanks, >>> ? Igor >>> >>> > From christian.thalinger at oracle.com Thu Dec 17 00:18:02 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Dec 2015 14:18:02 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> Message-ID: > On Dec 16, 2015, at 12:31 PM, Doug Simon wrote: > >> >> On 16 Dec 2015, at 01:08, Tom Rodriguez wrote: >> >>>> >>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html >>>> >>>> and moved abort_on_pending_exception into JVMCICompiler and made it private. It?s used for one thing only now. >> >> That all seems ok to me. >> >>>> >>>> Finally I replaced JVMCIRuntime::call_printStackTrace with calls to java_lang_Throwable::print_stack_trace. >>> >> >> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? > > > There are two issues with java_lang_Throwable::print_stack_trace: > > 1. It doesn?t print the exception message, just the stack. I?m printing the message separately: java_lang_Throwable::print(exception, tty); tty->cr(); java_lang_Throwable::print_stack_trace(exception(), tty); > 2. It doesn?t synchronize the printing on the stream object (in contrast to Throwable.printStackTrace()). We can solve that by using ttyLocker. > > Unless java_lang_Throwable::print_stack_trace is be modified to (optionally) include these 2 features, I think we should keep using JVMCIRuntime::call_printStackTrace and add a comment to it highlighting these differences. > > -Doug From kim.barrett at oracle.com Thu Dec 17 00:26:37 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 16 Dec 2015 19:26:37 -0500 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <566B5A19.6010301@redhat.com> References: <56697E62.9030306@redhat.com> <566A9E2F.2000606@redhat.com> <5C36B6CF-7098-4568-AA79-05F624580995@oracle.com> <07E5A6CA-1259-4CB6-B34B-B42442C820E5@oracle.com> <566B5A19.6010301@redhat.com> Message-ID: On Dec 11, 2015, at 6:19 PM, Andrew Haley wrote: > > On 11/12/15 19:33, Kim Barrett wrote: >> pps. The union trick is undefined behavior because it reads a union >> member other than the last one written. > > Hmm. The members are certainly in the same memory locations, and I > suspect that the language in 3.10 (Lvalues and rvalues) about signed > and unsigned types allows it too. But never mind: we only need one > way to do this, and if we can agree that it works we're done. I think we're all agreed that John's reinterpret_cast suggestion is the way to go, but for the record, there happens to be a parallel discussion of the union trick occurring on another mailing list I'm on. It's reported there that C11 allows the union trick. Also reported that discussion within the C++ committee has deemed it a bad idea for C++, and that there exist compilers which generate "bogus" code for the union trick, though no details were given. Regarding generation of "bogus" code, consider this function: int foo(int x) { union { int i; unsigned u; }; u = x; return i; } The statement "u = x;" is a dead assignment. Nowhere is u accessed directly; nor is there a access of something that could alias u, since there aren't any pointers/references taken. The access of i doesn't count, since accessing a union member other than the last one assigned is UB. Since the assignment is dead, the compiler may elide it. Another way of looking at it is that i is nowhere assigned, making the statement "return i;" problematic. There is no connection between the assignment of u and the access of i. The compiler might choose any value to return, including a trap-representation. From kim.barrett at oracle.com Thu Dec 17 00:28:18 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 16 Dec 2015 19:28:18 -0500 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <567042A9.8020706@redhat.com> References: <56697E62.9030306@redhat.com> <566A9E2F.2000606@redhat.com> <5C36B6CF-7098-4568-AA79-05F624580995@oracle.com> <07E5A6CA-1259-4CB6-B34B-B42442C820E5@oracle.com> <567042A9.8020706@redhat.com> Message-ID: <3F067BCB-6C44-43DC-85C5-37DC7E391F03@oracle.com> On Dec 15, 2015, at 11:41 AM, Andrew Haley wrote: > > On 12/11/2015 06:39 PM, John Rose wrote: > >> #define JAVA_INTEGER_OP(OP, NAME, TYPE, UNSIGNED_TYPE) \ >> inline TYPE NAME (TYPE in1, TYPE in2) { \ >> STATIC_ASSERT(sizeof(TYPE) == sizeof(UNSIGNED_TYPE)); \ >> UNSIGNED_TYPE ures = static_cast(in1); \ >> ures OP ## = static_cast(in2); \ >> return reinterpret_cast(ures); \ >> } > > I had to take out the STATIC_ASSERT because globalDefinitions.hpp > is included before STATIC_ASSERT is defined in debug.hpp. Oops, I forgot about that; I don?t have any problem with that change. From david.holmes at oracle.com Thu Dec 17 00:40:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Dec 2015 10:40:14 +1000 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <5671D90A.5020208@oracle.com> References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com> Message-ID: <5672046E.5@oracle.com> On 17/12/2015 7:35 AM, Erik Joelsson wrote: > One more thing, where should this fix be pushed? Do you need it urgently > in hs-rt? It is urgently needed in both the hs-rt and hs-comp repos as it affects nightly testing and JPRT. If Alejandro agrees I suggest pushing to jdk9/hs and it can then be pulled down to the team repos. With regard to the fix ... previously DEBUG_BINARIES was never set in spec.gmk and so was never externally introduced into the hotspot build this way. So why not simply change the name of the variable so that it has no affect on the hotspot part of the build? Thanks, David > /Erik > > On 2015-12-16 22:34, Erik Joelsson wrote: >> Hello, >> >> Please review this quick fix for the build issue introduced in Hotspot >> by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true >> when building Hotspot fastdebug, you essentially get a slowdebug >> build. For an explanation of why, see comment in bug. This behavior is >> of course also a bug, but not something I will address in this quick fix. >> >> What happened in JDK-8036003 was that a new configure API for >> controlling debug symbols was introduced. The two main settings of >> this new parameter, --with-native-debug-symbols, that we use >> internally at Oracle are "external" and "zipped". It was important to >> us that the behavior of these did not change with JDK-8036003, but >> exactly that did happen, because both of these settings now cause >> DEBUG_BINARIES=true to be set. This variable has never been set by >> configure before and because of the above weird behavior in the >> Hotspot makefiles, we are having problems. >> >> My proposed quick fix is to not set DEBUG_BINARIES=true for "external" >> or "zipped". It can remain true for "internal" since Oracle never >> builds it that way, and I understand those that requested this new >> configure parameter were setting DEBUG_BINARIES=true as a workaround >> before this anyway, so they should be fine with the broken fastdebug >> behavior for a while more. I will file a follow up bug to properly >> clean up this mess, but it will take some more time. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 >> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ >> >> /Erik > From kim.barrett at oracle.com Thu Dec 17 01:07:00 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 16 Dec 2015 20:07:00 -0500 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <56702E47.9090003@redhat.com> References: <56697E62.9030306@redhat.com> <56702E47.9090003@redhat.com> Message-ID: On Dec 15, 2015, at 10:14 AM, Andrew Haley wrote: > > On 12/10/2015 09:44 PM, Kim Barrett wrote: >> src/os/posix/vm/os_posix.cpp >> 756 unsigned int i; >> >> I'm not sure what the purpose of changing this to unsigned might be. >> The sa_flags member of struct sigaction is of type int. > > There are assignments into this field that overflow: SA_RESETHAND > (0x80000000) is implicitly unsigned, so assigning it to an int field > is at best implementation-define. I suppose that this is really a bug > in the Linux headers. I'll take it out. Ick, that's really annoying. It does seem like a bug in the Linux headers, with a poorly chosen value for SA_RESETHAND. Or in POSIX, for using a signed type for a bitmask. I suppose asking you to fix this root cause would be a bit much. ;-) Now that I understand it, and given its very localized scope, I would be fine with the original change to unsigned. That would prevent future verification/analysis from tripping over the same problem. My only concern is that someone reading this who is familiar with POSIX might wonder why an unsigned type is being used; maybe a brief comment? Up to you. >> 136 return (double)(method->rate() + 1) * ((double)(method->invocation_count() + 1) * (method->backedge_count() + 1)); >> >> I suspect the problem encountered here is that the multiplication of >> the two count values can overflow. If that multiplication was not >> grouped, but instead the rate term and invocation count were >> multiplied, then multiplied by the backedge count (e.g. use the >> natural grouping for operator*), the result should be mathematically >> the same, and I think should not run into overflow problems. Recall >> that method->rate() returns float. > > I guess this would be okay, but it seems prudent to use a double. Is > there some special performance optimization we have to care about? > The return type of AdvancedThresholdPolicy::weight() is double, so > I really can't think of any good reason not to do the arithmetic as > double. >> >> So I think a simpler change here might be >> >> return (method->rate() + 1) * (method->invocation_count() + 1) * (method->backedge_count() + 1); >> >> i.e. remove the parens that group the count multiplication before >> multiplying by the rate. The only use of weight() is about 10 lines later in the same file, in compare_methods. It seems unlikely that the extra bits of precision from computing in double vs float is going to matter in any interesting way there. Certainly it can't be worse than the "substantially noise" version we've been using! My preference is to avoid casts (especially C-style casts), preferably by arranging for types to match up properly. I suggest that the unnecessary grouping be eliminated and then either (1) change the return type for weight to float, to match the computation, (2) cast the rate to double, or (3) do neither, performing the computation in float with a final implicit conversion to double. (2) is probably *my* least preferred, but any of these would do for me. Since (2) is what is in the 8145096-2, I?ll leave it to you to decide whether you want to use either of the other options or leave it as is. > http://cr.openjdk.java.net/~aph/8145096-2/ I've now looked at the opto changes too. They mostly look ok to me. ------------------------------------------------------------------------------ src/share/vm/opto/mulnode.cpp 805 const jlong bits_mask = java_subtract((jlong)CONST64(1) << (jlong)(BitsPerJavaLong - con), CONST64(1)); Overflow in a left shift of a signed value is UB. I think this expression needs more revision than just dealing with the possible underflow in the subtraction, which can't be reached without already having UB when con == 1. [con == 0 is handled earlier.] Similarly here: 1257 const jlong mask = java_subtract(((jlong)CONST64(1) << (jlong)(BitsPerJavaLong - con)), (jlong)1); ------------------------------------------------------------------------------ src/share/vm/opto/type.cpp 3217 java_add(java_add(const_oop() ? const_oop()->hash() : 0, _klass_is_exact), 3218 java_add(_instance_id, TypePtr::hash())); Unaligned arguments for the outer java_add. ------------------------------------------------------------------------------ From alejandro.murillo at oracle.com Thu Dec 17 02:14:17 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 16 Dec 2015 19:14:17 -0700 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <5672046E.5@oracle.com> References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com> <5672046E.5@oracle.com> Message-ID: <56721A79.3080205@oracle.com> On 12/16/2015 5:40 PM, David Holmes wrote: > On 17/12/2015 7:35 AM, Erik Joelsson wrote: >> One more thing, where should this fix be pushed? Do you need it urgently >> in hs-rt? > > It is urgently needed in both the hs-rt and hs-comp repos as it > affects nightly testing and JPRT. If Alejandro agrees I suggest > pushing to jdk9/hs and it can then be pulled down to the team repos. Fine with me. It will go through PIT this weekend Alejandro > > With regard to the fix ... previously DEBUG_BINARIES was never set in > spec.gmk and so was never externally introduced into the hotspot build > this way. So why not simply change the name of the variable so that it > has no affect on the hotspot part of the build? > > Thanks, > David > >> /Erik >> >> On 2015-12-16 22:34, Erik Joelsson wrote: >>> Hello, >>> >>> Please review this quick fix for the build issue introduced in Hotspot >>> by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true >>> when building Hotspot fastdebug, you essentially get a slowdebug >>> build. For an explanation of why, see comment in bug. This behavior is >>> of course also a bug, but not something I will address in this quick >>> fix. >>> >>> What happened in JDK-8036003 was that a new configure API for >>> controlling debug symbols was introduced. The two main settings of >>> this new parameter, --with-native-debug-symbols, that we use >>> internally at Oracle are "external" and "zipped". It was important to >>> us that the behavior of these did not change with JDK-8036003, but >>> exactly that did happen, because both of these settings now cause >>> DEBUG_BINARIES=true to be set. This variable has never been set by >>> configure before and because of the above weird behavior in the >>> Hotspot makefiles, we are having problems. >>> >>> My proposed quick fix is to not set DEBUG_BINARIES=true for "external" >>> or "zipped". It can remain true for "internal" since Oracle never >>> builds it that way, and I understand those that requested this new >>> configure parameter were setting DEBUG_BINARIES=true as a workaround >>> before this anyway, so they should be fine with the broken fastdebug >>> behavior for a while more. I will file a follow up bug to properly >>> clean up this mess, but it will take some more time. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 >>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ >>> >>> /Erik >> -- Alejandro From ioi.lam at oracle.com Thu Dec 17 02:53:04 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 16 Dec 2015 18:53:04 -0800 Subject: RFR (XS) 8145620 - Disable compiler/floatingpoint/ModNaN.java Message-ID: <56722390.2050709@oracle.com> Please review a very very small but urgent fix: http://cr.openjdk.java.net/~iklam/jdk9/8145620-disable-modnan/ Bug: Disable compiler/floatingpoint/ModNaN.java https://bugs.openjdk.java.net/browse/JDK-8145620 Summary of fix: This test is failing intermittently when building the hs-rt repo with JPRT. The test should be disabled to avoid disruption of JPRT jobs while the main issue is being investigated. Thanks - Ioi From david.holmes at oracle.com Thu Dec 17 03:00:48 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Dec 2015 13:00:48 +1000 Subject: RFR (XS) 8145620 - Disable compiler/floatingpoint/ModNaN.java In-Reply-To: <56722390.2050709@oracle.com> References: <56722390.2050709@oracle.com> Message-ID: <56722560.9020503@oracle.com> Ship it! Thanks, David On 17/12/2015 12:53 PM, Ioi Lam wrote: > Please review a very very small but urgent fix: > > http://cr.openjdk.java.net/~iklam/jdk9/8145620-disable-modnan/ > > Bug: Disable compiler/floatingpoint/ModNaN.java > > https://bugs.openjdk.java.net/browse/JDK-8145620 > > Summary of fix: > > This test is failing intermittently when building the hs-rt > repo with JPRT. The test should be disabled to avoid disruption > of JPRT jobs while the main issue is being investigated. > > > Thanks > - Ioi > From coleen.phillimore at oracle.com Thu Dec 17 03:03:26 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Dec 2015 22:03:26 -0500 Subject: RFR (XS) 8145620 - Disable compiler/floatingpoint/ModNaN.java In-Reply-To: <56722390.2050709@oracle.com> References: <56722390.2050709@oracle.com> Message-ID: <567225FE.6010605@oracle.com> Looks good. I got that failure too. Coleen On 12/16/15 9:53 PM, Ioi Lam wrote: > Please review a very very small but urgent fix: > > http://cr.openjdk.java.net/~iklam/jdk9/8145620-disable-modnan/ > > Bug: Disable compiler/floatingpoint/ModNaN.java > > https://bugs.openjdk.java.net/browse/JDK-8145620 > > Summary of fix: > > This test is failing intermittently when building the hs-rt > repo with JPRT. The test should be disabled to avoid disruption > of JPRT jobs while the main issue is being investigated. > > > Thanks > - Ioi > From david.holmes at oracle.com Thu Dec 17 03:29:44 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Dec 2015 13:29:44 +1000 Subject: RFR (XS) 8145620 - Disable compiler/floatingpoint/ModNaN.java In-Reply-To: <567225FE.6010605@oracle.com> References: <56722390.2050709@oracle.com> <567225FE.6010605@oracle.com> Message-ID: <56722C28.50802@oracle.com> I ran the C test program from JDK-8015396 (which re-enabled the ModNan test) and it failed for our Linux devkits: both 4.8.2 and 4.9.2 David On 17/12/2015 1:03 PM, Coleen Phillimore wrote: > Looks good. I got that failure too. > Coleen > > On 12/16/15 9:53 PM, Ioi Lam wrote: >> Please review a very very small but urgent fix: >> >> http://cr.openjdk.java.net/~iklam/jdk9/8145620-disable-modnan/ >> >> Bug: Disable compiler/floatingpoint/ModNaN.java >> >> https://bugs.openjdk.java.net/browse/JDK-8145620 >> >> Summary of fix: >> >> This test is failing intermittently when building the hs-rt >> repo with JPRT. The test should be disabled to avoid disruption >> of JPRT jobs while the main issue is being investigated. >> >> >> Thanks >> - Ioi >> > From shafi.s.ahmad at oracle.com Thu Dec 17 04:28:36 2015 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 16 Dec 2015 20:28:36 -0800 (PST) Subject: RFR: JDK-8145099 - Better error message when SA can't attach to a process Message-ID: Hi, Please review the clean backport of bug: "JDK-8145099 - Better error message when SA can't attach to a process" to jdk8u-dev. Webrev: http://cr.openjdk.java.net/~poonam/8145099/webrev.00/ Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8145099 Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/cd0abe52014c Test: Run jprt. Regards, Shafi From thomas.stuefe at gmail.com Thu Dec 17 06:49:58 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 17 Dec 2015 07:49:58 +0100 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <5671D8CB.8080500@oracle.com> References: <5671D8CB.8080500@oracle.com> Message-ID: Hi Eric, short question, are other platforms beside Linux affected or is this Linux-specific (I saw you said Windows x64 showed no regression)? Reason I ask is, we just changed the default for AIX to "internal" because this is the only configuration we support and the build was broken after JDK-8036003 (see https://bugs.openjdk.java.net/browse/JDK-8145560) Kind Regards, Thomas On Wed, Dec 16, 2015 at 10:34 PM, Erik Joelsson wrote: > Hello, > > Please review this quick fix for the build issue introduced in Hotspot by > JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when > building Hotspot fastdebug, you essentially get a slowdebug build. For an > explanation of why, see comment in bug. This behavior is of course also a > bug, but not something I will address in this quick fix. > > What happened in JDK-8036003 was that a new configure API for controlling > debug symbols was introduced. The two main settings of this new parameter, > --with-native-debug-symbols, that we use internally at Oracle are > "external" and "zipped". It was important to us that the behavior of these > did not change with JDK-8036003, but exactly that did happen, because both > of these settings now cause DEBUG_BINARIES=true to be set. This variable > has never been set by configure before and because of the above weird > behavior in the Hotspot makefiles, we are having problems. > > My proposed quick fix is to not set DEBUG_BINARIES=true for "external" or > "zipped". It can remain true for "internal" since Oracle never builds it > that way, and I understand those that requested this new configure > parameter were setting DEBUG_BINARIES=true as a workaround before this > anyway, so they should be fine with the broken fastdebug behavior for a > while more. I will file a follow up bug to properly clean up this mess, but > it will take some more time. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 > Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ > > /Erik > From tom.rodriguez at oracle.com Thu Dec 17 07:20:26 2015 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Dec 2015 23:20:26 -0800 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> Message-ID: <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> >>> >>> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? >> >> >> There are two issues with java_lang_Throwable::print_stack_trace: >> >> 1. It doesn?t print the exception message, just the stack. > > I?m printing the message separately: > > java_lang_Throwable::print(exception, tty); > tty->cr(); > java_lang_Throwable::print_stack_trace(exception(), tty); There are already 3 other copies of this idiom. Throwable should probably have a single method for this. Or maybe print_stack_trace itself should do this? That would better parallel Throwable.printStackTrace(). tom > >> 2. It doesn?t synchronize the printing on the stream object (in contrast to Throwable.printStackTrace()). > > We can solve that by using ttyLocker. > >> >> Unless java_lang_Throwable::print_stack_trace is be modified to (optionally) include these 2 features, I think we should keep using JVMCIRuntime::call_printStackTrace and add a comment to it highlighting these differences. >> >> -Doug From erik.joelsson at oracle.com Thu Dec 17 07:54:53 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 17 Dec 2015 08:54:53 +0100 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <5672046E.5@oracle.com> References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com> <5672046E.5@oracle.com> Message-ID: <56726A4D.5050600@oracle.com> On 2015-12-17 01:40, David Holmes wrote: > On 17/12/2015 7:35 AM, Erik Joelsson wrote: >> One more thing, where should this fix be pushed? Do you need it urgently >> in hs-rt? > > It is urgently needed in both the hs-rt and hs-comp repos as it > affects nightly testing and JPRT. If Alejandro agrees I suggest > pushing to jdk9/hs and it can then be pulled down to the team repos. > Will do. > With regard to the fix ... previously DEBUG_BINARIES was never set in > spec.gmk and so was never externally introduced into the hotspot build > this way. So why not simply change the name of the variable so that it > has no affect on the hotspot part of the build? > Well, we don't want it affecting the jdk part of the build either at this point. This patch aims to restore the "external" and "zipped" settings to exactly what they were before the patch, as was promised. We will followup with a more complete fix. /Erik > Thanks, > David > >> /Erik >> >> On 2015-12-16 22:34, Erik Joelsson wrote: >>> Hello, >>> >>> Please review this quick fix for the build issue introduced in Hotspot >>> by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true >>> when building Hotspot fastdebug, you essentially get a slowdebug >>> build. For an explanation of why, see comment in bug. This behavior is >>> of course also a bug, but not something I will address in this quick >>> fix. >>> >>> What happened in JDK-8036003 was that a new configure API for >>> controlling debug symbols was introduced. The two main settings of >>> this new parameter, --with-native-debug-symbols, that we use >>> internally at Oracle are "external" and "zipped". It was important to >>> us that the behavior of these did not change with JDK-8036003, but >>> exactly that did happen, because both of these settings now cause >>> DEBUG_BINARIES=true to be set. This variable has never been set by >>> configure before and because of the above weird behavior in the >>> Hotspot makefiles, we are having problems. >>> >>> My proposed quick fix is to not set DEBUG_BINARIES=true for "external" >>> or "zipped". It can remain true for "internal" since Oracle never >>> builds it that way, and I understand those that requested this new >>> configure parameter were setting DEBUG_BINARIES=true as a workaround >>> before this anyway, so they should be fine with the broken fastdebug >>> behavior for a while more. I will file a follow up bug to properly >>> clean up this mess, but it will take some more time. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 >>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ >>> >>> /Erik >> From erik.joelsson at oracle.com Thu Dec 17 07:58:32 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 17 Dec 2015 08:58:32 +0100 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: References: <5671D8CB.8080500@oracle.com> Message-ID: <56726B28.7040002@oracle.com> I only got a bug report for Linux and can't test AIX. A quick look at the makefiles for AIX, I think you are probably fine. At least the weird construct in the Linux makefiles is not there to mess things up. /Erik On 2015-12-17 07:49, Thomas St?fe wrote: > Hi Eric, > > short question, are other platforms beside Linux affected or is this > Linux-specific (I saw you said Windows x64 showed no regression)? > > Reason I ask is, we just changed the default for AIX to "internal" > because this is the only configuration we support and the build was > broken after JDK-8036003 (see > https://bugs.openjdk.java.net/browse/JDK-8145560) > > Kind Regards, Thomas > > > On Wed, Dec 16, 2015 at 10:34 PM, Erik Joelsson > > wrote: > > Hello, > > Please review this quick fix for the build issue introduced in > Hotspot by JDK-8036003. The short story is that if you set > DEBUG_BINARIES=true when building Hotspot fastdebug, you > essentially get a slowdebug build. For an explanation of why, see > comment in bug. This behavior is of course also a bug, but not > something I will address in this quick fix. > > What happened in JDK-8036003 was that a new configure API for > controlling debug symbols was introduced. The two main settings of > this new parameter, --with-native-debug-symbols, that we use > internally at Oracle are "external" and "zipped". It was important > to us that the behavior of these did not change with JDK-8036003, > but exactly that did happen, because both of these settings now > cause DEBUG_BINARIES=true to be set. This variable has never been > set by configure before and because of the above weird behavior in > the Hotspot makefiles, we are having problems. > > My proposed quick fix is to not set DEBUG_BINARIES=true for > "external" or "zipped". It can remain true for "internal" since > Oracle never builds it that way, and I understand those that > requested this new configure parameter were setting > DEBUG_BINARIES=true as a workaround before this anyway, so they > should be fine with the broken fastdebug behavior for a while > more. I will file a follow up bug to properly clean up this mess, > but it will take some more time. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 > Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ > > > /Erik > > From thomas.stuefe at gmail.com Thu Dec 17 08:03:56 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 17 Dec 2015 09:03:56 +0100 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <56726B28.7040002@oracle.com> References: <5671D8CB.8080500@oracle.com> <56726B28.7040002@oracle.com> Message-ID: Thank you, Eric! On Thu, Dec 17, 2015 at 8:58 AM, Erik Joelsson wrote: > I only got a bug report for Linux and can't test AIX. A quick look at the > makefiles for AIX, I think you are probably fine. At least the weird > construct in the Linux makefiles is not there to mess things up. > > /Erik > > > On 2015-12-17 07:49, Thomas St?fe wrote: > > Hi Eric, > > short question, are other platforms beside Linux affected or is this > Linux-specific (I saw you said Windows x64 showed no regression)? > > Reason I ask is, we just changed the default for AIX to "internal" because > this is the only configuration we support and the build was broken after JDK-8036003 > (see > https://bugs.openjdk.java.net/browse/JDK-8145560) > > Kind Regards, Thomas > > > On Wed, Dec 16, 2015 at 10:34 PM, Erik Joelsson > wrote: > >> Hello, >> >> Please review this quick fix for the build issue introduced in Hotspot by >> JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when >> building Hotspot fastdebug, you essentially get a slowdebug build. For an >> explanation of why, see comment in bug. This behavior is of course also a >> bug, but not something I will address in this quick fix. >> >> What happened in JDK-8036003 was that a new configure API for controlling >> debug symbols was introduced. The two main settings of this new parameter, >> --with-native-debug-symbols, that we use internally at Oracle are >> "external" and "zipped". It was important to us that the behavior of these >> did not change with JDK-8036003, but exactly that did happen, because both >> of these settings now cause DEBUG_BINARIES=true to be set. This variable >> has never been set by configure before and because of the above weird >> behavior in the Hotspot makefiles, we are having problems. >> >> My proposed quick fix is to not set DEBUG_BINARIES=true for "external" or >> "zipped". It can remain true for "internal" since Oracle never builds it >> that way, and I understand those that requested this new configure >> parameter were setting DEBUG_BINARIES=true as a workaround before this >> anyway, so they should be fine with the broken fastdebug behavior for a >> while more. I will file a follow up bug to properly clean up this mess, but >> it will take some more time. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 >> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ >> >> /Erik >> > > > From david.holmes at oracle.com Thu Dec 17 08:08:53 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Dec 2015 18:08:53 +1000 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <56726A4D.5050600@oracle.com> References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com> <5672046E.5@oracle.com> <56726A4D.5050600@oracle.com> Message-ID: <56726D95.20103@oracle.com> On 17/12/2015 5:54 PM, Erik Joelsson wrote: > > > On 2015-12-17 01:40, David Holmes wrote: >> On 17/12/2015 7:35 AM, Erik Joelsson wrote: >>> One more thing, where should this fix be pushed? Do you need it urgently >>> in hs-rt? >> >> It is urgently needed in both the hs-rt and hs-comp repos as it >> affects nightly testing and JPRT. If Alejandro agrees I suggest >> pushing to jdk9/hs and it can then be pulled down to the team repos. >> > Will do. >> With regard to the fix ... previously DEBUG_BINARIES was never set in >> spec.gmk and so was never externally introduced into the hotspot build >> this way. So why not simply change the name of the variable so that it >> has no affect on the hotspot part of the build? >> > Well, we don't want it affecting the jdk part of the build either at > this point. This patch aims to restore the "external" and "zipped" > settings to exactly what they were before the patch, as was promised. I had not inferred from any of this that what was being done via NativeCompilation.gmk was in any way a problem. I would have expected any problems there to be readily seen before this was reviewed and pushed. So I'm a bit confused about this. I'm tempted to say rollback the whole thing rather than hack at it. And apologies as I'm just about to go offline for a few hours at least. David ----- > We will followup with a more complete fix. > > /Erik >> Thanks, >> David >> >>> /Erik >>> >>> On 2015-12-16 22:34, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please review this quick fix for the build issue introduced in Hotspot >>>> by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true >>>> when building Hotspot fastdebug, you essentially get a slowdebug >>>> build. For an explanation of why, see comment in bug. This behavior is >>>> of course also a bug, but not something I will address in this quick >>>> fix. >>>> >>>> What happened in JDK-8036003 was that a new configure API for >>>> controlling debug symbols was introduced. The two main settings of >>>> this new parameter, --with-native-debug-symbols, that we use >>>> internally at Oracle are "external" and "zipped". It was important to >>>> us that the behavior of these did not change with JDK-8036003, but >>>> exactly that did happen, because both of these settings now cause >>>> DEBUG_BINARIES=true to be set. This variable has never been set by >>>> configure before and because of the above weird behavior in the >>>> Hotspot makefiles, we are having problems. >>>> >>>> My proposed quick fix is to not set DEBUG_BINARIES=true for "external" >>>> or "zipped". It can remain true for "internal" since Oracle never >>>> builds it that way, and I understand those that requested this new >>>> configure parameter were setting DEBUG_BINARIES=true as a workaround >>>> before this anyway, so they should be fine with the broken fastdebug >>>> behavior for a while more. I will file a follow up bug to properly >>>> clean up this mess, but it will take some more time. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ >>>> >>>> /Erik >>> > From david.holmes at oracle.com Thu Dec 17 08:12:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Dec 2015 18:12:43 +1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <0FC1E0E8-8F34-4199-A2DF-3F6911211F08@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5670B659.7040000@oracle.com> <0FC1E0E8-8F34-4199-A2DF-3F6911211F08@oracle.com> Message-ID: <56726E7B.2070006@oracle.com> On 17/12/2015 3:45 AM, Christian Thalinger wrote: > >> On Dec 15, 2015, at 2:54 PM, David Holmes wrote: >> >> Hi Christian, >> >> os_posix.cpp: >> >> tl;dr: the new assert is wrong, don't add it. >> >> os::sleep has two paths: >> >> 1. interruptible sleeps >> >> This is the implementation of java.lang.Thread.sleep and should only be called by JavaThreads using that API (but see below) >> >> 2. non-interruptible sleep >> >> Used for 'incidental' sleeps within the VM, primarily by non-JavaThreads. If a JavaThread uses this it will delay safepoints, so the sleep should be very small. >> >> As you have discovered the Windows implementation of os::sleep actually asserts that JavaThreads don't take the second path. That's not correct. There are two existing cases where this will trigger today. >> >> The first is a historical usage of ConvertYieldToSleep: >> >> JVM_ENTRY(void, JVM_Yield(JNIEnv *env, jclass threadClass)) >> JVMWrapper("JVM_Yield"); >> if (os::dont_yield()) return; >> HOTSPOT_THREAD_YIELD(); >> >> // When ConvertYieldToSleep is off (default), this matches the classic VM use of yield. >> // Critical for similar threading behaviour >> if (ConvertYieldToSleep) { >> os::sleep(thread, MinSleepInterval, false); >> } else { >> os::naked_yield(); >> } >> JVM_END >> >> Then in JVM_Sleep itself: >> >> if (millis == 0) { >> if (ConvertSleepToYield) { >> os::naked_yield(); >> } else { >> ThreadState old_state = thread->osthread()->get_state(); >> thread->osthread()->set_state(SLEEPING); >> os::sleep(thread, MinSleepInterval, false); >> thread->osthread()->set_state(old_state); >> } >> >> This would also blow up on Windows - if ConvertSleepToYield is turned off (it is on by default on x86 - in fact all platforms except sparc - which really should be a Solaris setting as it will now affect the Linux/sparc port (which would then crash with your proposed additional assert in os_posix.cpp!). >> >> So adding the assert to os::sleep on Posix is not correct, and arguably the assertion should be removed from the windows code. > > I?ll let you guys take care of that. > >> >> -- >> >> os_windows.cpp: >> runtime/os.hpp" >> >> If you grep you will find about a 50-50 split between interruptible and interruptable through the codebase, so unless you want to file a cleanup bug to make it consistent I would just drop this change. > > It?s a cleanup and it?s already done but I?m not arguing for this. > >> >> --- >> >> java.cpp >> >> It is not at all clear to me will be in a position to print the exception information correctly at this stage of the termination logic. I would argue that any errors during JVMCIRuntime::shutdown should be handled internally and logged using the logging mechanism, not via exceptions and exception printing. > > I disagree. We are shutting down the VM and while doing that we are running Java code. If the Java code throws an exception the user wants to see that exception. But it is not the user's Java code it is an internal implementation artifact. I have no doubt this is helping you with debugging JVMCI but I don't think it is the correct way to handle an internal JVMCI error during termination. Ditto for the use of the sleep mechanism. David ------ > >> >> --- >> >> src/share/vm/jvmci/jvmciCompiler.cpp >> >> typo: >> >> + // Give other aborting threads to also print their stack traces. >> >> should be: >> >> + // Give other aborting threads a chance to also print their stack traces. >> >> though I am dubious about the need for this and the use of the os::sleep that seemed to trigger this whole issue. Why aren't you using a normal vmError-based termination path for such fatal errors? > > As the comment says: > > + // This can be very useful when debugging class initialization > + // failures. > > Since multiple compiler threads can initialize the JVMCI subsystem we need to print all of the exceptions to see the root cause. Doug would know more about this but that?s the gist. > >> >> Cheers, >> David >> >> On 16/12/2015 6:54 AM, Christian Thalinger wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8145435 >>> http://cr.openjdk.java.net/~twisti/8145435/webrev/ >>> >>> The actual fix for the problem is passing true to os::sleep: >>> >>> + const bool interruptible = true; >>> + os::sleep(THREAD, 200, interruptible); >>> >>> since compiler threads are Java threads but I fixed a couple more things... >>> >>> First, I?ve added the same assert to os_posix.cpp: >>> >>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/os/posix/vm/os_posix.cpp.udiff.html >>> >>> because it?s odd to only hit this assert on Windows: >>> >>> Additionally I?ve changed the way we handle an exception in before_exit: >>> >>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html >>> >>> and moved abort_on_pending_exception into JVMCICompiler and made it private. It?s used for one thing only now. >>> >>> Finally I replaced JVMCIRuntime::call_printStackTrace with calls to java_lang_Throwable::print_stack_trace. >>> > From magnus.ihse.bursie at oracle.com Thu Dec 17 08:18:41 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 17 Dec 2015 09:18:41 +0100 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <56726D95.20103@oracle.com> References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com> <5672046E.5@oracle.com> <56726A4D.5050600@oracle.com> <56726D95.20103@oracle.com> Message-ID: <56726FE1.6020906@oracle.com> On 2015-12-17 09:08, David Holmes wrote: > On 17/12/2015 5:54 PM, Erik Joelsson wrote: >> >> >> On 2015-12-17 01:40, David Holmes wrote: >>> On 17/12/2015 7:35 AM, Erik Joelsson wrote: >>>> One more thing, where should this fix be pushed? Do you need it >>>> urgently >>>> in hs-rt? >>> >>> It is urgently needed in both the hs-rt and hs-comp repos as it >>> affects nightly testing and JPRT. If Alejandro agrees I suggest >>> pushing to jdk9/hs and it can then be pulled down to the team repos. >>> >> Will do. >>> With regard to the fix ... previously DEBUG_BINARIES was never set in >>> spec.gmk and so was never externally introduced into the hotspot build >>> this way. So why not simply change the name of the variable so that it >>> has no affect on the hotspot part of the build? >>> >> Well, we don't want it affecting the jdk part of the build either at >> this point. This patch aims to restore the "external" and "zipped" >> settings to exactly what they were before the patch, as was promised. > > I had not inferred from any of this that what was being done via > NativeCompilation.gmk was in any way a problem. I would have expected > any problems there to be readily seen before this was reviewed and > pushed. So I'm a bit confused about this. The changes in NativeCompilation.gmk looked perfectly fine. They turned out to trigger a bug (or, at the very least, very unsuspected behavior) which was deeply hidden in the hotspot linux makefiles, where setting DEBUG_BINARIES did indeed enable the -g flag, but also, as a side effect, turned fastdebug builds into slowdebug builds. This was not something that we could possibly forsee. > > I'm tempted to say rollback the whole thing rather than hack at it. I don't think there is any compelling reason to rollback the whole change. The basic idea is sound. However, we do need to work on how to handle the debug symbols "under the hood". This deficit has been known for a long time to me and Erik but we have not spent any time on it. This change brought the problems up to daylight, and I think that's a good thing. I've started working on JDK-8145596, which will provide a proper solution to how we handle debug symbols. It is based on JDK-8036003. /Magnus > > And apologies as I'm just about to go offline for a few hours at least. > > David > ----- > > > >> We will followup with a more complete fix. >> >> /Erik >>> Thanks, >>> David >>> >>>> /Erik >>>> >>>> On 2015-12-16 22:34, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> Please review this quick fix for the build issue introduced in >>>>> Hotspot >>>>> by JDK-8036003. The short story is that if you set >>>>> DEBUG_BINARIES=true >>>>> when building Hotspot fastdebug, you essentially get a slowdebug >>>>> build. For an explanation of why, see comment in bug. This >>>>> behavior is >>>>> of course also a bug, but not something I will address in this quick >>>>> fix. >>>>> >>>>> What happened in JDK-8036003 was that a new configure API for >>>>> controlling debug symbols was introduced. The two main settings of >>>>> this new parameter, --with-native-debug-symbols, that we use >>>>> internally at Oracle are "external" and "zipped". It was important to >>>>> us that the behavior of these did not change with JDK-8036003, but >>>>> exactly that did happen, because both of these settings now cause >>>>> DEBUG_BINARIES=true to be set. This variable has never been set by >>>>> configure before and because of the above weird behavior in the >>>>> Hotspot makefiles, we are having problems. >>>>> >>>>> My proposed quick fix is to not set DEBUG_BINARIES=true for >>>>> "external" >>>>> or "zipped". It can remain true for "internal" since Oracle never >>>>> builds it that way, and I understand those that requested this new >>>>> configure parameter were setting DEBUG_BINARIES=true as a workaround >>>>> before this anyway, so they should be fine with the broken fastdebug >>>>> behavior for a while more. I will file a follow up bug to properly >>>>> clean up this mess, but it will take some more time. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ >>>>> >>>>> /Erik >>>> >> From magnus.ihse.bursie at oracle.com Thu Dec 17 08:22:52 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 17 Dec 2015 09:22:52 +0100 Subject: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes In-Reply-To: <1cddb01d13827$2bb383c0$831a8b40$@oracle.com> References: <1cddb01d13827$2bb383c0$831a8b40$@oracle.com> Message-ID: <567270DC.1040701@oracle.com> On 2015-12-16 18:28, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this change that updates ProjectCreator to work with the new > version string change in JEP 223. Tested the change locally, had to use a > workaround for the issue described in JDK-8144716. > > Also cleaned up some old build targets that are not needed anymore. > > > > This is how the version string looks like when building in VS: > > Debug: > > Java HotSpot(TM) 64-Bit Server VM (debug build > 9-internal+0.christian.vsbuild-debug, mixed mode) That does not look like a valid version string. '9-internal+0-.christian.vsbuild-debug' would be valid but strange-looking, '9-internal+0-christian.vsbuild-debug' would probably be better. Also note that the "opt" part of the version string does not contain "debug" any more in make builds. (But you are of course free to add anything to the opt string.) /Magnus > > Fastdebug: > > Java HotSpot(TM) 64-Bit Server VM (fastdebug build > 9-internal+0.christian.vsbuild-fastdebug, mixed mode) > > Product: > > Java HotSpot(TM) 64-Bit Server VM (product build > 9-internal+0.christian.vsbuild, mixed mode) > > > > Using make system > > Fastdebug: > > Java HotSpot(TM) 64-Bit Server VM (fastdebug build > 9-internal+0-2015-12-16-120539.christian.jdk9-rt, mixed mode) > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.00/ > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8145400 > > > > Thanks, > > Christian > From konstantin.shefov at oracle.com Thu Dec 17 08:26:54 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 17 Dec 2015 11:26:54 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <38C93A32-85EF-4B51-BADE-730A1C1CD656@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> <566FD940.4090608@oracle.com> <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> <56714765.5010009@oracle.com> <38C93A32-85EF-4B51-BADE-730A1C1CD656@oracle.com> Message-ID: <567271CE.3080604@oracle.com> Hi Coleen You have previously reviewed this enhancement and made a few comments I have resolved them, so could you look at the webrevs again, please? I have added tests, removed cp tags that are not in JVM spec (100 - 105) and made some other changes. JDK: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04 HOTSPOT: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 Thanks -Konstantin On 12/16/2015 07:42 PM, Christian Thalinger wrote: > Looks good. Thanks. > >> On Dec 16, 2015, at 1:13 AM, Konstantin Shefov wrote: >> >> Christian >> >> I have fixed the enum so it uses "ENUMENTRY(int)" format now and does linear search. >> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04/ >> >> -Konstantin >> >> On 12/15/2015 08:36 PM, Christian Thalinger wrote: >>>> On Dec 14, 2015, at 11:11 PM, Konstantin Shefov > wrote: >>>> >>>> Hi Christian >>>> >>>> Thanks for reviewing, I have changed indents as you asked: >>>> >>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.03 >>> Thanks. I?m still not comfortable with the enum. It would be great if we could get the values from the VM like in JVMCI: >>> >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#l101 >>> >>> but that would be overkill here. But I would like to see the enum entries take the integer values as arguments, like here: >>> >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARCKind.java#l27 >>> >>> and either do a simple linear search to find the entry or build up a table like the HotSpotConstantPool example above. >>> >>>> -Konstantin >>>> >>>> On 12/15/2015 06:23 AM, Christian Thalinger wrote: >>>>>> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov > wrote: >>>>>> >>>>>> Hello >>>>>> >>>>>> Please review the new version on the patch. >>>>>> >>>>>> New webrev: >>>>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >>>>> These newlines look ridiculous especially when it?s not even needed: >>>>> >>>>> + // Returns a class reference index for a method or a field. >>>>> + public int getClassRefIndexAt >>>>> + (int index) { return getClassRefIndexAt0 (constantPoolOop, index); } >>>>> >>>>> Either fix the indent or just add them like regular methods should look like. >>>>> >>>>>> What has been changed: >>>>>> 1. Added tests for the new added methods. >>>>>> 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). >>>>>> >>>>>> Thanks >>>>>> -Konstantin >>>>>> >>>>>> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>>>>>> Coleen, >>>>>>> Thanks for review >>>>>>> >>>>>>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>>>>>> I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be added with the functionality changeset, not promised afterward. >>>>>>> I will add tests. >>>>>>>> Secondly, I do not like that JDK code knows the implementation details of the JVM's constant pool tags. These should be only for internal use. >>>>>>> The package "sun.reflect" is for internal use only, so it shouldn?t be a problem. >>>>>>>> My third comment is that I haven't looked carefully at this constant pool implementation but it seems very unsafe if the class is redefined and relies on an implementation detail in the JVM that can change. I will have more comments once I look more at the jvmti specification. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>>>>>> Hello >>>>>>>>> >>>>>>>>> Please, review modified webrev. >>>>>>>>> >>>>>>>>> I have added methods >>>>>>>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; >>>>>>>>> getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; >>>>>>>>> >>>>>>>>> I removed previously added method >>>>>>>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>>>>>>> >>>>>>>>> New webrev: >>>>>>>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Konstantin >>>>>>>>> >>>>>>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>>>>>> Remi, >>>>>>>>>> >>>>>>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>>>>>> May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. >>>>>>>>>> >>>>>>>>>> -Konstantin >>>>>>>>>> >>>>>>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>>>>>> Hi Konstantin, >>>>>>>>>>> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef. >>>>>>>>>>> >>>>>>>>>>> In term of API, I think it's better to decompose the API, i.e. to have a method >>>>>>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>>>>>> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. >>>>>>>>>>> >>>>>>>>>>> cheers, >>>>>>>>>>> R?mi >>>>>>>>>>> >>>>>>>>>>> ----- Mail original ----- >>>>>>>>>>>> De: "Christian Thalinger" > >>>>>>>>>>>> ?: "Konstantin Shefov" >>>>>>>>>>>> Cc: "hotspot-dev developers" , core-libs-dev at openjdk.java.net >>>>>>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool >>>>>>>>>>>> >>>>>>>>>>>> [CC'ing core-libs-dev] >>>>>>>>>>>> >>>>>>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hello >>>>>>>>>>>>> >>>>>>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>>>>>> The following methods are suggested: >>>>>>>>>>>>> >>>>>>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>>>>>>>> representation of name and type from a NameAndType constant pool entry >>>>>>>>>>>>> with the specified index >>>>>>>>>>>>> >>>>>>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string >>>>>>>>>>>>> representation of name and type from an InvokeDynamic constant pool entry >>>>>>>>>>>>> with the specified index >>>>>>>>>>>>> >>>>>>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant >>>>>>>>>>>>> pool entry with the specified index >>>>>>>>>>>>> >>>>>>>>>>>>> These three methods could be used for testing API working with constant >>>>>>>>>>>>> pool, e.g. JVMCI. >>>>>>>>>>>>> >>>>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>>>>>> Webrev hotspot: >>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> -Konstantin From staffan.larsen at oracle.com Thu Dec 17 08:44:27 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 17 Dec 2015 09:44:27 +0100 Subject: RFR: JDK-8145099 - Better error message when SA can't attach to a process In-Reply-To: References: Message-ID: <6D2B497C-5E69-4D37-BB73-5D66686E45EC@oracle.com> Hi Shafi, Clean backports do not usually need a review round, but you do need approval from the JDK 8u maintainers: http://openjdk.java.net/projects/jdk8u/approval-template.html Thanks, /Staffan > On 17 dec. 2015, at 05:28, Shafi Ahmad wrote: > > Hi, > > > > Please review the clean backport of bug: "JDK-8145099 - Better error message when SA can't attach to a process" to jdk8u-dev. > > > > Webrev: http://cr.openjdk.java.net/~poonam/8145099/webrev.00/ > > Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8145099 > > Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/cd0abe52014c > > > > Test: Run jprt. > > > > Regards, > > Shafi From erik.joelsson at oracle.com Thu Dec 17 09:24:13 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 17 Dec 2015 10:24:13 +0100 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <56726D95.20103@oracle.com> References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com> <5672046E.5@oracle.com> <56726A4D.5050600@oracle.com> <56726D95.20103@oracle.com> Message-ID: <56727F3D.7090600@oracle.com> On 2015-12-17 09:08, David Holmes wrote: > On 17/12/2015 5:54 PM, Erik Joelsson wrote: >> >> >> On 2015-12-17 01:40, David Holmes wrote: >>> On 17/12/2015 7:35 AM, Erik Joelsson wrote: >>>> One more thing, where should this fix be pushed? Do you need it >>>> urgently >>>> in hs-rt? >>> >>> It is urgently needed in both the hs-rt and hs-comp repos as it >>> affects nightly testing and JPRT. If Alejandro agrees I suggest >>> pushing to jdk9/hs and it can then be pulled down to the team repos. >>> >> Will do. >>> With regard to the fix ... previously DEBUG_BINARIES was never set in >>> spec.gmk and so was never externally introduced into the hotspot build >>> this way. So why not simply change the name of the variable so that it >>> has no affect on the hotspot part of the build? >>> >> Well, we don't want it affecting the jdk part of the build either at >> this point. This patch aims to restore the "external" and "zipped" >> settings to exactly what they were before the patch, as was promised. > > I had not inferred from any of this that what was being done via > NativeCompilation.gmk was in any way a problem. I would have expected > any problems there to be readily seen before this was reviewed and > pushed. So I'm a bit confused about this. > I didn't follow this particular review closely as Magnus was on it and so I had missed the NativeCompilation part. It's true that it is very unlikely to be part of the problem described in this bug, but I still feel that the safest action at this point is to restore the behavior of "external" and "zipped" to what they used to be. Magnus is working on a complete fix where debug symbols will be enabled for everything in NativeCompilation. > I'm tempted to say rollback the whole thing rather than hack at it. > Rolling back will be much more work for me than submitting this patch. There are two changes already that depend on this change. I also don't dislike the idea of the new configure parameter. > And apologies as I'm just about to go offline for a few hours at least. > I hope you won't object to me pushing this with just ihse as reviewer. I feel this is rather a priority to get fixed. /Erik From adinn at redhat.com Thu Dec 17 09:27:43 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 17 Dec 2015 09:27:43 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: References: <56697E62.9030306@redhat.com> <566A9E2F.2000606@redhat.com> <5C36B6CF-7098-4568-AA79-05F624580995@oracle.com> <07E5A6CA-1259-4CB6-B34B-B42442C820E5@oracle.com> <566B5A19.6010301@redhat.com> Message-ID: <5672800F.30704@redhat.com> On 17/12/15 00:26, Kim Barrett wrote: > Regarding generation of "bogus" code, consider this function: > > int foo(int x) { > union { int i; unsigned u; }; > u = x; > return i; > } > > The statement "u = x;" is a dead assignment. Nowhere is u accessed > directly; nor is there a access of something that could alias u, since > there aren't any pointers/references taken. The access of i doesn't > count, since accessing a union member other than the last one assigned > is UB. Since the assignment is dead, the compiler may elide it. Hmm, no aliasing? That's an /interesting/ point of view. If only it were correct (... by some criterion more well-founded than committee-sanctioned derogation :-). > Another way of looking at it is that i is nowhere assigned, making the > statement "return i;" problematic. There is no connection between the > assignment of u and the access of i. The compiler might choose any > value to return, including a trap-representation. Hmm, no connection? Ditto! regards, Andrew Dinn ----------- From aph at redhat.com Thu Dec 17 10:12:35 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 17 Dec 2015 10:12:35 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: References: <56697E62.9030306@redhat.com> <566A9E2F.2000606@redhat.com> <5C36B6CF-7098-4568-AA79-05F624580995@oracle.com> <07E5A6CA-1259-4CB6-B34B-B42442C820E5@oracle.com> <566B5A19.6010301@redhat.com> Message-ID: <56728A93.8070004@redhat.com> On 17/12/15 00:26, Kim Barrett wrote: > I think we're all agreed that John's reinterpret_cast suggestion is > the way to go, but for the record, there happens to be a parallel > discussion of the union trick occurring on another mailing list I'm > on. It's reported there that C11 allows the union trick. Also > reported that discussion within the C++ committee has deemed it a > bad idea for C++, and that there exist compilers which generate > "bogus" code for the union trick, though no details were given. So, what we have here is a portability problem between C and C++. I'm surprised, to be honest, because I thought that the TCs were getting together to try to reduce the divergence. Especially in this case, given that the union trick is common practice, it makes no sense to have such a difference. I'm sure the authors of such compilers are not helping their users at all. Andrew. From aph at redhat.com Thu Dec 17 10:31:21 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 17 Dec 2015 10:31:21 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: References: <56697E62.9030306@redhat.com> <56702E47.9090003@redhat.com> Message-ID: <56728EF9.6050300@redhat.com> On 17/12/15 01:07, Kim Barrett wrote: > On Dec 15, 2015, at 10:14 AM, Andrew Haley wrote: >> >> On 12/10/2015 09:44 PM, Kim Barrett wrote: >>> src/os/posix/vm/os_posix.cpp >>> 756 unsigned int i; >>> >>> I'm not sure what the purpose of changing this to unsigned might be. >>> The sa_flags member of struct sigaction is of type int. >> >> There are assignments into this field that overflow: SA_RESETHAND >> (0x80000000) is implicitly unsigned, so assigning it to an int field >> is at best implementation-define. I suppose that this is really a bug >> in the Linux headers. I'll take it out. > > Ick, that's really annoying. It does seem like a bug in the Linux > headers, with a poorly chosen value for SA_RESETHAND. Or in POSIX, > for using a signed type for a bitmask. I suppose asking you to fix > this root cause would be a bit much. ;-) We have to work with old kernels, so it wouldn't help for a while. > Now that I understand it, and given its very localized scope, I would > be fine with the original change to unsigned. That would prevent > future verification/analysis from tripping over the same problem. My > only concern is that someone reading this who is familiar with POSIX > might wonder why an unsigned type is being used; maybe a brief comment? > Up to you. OK. >>> 136 return (double)(method->rate() + 1) * ((double)(method->invocation_count() + 1) * (method->backedge_count() + 1)); >>> >>> I suspect the problem encountered here is that the multiplication of >>> the two count values can overflow. If that multiplication was not >>> grouped, but instead the rate term and invocation count were >>> multiplied, then multiplied by the backedge count (e.g. use the >>> natural grouping for operator*), the result should be mathematically >>> the same, and I think should not run into overflow problems. Recall >>> that method->rate() returns float. >> >> I guess this would be okay, but it seems prudent to use a double. Is >> there some special performance optimization we have to care about? >> The return type of AdvancedThresholdPolicy::weight() is double, so >> I really can't think of any good reason not to do the arithmetic as >> double. >>> >>> So I think a simpler change here might be >>> >>> return (method->rate() + 1) * (method->invocation_count() + 1) * (method->backedge_count() + 1); >>> >>> i.e. remove the parens that group the count multiplication before >>> multiplying by the rate. > > The only use of weight() is about 10 lines later in the same file, in > compare_methods. It seems unlikely that the extra bits of precision > from computing in double vs float is going to matter in any > interesting way there. Certainly it can't be worse than the > "substantially noise" version we've been using! I'm trying not to break anything. It's not precision I'm worried about, it's overflow. I assumed that the double return type was there for a reason, given that the existing code very carefully casts to a double. If you tell me that there is no reason for that cast I'll happily do the whole function as float. > I've now looked at the opto changes too. They mostly look ok to me. > > ------------------------------------------------------------------------------ > src/share/vm/opto/mulnode.cpp > 805 const jlong bits_mask = java_subtract((jlong)CONST64(1) << (jlong)(BitsPerJavaLong - con), CONST64(1)); > > Overflow in a left shift of a signed value is UB. Argh. I am aware of that, but IMVHO it's a rather pedantic rule: it disallows simple and obvious expressions such as -16 << 2. (What for? Sign-and-absolute-magnitude machines?) However, them's the rules, I guess. I'm sure that it makes no sense ever to construct bitmasks using a signed type. I am doing my best to be certain that I don't break anything. I'll have a look to see if there is some way that I can change this to unsigned without changing behaviour. Andrew. From aph at redhat.com Thu Dec 17 10:52:24 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 17 Dec 2015 10:52:24 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <56728EF9.6050300@redhat.com> References: <56697E62.9030306@redhat.com> <56702E47.9090003@redhat.com> <56728EF9.6050300@redhat.com> Message-ID: <567293E8.8060007@redhat.com> Re left shifts of negative numbers: There are many of these in HotSpot, and fixing them all is a much larger change, and much more risky. Do you mind if this is done with a separate patch? Andrew. From christian.tornqvist at oracle.com Thu Dec 17 12:08:41 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 17 Dec 2015 07:08:41 -0500 Subject: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes In-Reply-To: <567270DC.1040701@oracle.com> References: <1cddb01d13827$2bb383c0$831a8b40$@oracle.com> <567270DC.1040701@oracle.com> Message-ID: <1d11c01d138c3$abd90600$038b1200$@oracle.com> Hi Magnus, Good catch, didn't read the version string as closely as I thought I did. I changed the opt part to not include the debug_level either, now the version string looks like this: Java HotSpot(TM) 64-Bit Client VM (fastdebug build 9-internal+0-christian.vsbuild, mixed mode) Please see the new webrev at: http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.01/ Thanks, Christian -----Original Message----- From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] Sent: Thursday, December 17, 2015 3:23 AM To: Christian Tornqvist ; hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes On 2015-12-16 18:28, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this change that updates ProjectCreator to work with the > new version string change in JEP 223. Tested the change locally, had > to use a workaround for the issue described in JDK-8144716. > > Also cleaned up some old build targets that are not needed anymore. > > > > This is how the version string looks like when building in VS: > > Debug: > > Java HotSpot(TM) 64-Bit Server VM (debug build > 9-internal+0.christian.vsbuild-debug, mixed mode) That does not look like a valid version string. '9-internal+0-.christian.vsbuild-debug' would be valid but strange-looking, '9-internal+0-christian.vsbuild-debug' would probably be better. Also note that the "opt" part of the version string does not contain "debug" any more in make builds. (But you are of course free to add anything to the opt string.) /Magnus > > Fastdebug: > > Java HotSpot(TM) 64-Bit Server VM (fastdebug build > 9-internal+0.christian.vsbuild-fastdebug, mixed mode) > > Product: > > Java HotSpot(TM) 64-Bit Server VM (product build > 9-internal+0.christian.vsbuild, mixed mode) > > > > Using make system > > Fastdebug: > > Java HotSpot(TM) 64-Bit Server VM (fastdebug build > 9-internal+0-2015-12-16-120539.christian.jdk9-rt, mixed mode) > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.00/ > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8145400 > > > > Thanks, > > Christian > From christian.tornqvist at oracle.com Thu Dec 17 12:09:46 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 17 Dec 2015 07:09:46 -0500 Subject: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes In-Reply-To: References: <1cddb01d13827$2bb383c0$831a8b40$@oracle.com> Message-ID: <1d11e01d138c3$d2705390$7750fab0$@oracle.com> Hi Markus, As per our offline discussion, I put back compiler1 for 64bit targets. Please see the new webrev at: http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.01/ Thanks, Christian -----Original Message----- From: Markus Gronlund [mailto:markus.gronlund at oracle.com] Sent: Wednesday, December 16, 2015 1:47 PM To: Christian Tornqvist Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes Hi Christian, Thanks for taking this on. Could you please retain the build targets please? I use debug C2 on my win32 laptop as a matter of course. There is no need to limit the amount of build targets, it allows for flexibility. Thanks Markus -----Original Message----- From: Christian Tornqvist Sent: den 16 december 2015 18:28 To: hotspot-dev at openjdk.java.net Subject: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes Hi everyone, Please review this change that updates ProjectCreator to work with the new version string change in JEP 223. Tested the change locally, had to use a workaround for the issue described in JDK-8144716. Also cleaned up some old build targets that are not needed anymore. This is how the version string looks like when building in VS: Debug: Java HotSpot(TM) 64-Bit Server VM (debug build 9-internal+0.christian.vsbuild-debug, mixed mode) Fastdebug: Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0.christian.vsbuild-fastdebug, mixed mode) Product: Java HotSpot(TM) 64-Bit Server VM (product build 9-internal+0.christian.vsbuild, mixed mode) Using make system Fastdebug: Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2015-12-16-120539.christian.jdk9-rt, mixed mode) Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8145400 Thanks, Christian From christian.tornqvist at oracle.com Thu Dec 17 12:13:49 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 17 Dec 2015 07:13:49 -0500 Subject: RFR(S): 8145603 - Enable build.bat to use vcproj to build In-Reply-To: <5671EE9B.7030503@oracle.com> References: <1cfa801d13853$d774c490$865e4db0$@oracle.com> <5671EE9B.7030503@oracle.com> Message-ID: <1d12001d138c4$635e1270$2a1a3750$@oracle.com> Hi Mikael, Thanks for the review, added a comment. Please see the updated webrev at: http://cr.openjdk.java.net/~ctornqvi/webrev/8145603/webrev.01/make/windows/b uild.bat.sdiff.html Thanks, Christian -----Original Message----- From: Mikael Vidstedt [mailto:mikael.vidstedt at oracle.com] Sent: Wednesday, December 16, 2015 6:07 PM To: Christian Tornqvist ; hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8145603 - Enable build.bat to use vcproj to build On 2015-12-16 14:48, Christian Tornqvist wrote: > Hi everyone, > > > > Build.bat has not been working correctly for a couple of years and is > now completely broken after the JDK Version change. Rewrote it to use > the Visual Studio project files instead, examples of use: > > > > make\windows\build.bat tiered fastdebug > > > > This will generate the vcproj files using create.bat (if they haven't > been generated before) and compile the JVM using msbuild. The whole > process takes about a minute on my machine and less than that if the > vcproj files are already there. > > > > Tested locally with x86 and x64 builds. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8145603/webrev.00/ > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8145603 Not being fluent in .bat I could use a helpful comment on what line 26 (set HotSpotWorkSpace) actually does. Apart from that it looks good! Cheers, Mikael From markus.gronlund at oracle.com Thu Dec 17 12:32:24 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 17 Dec 2015 04:32:24 -0800 (PST) Subject: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes In-Reply-To: <1d11e01d138c3$d2705390$7750fab0$@oracle.com> References: <1cddb01d13827$2bb383c0$831a8b40$@oracle.com> <1d11e01d138c3$d2705390$7750fab0$@oracle.com> Message-ID: <99bb349f-d443-42d8-9d50-807b9743612f@default> Hi again Christian, Thanks again for doing this! I think it looks good. /Markus -----Original Message----- From: Christian Tornqvist Sent: den 17 december 2015 13:10 To: Markus Gronlund Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes Hi Markus, As per our offline discussion, I put back compiler1 for 64bit targets. Please see the new webrev at: http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.01/ Thanks, Christian -----Original Message----- From: Markus Gronlund [mailto:markus.gronlund at oracle.com] Sent: Wednesday, December 16, 2015 1:47 PM To: Christian Tornqvist Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes Hi Christian, Thanks for taking this on. Could you please retain the build targets please? I use debug C2 on my win32 laptop as a matter of course. There is no need to limit the amount of build targets, it allows for flexibility. Thanks Markus -----Original Message----- From: Christian Tornqvist Sent: den 16 december 2015 18:28 To: hotspot-dev at openjdk.java.net Subject: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes Hi everyone, Please review this change that updates ProjectCreator to work with the new version string change in JEP 223. Tested the change locally, had to use a workaround for the issue described in JDK-8144716. Also cleaned up some old build targets that are not needed anymore. This is how the version string looks like when building in VS: Debug: Java HotSpot(TM) 64-Bit Server VM (debug build 9-internal+0.christian.vsbuild-debug, mixed mode) Fastdebug: Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0.christian.vsbuild-fastdebug, mixed mode) Product: Java HotSpot(TM) 64-Bit Server VM (product build 9-internal+0.christian.vsbuild, mixed mode) Using make system Fastdebug: Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2015-12-16-120539.christian.jdk9-rt, mixed mode) Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8145400 Thanks, Christian From markus.gronlund at oracle.com Thu Dec 17 12:35:48 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 17 Dec 2015 04:35:48 -0800 (PST) Subject: RFR(S): 8144716 - Unable to build in Visual Studio after JVMCI change In-Reply-To: <1cf4f01d1384c$11b26930$35173b90$@oracle.com> References: <1cf4f01d1384c$11b26930$35173b90$@oracle.com> Message-ID: <2516104b-d1a0-4456-b985-9262a6ccb088@default> Looks good, thanks for fixing. /Markus -----Original Message----- From: Christian Tornqvist Sent: den 16 december 2015 22:53 To: hotspot-dev at openjdk.java.net Subject: RFR(S): 8144716 - Unable to build in Visual Studio after JVMCI change Hi everyone, Please review this fix to ProjectCreator that fixes build issues in Visual Studio caused by the JVMCI change. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8144716/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8144716 Thanks, Christian From markus.gronlund at oracle.com Thu Dec 17 12:37:25 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 17 Dec 2015 04:37:25 -0800 (PST) Subject: RFR(S): 8145603 - Enable build.bat to use vcproj to build In-Reply-To: <1cfa801d13853$d774c490$865e4db0$@oracle.com> References: <1cfa801d13853$d774c490$865e4db0$@oracle.com> Message-ID: <390bb7f8-de24-4bbc-b8c3-ed02b6014fec@default> Looks good, thanks for fixing. /Markus -----Original Message----- From: Christian Tornqvist Sent: den 16 december 2015 23:48 To: hotspot-dev at openjdk.java.net Subject: RFR(S): 8145603 - Enable build.bat to use vcproj to build Hi everyone, Build.bat has not been working correctly for a couple of years and is now completely broken after the JDK Version change. Rewrote it to use the Visual Studio project files instead, examples of use: make\windows\build.bat tiered fastdebug This will generate the vcproj files using create.bat (if they haven't been generated before) and compile the JVM using msbuild. The whole process takes about a minute on my machine and less than that if the vcproj files are already there. Tested locally with x86 and x64 builds. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8145603/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8145603 Thanks, Christian From igor.ignatyev at oracle.com Thu Dec 17 13:22:28 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 17 Dec 2015 16:22:28 +0300 Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build In-Reply-To: References: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com> Message-ID: <5FB23711-1ED5-4ABB-8F1C-D6EEA551ED22@oracle.com> > On Dec 17, 2015, at 2:10 AM, Kim Barrett wrote: > > On Dec 16, 2015, at 5:54 PM, Igor Ignatyev wrote: >> >> as Mikael V correctly pointed out, there is missed $( ) in solaris/adlc. >> here is the new webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.01/ > > I wonder why the value for WARNINGS_ARE_ERRORS isn't obtained from the > configure-provided variable CFLAGS_WARNINGS_ARE_ERRORS? > E.g. something like > > WARNINGS_ARE_ERRORS ?= $(CFLAGS_WARNINGS_ARE_ERRORS) > > There may be a good reason for that, and thinking about it is probably > better done as a separate RFE. Doing so might simplify things by > allowing the assignment to be moved to some higher level common point. > [The bsd conditionalization on $(COMPILER_WARNINGS_FATAL) might make > that hard. Where does that variable come from? I haven't looked for > anything similar elsewhere.] > > ------------------------------------------------------------------------------ > make/solaris/makefiles/adlc.make > 77 WARNINGS_ARE_ERRORS ?= -w -xwe > > I'm pretty sure "-w" is wrong here, and should be removed. you are right, I made a typo, it was ?+w? before. the new webrev : http://cr.openjdk.java.net/~iignatyev/8144695/webrev.02/ > And it's > not clear why this assignment should be conditional on the compiler > version. it was added as a fix for https://bugs.openjdk.java.net/browse/JDK-6851829, excerpt from Chris?s evaluation: > Since some of the errors are in system headers we can only disable the "+w -errwarn" on SS11 and below. From aph at redhat.com Thu Dec 17 13:37:00 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 17 Dec 2015 13:37:00 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: References: <56697E62.9030306@redhat.com> <56702E47.9090003@redhat.com> Message-ID: <5672BA7C.3000700@redhat.com> OK. I think this change addresses all of your points. http://cr.openjdk.java.net/~aph/8145096-3 The complex (and incorrect) ((jlong)CONST64(1) << (jlong)(BitsPerJavaLong - con)) - CONST64(1); is merely a difficult way to write jlong((~ UCONST64(0)) >> con) Andrew. From doug.simon at oracle.com Thu Dec 17 13:56:45 2015 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 17 Dec 2015 14:56:45 +0100 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> Message-ID: <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> > On 17 Dec 2015, at 08:20, Tom Rodriguez wrote: > >>>> >>>> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? >>> >>> >>> There are two issues with java_lang_Throwable::print_stack_trace: >>> >>> 1. It doesn?t print the exception message, just the stack. >> >> I?m printing the message separately: >> >> java_lang_Throwable::print(exception, tty); >> tty->cr(); >> java_lang_Throwable::print_stack_trace(exception(), tty); > > There are already 3 other copies of this idiom. Throwable should probably have a single method for this. Or maybe print_stack_trace itself should do this? +1 > That would better parallel Throwable.printStackTrace(). Makes sense to me! -Doug From lois.foltan at oracle.com Thu Dec 17 14:06:21 2015 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 17 Dec 2015 09:06:21 -0500 Subject: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes In-Reply-To: <1d11c01d138c3$abd90600$038b1200$@oracle.com> References: <1cddb01d13827$2bb383c0$831a8b40$@oracle.com> <567270DC.1040701@oracle.com> <1d11c01d138c3$abd90600$038b1200$@oracle.com> Message-ID: <5672C15D.80409@oracle.com> I think the latest webrev looks good. Thanks for doing this Christian! Lois On 12/17/2015 7:08 AM, Christian Tornqvist wrote: > Hi Magnus, > > Good catch, didn't read the version string as closely as I thought I did. > I changed the opt part to not include the debug_level either, now the > version string looks like this: > > Java HotSpot(TM) 64-Bit Client VM (fastdebug build > 9-internal+0-christian.vsbuild, mixed mode) > > Please see the new webrev at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.01/ > > Thanks, > Christian > > -----Original Message----- > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > Sent: Thursday, December 17, 2015 3:23 AM > To: Christian Tornqvist ; > hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes > > On 2015-12-16 18:28, Christian Tornqvist wrote: >> Hi everyone, >> >> >> >> Please review this change that updates ProjectCreator to work with the >> new version string change in JEP 223. Tested the change locally, had >> to use a workaround for the issue described in JDK-8144716. >> >> Also cleaned up some old build targets that are not needed anymore. >> >> >> >> This is how the version string looks like when building in VS: >> >> Debug: >> >> Java HotSpot(TM) 64-Bit Server VM (debug build >> 9-internal+0.christian.vsbuild-debug, mixed mode) > That does not look like a valid version string. > '9-internal+0-.christian.vsbuild-debug' would be valid but strange-looking, > '9-internal+0-christian.vsbuild-debug' would probably be better. Also note > that the "opt" part of the version string does not contain "debug" any more > in make builds. (But you are of course free to add anything to the opt > string.) > > /Magnus > >> Fastdebug: >> >> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >> 9-internal+0.christian.vsbuild-fastdebug, mixed mode) >> >> Product: >> >> Java HotSpot(TM) 64-Bit Server VM (product build >> 9-internal+0.christian.vsbuild, mixed mode) >> >> >> >> Using make system >> >> Fastdebug: >> >> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >> 9-internal+0-2015-12-16-120539.christian.jdk9-rt, mixed mode) >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.00/ >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8145400 >> >> >> >> Thanks, >> >> Christian >> > From mikael.gerdin at oracle.com Thu Dec 17 14:29:40 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 17 Dec 2015 15:29:40 +0100 Subject: Moving the _vtable_len into Klass In-Reply-To: References: <567150E5.9060308@oracle.com> <56719EB0.6030504@oracle.com> Message-ID: <5672C6D4.4020509@oracle.com> Hi John, On 2015-12-16 21:48, John Rose wrote: > On Dec 16, 2015, at 9:26 AM, Chris Plummer > wrote: >> >>> Does anyone know if there is a reason for vtable_length_offset to be >>> a word offset? >> Sorry, I don't have any historical perspective here, other than saying >> that specifying size, lengths, and offsets for InstanceKlass related >> stuff seems to all be scaled to HeapWordSize. Just started looking in >> this area recently for the first time myself. BTW, I think it should >> be using wordSize instead of HeapWordSize, although they do both >> evaluate to the same thing. > > Basic facts: > > InstanceKlass and ArrayKlass are the only subclasses of Klass. > Java objects can be instances or arrays, and both have v-tables. > Array v-tables have uninteresting Object methods (only clone is special). > In the A2.0 future, Array v-tables will (probably) have additional methods. > Therefore the property of having a v-table is universal to all Klasses. > Therefore this is a good refactoring. Good, thanks. > > Here are some bits of ancient history, plus thoughts on scaled sizes: > > In the old days (metadata in perm-gen) some Klasses (method-klass, > instance-klass-klass, etc.) did *not* have v-tables. > > The necessary alignment of v-table position between InstanceKlass and > ArrayKlass had to be forced by a hack. We have inherited this hack, > but should get rid of it. > > The original sizing logic for HotSpot was designed for 32-bit machines. > Using 32-bit integers, sizing logic for some Java data structures is subject > to embarrassing overflows. (Consider `new long[0x7FFFFFFE]`.) > > Even size_t (which is unsigned) doesn't quite have enough bits of > dynamic range. And size_t itself was new (not so portable) when > HotSpot was first written. Also, 64-bit integer arithmetic was more > expensive in those days, on some platforms, so the original coders > did not resort to uint64_t for sizing calculations. > > By working with ints scaled by wordSize (== sizeof(HeapWord)), > we bought a couple more bits of dynamic range, to avoid overflows > more easily. Having 32-bit ints stored in metadata is also a little > more compact, although this sometimes comes with a risk of > truncation when large values pass through small storage fields. I appreciate that word sizes are useful and sometimes necessary on 32 bit platforms but I think that offsets of fields inside structs should never be so large as to require wordSize scaling. > > Today's trade-offs: > > Nowadays, it would be reasonable to use unscaled sizes almost > everywhere, passed as uint64_t values, and stored smaller > where possible (using scaling or var-ints or whatever, as a > local decision). > > (BTW, I think we should use more UNSIGNED5 var-ints for > metadata sizes, to save footprint and provide safer dynamic range.) > > Even from the beginning, the JVM used a mix of scaled > and unscaled size values, although there was an attempt > to make the scaled ones predominate. At some point > we tried to introduce some static typing help to avoid > the obvious sort of bugs; see classes ByteSize and > WordSize. These are helpful but also not universal. > So we have a mix of conventions, not always clearly > sorted out. The complexity and bug-worthiness of > this setup is the biggest down-side to scaled size logic. > > An up-side of having scaled sizes is you get 2-3 more bits > of dynamic range. A down-side of having scaled sizes is > you have to decode scaled values by shifting them 2-3 bits. > Sometimes x86 addressing modes help make this decoding > happen "for free" as part of an address formation operation, > but in practice I think this happens unreliably. > > (Using a tighter encoding like UNSIGNED5 could decode > about as quickly as an explicit shift, but gain more footprint > benefits. But that's a future conversation.) > > I personally don't regard the up-sides for scaled sizes as > sufficient, now that 64-bit math is perfectly cheap. > It will be will be hard to change to unscaled sizes everywhere, > (and I've surely not given the full arguments both ways!) > so we will be living in a mixed world for the foreseeable > future. I do think, however, that it is reasonable to remove > scaled sizes from JVM internal APIs, incrementally over time. > > Bottom line: My suggestion is that you make Klass admit > that it always has a v-table, and don't feel bad about using > unscaled sizes appearing in the JVM internal APIs, as long > as you control footprint inside each class. Thanks for the detailed background info, John. My current plan is to first modify the vtable_length_offset accessor to return a byte offset (which is what it's translated to by all callers). Then I'll tackle moving the _vtable_len field to Klass. Finally I'll try to consolidate the vtable related methods to Klass, where they belong. The vtable_start_offset is a slightly more difficult beast since it's more often used in wordSize scaled calculations, my current idea is to leave it alone for now. Does that sound like a good plan? /Mikael > > ? John From paul.sandoz at oracle.com Thu Dec 17 15:07:22 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Dec 2015 16:07:22 +0100 Subject: Vectorized array mismatch updates Message-ID: <247E5E23-8037-4B33-BE84-4BABAD1EAE7D@oracle.com> Hi, The vectorized array mismatch implementation is now fully wired up to Arrays.equals/compare/mismatch in hs-comp and the intrinsic kicks in on x86 for C2. There are a bunch of follow up tasks that need to be done (where appropriate i will log issues): 1) wiring up the vectorizedMismatch intrinsic stub in C1 on x86; 2) implementing the vectorizedMismatch intrinsic on other platforms, such Sparc and ARM (volunteers? the work is likely similar to that for compact string equality/comparison); and 3) from performance data cleaning up edge cases to reduce or ensure no regressions. With regards to 3) i have uploaded a JMH benchmark project and raw results for: - two x86 platforms supporting UseAVX=1 (AVX_1) and UseAVX=2 (AVX_2) respectively (thus AVX_1 and AVX_2 results are not directly comparable) - C2 (-XX:-UseVectorizedMismatchIntrinsic as ?Unsafe", and -XX:+UseVectorizedMismatchIntrinsic as ?Vectorized") - C1 (as ?Unsafe", implicitly -XX:-UseVectorizedMismatchIntrinsic since there is no intrinsic yet for C1) - comparing byte[] and long[] - small (1..16) and large (2^2..12) array lengths where the content of two arrays are the same, or the last element differs (lastNEQ=false/true). http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/perf/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/perf/results/AVX_1/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/perf/results/AVX_2/ Observations so far: (Note for byte[] the vectorizedMismatch does not kick in for an array length < 8). - byte[], AVX_1, C2 - No regressions for small arrays, good improvements for large arrays - For large arrays the Vectorized performance is marginally better than the Unsafe performance. I expect the gap to close once Roland?s fix for JDK-8145322 is pushed (which creates more efficient address computation for unrolled Unsafe access loops) - long[], AVX_1, C2 - For small arrays there are some regressions both for Vectorized and Unsafe - For large arrays there are some regressions both for Vectorized and Unsafe. For Unsafe this is due to JDK-8145322. For Vectorized there is some variance that might be due to unlucky alignment of quadwords. - Further investigation is required: e.g. have a threshold when vectorizedMismatch kicks in or we somehow disable Unsafe and/or Vectorized for UseAVX=1, if we can surface constants of vectorization/register widths etc. in a platform independent manner. - byte[], AVX_2, C2 - For small arrays with Unsafe a small regression is observed at lengths of 11 and 15 when the contents of the arrays are equal. This seems like a blip, but might be due to some odd code generation. - For small arrays with Vectorized there is no regression. - For large arrays performance is good, with Vectorized ~ 2x Unsafe once the length gets large enough (256/512 or larger) This translates into an ~10x improvement compared to an ordinary loop. - long[], AVX_2, C2 - For small arrays there are some regressions, like for AVX_1 - For large arrays AVX_2 starts to show a 1.5x improvement. Again some variance is observable, perhaps due to unlucky alignment. - byte[]. AVX_1/2, C1 (Note only Unsafe results are available) - For small arrays there are small regressions for < 8 probably due to the length check and branch to the ordinary loop. Not sure if there is much that can be done about. - For large arrays the performance boost is good and can be much better if made intrinsic, e.g. ~5x to 8x - long[]. AVX_1/2, C1 (Note only Unsafe results are available) - For small and large arrays there are noticeable regressions. A C1 intrinsic should improve things. Thanks, Paul. From george.triantafillou at oracle.com Thu Dec 17 15:48:53 2015 From: george.triantafillou at oracle.com (George Triantafillou) Date: Thu, 17 Dec 2015 10:48:53 -0500 Subject: RFR(S): 8145603 - Enable build.bat to use vcproj to build In-Reply-To: <1d12001d138c4$635e1270$2a1a3750$@oracle.com> References: <1cfa801d13853$d774c490$865e4db0$@oracle.com> <5671EE9B.7030503@oracle.com> <1d12001d138c4$635e1270$2a1a3750$@oracle.com> Message-ID: <5672D965.1030305@oracle.com> Hi Christian, http://cr.openjdk.java.net/~ctornqvi/webrev/8145603/webrev.01/make/windows/build.bat.sdiff.html 26 REM Set HotSpotWorkSpace to the directy two steps above this script Change "directy" to "directory". Otherwise, it looks good. Thanks for fixing this. -George On 12/17/2015 7:13 AM, Christian Tornqvist wrote: > Hi Mikael, > > > Thanks for the review, added a comment. Please see the updated webrev at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8145603/webrev.01/make/windows/b > uild.bat.sdiff.html > > Thanks, > Christian > > -----Original Message----- > From: Mikael Vidstedt [mailto:mikael.vidstedt at oracle.com] > Sent: Wednesday, December 16, 2015 6:07 PM > To: Christian Tornqvist ; > hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8145603 - Enable build.bat to use vcproj to build > > > > > On 2015-12-16 14:48, Christian Tornqvist wrote: >> Hi everyone, >> >> >> >> Build.bat has not been working correctly for a couple of years and is >> now completely broken after the JDK Version change. Rewrote it to use >> the Visual Studio project files instead, examples of use: >> >> >> >> make\windows\build.bat tiered fastdebug >> >> >> >> This will generate the vcproj files using create.bat (if they haven't >> been generated before) and compile the JVM using msbuild. The whole >> process takes about a minute on my machine and less than that if the >> vcproj files are already there. >> >> >> >> Tested locally with x86 and x64 builds. >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8145603/webrev.00/ >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8145603 > Not being fluent in .bat I could use a helpful comment on what line 26 (set > HotSpotWorkSpace) actually does. > > Apart from that it looks good! > > Cheers, > Mikael > > From daniel.daugherty at oracle.com Thu Dec 17 15:58:17 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Dec 2015 08:58:17 -0700 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <56727F3D.7090600@oracle.com> References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com> <5672046E.5@oracle.com> <56726A4D.5050600@oracle.com> <56726D95.20103@oracle.com> <56727F3D.7090600@oracle.com> Message-ID: <5672DB99.3070403@oracle.com> DEBUG_BINARIES is one of those "hidden" HotSpot big hammers that only affects Linux (IIRC). Basically, many years ago someone got tired of trying to figure out how to get completely debuggable HotSpot build on Linux and this big hammer was dropped in. I could chase down who and when, but I don't think that really matters... When I did FDS a few years back, I was asked to not break the semantics of DEBUG_BINARIES and so the big hammer was left in. Solaris is my primary dev platform and DEBUG_BINARIES doesn't work there so I didn't mind leaving in DEBUG_BINARIES for the Linux folks... Fast forward to today... I don't think the entire patch needs to be backed out. Not touching DEBUG_BINARIES via configure is a "good idea" (TM) because it is such a big hammer. I do recommend trying to deprecate the DEBUG_BINARIES setting in the big HotSpot Makefile rewrite... I'm very much looking forward to a cleaner HotSpot build... Dan On 12/17/15 2:24 AM, Erik Joelsson wrote: > > > On 2015-12-17 09:08, David Holmes wrote: >> On 17/12/2015 5:54 PM, Erik Joelsson wrote: >>> >>> >>> On 2015-12-17 01:40, David Holmes wrote: >>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote: >>>>> One more thing, where should this fix be pushed? Do you need it >>>>> urgently >>>>> in hs-rt? >>>> >>>> It is urgently needed in both the hs-rt and hs-comp repos as it >>>> affects nightly testing and JPRT. If Alejandro agrees I suggest >>>> pushing to jdk9/hs and it can then be pulled down to the team repos. >>>> >>> Will do. >>>> With regard to the fix ... previously DEBUG_BINARIES was never set in >>>> spec.gmk and so was never externally introduced into the hotspot build >>>> this way. So why not simply change the name of the variable so that it >>>> has no affect on the hotspot part of the build? >>>> >>> Well, we don't want it affecting the jdk part of the build either at >>> this point. This patch aims to restore the "external" and "zipped" >>> settings to exactly what they were before the patch, as was promised. >> >> I had not inferred from any of this that what was being done via >> NativeCompilation.gmk was in any way a problem. I would have expected >> any problems there to be readily seen before this was reviewed and >> pushed. So I'm a bit confused about this. >> > I didn't follow this particular review closely as Magnus was on it and > so I had missed the NativeCompilation part. It's true that it is very > unlikely to be part of the problem described in this bug, but I still > feel that the safest action at this point is to restore the behavior > of "external" and "zipped" to what they used to be. Magnus is working > on a complete fix where debug symbols will be enabled for everything > in NativeCompilation. >> I'm tempted to say rollback the whole thing rather than hack at it. >> > Rolling back will be much more work for me than submitting this patch. > There are two changes already that depend on this change. I also don't > dislike the idea of the new configure parameter. >> And apologies as I'm just about to go offline for a few hours at least. >> > I hope you won't object to me pushing this with just ihse as reviewer. > I feel this is rather a priority to get fixed. > > /Erik From kim.barrett at oracle.com Thu Dec 17 17:01:16 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 17 Dec 2015 12:01:16 -0500 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <567293E8.8060007@redhat.com> References: <56697E62.9030306@redhat.com> <56702E47.9090003@redhat.com> <56728EF9.6050300@redhat.com> <567293E8.8060007@redhat.com> Message-ID: <1E4548D7-BB09-49E5-BE98-06A8BE1D5237@oracle.com> On Dec 17, 2015, at 5:52 AM, Andrew Haley wrote: > > Re left shifts of negative numbers: > > There are many of these in HotSpot, and fixing them all is a much > larger change, and much more risky. Do you mind if this is done with > a separate patch? That?s fine. I wasn?t intending to greatly expand the scope of the current patch, only (possibly) address lines that were already being touched for other reasons. And reading ahead in the email thread, it looks like you?ve done that. From kim.barrett at oracle.com Thu Dec 17 17:13:01 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 17 Dec 2015 12:13:01 -0500 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <5672BA7C.3000700@redhat.com> References: <56697E62.9030306@redhat.com> <56702E47.9090003@redhat.com> <5672BA7C.3000700@redhat.com> Message-ID: <9BDAB29C-BC4B-464D-98BB-7D7AF2B8CF7B@oracle.com> On Dec 17, 2015, at 8:37 AM, Andrew Haley wrote: > > OK. I think this change addresses all of your points. > > http://cr.openjdk.java.net/~aph/8145096-3 > > The complex (and incorrect) > > ((jlong)CONST64(1) << (jlong)(BitsPerJavaLong - con)) - CONST64(1); > > is merely a difficult way to write > > jlong((~ UCONST64(0)) >> con) > > Andrew. Nice. There's another that looks like that here: src/share/vm/opto/mulnode.cpp 577 jlong t1_support = java_subtract(((jlong)1 << (1 + log2_long(t1->_hi))), (jlong)1); Everything else looks good. From mikael.vidstedt at oracle.com Thu Dec 17 17:27:09 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 17 Dec 2015 09:27:09 -0800 Subject: RFR(S): 8145603 - Enable build.bat to use vcproj to build In-Reply-To: <5672D965.1030305@oracle.com> References: <1cfa801d13853$d774c490$865e4db0$@oracle.com> <5671EE9B.7030503@oracle.com> <1d12001d138c4$635e1270$2a1a3750$@oracle.com> <5672D965.1030305@oracle.com> Message-ID: <5672F06D.7080606@oracle.com> Thanks for adding the comment. Still good! Cheers, Mikael On 2015-12-17 07:48, George Triantafillou wrote: > Hi Christian, > > http://cr.openjdk.java.net/~ctornqvi/webrev/8145603/webrev.01/make/windows/build.bat.sdiff.html > > > > 26 REM Set HotSpotWorkSpace to the directy two steps above this script > > Change "directy" to "directory". > > Otherwise, it looks good. Thanks for fixing this. > > -George > > On 12/17/2015 7:13 AM, Christian Tornqvist wrote: >> Hi Mikael, >> >> >> Thanks for the review, added a comment. Please see the updated webrev >> at: >> http://cr.openjdk.java.net/~ctornqvi/webrev/8145603/webrev.01/make/windows/b >> >> uild.bat.sdiff.html >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Mikael Vidstedt [mailto:mikael.vidstedt at oracle.com] >> Sent: Wednesday, December 16, 2015 6:07 PM >> To: Christian Tornqvist ; >> hotspot-dev at openjdk.java.net >> Subject: Re: RFR(S): 8145603 - Enable build.bat to use vcproj to build >> >> >> >> >> On 2015-12-16 14:48, Christian Tornqvist wrote: >>> Hi everyone, >>> >>> >>> Build.bat has not been working correctly for a couple of years and is >>> now completely broken after the JDK Version change. Rewrote it to use >>> the Visual Studio project files instead, examples of use: >>> >>> >>> make\windows\build.bat tiered fastdebug >>> >>> >>> This will generate the vcproj files using create.bat (if they haven't >>> been generated before) and compile the JVM using msbuild. The whole >>> process takes about a minute on my machine and less than that if the >>> vcproj files are already there. >>> >>> >>> Tested locally with x86 and x64 builds. >>> >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~ctornqvi/webrev/8145603/webrev.00/ >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8145603 >> Not being fluent in .bat I could use a helpful comment on what line >> 26 (set >> HotSpotWorkSpace) actually does. >> >> Apart from that it looks good! >> >> Cheers, >> Mikael >> >> > From christian.thalinger at oracle.com Thu Dec 17 17:29:31 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Dec 2015 07:29:31 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <56726E7B.2070006@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5670B659.7040000@oracle.com> <0FC1E0E8-8F34-4199-A2DF-3F6911211F08@oracle.com> <56726E7B.2070006@oracle.com> Message-ID: > On Dec 16, 2015, at 10:12 PM, David Holmes wrote: > > > > On 17/12/2015 3:45 AM, Christian Thalinger wrote: >> >>> On Dec 15, 2015, at 2:54 PM, David Holmes wrote: >>> >>> Hi Christian, >>> >>> os_posix.cpp: >>> >>> tl;dr: the new assert is wrong, don't add it. >>> >>> os::sleep has two paths: >>> >>> 1. interruptible sleeps >>> >>> This is the implementation of java.lang.Thread.sleep and should only be called by JavaThreads using that API (but see below) >>> >>> 2. non-interruptible sleep >>> >>> Used for 'incidental' sleeps within the VM, primarily by non-JavaThreads. If a JavaThread uses this it will delay safepoints, so the sleep should be very small. >>> >>> As you have discovered the Windows implementation of os::sleep actually asserts that JavaThreads don't take the second path. That's not correct. There are two existing cases where this will trigger today. >>> >>> The first is a historical usage of ConvertYieldToSleep: >>> >>> JVM_ENTRY(void, JVM_Yield(JNIEnv *env, jclass threadClass)) >>> JVMWrapper("JVM_Yield"); >>> if (os::dont_yield()) return; >>> HOTSPOT_THREAD_YIELD(); >>> >>> // When ConvertYieldToSleep is off (default), this matches the classic VM use of yield. >>> // Critical for similar threading behaviour >>> if (ConvertYieldToSleep) { >>> os::sleep(thread, MinSleepInterval, false); >>> } else { >>> os::naked_yield(); >>> } >>> JVM_END >>> >>> Then in JVM_Sleep itself: >>> >>> if (millis == 0) { >>> if (ConvertSleepToYield) { >>> os::naked_yield(); >>> } else { >>> ThreadState old_state = thread->osthread()->get_state(); >>> thread->osthread()->set_state(SLEEPING); >>> os::sleep(thread, MinSleepInterval, false); >>> thread->osthread()->set_state(old_state); >>> } >>> >>> This would also blow up on Windows - if ConvertSleepToYield is turned off (it is on by default on x86 - in fact all platforms except sparc - which really should be a Solaris setting as it will now affect the Linux/sparc port (which would then crash with your proposed additional assert in os_posix.cpp!). >>> >>> So adding the assert to os::sleep on Posix is not correct, and arguably the assertion should be removed from the windows code. >> >> I?ll let you guys take care of that. >> >>> >>> -- >>> >>> os_windows.cpp: >>> runtime/os.hpp" >>> >>> If you grep you will find about a 50-50 split between interruptible and interruptable through the codebase, so unless you want to file a cleanup bug to make it consistent I would just drop this change. >> >> It?s a cleanup and it?s already done but I?m not arguing for this. >> >>> >>> --- >>> >>> java.cpp >>> >>> It is not at all clear to me will be in a position to print the exception information correctly at this stage of the termination logic. I would argue that any errors during JVMCIRuntime::shutdown should be handled internally and logged using the logging mechanism, not via exceptions and exception printing. >> >> I disagree. We are shutting down the VM and while doing that we are running Java code. If the Java code throws an exception the user wants to see that exception. > > But it is not the user's Java code it is an internal implementation artifact. I have no doubt this is helping you with debugging JVMCI but I don't think it is the correct way to handle an internal JVMCI error during termination. Ditto for the use of the sleep mechanism. I?m not sure I understand. Are you saying that users should not see exceptions that are thrown from system code when the VM starts up and shuts down? That doesn?t make any sense. Also, remember that JVMCI is an experimental feature in 9. It is not turned on by default. > > David > ------ > >> >>> >>> --- >>> >>> src/share/vm/jvmci/jvmciCompiler.cpp >>> >>> typo: >>> >>> + // Give other aborting threads to also print their stack traces. >>> >>> should be: >>> >>> + // Give other aborting threads a chance to also print their stack traces. >>> >>> though I am dubious about the need for this and the use of the os::sleep that seemed to trigger this whole issue. Why aren't you using a normal vmError-based termination path for such fatal errors? >> >> As the comment says: >> >> + // This can be very useful when debugging class initialization >> + // failures. >> >> Since multiple compiler threads can initialize the JVMCI subsystem we need to print all of the exceptions to see the root cause. Doug would know more about this but that?s the gist. >> >>> >>> Cheers, >>> David >>> >>> On 16/12/2015 6:54 AM, Christian Thalinger wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8145435 >>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/ >>>> >>>> The actual fix for the problem is passing true to os::sleep: >>>> >>>> + const bool interruptible = true; >>>> + os::sleep(THREAD, 200, interruptible); >>>> >>>> since compiler threads are Java threads but I fixed a couple more things... >>>> >>>> First, I?ve added the same assert to os_posix.cpp: >>>> >>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/os/posix/vm/os_posix.cpp.udiff.html >>>> >>>> because it?s odd to only hit this assert on Windows: >>>> >>>> Additionally I?ve changed the way we handle an exception in before_exit: >>>> >>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html >>>> >>>> and moved abort_on_pending_exception into JVMCICompiler and made it private. It?s used for one thing only now. >>>> >>>> Finally I replaced JVMCIRuntime::call_printStackTrace with calls to java_lang_Throwable::print_stack_trace. From christian.thalinger at oracle.com Thu Dec 17 17:46:54 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Dec 2015 07:46:54 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> Message-ID: <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> > On Dec 17, 2015, at 3:56 AM, Doug Simon wrote: > >> >> On 17 Dec 2015, at 08:20, Tom Rodriguez wrote: >> >>>>> >>>>> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? >>>> >>>> >>>> There are two issues with java_lang_Throwable::print_stack_trace: >>>> >>>> 1. It doesn?t print the exception message, just the stack. >>> >>> I?m printing the message separately: >>> >>> java_lang_Throwable::print(exception, tty); >>> tty->cr(); >>> java_lang_Throwable::print_stack_trace(exception(), tty); >> >> There are already 3 other copies of this idiom. Throwable should probably have a single method for this. Or maybe print_stack_trace itself should do this? > > +1 > >> That would better parallel Throwable.printStackTrace(). > > Makes sense to me! It does. Here it goes: http://cr.openjdk.java.net/~twisti/8145435/webrev.02/ I?ve made java_lang_Throwable::print_stack_trace to take a Handle instead of an oop and removed the unneeded copy of java_lang_Throwable::print. > > -Doug From aph at redhat.com Thu Dec 17 17:56:43 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 17 Dec 2015 17:56:43 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <9BDAB29C-BC4B-464D-98BB-7D7AF2B8CF7B@oracle.com> References: <56697E62.9030306@redhat.com> <56702E47.9090003@redhat.com> <5672BA7C.3000700@redhat.com> <9BDAB29C-BC4B-464D-98BB-7D7AF2B8CF7B@oracle.com> Message-ID: <5672F75B.50802@redhat.com> On 12/17/2015 05:13 PM, Kim Barrett wrote: > Nice. > > There's another that looks like that here: > src/share/vm/opto/mulnode.cpp > 577 jlong t1_support = java_subtract(((jlong)1 << (1 + log2_long(t1->_hi))), (jlong)1); > > Everything else looks good. Ah, I didn't want to touch that one. :-) Here's the original: jlong t1_support = ((jlong)1 << (1 + log2_long(t1->_hi))) - 1; I think that the equivalent is int type_bit_count = log2_long(t1->_hi) + 1; jlong t1_support = jlong((~ UCONST64(0)) >> (BitsPerJavaLong - type_bit_count)); I've broken it apart for clarity. However, I'm having trouble analysing this to prove that all the corner cases are correct. Andrew. From coleen.phillimore at oracle.com Thu Dec 17 18:02:33 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 17 Dec 2015 13:02:33 -0500 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> Message-ID: <5672F8B9.6040802@oracle.com> This looks like a good cleanup. thanks! Coleen On 12/17/15 12:46 PM, Christian Thalinger wrote: >> On Dec 17, 2015, at 3:56 AM, Doug Simon wrote: >> >>> On 17 Dec 2015, at 08:20, Tom Rodriguez wrote: >>> >>>>>> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? >>>>> >>>>> There are two issues with java_lang_Throwable::print_stack_trace: >>>>> >>>>> 1. It doesn?t print the exception message, just the stack. >>>> I?m printing the message separately: >>>> >>>> java_lang_Throwable::print(exception, tty); >>>> tty->cr(); >>>> java_lang_Throwable::print_stack_trace(exception(), tty); >>> There are already 3 other copies of this idiom. Throwable should probably have a single method for this. Or maybe print_stack_trace itself should do this? >> +1 >> >>> That would better parallel Throwable.printStackTrace(). >> Makes sense to me! > It does. Here it goes: > > http://cr.openjdk.java.net/~twisti/8145435/webrev.02/ > > I?ve made java_lang_Throwable::print_stack_trace to take a Handle instead of an oop and removed the unneeded copy of java_lang_Throwable::print. > >> -Doug From tom.rodriguez at oracle.com Thu Dec 17 18:28:05 2015 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 17 Dec 2015 10:28:05 -0800 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> Message-ID: <2AE2D2D0-87ED-4794-A50F-818C1B05A373@oracle.com> I think the ttyLocker should be in print_stack_trace. A short comment on print_stack_trace explaining that it prints the exception message along with the exception chain wouldn?t hurt. Otherwise looks good. tom > On Dec 17, 2015, at 9:46 AM, Christian Thalinger wrote: > >> >> On Dec 17, 2015, at 3:56 AM, Doug Simon > wrote: >> >>> >>> On 17 Dec 2015, at 08:20, Tom Rodriguez wrote: >>> >>>>>> >>>>>> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? >>>>> >>>>> >>>>> There are two issues with java_lang_Throwable::print_stack_trace: >>>>> >>>>> 1. It doesn?t print the exception message, just the stack. >>>> >>>> I?m printing the message separately: >>>> >>>> java_lang_Throwable::print(exception, tty); >>>> tty->cr(); >>>> java_lang_Throwable::print_stack_trace(exception(), tty); >>> >>> There are already 3 other copies of this idiom. Throwable should probably have a single method for this. Or maybe print_stack_trace itself should do this? >> >> +1 >> >>> That would better parallel Throwable.printStackTrace(). >> >> Makes sense to me! > > It does. Here it goes: > > http://cr.openjdk.java.net/~twisti/8145435/webrev.02/ > > I?ve made java_lang_Throwable::print_stack_trace to take a Handle instead of an oop and removed the unneeded copy of java_lang_Throwable::print. > >> >> -Doug From christian.thalinger at oracle.com Thu Dec 17 18:53:09 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Dec 2015 08:53:09 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <2AE2D2D0-87ED-4794-A50F-818C1B05A373@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> <2AE2D2D0-87ED-4794-A50F-818C1B05A373@oracle.com> Message-ID: <393F4221-839F-4BBE-8FBE-2BEF8E974BCB@oracle.com> > On Dec 17, 2015, at 8:28 AM, Tom Rodriguez wrote: > > I think the ttyLocker should be in print_stack_trace. Well, the problem is that ttyLocker only locks defaultStream::instance (whatever that is) but print_stack_trace can take any outputStream. > A short comment on print_stack_trace explaining that it prints the exception message along with the exception chain wouldn?t hurt. Otherwise looks good. Sure. > > tom > >> On Dec 17, 2015, at 9:46 AM, Christian Thalinger wrote: >> >>> >>> On Dec 17, 2015, at 3:56 AM, Doug Simon > wrote: >>> >>>> >>>> On 17 Dec 2015, at 08:20, Tom Rodriguez wrote: >>>> >>>>>>> >>>>>>> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? >>>>>> >>>>>> >>>>>> There are two issues with java_lang_Throwable::print_stack_trace: >>>>>> >>>>>> 1. It doesn?t print the exception message, just the stack. >>>>> >>>>> I?m printing the message separately: >>>>> >>>>> java_lang_Throwable::print(exception, tty); >>>>> tty->cr(); >>>>> java_lang_Throwable::print_stack_trace(exception(), tty); >>>> >>>> There are already 3 other copies of this idiom. Throwable should probably have a single method for this. Or maybe print_stack_trace itself should do this? >>> >>> +1 >>> >>>> That would better parallel Throwable.printStackTrace(). >>> >>> Makes sense to me! >> >> It does. Here it goes: >> >> http://cr.openjdk.java.net/~twisti/8145435/webrev.02/ >> >> I?ve made java_lang_Throwable::print_stack_trace to take a Handle instead of an oop and removed the unneeded copy of java_lang_Throwable::print. >> >>> >>> -Doug > From kim.barrett at oracle.com Thu Dec 17 18:58:19 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 17 Dec 2015 13:58:19 -0500 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <5672F75B.50802@redhat.com> References: <56697E62.9030306@redhat.com> <56702E47.9090003@redhat.com> <5672BA7C.3000700@redhat.com> <9BDAB29C-BC4B-464D-98BB-7D7AF2B8CF7B@oracle.com> <5672F75B.50802@redhat.com> Message-ID: <340D0241-C04C-4353-A995-054094989789@oracle.com> On Dec 17, 2015, at 12:56 PM, Andrew Haley wrote: > > On 12/17/2015 05:13 PM, Kim Barrett wrote: >> Nice. >> >> There's another that looks like that here: >> src/share/vm/opto/mulnode.cpp >> 577 jlong t1_support = java_subtract(((jlong)1 << (1 + log2_long(t1->_hi))), (jlong)1); >> >> Everything else looks good. > > Ah, I didn't want to touch that one. :-) > > Here's the original: > > jlong t1_support = ((jlong)1 << (1 + log2_long(t1->_hi))) - 1; > > I think that the equivalent is > > int type_bit_count = log2_long(t1->_hi) + 1; > jlong t1_support = jlong((~ UCONST64(0)) >> (BitsPerJavaLong - type_bit_count)); > > I've broken it apart for clarity. > > However, I'm having trouble analysing this to prove that all the > corner cases are correct. You?re right, this one looks messy. As far as I?m concerned, feel free to file an RFE for this one and call 8145096-3 done. From tom.rodriguez at oracle.com Thu Dec 17 19:03:31 2015 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 17 Dec 2015 11:03:31 -0800 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <393F4221-839F-4BBE-8FBE-2BEF8E974BCB@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> <2AE2D2D0-87ED-4794-A50F-818C1B05A373@oracle.com> <393F4221-839F-4BBE-8FBE-2BEF8E974BCB@oracle.com> Message-ID: <2E250702-A55C-43C0-B549-6E5D39A9DB4D@oracle.com> > On Dec 17, 2015, at 10:53 AM, Christian Thalinger wrote: > > >> On Dec 17, 2015, at 8:28 AM, Tom Rodriguez wrote: >> >> I think the ttyLocker should be in print_stack_trace. > > Well, the problem is that ttyLocker only locks defaultStream::instance (whatever that is) but print_stack_trace can take any outputStream. Well maybe it shouldn?t. No one uses that flexibility but having a ttyLocker would be practically useful. Anyway, it?s ok as is too. tom > >> A short comment on print_stack_trace explaining that it prints the exception message along with the exception chain wouldn?t hurt. Otherwise looks good. > > Sure. > >> >> tom >> >>> On Dec 17, 2015, at 9:46 AM, Christian Thalinger wrote: >>> >>>> >>>> On Dec 17, 2015, at 3:56 AM, Doug Simon > wrote: >>>> >>>>> >>>>> On 17 Dec 2015, at 08:20, Tom Rodriguez wrote: >>>>> >>>>>>>> >>>>>>>> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? >>>>>>> >>>>>>> >>>>>>> There are two issues with java_lang_Throwable::print_stack_trace: >>>>>>> >>>>>>> 1. It doesn?t print the exception message, just the stack. >>>>>> >>>>>> I?m printing the message separately: >>>>>> >>>>>> java_lang_Throwable::print(exception, tty); >>>>>> tty->cr(); >>>>>> java_lang_Throwable::print_stack_trace(exception(), tty); >>>>> >>>>> There are already 3 other copies of this idiom. Throwable should probably have a single method for this. Or maybe print_stack_trace itself should do this? >>>> >>>> +1 >>>> >>>>> That would better parallel Throwable.printStackTrace(). >>>> >>>> Makes sense to me! >>> >>> It does. Here it goes: >>> >>> http://cr.openjdk.java.net/~twisti/8145435/webrev.02/ >>> >>> I?ve made java_lang_Throwable::print_stack_trace to take a Handle instead of an oop and removed the unneeded copy of java_lang_Throwable::print. >>> >>>> >>>> -Doug >> > From christian.thalinger at oracle.com Thu Dec 17 19:08:40 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Dec 2015 09:08:40 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <2E250702-A55C-43C0-B549-6E5D39A9DB4D@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> <2AE2D2D0-87ED-4794-A50F-818C1B05A373@oracle.com> <393F4221-839F-4BBE-8FBE-2BEF8E974BCB@oracle.com> <2E250702-A55C-43C0-B549-6E5D39A9DB4D@oracle.com> Message-ID: > On Dec 17, 2015, at 9:03 AM, Tom Rodriguez wrote: > > >> On Dec 17, 2015, at 10:53 AM, Christian Thalinger wrote: >> >> >>> On Dec 17, 2015, at 8:28 AM, Tom Rodriguez wrote: >>> >>> I think the ttyLocker should be in print_stack_trace. >> >> Well, the problem is that ttyLocker only locks defaultStream::instance (whatever that is) but print_stack_trace can take any outputStream. > > Well maybe it shouldn?t. No one uses that flexibility but having a ttyLocker would be practically useful. True. I?m tempted to make that change but I see more bike-shedding coming up. Maybe if Coleen is okay with that? ;-) > Anyway, it?s ok as is too. > > tom > >> >>> A short comment on print_stack_trace explaining that it prints the exception message along with the exception chain wouldn?t hurt. Otherwise looks good. >> >> Sure. >> >>> >>> tom >>> >>>> On Dec 17, 2015, at 9:46 AM, Christian Thalinger wrote: >>>> >>>>> >>>>> On Dec 17, 2015, at 3:56 AM, Doug Simon > wrote: >>>>> >>>>>> >>>>>> On 17 Dec 2015, at 08:20, Tom Rodriguez wrote: >>>>>> >>>>>>>>> >>>>>>>>> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? >>>>>>>> >>>>>>>> >>>>>>>> There are two issues with java_lang_Throwable::print_stack_trace: >>>>>>>> >>>>>>>> 1. It doesn?t print the exception message, just the stack. >>>>>>> >>>>>>> I?m printing the message separately: >>>>>>> >>>>>>> java_lang_Throwable::print(exception, tty); >>>>>>> tty->cr(); >>>>>>> java_lang_Throwable::print_stack_trace(exception(), tty); >>>>>> >>>>>> There are already 3 other copies of this idiom. Throwable should probably have a single method for this. Or maybe print_stack_trace itself should do this? >>>>> >>>>> +1 >>>>> >>>>>> That would better parallel Throwable.printStackTrace(). >>>>> >>>>> Makes sense to me! >>>> >>>> It does. Here it goes: >>>> >>>> http://cr.openjdk.java.net/~twisti/8145435/webrev.02/ >>>> >>>> I?ve made java_lang_Throwable::print_stack_trace to take a Handle instead of an oop and removed the unneeded copy of java_lang_Throwable::print. >>>> >>>>> >>>>> -Doug >>> >> > From coleen.phillimore at oracle.com Thu Dec 17 19:17:34 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 17 Dec 2015 14:17:34 -0500 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> <2AE2D2D0-87ED-4794-A50F-818C1B05A373@oracle.com> <393F4221-839F-4BBE-8FBE-2BEF8E974BCB@oracle.com> <2E250702-A55C-43C0-B549-6E5D39A9DB4D@oracle.com> Message-ID: <56730A4E.3020204@oracle.com> On 12/17/15 2:08 PM, Christian Thalinger wrote: >> On Dec 17, 2015, at 9:03 AM, Tom Rodriguez wrote: >> >> >>> On Dec 17, 2015, at 10:53 AM, Christian Thalinger wrote: >>> >>> >>>> On Dec 17, 2015, at 8:28 AM, Tom Rodriguez wrote: >>>> >>>> I think the ttyLocker should be in print_stack_trace. >>> Well, the problem is that ttyLocker only locks defaultStream::instance (whatever that is) but print_stack_trace can take any outputStream. >> Well maybe it shouldn?t. No one uses that flexibility but having a ttyLocker would be practically useful. > True. I?m tempted to make that change but I see more bike-shedding coming up. Maybe if Coleen is okay with that? ;-) No, just leave it where it was.... With logging the ttyLocker doesn't work anyway. Coleen > >> Anyway, it?s ok as is too. >> >> tom >> >>>> A short comment on print_stack_trace explaining that it prints the exception message along with the exception chain wouldn?t hurt. Otherwise looks good. >>> Sure. >>> >>>> tom >>>> >>>>> On Dec 17, 2015, at 9:46 AM, Christian Thalinger wrote: >>>>> >>>>>> On Dec 17, 2015, at 3:56 AM, Doug Simon > wrote: >>>>>> >>>>>>> On 17 Dec 2015, at 08:20, Tom Rodriguez wrote: >>>>>>> >>>>>>>>>> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? >>>>>>>>> >>>>>>>>> There are two issues with java_lang_Throwable::print_stack_trace: >>>>>>>>> >>>>>>>>> 1. It doesn?t print the exception message, just the stack. >>>>>>>> I?m printing the message separately: >>>>>>>> >>>>>>>> java_lang_Throwable::print(exception, tty); >>>>>>>> tty->cr(); >>>>>>>> java_lang_Throwable::print_stack_trace(exception(), tty); >>>>>>> There are already 3 other copies of this idiom. Throwable should probably have a single method for this. Or maybe print_stack_trace itself should do this? >>>>>> +1 >>>>>> >>>>>>> That would better parallel Throwable.printStackTrace(). >>>>>> Makes sense to me! >>>>> It does. Here it goes: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev.02/ >>>>> >>>>> I?ve made java_lang_Throwable::print_stack_trace to take a Handle instead of an oop and removed the unneeded copy of java_lang_Throwable::print. >>>>> >>>>>> -Doug From kim.barrett at oracle.com Thu Dec 17 20:30:17 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 17 Dec 2015 15:30:17 -0500 Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build In-Reply-To: <5FB23711-1ED5-4ABB-8F1C-D6EEA551ED22@oracle.com> References: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com> <5FB23711-1ED5-4ABB-8F1C-D6EEA551ED22@oracle.com> Message-ID: <100FFD7C-1F76-4C17-BA8F-293C99F1B6C1@oracle.com> On Dec 17, 2015, at 8:22 AM, Igor Ignatyev wrote: > > >> On Dec 17, 2015, at 2:10 AM, Kim Barrett wrote: >> make/solaris/makefiles/adlc.make >> 77 WARNINGS_ARE_ERRORS ?= -w -xwe >> >> I'm pretty sure "-w" is wrong here, and should be removed. > you are right, I made a typo, it was ?+w? before. the new webrev : http://cr.openjdk.java.net/~iignatyev/8144695/webrev.02/ > >> And it's >> not clear why this assignment should be conditional on the compiler >> version. > it was added as a fix for https://bugs.openjdk.java.net/browse/JDK-6851829, excerpt from Chris?s evaluation: > >> Since some of the errors are in system headers we can only disable the "+w -errwarn" on SS11 and below. "+w" has nothing to do with warnings being errors; it just turns on more warnings. So it shouldn't be in WARNINGS_ARE_ERRORS. CFLAGS_WARN is (according to various comments) supposed to hold options to enable/disable warnings, so "+w" there was reasonable, while -errwarn should not have been there by that definition. The conditionalization disables additional warnings and "warnings are errors" for older compilers that I think we're no longer using for jdk9. Are we allowed to retire support for such? The conditionalization may only be needed for "+w", though without testing on a no longer officially supported version of the compiler that would be hard to prove. From david.holmes at oracle.com Thu Dec 17 21:24:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Dec 2015 07:24:43 +1000 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <56726FE1.6020906@oracle.com> References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com> <5672046E.5@oracle.com> <56726A4D.5050600@oracle.com> <56726D95.20103@oracle.com> <56726FE1.6020906@oracle.com> Message-ID: <5673281B.8000800@oracle.com> On 17/12/2015 6:18 PM, Magnus Ihse Bursie wrote: > On 2015-12-17 09:08, David Holmes wrote: >> On 17/12/2015 5:54 PM, Erik Joelsson wrote: >>> >>> >>> On 2015-12-17 01:40, David Holmes wrote: >>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote: >>>>> One more thing, where should this fix be pushed? Do you need it >>>>> urgently >>>>> in hs-rt? >>>> >>>> It is urgently needed in both the hs-rt and hs-comp repos as it >>>> affects nightly testing and JPRT. If Alejandro agrees I suggest >>>> pushing to jdk9/hs and it can then be pulled down to the team repos. >>>> >>> Will do. >>>> With regard to the fix ... previously DEBUG_BINARIES was never set in >>>> spec.gmk and so was never externally introduced into the hotspot build >>>> this way. So why not simply change the name of the variable so that it >>>> has no affect on the hotspot part of the build? >>>> >>> Well, we don't want it affecting the jdk part of the build either at >>> this point. This patch aims to restore the "external" and "zipped" >>> settings to exactly what they were before the patch, as was promised. >> >> I had not inferred from any of this that what was being done via >> NativeCompilation.gmk was in any way a problem. I would have expected >> any problems there to be readily seen before this was reviewed and >> pushed. So I'm a bit confused about this. > > The changes in NativeCompilation.gmk looked perfectly fine. They turned > out to trigger a bug (or, at the very least, very unsuspected behavior) > which was deeply hidden in the hotspot linux makefiles, where setting > DEBUG_BINARIES did indeed enable the -g flag, but also, as a side > effect, turned fastdebug builds into slowdebug builds. This was not > something that we could possibly forsee. That was my understanding too - that this was simply a side-effect on hotspot, hence my suggestion to rename the variable. But Erik then said this was also not working correctly for the JDK side - which means the problem is far worse. David ----- >> >> I'm tempted to say rollback the whole thing rather than hack at it. > > I don't think there is any compelling reason to rollback the whole > change. The basic idea is sound. However, we do need to work on how to > handle the debug symbols "under the hood". This deficit has been known > for a long time to me and Erik but we have not spent any time on it. > This change brought the problems up to daylight, and I think that's a > good thing. > > I've started working on JDK-8145596, which will provide a proper > solution to how we handle debug symbols. It is based on JDK-8036003. > > /Magnus > > >> >> And apologies as I'm just about to go offline for a few hours at least. >> >> David >> ----- >> >> >> >>> We will followup with a more complete fix. >>> >>> /Erik >>>> Thanks, >>>> David >>>> >>>>> /Erik >>>>> >>>>> On 2015-12-16 22:34, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this quick fix for the build issue introduced in >>>>>> Hotspot >>>>>> by JDK-8036003. The short story is that if you set >>>>>> DEBUG_BINARIES=true >>>>>> when building Hotspot fastdebug, you essentially get a slowdebug >>>>>> build. For an explanation of why, see comment in bug. This >>>>>> behavior is >>>>>> of course also a bug, but not something I will address in this quick >>>>>> fix. >>>>>> >>>>>> What happened in JDK-8036003 was that a new configure API for >>>>>> controlling debug symbols was introduced. The two main settings of >>>>>> this new parameter, --with-native-debug-symbols, that we use >>>>>> internally at Oracle are "external" and "zipped". It was important to >>>>>> us that the behavior of these did not change with JDK-8036003, but >>>>>> exactly that did happen, because both of these settings now cause >>>>>> DEBUG_BINARIES=true to be set. This variable has never been set by >>>>>> configure before and because of the above weird behavior in the >>>>>> Hotspot makefiles, we are having problems. >>>>>> >>>>>> My proposed quick fix is to not set DEBUG_BINARIES=true for >>>>>> "external" >>>>>> or "zipped". It can remain true for "internal" since Oracle never >>>>>> builds it that way, and I understand those that requested this new >>>>>> configure parameter were setting DEBUG_BINARIES=true as a workaround >>>>>> before this anyway, so they should be fine with the broken fastdebug >>>>>> behavior for a while more. I will file a follow up bug to properly >>>>>> clean up this mess, but it will take some more time. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 >>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ >>>>>> >>>>>> /Erik >>>>> >>> > From david.holmes at oracle.com Thu Dec 17 21:32:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Dec 2015 07:32:00 +1000 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <56727F3D.7090600@oracle.com> References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com> <5672046E.5@oracle.com> <56726A4D.5050600@oracle.com> <56726D95.20103@oracle.com> <56727F3D.7090600@oracle.com> Message-ID: <567329D0.8010303@oracle.com> On 17/12/2015 7:24 PM, Erik Joelsson wrote: > On 2015-12-17 09:08, David Holmes wrote: >> On 17/12/2015 5:54 PM, Erik Joelsson wrote: >>> >>> >>> On 2015-12-17 01:40, David Holmes wrote: >>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote: >>>>> One more thing, where should this fix be pushed? Do you need it >>>>> urgently >>>>> in hs-rt? >>>> >>>> It is urgently needed in both the hs-rt and hs-comp repos as it >>>> affects nightly testing and JPRT. If Alejandro agrees I suggest >>>> pushing to jdk9/hs and it can then be pulled down to the team repos. >>>> >>> Will do. >>>> With regard to the fix ... previously DEBUG_BINARIES was never set in >>>> spec.gmk and so was never externally introduced into the hotspot build >>>> this way. So why not simply change the name of the variable so that it >>>> has no affect on the hotspot part of the build? >>>> >>> Well, we don't want it affecting the jdk part of the build either at >>> this point. This patch aims to restore the "external" and "zipped" >>> settings to exactly what they were before the patch, as was promised. >> >> I had not inferred from any of this that what was being done via >> NativeCompilation.gmk was in any way a problem. I would have expected >> any problems there to be readily seen before this was reviewed and >> pushed. So I'm a bit confused about this. >> > I didn't follow this particular review closely as Magnus was on it and > so I had missed the NativeCompilation part. It's true that it is very > unlikely to be part of the problem described in this bug, but I still > feel that the safest action at this point is to restore the behavior of > "external" and "zipped" to what they used to be. My concern is recognizing that these adjustments do in fact restore the old behaviour. From the hotspot side it seemed cleaner to avoid the breakage by using a different variable name. > Magnus is working on a > complete fix where debug symbols will be enabled for everything in > NativeCompilation. >> I'm tempted to say rollback the whole thing rather than hack at it. >> > Rolling back will be much more work for me than submitting this patch. > There are two changes already that depend on this change. I also don't > dislike the idea of the new configure parameter. Rolling back the new configure parameters and then reinstating them again would also not win us any friends as it would be very disruptive. As others have noted the way we introduce and remove configure parameters needs to be looked at. I was mainly concerned that the out-of-the-box default behaviour was unchanged. >> And apologies as I'm just about to go offline for a few hours at least. >> > I hope you won't object to me pushing this with just ihse as reviewer. I > feel this is rather a priority to get fixed. Sure. I had verified that DEBUG_BINARIES is only ever tested against "true" so setting it to false should be as effective as not setting it at all. I'll follow up separately to see where this was pushed and whether we need to pull it into anywhere else urgently. Thanks, David > /Erik From david.holmes at oracle.com Thu Dec 17 21:33:41 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Dec 2015 07:33:41 +1000 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <5672DB99.3070403@oracle.com> References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com> <5672046E.5@oracle.com> <56726A4D.5050600@oracle.com> <56726D95.20103@oracle.com> <56727F3D.7090600@oracle.com> <5672DB99.3070403@oracle.com> Message-ID: <56732A35.5030505@oracle.com> On 18/12/2015 1:58 AM, Daniel D. Daugherty wrote: > DEBUG_BINARIES is one of those "hidden" HotSpot big hammers that only > affects Linux (IIRC). Basically, many years ago someone got tired of > trying to figure out how to get completely debuggable HotSpot build > on Linux and this big hammer was dropped in. I could chase down who > and when, but I don't think that really matters... Unfortunately it also got "cloned" into BSD and AIX ports. Thanks for the additional info. David ----- > When I did FDS a few years back, I was asked to not break the semantics > of DEBUG_BINARIES and so the big hammer was left in. Solaris is my > primary dev platform and DEBUG_BINARIES doesn't work there so I didn't > mind leaving in DEBUG_BINARIES for the Linux folks... > > Fast forward to today... I don't think the entire patch needs to be > backed out. Not touching DEBUG_BINARIES via configure is a "good idea" > (TM) because it is such a big hammer. I do recommend trying to deprecate > the DEBUG_BINARIES setting in the big HotSpot Makefile rewrite... > > I'm very much looking forward to a cleaner HotSpot build... > > Dan > > > On 12/17/15 2:24 AM, Erik Joelsson wrote: >> >> >> On 2015-12-17 09:08, David Holmes wrote: >>> On 17/12/2015 5:54 PM, Erik Joelsson wrote: >>>> >>>> >>>> On 2015-12-17 01:40, David Holmes wrote: >>>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote: >>>>>> One more thing, where should this fix be pushed? Do you need it >>>>>> urgently >>>>>> in hs-rt? >>>>> >>>>> It is urgently needed in both the hs-rt and hs-comp repos as it >>>>> affects nightly testing and JPRT. If Alejandro agrees I suggest >>>>> pushing to jdk9/hs and it can then be pulled down to the team repos. >>>>> >>>> Will do. >>>>> With regard to the fix ... previously DEBUG_BINARIES was never set in >>>>> spec.gmk and so was never externally introduced into the hotspot build >>>>> this way. So why not simply change the name of the variable so that it >>>>> has no affect on the hotspot part of the build? >>>>> >>>> Well, we don't want it affecting the jdk part of the build either at >>>> this point. This patch aims to restore the "external" and "zipped" >>>> settings to exactly what they were before the patch, as was promised. >>> >>> I had not inferred from any of this that what was being done via >>> NativeCompilation.gmk was in any way a problem. I would have expected >>> any problems there to be readily seen before this was reviewed and >>> pushed. So I'm a bit confused about this. >>> >> I didn't follow this particular review closely as Magnus was on it and >> so I had missed the NativeCompilation part. It's true that it is very >> unlikely to be part of the problem described in this bug, but I still >> feel that the safest action at this point is to restore the behavior >> of "external" and "zipped" to what they used to be. Magnus is working >> on a complete fix where debug symbols will be enabled for everything >> in NativeCompilation. >>> I'm tempted to say rollback the whole thing rather than hack at it. >>> >> Rolling back will be much more work for me than submitting this patch. >> There are two changes already that depend on this change. I also don't >> dislike the idea of the new configure parameter. >>> And apologies as I'm just about to go offline for a few hours at least. >>> >> I hope you won't object to me pushing this with just ihse as reviewer. >> I feel this is rather a priority to get fixed. >> >> /Erik > From david.holmes at oracle.com Fri Dec 18 04:37:40 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Dec 2015 14:37:40 +1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5670B659.7040000@oracle.com> <0FC1E0E8-8F34-4199-A2DF-3F6911211F08@oracle.com> <56726E7B.2070006@oracle.com> Message-ID: <56738D94.30107@oracle.com> On 18/12/2015 3:29 AM, Christian Thalinger wrote: > >> On Dec 16, 2015, at 10:12 PM, David Holmes > > wrote: >> >> >> >> On 17/12/2015 3:45 AM, Christian Thalinger wrote: >>> >>>> On Dec 15, 2015, at 2:54 PM, David Holmes >>> > wrote: >>>> >>>> Hi Christian, >>>> >>>> os_posix.cpp: >>>> >>>> tl;dr: the new assert is wrong, don't add it. >>>> >>>> os::sleep has two paths: >>>> >>>> 1. interruptible sleeps >>>> >>>> This is the implementation of java.lang.Thread.sleep and should only >>>> be called by JavaThreads using that API (but see below) >>>> >>>> 2. non-interruptible sleep >>>> >>>> Used for 'incidental' sleeps within the VM, primarily by >>>> non-JavaThreads. If a JavaThread uses this it will delay safepoints, >>>> so the sleep should be very small. >>>> >>>> As you have discovered the Windows implementation of os::sleep >>>> actually asserts that JavaThreads don't take the second path. That's >>>> not correct. There are two existing cases where this will trigger today. >>>> >>>> The first is a historical usage of ConvertYieldToSleep: >>>> >>>> JVM_ENTRY(void, JVM_Yield(JNIEnv *env, jclass threadClass)) >>>> JVMWrapper("JVM_Yield"); >>>> if (os::dont_yield()) return; >>>> HOTSPOT_THREAD_YIELD(); >>>> >>>> // When ConvertYieldToSleep is off (default), this matches the >>>> classic VM use of yield. >>>> // Critical for similar threading behaviour >>>> if (ConvertYieldToSleep) { >>>> os::sleep(thread, MinSleepInterval, false); >>>> } else { >>>> os::naked_yield(); >>>> } >>>> JVM_END >>>> >>>> Then in JVM_Sleep itself: >>>> >>>> if (millis == 0) { >>>> if (ConvertSleepToYield) { >>>> os::naked_yield(); >>>> } else { >>>> ThreadState old_state = thread->osthread()->get_state(); >>>> thread->osthread()->set_state(SLEEPING); >>>> os::sleep(thread, MinSleepInterval, false); >>>> thread->osthread()->set_state(old_state); >>>> } >>>> >>>> This would also blow up on Windows - if ConvertSleepToYield is >>>> turned off (it is on by default on x86 - in fact all platforms >>>> except sparc - which really should be a Solaris setting as it will >>>> now affect the Linux/sparc port (which would then crash with your >>>> proposed additional assert in os_posix.cpp!). >>>> >>>> So adding the assert to os::sleep on Posix is not correct, and >>>> arguably the assertion should be removed from the windows code. >>> >>> I?ll let you guys take care of that. >>> >>>> >>>> -- >>>> >>>> os_windows.cpp: >>>> runtime/os.hpp" >>>> >>>> If you grep you will find about a 50-50 split between interruptible >>>> and interruptable through the codebase, so unless you want to file a >>>> cleanup bug to make it consistent I would just drop this change. >>> >>> It?s a cleanup and it?s already done but I?m not arguing for this. >>> >>>> >>>> --- >>>> >>>> java.cpp >>>> >>>> It is not at all clear to me will be in a position to print the >>>> exception information correctly at this stage of the termination >>>> logic. I would argue that any errors during JVMCIRuntime::shutdown >>>> should be handled internally and logged using the logging mechanism, >>>> not via exceptions and exception printing. >>> >>> I disagree. We are shutting down the VM and while doing that we are >>> running Java code. If the Java code throws an exception the user >>> wants to see that exception. >> >> But it is not the user's Java code it is an internal implementation >> artifact. I have no doubt this is helping you with debugging JVMCI but >> I don't think it is the correct way to handle an internal JVMCI error >> during termination. Ditto for the use of the sleep mechanism. > > I?m not sure I understand. Are you saying that users should not see > exceptions that are thrown from system code when the VM starts up and > shuts down? That doesn?t make any sense. I think logging plus use of fatal error handler is preferable. I'm genuinely concerned that the VM may not be in any position to print exception stacktraces at late stages of VM termination. David ----- > Also, remember that JVMCI is an experimental feature in 9. It is not > turned on by default. > >> >> David >> ------ >> >>> >>>> >>>> --- >>>> >>>> src/share/vm/jvmci/jvmciCompiler.cpp >>>> >>>> typo: >>>> >>>> + // Give other aborting threads to also print their stack traces. >>>> >>>> should be: >>>> >>>> + // Give other aborting threads a chance to also print their >>>> stack traces. >>>> >>>> though I am dubious about the need for this and the use of the >>>> os::sleep that seemed to trigger this whole issue. Why aren't you >>>> using a normal vmError-based termination path for such fatal errors? >>> >>> As the comment says: >>> >>> + // This can be very useful when debugging class initialization >>> + // failures. >>> >>> Since multiple compiler threads can initialize the JVMCI subsystem we >>> need to print all of the exceptions to see the root cause. Doug >>> would know more about this but that?s the gist. >>> >>>> >>>> Cheers, >>>> David >>>> >>>> On 16/12/2015 6:54 AM, Christian Thalinger wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8145435 >>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/ >>>>> >>>>> The actual fix for the problem is passing true to os::sleep: >>>>> >>>>> + const bool interruptible = true; >>>>> + os::sleep(THREAD, 200, interruptible); >>>>> >>>>> since compiler threads are Java threads but I fixed a couple more >>>>> things... >>>>> >>>>> First, I?ve added the same assert to os_posix.cpp: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/os/posix/vm/os_posix.cpp.udiff.html >>>>> >>>>> because it?s odd to only hit this assert on Windows: >>>>> >>>>> Additionally I?ve changed the way we handle an exception in >>>>> before_exit: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html >>>>> >>>>> and moved abort_on_pending_exception into JVMCICompiler and made it >>>>> private. It?s used for one thing only now. >>>>> >>>>> Finally I replaced JVMCIRuntime::call_printStackTrace with calls to >>>>> java_lang_Throwable::print_stack_trace. > From john.r.rose at oracle.com Fri Dec 18 04:38:45 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 17 Dec 2015 20:38:45 -0800 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <56728EF9.6050300@redhat.com> References: <56697E62.9030306@redhat.com> <56702E47.9090003@redhat.com> <56728EF9.6050300@redhat.com> Message-ID: On Dec 17, 2015, at 2:31 AM, Andrew Haley wrote: > > I'm sure that it makes no sense ever to construct bitmasks using a > signed type. I am doing my best to be certain that I don't break > anything. I'll have a look to see if there is some way that I can > change this to unsigned without changing behaviour. This is more reason to avoid using the built-in C operators for bit-twiddling and use macros or inlines instead. See globalDefinitions.hpp, near right_n_bits. (Which is wrong, but less wrong than writing built-in C operators.) ? John From christian.thalinger at oracle.com Fri Dec 18 07:33:18 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Dec 2015 21:33:18 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <56738D94.30107@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5670B659.7040000@oracle.com> <0FC1E0E8-8F34-4199-A2DF-3F6911211F08@oracle.com> <56726E7B.2070006@oracle.com> <56738D94.30107@oracle.com> Message-ID: <57F69528-F768-4BBE-AE87-8FE4FDDD814D@oracle.com> > On Dec 17, 2015, at 6:37 PM, David Holmes wrote: > > On 18/12/2015 3:29 AM, Christian Thalinger wrote: >> >>> On Dec 16, 2015, at 10:12 PM, David Holmes >>> >> wrote: >>> >>> >>> >>> On 17/12/2015 3:45 AM, Christian Thalinger wrote: >>>> >>>>> On Dec 15, 2015, at 2:54 PM, David Holmes >>>>> >> wrote: >>>>> >>>>> Hi Christian, >>>>> >>>>> os_posix.cpp: >>>>> >>>>> tl;dr: the new assert is wrong, don't add it. >>>>> >>>>> os::sleep has two paths: >>>>> >>>>> 1. interruptible sleeps >>>>> >>>>> This is the implementation of java.lang.Thread.sleep and should only >>>>> be called by JavaThreads using that API (but see below) >>>>> >>>>> 2. non-interruptible sleep >>>>> >>>>> Used for 'incidental' sleeps within the VM, primarily by >>>>> non-JavaThreads. If a JavaThread uses this it will delay safepoints, >>>>> so the sleep should be very small. >>>>> >>>>> As you have discovered the Windows implementation of os::sleep >>>>> actually asserts that JavaThreads don't take the second path. That's >>>>> not correct. There are two existing cases where this will trigger today. >>>>> >>>>> The first is a historical usage of ConvertYieldToSleep: >>>>> >>>>> JVM_ENTRY(void, JVM_Yield(JNIEnv *env, jclass threadClass)) >>>>> JVMWrapper("JVM_Yield"); >>>>> if (os::dont_yield()) return; >>>>> HOTSPOT_THREAD_YIELD(); >>>>> >>>>> // When ConvertYieldToSleep is off (default), this matches the >>>>> classic VM use of yield. >>>>> // Critical for similar threading behaviour >>>>> if (ConvertYieldToSleep) { >>>>> os::sleep(thread, MinSleepInterval, false); >>>>> } else { >>>>> os::naked_yield(); >>>>> } >>>>> JVM_END >>>>> >>>>> Then in JVM_Sleep itself: >>>>> >>>>> if (millis == 0) { >>>>> if (ConvertSleepToYield) { >>>>> os::naked_yield(); >>>>> } else { >>>>> ThreadState old_state = thread->osthread()->get_state(); >>>>> thread->osthread()->set_state(SLEEPING); >>>>> os::sleep(thread, MinSleepInterval, false); >>>>> thread->osthread()->set_state(old_state); >>>>> } >>>>> >>>>> This would also blow up on Windows - if ConvertSleepToYield is >>>>> turned off (it is on by default on x86 - in fact all platforms >>>>> except sparc - which really should be a Solaris setting as it will >>>>> now affect the Linux/sparc port (which would then crash with your >>>>> proposed additional assert in os_posix.cpp!). >>>>> >>>>> So adding the assert to os::sleep on Posix is not correct, and >>>>> arguably the assertion should be removed from the windows code. >>>> >>>> I?ll let you guys take care of that. >>>> >>>>> >>>>> -- >>>>> >>>>> os_windows.cpp: >>>>> runtime/os.hpp" >>>>> >>>>> If you grep you will find about a 50-50 split between interruptible >>>>> and interruptable through the codebase, so unless you want to file a >>>>> cleanup bug to make it consistent I would just drop this change. >>>> >>>> It?s a cleanup and it?s already done but I?m not arguing for this. >>>> >>>>> >>>>> --- >>>>> >>>>> java.cpp >>>>> >>>>> It is not at all clear to me will be in a position to print the >>>>> exception information correctly at this stage of the termination >>>>> logic. I would argue that any errors during JVMCIRuntime::shutdown >>>>> should be handled internally and logged using the logging mechanism, >>>>> not via exceptions and exception printing. >>>> >>>> I disagree. We are shutting down the VM and while doing that we are >>>> running Java code. If the Java code throws an exception the user >>>> wants to see that exception. >>> >>> But it is not the user's Java code it is an internal implementation >>> artifact. I have no doubt this is helping you with debugging JVMCI but >>> I don't think it is the correct way to handle an internal JVMCI error >>> during termination. Ditto for the use of the sleep mechanism. >> >> I?m not sure I understand. Are you saying that users should not see >> exceptions that are thrown from system code when the VM starts up and >> shuts down? That doesn?t make any sense. > > I think logging plus use of fatal error handler is preferable. I'm genuinely concerned that the VM may not be in any position to print exception stacktraces at late stages of VM termination. It is. Perhaps I should have mentioned that I tried to throw an exception and it works perfectly fine. All this is very theoretical because in practice this will never happen. > > David > ----- > >> Also, remember that JVMCI is an experimental feature in 9. It is not >> turned on by default. >> >>> >>> David >>> ------ >>> >>>> >>>>> >>>>> --- >>>>> >>>>> src/share/vm/jvmci/jvmciCompiler.cpp >>>>> >>>>> typo: >>>>> >>>>> + // Give other aborting threads to also print their stack traces. >>>>> >>>>> should be: >>>>> >>>>> + // Give other aborting threads a chance to also print their >>>>> stack traces. >>>>> >>>>> though I am dubious about the need for this and the use of the >>>>> os::sleep that seemed to trigger this whole issue. Why aren't you >>>>> using a normal vmError-based termination path for such fatal errors? >>>> >>>> As the comment says: >>>> >>>> + // This can be very useful when debugging class initialization >>>> + // failures. >>>> >>>> Since multiple compiler threads can initialize the JVMCI subsystem we >>>> need to print all of the exceptions to see the root cause. Doug >>>> would know more about this but that?s the gist. >>>> >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 16/12/2015 6:54 AM, Christian Thalinger wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8145435 >>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/ >>>>>> >>>>>> The actual fix for the problem is passing true to os::sleep: >>>>>> >>>>>> + const bool interruptible = true; >>>>>> + os::sleep(THREAD, 200, interruptible); >>>>>> >>>>>> since compiler threads are Java threads but I fixed a couple more >>>>>> things... >>>>>> >>>>>> First, I?ve added the same assert to os_posix.cpp: >>>>>> >>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/os/posix/vm/os_posix.cpp.udiff.html >>>>>> >>>>>> because it?s odd to only hit this assert on Windows: >>>>>> >>>>>> Additionally I?ve changed the way we handle an exception in >>>>>> before_exit: >>>>>> >>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html >>>>>> >>>>>> and moved abort_on_pending_exception into JVMCICompiler and made it >>>>>> private. It?s used for one thing only now. >>>>>> >>>>>> Finally I replaced JVMCIRuntime::call_printStackTrace with calls to >>>>>> java_lang_Throwable::print_stack_trace. From john.r.rose at oracle.com Fri Dec 18 10:33:37 2015 From: john.r.rose at oracle.com (John Rose) Date: Fri, 18 Dec 2015 02:33:37 -0800 Subject: Moving the _vtable_len into Klass In-Reply-To: <5672C6D4.4020509@oracle.com> References: <567150E5.9060308@oracle.com> <56719EB0.6030504@oracle.com> <5672C6D4.4020509@oracle.com> Message-ID: On Dec 17, 2015, at 6:29 AM, Mikael Gerdin wrote: > > My current plan is to first modify the vtable_length_offset accessor to return a byte offset (which is what it's translated to by all callers). > > Then I'll tackle moving the _vtable_len field to Klass. > > Finally I'll try to consolidate the vtable related methods to Klass, where they belong. > > The vtable_start_offset is a slightly more difficult beast since it's more often used in wordSize scaled calculations, my current idea is to leave it alone for now. > > Does that sound like a good plan? Sure, that's fine. It might be slightly better if you could make vtable_start_offset also be unscaled, but (as I said) that's more of a long-term goal, to move towards unscaled offset calculations. ? John From aph at redhat.com Fri Dec 18 11:13:45 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 18 Dec 2015 11:13:45 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: References: <56697E62.9030306@redhat.com> <56702E47.9090003@redhat.com> <56728EF9.6050300@redhat.com> Message-ID: <5673EA69.5090504@redhat.com> On 18/12/15 04:38, John Rose wrote: > On Dec 17, 2015, at 2:31 AM, Andrew Haley wrote: >> >> I'm sure that it makes no sense ever to construct bitmasks using a >> signed type. I am doing my best to be certain that I don't break >> anything. I'll have a look to see if there is some way that I can >> change this to unsigned without changing behaviour. > > This is more reason to avoid using the built-in C operators for bit-twiddling > and use macros or inlines instead. See globalDefinitions.hpp, near right_n_bits. > (Which is wrong, but less wrong than writing built-in C operators.) Mmmm, and I notice that right_n_bits() has undefined behaviour too. Looks like this task is turning onto something substantial. Never mind, it can be done in pieces. Andrew. From magnus.ihse.bursie at oracle.com Fri Dec 18 12:40:21 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Dec 2015 13:40:21 +0100 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> Message-ID: <5673FEB5.3080804@oracle.com> On 2015-12-16 14:50, Magnus Ihse Bursie wrote: > There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. > > This patch is provided by Timo Kinnunen . I am sponsoring this patch. > > The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. > > I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 > > /Magnus Kumar had a reply to this which unfortunately ended up on a different thread on which the component teams were not cc'ed. Here are the relevant parts: > On 12/16/2015 12:18 PM, Magnus Ihse Bursie wrote: > On 2015-12-16 16:33, Kumar Srinivasan wrote: >> Hello, >> >> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html >> >> >> You are undefining Windows math.h OVERFLOW, what is it defined >> as ? With you redefining this, will it cause problems for users of >> this API, likely to affect JNI apps. >> >> Probably need to redefine the pack200 OVERFLOW constant to >> something else, probably PACK200_OVERFLOW to prevent namespace >> collisions. > > I agree, this is a better solution. I've updated the webrev with this > solution (although I used the name PSIZE_OVERFLOW to align with > PSIZE_MAX). > > http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.02 > > > /Magnus /Magnus From magnus.ihse.bursie at oracle.com Fri Dec 18 12:46:28 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Dec 2015 13:46:28 +0100 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <5673281B.8000800@oracle.com> References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com> <5672046E.5@oracle.com> <56726A4D.5050600@oracle.com> <56726D95.20103@oracle.com> <56726FE1.6020906@oracle.com> <5673281B.8000800@oracle.com> Message-ID: <56740024.40500@oracle.com> On 2015-12-17 22:24, David Holmes wrote: > On 17/12/2015 6:18 PM, Magnus Ihse Bursie wrote: >> On 2015-12-17 09:08, David Holmes wrote: >>> On 17/12/2015 5:54 PM, Erik Joelsson wrote: >>>> >>>> >>>> On 2015-12-17 01:40, David Holmes wrote: >>>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote: >>>>>> One more thing, where should this fix be pushed? Do you need it >>>>>> urgently >>>>>> in hs-rt? >>>>> >>>>> It is urgently needed in both the hs-rt and hs-comp repos as it >>>>> affects nightly testing and JPRT. If Alejandro agrees I suggest >>>>> pushing to jdk9/hs and it can then be pulled down to the team repos. >>>>> >>>> Will do. >>>>> With regard to the fix ... previously DEBUG_BINARIES was never set in >>>>> spec.gmk and so was never externally introduced into the hotspot >>>>> build >>>>> this way. So why not simply change the name of the variable so >>>>> that it >>>>> has no affect on the hotspot part of the build? >>>>> >>>> Well, we don't want it affecting the jdk part of the build either at >>>> this point. This patch aims to restore the "external" and "zipped" >>>> settings to exactly what they were before the patch, as was promised. >>> >>> I had not inferred from any of this that what was being done via >>> NativeCompilation.gmk was in any way a problem. I would have expected >>> any problems there to be readily seen before this was reviewed and >>> pushed. So I'm a bit confused about this. >> >> The changes in NativeCompilation.gmk looked perfectly fine. They turned >> out to trigger a bug (or, at the very least, very unsuspected behavior) >> which was deeply hidden in the hotspot linux makefiles, where setting >> DEBUG_BINARIES did indeed enable the -g flag, but also, as a side >> effect, turned fastdebug builds into slowdebug builds. This was not >> something that we could possibly forsee. > > That was my understanding too - that this was simply a side-effect on > hotspot, hence my suggestion to rename the variable. But Erik then > said this was also not working correctly for the JDK side - which > means the problem is far worse. JDK-8036003 introduced the the use of DEBUG_BINARIES in jdk code as well. So it "affects" jdk libraries as well, but not with the kind of performance regression. However, it did enable debug information were we didn't have it before in the Oracle builds. While I believe this is a good thing, it should be added under more controlled forms. Therefore we want to revert the effect of DEBUG_BINARIES for the kinds of build we do at Oracle (external/zipped), keep the effect added in JDK-8036003 for the new kind of builds the community requested (internal), and finally we want to enable debug symbols for all our jdk libraries as a separate change, JDK-8145596. The only thing left to do is for the community to provide a fix to the problem that the newly added functionality of debug-symbols=internal means that hotspot in effect turns into a slowdebug build. Since the community regularly builds by setting DEBUG_BINARIES=true on the command line, it's not really a regression for them, but it's still a bug since they get unnecessarily slow builds. Either they need to provide a patch, or wait for the new hotspot build where this won't be a problem. /Magnus It was not "far worse", but > > David > ----- > > >>> >>> I'm tempted to say rollback the whole thing rather than hack at it. >> >> I don't think there is any compelling reason to rollback the whole >> change. The basic idea is sound. However, we do need to work on how to >> handle the debug symbols "under the hood". This deficit has been known >> for a long time to me and Erik but we have not spent any time on it. >> This change brought the problems up to daylight, and I think that's a >> good thing. >> >> I've started working on JDK-8145596, which will provide a proper >> solution to how we handle debug symbols. It is based on JDK-8036003. >> >> /Magnus >> >> >>> >>> And apologies as I'm just about to go offline for a few hours at least. >>> >>> David >>> ----- >>> >>> >>> >>>> We will followup with a more complete fix. >>>> >>>> /Erik >>>>> Thanks, >>>>> David >>>>> >>>>>> /Erik >>>>>> >>>>>> On 2015-12-16 22:34, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this quick fix for the build issue introduced in >>>>>>> Hotspot >>>>>>> by JDK-8036003. The short story is that if you set >>>>>>> DEBUG_BINARIES=true >>>>>>> when building Hotspot fastdebug, you essentially get a slowdebug >>>>>>> build. For an explanation of why, see comment in bug. This >>>>>>> behavior is >>>>>>> of course also a bug, but not something I will address in this >>>>>>> quick >>>>>>> fix. >>>>>>> >>>>>>> What happened in JDK-8036003 was that a new configure API for >>>>>>> controlling debug symbols was introduced. The two main settings of >>>>>>> this new parameter, --with-native-debug-symbols, that we use >>>>>>> internally at Oracle are "external" and "zipped". It was >>>>>>> important to >>>>>>> us that the behavior of these did not change with JDK-8036003, but >>>>>>> exactly that did happen, because both of these settings now cause >>>>>>> DEBUG_BINARIES=true to be set. This variable has never been set by >>>>>>> configure before and because of the above weird behavior in the >>>>>>> Hotspot makefiles, we are having problems. >>>>>>> >>>>>>> My proposed quick fix is to not set DEBUG_BINARIES=true for >>>>>>> "external" >>>>>>> or "zipped". It can remain true for "internal" since Oracle never >>>>>>> builds it that way, and I understand those that requested this new >>>>>>> configure parameter were setting DEBUG_BINARIES=true as a >>>>>>> workaround >>>>>>> before this anyway, so they should be fine with the broken >>>>>>> fastdebug >>>>>>> behavior for a while more. I will file a follow up bug to properly >>>>>>> clean up this mess, but it will take some more time. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 >>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ >>>>>>> >>>>>>> /Erik >>>>>> >>>> >> From magnus.ihse.bursie at oracle.com Fri Dec 18 13:01:08 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Dec 2015 14:01:08 +0100 Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds In-Reply-To: <567329D0.8010303@oracle.com> References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com> <5672046E.5@oracle.com> <56726A4D.5050600@oracle.com> <56726D95.20103@oracle.com> <56727F3D.7090600@oracle.com> <567329D0.8010303@oracle.com> Message-ID: <56740394.30706@oracle.com> On 2015-12-17 22:32, David Holmes wrote: > On 17/12/2015 7:24 PM, Erik Joelsson wrote: >> On 2015-12-17 09:08, David Holmes wrote: >>> On 17/12/2015 5:54 PM, Erik Joelsson wrote: >>>> >>>> >>>> On 2015-12-17 01:40, David Holmes wrote: >>>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote: >>>>>> One more thing, where should this fix be pushed? Do you need it >>>>>> urgently >>>>>> in hs-rt? >>>>> >>>>> It is urgently needed in both the hs-rt and hs-comp repos as it >>>>> affects nightly testing and JPRT. If Alejandro agrees I suggest >>>>> pushing to jdk9/hs and it can then be pulled down to the team repos. >>>>> >>>> Will do. >>>>> With regard to the fix ... previously DEBUG_BINARIES was never set in >>>>> spec.gmk and so was never externally introduced into the hotspot >>>>> build >>>>> this way. So why not simply change the name of the variable so >>>>> that it >>>>> has no affect on the hotspot part of the build? >>>>> >>>> Well, we don't want it affecting the jdk part of the build either at >>>> this point. This patch aims to restore the "external" and "zipped" >>>> settings to exactly what they were before the patch, as was promised. >>> >>> I had not inferred from any of this that what was being done via >>> NativeCompilation.gmk was in any way a problem. I would have expected >>> any problems there to be readily seen before this was reviewed and >>> pushed. So I'm a bit confused about this. >>> >> I didn't follow this particular review closely as Magnus was on it and >> so I had missed the NativeCompilation part. It's true that it is very >> unlikely to be part of the problem described in this bug, but I still >> feel that the safest action at this point is to restore the behavior of >> "external" and "zipped" to what they used to be. > > My concern is recognizing that these adjustments do in fact restore > the old behaviour. From the hotspot side it seemed cleaner to avoid > the breakage by using a different variable name. I'm not sure about this talk about a different variable name? The *point* of the patch was *exactly* to set DEBUG_BINARIES=true for internal builds. The problem was that it also set it for external/zipped, which was incorrect. But neither the writer of the patch nor me (or any other reviewer) realized that this would have this "hammer" effect. > >> Magnus is working on a >> complete fix where debug symbols will be enabled for everything in >> NativeCompilation. >>> I'm tempted to say rollback the whole thing rather than hack at it. >>> >> Rolling back will be much more work for me than submitting this patch. >> There are two changes already that depend on this change. I also don't >> dislike the idea of the new configure parameter. > > Rolling back the new configure parameters and then reinstating them > again would also not win us any friends as it would be very > disruptive. As others have noted the way we introduce and remove > configure parameters needs to be looked at. This makes it sound like we're sloppy with configure arguments when we actually try hard not to be. Normally, we don't have any problems with introducing new configure arguments. Most often, when we introduce a new argument, the behaviour falls back to the old behaviour as default if the argument is not specified. From time to time, we actually need to change the behaviour of configure, and this does not really apply. But then again, all modification somehow change behaviour regardless of if any options are changed, an all changes in behaviour breaks someones workflow (compulsory xkcd reference: https://xkcd.com/1172/). In this case, not setting the new configure option resulted in the old default behaviour. As for removing options, we are more conservative. We never remove options, we just deprecate them. (With a few exceptions, e.g. sometimes we have introduced temporary options which are clearly announced as such.) Our plan is to remove deprecated options once some time has passed (e.g. next major release) but, like the Java language itself, so far we have not actually removed any deprecated options. :-) When we deprecate an option, we ignore the value it sets, but prints a warning stating that the option is deprecated. The configure call will not fail, though. The warning is repeated as the very last thing so it should be easy for the user to spot, like this: The following warnings were produced. Repeated here for convenience: WARNING: Option --with-override-jaxp is deprecated and will be ignored. In some cases we've tried to write some "glue" to interpret old and deprecated options in terms of new. (I only think we've done this in the closed source). I don't really like it. It means a lot of tests, handling situations like what if both old and new are set, and they conflict? Or if both old and new are set and they do *not* conflict? What if the behaviour has changed slightly, so it does not really match? When should we stop helping the user to convert from the old to the new? > I was mainly concerned that the out-of-the-box default behaviour was > unchanged. The stated goal of the patch was that out of the box behaviour should have been unchanged. The patch was however incorrect, and this fact was not detected during testing of the patch (I only tested if it built ok, not that the resulting build did not degrade in performance) nor during code review. Such things happen, and then you need to fix them. /Magnus > >>> And apologies as I'm just about to go offline for a few hours at least. >>> >> I hope you won't object to me pushing this with just ihse as reviewer. I >> feel this is rather a priority to get fixed. > > Sure. I had verified that DEBUG_BINARIES is only ever tested against > "true" so setting it to false should be as effective as not setting it > at all. > > I'll follow up separately to see where this was pushed and whether we > need to pull it into anywhere else urgently. > > Thanks, > David > >> /Erik From magnus.ihse.bursie at oracle.com Fri Dec 18 13:08:24 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Dec 2015 14:08:24 +0100 Subject: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes In-Reply-To: <1d11c01d138c3$abd90600$038b1200$@oracle.com> References: <1cddb01d13827$2bb383c0$831a8b40$@oracle.com> <567270DC.1040701@oracle.com> <1d11c01d138c3$abd90600$038b1200$@oracle.com> Message-ID: <56740548.2070408@oracle.com> On 2015-12-17 13:08, Christian Tornqvist wrote: > Hi Magnus, > > Good catch, didn't read the version string as closely as I thought I did. > I changed the opt part to not include the debug_level either, now the > version string looks like this: > > Java HotSpot(TM) 64-Bit Client VM (fastdebug build > 9-internal+0-christian.vsbuild, mixed mode) > > Please see the new webrev at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.01/ I'm not really familiar with the ProjectCreator (but I suspect it's time I'm starting to get that), but from what I can tell this new change looks good. I'm especially happy to see the cleanup in vm_version.c. Even post-Verona we still have too much version "junk" floating around. Now it's slighly less so. /Magnus > > Thanks, > Christian > > -----Original Message----- > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > Sent: Thursday, December 17, 2015 3:23 AM > To: Christian Tornqvist ; > hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8145400 - ProjectCreator broken after JEP 223 changes > > On 2015-12-16 18:28, Christian Tornqvist wrote: >> Hi everyone, >> >> >> >> Please review this change that updates ProjectCreator to work with the >> new version string change in JEP 223. Tested the change locally, had >> to use a workaround for the issue described in JDK-8144716. >> >> Also cleaned up some old build targets that are not needed anymore. >> >> >> >> This is how the version string looks like when building in VS: >> >> Debug: >> >> Java HotSpot(TM) 64-Bit Server VM (debug build >> 9-internal+0.christian.vsbuild-debug, mixed mode) > That does not look like a valid version string. > '9-internal+0-.christian.vsbuild-debug' would be valid but strange-looking, > '9-internal+0-christian.vsbuild-debug' would probably be better. Also note > that the "opt" part of the version string does not contain "debug" any more > in make builds. (But you are of course free to add anything to the opt > string.) > > /Magnus > >> Fastdebug: >> >> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >> 9-internal+0.christian.vsbuild-fastdebug, mixed mode) >> >> Product: >> >> Java HotSpot(TM) 64-Bit Server VM (product build >> 9-internal+0.christian.vsbuild, mixed mode) >> >> >> >> Using make system >> >> Fastdebug: >> >> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >> 9-internal+0-2015-12-16-120539.christian.jdk9-rt, mixed mode) >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8145400/webrev.00/ >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8145400 >> >> >> >> Thanks, >> >> Christian >> > From matthias.baesken at sap.com Fri Dec 18 13:29:52 2015 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 18 Dec 2015 13:29:52 +0000 Subject: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER Message-ID: <98C2119538350A4E92B3DD08E7B4146801E207D8A2@DEWDFEMB14B.global.corp.sap> Hello, can you please review and sponsor this change : https://bugs.openjdk.java.net/browse/JDK-8145740 http://cr.openjdk.java.net/~clanger/webrevs/8145740.0/ Some details : while Visual Studio pragmas in shared code are usually guarded with _MSC_VER in the hotspot codebase ( see for example taskqueue.hpp or compressedStream.cpp ) , the guarding is missing in src/share/vm/utilities/growableArray.hpp , which is not really a "good thing" for other compilers . Thanks and regards, Matthias From coleen.phillimore at oracle.com Fri Dec 18 13:49:09 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Dec 2015 08:49:09 -0500 Subject: RFR: 8074457: Remove the non-Zero CPP Interpreter Message-ID: <56740ED5.4090700@oracle.com> Summary: Remove cppInterpreter assembly files and reorganize InterpreterGenerator includes This change is mostly removal and removing the InterpreterGenerator class and making class Interpreter a typedef. I removed conditional includes from interpreter header files in favor of small sections with ifdefs. Many interpreter functions are still in the wrong cpp files but I want to leave that for a follow on, to not overwhelm reviewers. This is Large but not difficult to review. There is also more purging that can be done with Zero, but I also want to leave that as a follow on RFE. This has been tested with RBT (most of runtime tests on x86 and sparc), JPRT and builds zero with debug/fastdebug and product. There are changes and deletions to ppc and aarch64. Please let me know if you want to test with this patch or leave for follow on fixes. open webrev at http://cr.openjdk.java.net/~coleenp/8074457/ bug link https://bugs.openjdk.java.net/browse/JDK-8074457 Thanks, Coleen From weijun.wang at oracle.com Fri Dec 18 14:11:23 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 18 Dec 2015 22:11:23 +0800 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> Message-ID: <57E1C404-21A6-41F7-87EF-881EDD3830C1@oracle.com> Hi Vinnie I take a look and it includes a change for src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp in the Java_sun_security_mscapi_KeyStore_getKeyLength() function. It seems there is no sun.security.mscapi.KeyStore#getKeyLength on the java side. Is the function useless now? Thanks Max > On Dec 16, 2015, at 9:50 PM, Magnus Ihse Bursie wrote: > > There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. > > This patch is provided by Timo Kinnunen . I am sponsoring this patch. > > The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. > > I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 > > /Magnus From goetz.lindenmaier at sap.com Fri Dec 18 15:36:37 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 18 Dec 2015 15:36:37 +0000 Subject: 8074457: Remove the non-Zero CPP Interpreter In-Reply-To: <56740ED5.4090700@oracle.com> References: <56740ED5.4090700@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EE386C@DEWDFEMB12A.global.corp.sap> Hi Coleen, I had a look at the shared and ppc files. I also tested it on ppc, works fine. Some smaller things: http://cr.openjdk.java.net/~coleenp/8074457/src/share/vm/interpreter/abstractInterpreter.hpp.udiff.html + #if defined(TARGET_ARCH_ppc) || defined(TARGET_ARCH_sparc) I's more common to use #if defined(PPC) || defined(AARCH64) bytecodeInterpreter.hpp: Maybe you want to clean up the #includes at the bottom as you do in the other files? cppInterpreterGenerator.hpp #ifdef TARGET_ARCH_zero --> #ifdef ZERO templateInterpreter.hpp #ifdef TARGET_ARCH_ppc --> #ifdef PPC ... there are more of these. templateInterpreter.hpp I think the ppc method math_entry_available() can just be 'inlined' at its callsite, so that the platform special case goes away. templateInterpreterGenerator.hpp lock_method(): I would just add the ppc parameters with default values to the existing definition of lock_method(). unlock_method(): I would place this near lock_method(). generate_fixed_frame(): generate_stack_overflow_check() Here also I would add the parameters to the existing function with default values. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Coleen Phillimore > Sent: Freitag, 18. Dezember 2015 14:49 > To: hotspot-dev developers > Subject: RFR: 8074457: Remove the non-Zero CPP Interpreter > > Summary: Remove cppInterpreter assembly files and reorganize > InterpreterGenerator includes > > This change is mostly removal and removing the InterpreterGenerator > class and making class Interpreter a typedef. I removed conditional > includes from interpreter header files in favor of small sections with > ifdefs. Many interpreter functions are still in the wrong cpp files > but I want to leave that for a follow on, to not overwhelm reviewers. > This is Large but not difficult to review. There is also more purging > that can be done with Zero, but I also want to leave that as a follow on > RFE. > > This has been tested with RBT (most of runtime tests on x86 and sparc), > JPRT and builds zero with debug/fastdebug and product. > > There are changes and deletions to ppc and aarch64. Please let me know > if you want to test with this patch or leave for follow on fixes. > > open webrev at http://cr.openjdk.java.net/~coleenp/8074457/ > bug link https://bugs.openjdk.java.net/browse/JDK-8074457 > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Dec 18 20:44:56 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Dec 2015 15:44:56 -0500 Subject: 8074457: Remove the non-Zero CPP Interpreter In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EE386C@DEWDFEMB12A.global.corp.sap> References: <56740ED5.4090700@oracle.com> <4295855A5C1DE049A61835A1887419CC41EE386C@DEWDFEMB12A.global.corp.sap> Message-ID: <56747048.8040400@oracle.com> Hi Goetz, Thank you for reviewing this so quickly and testing on PPC. Does Zero build on PPC too? On 12/18/15 10:36 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > I had a look at the shared and ppc files. I also tested it on ppc, works > fine. > > Some smaller things: > http://cr.openjdk.java.net/~coleenp/8074457/src/share/vm/interpreter/abstractInterpreter.hpp.udiff.html > + #if defined(TARGET_ARCH_ppc) || defined(TARGET_ARCH_sparc) > I's more common to use > #if defined(PPC) || defined(AARCH64) I made this change but PPC can be defined with ZERO, so these lines have to exclude ZERO. > > bytecodeInterpreter.hpp: > Maybe you want to clean up the #includes at the bottom as > you do in the other files? Yes, I missed this one. > > cppInterpreterGenerator.hpp > #ifdef TARGET_ARCH_zero --> #ifdef ZERO > templateInterpreter.hpp > #ifdef TARGET_ARCH_ppc --> #ifdef PPC > ... there are more of these. These ones I changed too. I didn't change the one in: http://cr.openjdk.java.net/~coleenp/8074457/src/share/vm/interpreter/templateInterpreter.cpp.udiff.html because I didn't add it and don't know what tests use it. > > templateInterpreter.hpp > I think the ppc method math_entry_available() can just be 'inlined' > at its callsite, so that the platform special case goes away. This seemed tricky since it has some semantics you wouldn't want to duplicate for using both in TemplateInterpreter and TemplateInterpreterGenerator functions. I'd like to just leave this conditional. > > templateInterpreterGenerator.hpp > lock_method(): > I would just add the ppc parameters with default values to the existing definition > of lock_method(). > unlock_method(): I would place this near lock_method(). > generate_fixed_frame(): > generate_stack_overflow_check() > Here also I would add the parameters to the existing function with default > values. I thought of doing this, but recently got burned by default parameters so I don't like them anymore. And I didn't want to change the other platforms to include the default parameters that aren't used in the definition of the functions. I thought the small set of conditionals was a small price to pay so I'd like to leave these too. See new webrev at: Thanks, Coleen > > Best regards, > Goetz. > > > > > > > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Coleen Phillimore >> Sent: Freitag, 18. Dezember 2015 14:49 >> To: hotspot-dev developers >> Subject: RFR: 8074457: Remove the non-Zero CPP Interpreter >> >> Summary: Remove cppInterpreter assembly files and reorganize >> InterpreterGenerator includes >> >> This change is mostly removal and removing the InterpreterGenerator >> class and making class Interpreter a typedef. I removed conditional >> includes from interpreter header files in favor of small sections with >> ifdefs. Many interpreter functions are still in the wrong cpp files >> but I want to leave that for a follow on, to not overwhelm reviewers. >> This is Large but not difficult to review. There is also more purging >> that can be done with Zero, but I also want to leave that as a follow on >> RFE. >> >> This has been tested with RBT (most of runtime tests on x86 and sparc), >> JPRT and builds zero with debug/fastdebug and product. >> >> There are changes and deletions to ppc and aarch64. Please let me know >> if you want to test with this patch or leave for follow on fixes. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8074457/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8074457 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Fri Dec 18 20:49:33 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Dec 2015 15:49:33 -0500 Subject: 8074457: Remove the non-Zero CPP Interpreter In-Reply-To: <56747048.8040400@oracle.com> References: <56740ED5.4090700@oracle.com> <4295855A5C1DE049A61835A1887419CC41EE386C@DEWDFEMB12A.global.corp.sap> <56747048.8040400@oracle.com> Message-ID: <5674715D.70201@oracle.com> On 12/18/15 3:44 PM, Coleen Phillimore wrote: > > Hi Goetz, Thank you for reviewing this so quickly and testing on > PPC. Does Zero build on PPC too? > > On 12/18/15 10:36 AM, Lindenmaier, Goetz wrote: >> Hi Coleen, >> >> I had a look at the shared and ppc files. I also tested it on ppc, >> works >> fine. >> >> Some smaller things: >> http://cr.openjdk.java.net/~coleenp/8074457/src/share/vm/interpreter/abstractInterpreter.hpp.udiff.html >> >> + #if defined(TARGET_ARCH_ppc) || defined(TARGET_ARCH_sparc) >> I's more common to use >> #if defined(PPC) || defined(AARCH64) > > I made this change but PPC can be defined with ZERO, so these lines > have to exclude ZERO. > >> >> bytecodeInterpreter.hpp: >> Maybe you want to clean up the #includes at the bottom as >> you do in the other files? > > Yes, I missed this one. >> >> cppInterpreterGenerator.hpp >> #ifdef TARGET_ARCH_zero --> #ifdef ZERO >> templateInterpreter.hpp >> #ifdef TARGET_ARCH_ppc --> #ifdef PPC >> ... there are more of these. > > These ones I changed too. I didn't change the one in: > > http://cr.openjdk.java.net/~coleenp/8074457/src/share/vm/interpreter/templateInterpreter.cpp.udiff.html > > > because I didn't add it and don't know what tests use it. I am testing out changing this to #ifdef IA32 (as well as the declarations in templateInterpreterGenerator.hpp file). > >> >> templateInterpreter.hpp >> I think the ppc method math_entry_available() can just be 'inlined' >> at its callsite, so that the platform special case goes away. > > This seemed tricky since it has some semantics you wouldn't want to > duplicate for using both in TemplateInterpreter and > TemplateInterpreterGenerator functions. I'd like to just leave this > conditional. > >> >> templateInterpreterGenerator.hpp >> lock_method(): >> I would just add the ppc parameters with default values to the >> existing definition >> of lock_method(). >> unlock_method(): I would place this near lock_method(). >> generate_fixed_frame(): >> generate_stack_overflow_check() >> Here also I would add the parameters to the existing function with >> default >> values. > > I thought of doing this, but recently got burned by default parameters > so I don't like them anymore. And I didn't want to change the other > platforms to include the default parameters that aren't used in the > definition of the functions. I thought the small set of conditionals > was a small price to pay so I'd like to leave these too. > > > See new webrev at: > Oops, here's webrev: open webrev at http://cr.openjdk.java.net/~coleenp/8074457.02/ Coleen > > Thanks, > Coleen > >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>> Behalf Of Coleen Phillimore >>> Sent: Freitag, 18. Dezember 2015 14:49 >>> To: hotspot-dev developers >>> Subject: RFR: 8074457: Remove the non-Zero CPP Interpreter >>> >>> Summary: Remove cppInterpreter assembly files and reorganize >>> InterpreterGenerator includes >>> >>> This change is mostly removal and removing the InterpreterGenerator >>> class and making class Interpreter a typedef. I removed conditional >>> includes from interpreter header files in favor of small sections with >>> ifdefs. Many interpreter functions are still in the wrong cpp files >>> but I want to leave that for a follow on, to not overwhelm reviewers. >>> This is Large but not difficult to review. There is also more purging >>> that can be done with Zero, but I also want to leave that as a >>> follow on >>> RFE. >>> >>> This has been tested with RBT (most of runtime tests on x86 and sparc), >>> JPRT and builds zero with debug/fastdebug and product. >>> >>> There are changes and deletions to ppc and aarch64. Please let me >>> know >>> if you want to test with this patch or leave for follow on fixes. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8074457/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8074457 >>> >>> Thanks, >>> Coleen > From goetz.lindenmaier at sap.com Fri Dec 18 21:10:34 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 18 Dec 2015 21:10:34 +0000 Subject: 8074457: Remove the non-Zero CPP Interpreter In-Reply-To: <56747048.8040400@oracle.com> References: <56740ED5.4090700@oracle.com> <4295855A5C1DE049A61835A1887419CC41EE386C@DEWDFEMB12A.global.corp.sap> <56747048.8040400@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EE3D69@DEWDFEMB12A.global.corp.sap> Hi, My commandline for that is too old. Do you have a hint what I need to set to do a hotspot only build of zero? Best regards, Goetz. > -----Original Message----- > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > Sent: Friday, December 18, 2015 9:45 PM > To: Lindenmaier, Goetz ; hotspot-dev > developers > Subject: Re: 8074457: Remove the non-Zero CPP Interpreter > > > Hi Goetz, Thank you for reviewing this so quickly and testing on PPC. > Does Zero build on PPC too? > > On 12/18/15 10:36 AM, Lindenmaier, Goetz wrote: > > Hi Coleen, > > > > I had a look at the shared and ppc files. I also tested it on ppc, works > > fine. > > > > Some smaller things: > > > http://cr.openjdk.java.net/~coleenp/8074457/src/share/vm/interpreter/abs > tractInterpreter.hpp.udiff.html > > + #if defined(TARGET_ARCH_ppc) || defined(TARGET_ARCH_sparc) > > I's more common to use > > #if defined(PPC) || defined(AARCH64) > > I made this change but PPC can be defined with ZERO, so these lines have > to exclude ZERO. > > > > > bytecodeInterpreter.hpp: > > Maybe you want to clean up the #includes at the bottom as > > you do in the other files? > > Yes, I missed this one. > > > > cppInterpreterGenerator.hpp > > #ifdef TARGET_ARCH_zero --> #ifdef ZERO > > templateInterpreter.hpp > > #ifdef TARGET_ARCH_ppc --> #ifdef PPC > > ... there are more of these. > > These ones I changed too. I didn't change the one in: > > http://cr.openjdk.java.net/~coleenp/8074457/src/share/vm/interpreter/te > mplateInterpreter.cpp.udiff.html > > because I didn't add it and don't know what tests use it. > > > > > templateInterpreter.hpp > > I think the ppc method math_entry_available() can just be 'inlined' > > at its callsite, so that the platform special case goes away. > > This seemed tricky since it has some semantics you wouldn't want to > duplicate for using both in TemplateInterpreter and > TemplateInterpreterGenerator functions. I'd like to just leave this > conditional. > > > > > templateInterpreterGenerator.hpp > > lock_method(): > > I would just add the ppc parameters with default values to the existing > definition > > of lock_method(). > > unlock_method(): I would place this near lock_method(). > > generate_fixed_frame(): > > generate_stack_overflow_check() > > Here also I would add the parameters to the existing function with default > > values. > > I thought of doing this, but recently got burned by default parameters > so I don't like them anymore. And I didn't want to change the other > platforms to include the default parameters that aren't used in the > definition of the functions. I thought the small set of conditionals > was a small price to pay so I'd like to leave these too. > > > See new webrev at: > > > Thanks, > Coleen > > > > > Best regards, > > Goetz. > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > >> Behalf Of Coleen Phillimore > >> Sent: Freitag, 18. Dezember 2015 14:49 > >> To: hotspot-dev developers > >> Subject: RFR: 8074457: Remove the non-Zero CPP Interpreter > >> > >> Summary: Remove cppInterpreter assembly files and reorganize > >> InterpreterGenerator includes > >> > >> This change is mostly removal and removing the InterpreterGenerator > >> class and making class Interpreter a typedef. I removed conditional > >> includes from interpreter header files in favor of small sections with > >> ifdefs. Many interpreter functions are still in the wrong cpp files > >> but I want to leave that for a follow on, to not overwhelm reviewers. > >> This is Large but not difficult to review. There is also more purging > >> that can be done with Zero, but I also want to leave that as a follow on > >> RFE. > >> > >> This has been tested with RBT (most of runtime tests on x86 and sparc), > >> JPRT and builds zero with debug/fastdebug and product. > >> > >> There are changes and deletions to ppc and aarch64. Please let me know > >> if you want to test with this patch or leave for follow on fixes. > >> > >> open webrev at http://cr.openjdk.java.net/~coleenp/8074457/ > >> bug link https://bugs.openjdk.java.net/browse/JDK-8074457 > >> > >> Thanks, > >> Coleen From coleen.phillimore at oracle.com Fri Dec 18 21:27:12 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Dec 2015 16:27:12 -0500 Subject: 8074457: Remove the non-Zero CPP Interpreter In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EE3D69@DEWDFEMB12A.global.corp.sap> References: <56740ED5.4090700@oracle.com> <4295855A5C1DE049A61835A1887419CC41EE386C@DEWDFEMB12A.global.corp.sap> <56747048.8040400@oracle.com> <4295855A5C1DE049A61835A1887419CC41EE3D69@DEWDFEMB12A.global.corp.sap> Message-ID: <56747A30.7020005@oracle.com> You have to install libffi to some typical place, and you can't use devkits (because liffi location and devkits conflict). bash configure --with-debug-level=slowdebug --with-boot-jdk=$boot --disable-precompiled-headers --disable-zip-debug-info --enable-deploy=no --enable-installer=no --with-jvm-variants=zero --with-target-bits=64 --disable-jfr --disable-warnings-as-errors where $boot is a jdk8 bootstrap binary. I have a couple extra configure options that you don't need. Coleen On 12/18/15 4:10 PM, Lindenmaier, Goetz wrote: > Hi, > > My commandline for that is too old. Do you have a hint what I need > to set to do a hotspot only build of zero? > > Best regards, > Goetz. > >> -----Original Message----- >> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >> Sent: Friday, December 18, 2015 9:45 PM >> To: Lindenmaier, Goetz ; hotspot-dev >> developers >> Subject: Re: 8074457: Remove the non-Zero CPP Interpreter >> >> >> Hi Goetz, Thank you for reviewing this so quickly and testing on PPC. >> Does Zero build on PPC too? >> >> On 12/18/15 10:36 AM, Lindenmaier, Goetz wrote: >>> Hi Coleen, >>> >>> I had a look at the shared and ppc files. I also tested it on ppc, works >>> fine. >>> >>> Some smaller things: >>> >> http://cr.openjdk.java.net/~coleenp/8074457/src/share/vm/interpreter/abs >> tractInterpreter.hpp.udiff.html >>> + #if defined(TARGET_ARCH_ppc) || defined(TARGET_ARCH_sparc) >>> I's more common to use >>> #if defined(PPC) || defined(AARCH64) >> I made this change but PPC can be defined with ZERO, so these lines have >> to exclude ZERO. >> >>> bytecodeInterpreter.hpp: >>> Maybe you want to clean up the #includes at the bottom as >>> you do in the other files? >> Yes, I missed this one. >>> cppInterpreterGenerator.hpp >>> #ifdef TARGET_ARCH_zero --> #ifdef ZERO >>> templateInterpreter.hpp >>> #ifdef TARGET_ARCH_ppc --> #ifdef PPC >>> ... there are more of these. >> These ones I changed too. I didn't change the one in: >> >> http://cr.openjdk.java.net/~coleenp/8074457/src/share/vm/interpreter/te >> mplateInterpreter.cpp.udiff.html >> >> because I didn't add it and don't know what tests use it. >> >>> templateInterpreter.hpp >>> I think the ppc method math_entry_available() can just be 'inlined' >>> at its callsite, so that the platform special case goes away. >> This seemed tricky since it has some semantics you wouldn't want to >> duplicate for using both in TemplateInterpreter and >> TemplateInterpreterGenerator functions. I'd like to just leave this >> conditional. >> >>> templateInterpreterGenerator.hpp >>> lock_method(): >>> I would just add the ppc parameters with default values to the existing >> definition >>> of lock_method(). >>> unlock_method(): I would place this near lock_method(). >>> generate_fixed_frame(): >>> generate_stack_overflow_check() >>> Here also I would add the parameters to the existing function with default >>> values. >> I thought of doing this, but recently got burned by default parameters >> so I don't like them anymore. And I didn't want to change the other >> platforms to include the default parameters that aren't used in the >> definition of the functions. I thought the small set of conditionals >> was a small price to pay so I'd like to leave these too. >> >> >> See new webrev at: >> >> >> Thanks, >> Coleen >> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Coleen Phillimore >>>> Sent: Freitag, 18. Dezember 2015 14:49 >>>> To: hotspot-dev developers >>>> Subject: RFR: 8074457: Remove the non-Zero CPP Interpreter >>>> >>>> Summary: Remove cppInterpreter assembly files and reorganize >>>> InterpreterGenerator includes >>>> >>>> This change is mostly removal and removing the InterpreterGenerator >>>> class and making class Interpreter a typedef. I removed conditional >>>> includes from interpreter header files in favor of small sections with >>>> ifdefs. Many interpreter functions are still in the wrong cpp files >>>> but I want to leave that for a follow on, to not overwhelm reviewers. >>>> This is Large but not difficult to review. There is also more purging >>>> that can be done with Zero, but I also want to leave that as a follow on >>>> RFE. >>>> >>>> This has been tested with RBT (most of runtime tests on x86 and sparc), >>>> JPRT and builds zero with debug/fastdebug and product. >>>> >>>> There are changes and deletions to ppc and aarch64. Please let me know >>>> if you want to test with this patch or leave for follow on fixes. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8074457/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8074457 >>>> >>>> Thanks, >>>> Coleen From goetz.lindenmaier at sap.com Fri Dec 18 21:54:35 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 18 Dec 2015 21:54:35 +0000 Subject: 8074457: Remove the non-Zero CPP Interpreter In-Reply-To: <56747A30.7020005@oracle.com> References: <56740ED5.4090700@oracle.com> <4295855A5C1DE049A61835A1887419CC41EE386C@DEWDFEMB12A.global.corp.sap> <56747048.8040400@oracle.com> <4295855A5C1DE049A61835A1887419CC41EE3D69@DEWDFEMB12A.global.corp.sap> <56747A30.7020005@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EE3DAD@DEWDFEMB12A.global.corp.sap> Hi I don't have a ppc machine with libffi and the header files properly installed. But using headers from an x86 machine get's me through the build up to linking the libjvm.so. If there's still people around, I might get libffi installed on Monday. Best regards, Goetz. > -----Original Message----- > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > Sent: Friday, December 18, 2015 10:27 PM > To: Lindenmaier, Goetz ; hotspot-dev > developers > Subject: Re: 8074457: Remove the non-Zero CPP Interpreter > > > You have to install libffi to some typical place, and you can't use > devkits (because liffi location and devkits conflict). > > bash configure --with-debug-level=slowdebug --with-boot-jdk=$boot > --disable-precompiled-headers --disable-zip-debug-info > --enable-deploy=no --enable-installer=no --with-jvm-variants=zero > --with-target-bits=64 --disable-jfr --disable-warnings-as-errors > > where $boot is a jdk8 bootstrap binary. I have a couple extra configure > options that you don't need. > > Coleen > > On 12/18/15 4:10 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > My commandline for that is too old. Do you have a hint what I need > > to set to do a hotspot only build of zero? > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > >> Sent: Friday, December 18, 2015 9:45 PM > >> To: Lindenmaier, Goetz ; hotspot-dev > >> developers > >> Subject: Re: 8074457: Remove the non-Zero CPP Interpreter > >> > >> > >> Hi Goetz, Thank you for reviewing this so quickly and testing on PPC. > >> Does Zero build on PPC too? > >> > >> On 12/18/15 10:36 AM, Lindenmaier, Goetz wrote: > >>> Hi Coleen, > >>> > >>> I had a look at the shared and ppc files. I also tested it on ppc, works > >>> fine. > >>> > >>> Some smaller things: > >>> > >> > http://cr.openjdk.java.net/~coleenp/8074457/src/share/vm/interpreter/abs > >> tractInterpreter.hpp.udiff.html > >>> + #if defined(TARGET_ARCH_ppc) || defined(TARGET_ARCH_sparc) > >>> I's more common to use > >>> #if defined(PPC) || defined(AARCH64) > >> I made this change but PPC can be defined with ZERO, so these lines have > >> to exclude ZERO. > >> > >>> bytecodeInterpreter.hpp: > >>> Maybe you want to clean up the #includes at the bottom as > >>> you do in the other files? > >> Yes, I missed this one. > >>> cppInterpreterGenerator.hpp > >>> #ifdef TARGET_ARCH_zero --> #ifdef ZERO > >>> templateInterpreter.hpp > >>> #ifdef TARGET_ARCH_ppc --> #ifdef PPC > >>> ... there are more of these. > >> These ones I changed too. I didn't change the one in: > >> > >> > http://cr.openjdk.java.net/~coleenp/8074457/src/share/vm/interpreter/te > >> mplateInterpreter.cpp.udiff.html > >> > >> because I didn't add it and don't know what tests use it. > >> > >>> templateInterpreter.hpp > >>> I think the ppc method math_entry_available() can just be 'inlined' > >>> at its callsite, so that the platform special case goes away. > >> This seemed tricky since it has some semantics you wouldn't want to > >> duplicate for using both in TemplateInterpreter and > >> TemplateInterpreterGenerator functions. I'd like to just leave this > >> conditional. > >> > >>> templateInterpreterGenerator.hpp > >>> lock_method(): > >>> I would just add the ppc parameters with default values to the existing > >> definition > >>> of lock_method(). > >>> unlock_method(): I would place this near lock_method(). > >>> generate_fixed_frame(): > >>> generate_stack_overflow_check() > >>> Here also I would add the parameters to the existing function with > default > >>> values. > >> I thought of doing this, but recently got burned by default parameters > >> so I don't like them anymore. And I didn't want to change the other > >> platforms to include the default parameters that aren't used in the > >> definition of the functions. I thought the small set of conditionals > >> was a small price to pay so I'd like to leave these too. > >> > >> > >> See new webrev at: > >> > >> > >> Thanks, > >> Coleen > >> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] > On > >>>> Behalf Of Coleen Phillimore > >>>> Sent: Freitag, 18. Dezember 2015 14:49 > >>>> To: hotspot-dev developers > >>>> Subject: RFR: 8074457: Remove the non-Zero CPP Interpreter > >>>> > >>>> Summary: Remove cppInterpreter assembly files and reorganize > >>>> InterpreterGenerator includes > >>>> > >>>> This change is mostly removal and removing the InterpreterGenerator > >>>> class and making class Interpreter a typedef. I removed conditional > >>>> includes from interpreter header files in favor of small sections with > >>>> ifdefs. Many interpreter functions are still in the wrong cpp files > >>>> but I want to leave that for a follow on, to not overwhelm reviewers. > >>>> This is Large but not difficult to review. There is also more purging > >>>> that can be done with Zero, but I also want to leave that as a follow on > >>>> RFE. > >>>> > >>>> This has been tested with RBT (most of runtime tests on x86 and sparc), > >>>> JPRT and builds zero with debug/fastdebug and product. > >>>> > >>>> There are changes and deletions to ppc and aarch64. Please let me > know > >>>> if you want to test with this patch or leave for follow on fixes. > >>>> > >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8074457/ > >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8074457 > >>>> > >>>> Thanks, > >>>> Coleen From mikael.vidstedt at oracle.com Fri Dec 18 22:20:35 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 18 Dec 2015 14:20:35 -0800 Subject: RFR(XS): 8145828: JPRT hotspot push jobs should allow merge on push Message-ID: <567486B3.4010808@oracle.com> Please review this small change which relaxes the check made in JPRT at the time when a hotspot push job has finished successfully, and the changes are about to be pushed. Currently the job will be marked as failed if a merge is needed, even if an automatic merge would complete successfully. This "safety mechanism" was reasonable when all pushes were made using JPRT, but since we started allowing direct pushes the failure rate has gone up. The assumption here is that the code changes will very rarely overlap, and even more rarely conflict, so if the automatic merge is successful then it's highly likely that the resulting code would (also) pass the JPRT testing. This change enables the automatic merge to be attempted, and if it is successful the resulting changes will be pushed. Bug: https://bugs.openjdk.java.net/browse/JDK-8145828 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8145828/webrev.00/webrev/ Cheers, Mikael From kim.barrett at oracle.com Sat Dec 19 00:41:49 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 18 Dec 2015 19:41:49 -0500 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> Message-ID: On Dec 16, 2015, at 8:50 AM, Magnus Ihse Bursie wrote: > > There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. > > This patch is provided by Timo Kinnunen . I am sponsoring this patch. > > The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. > > I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 > > /Magnus I only looked at hotspot files. Breaking this up into smaller and more focused chunks would be nice. Large changes that do 17 different things are hard to deal with. I think the various casts to uintptr_t (commented with "What???" below) should be done differently. They are addressing problems of differences between pointer size and various integer sizes, and conversions between them. I think in some cases there is a poorly chosen surrounding type involved. For the 0xdeadbeef cases, there probably ought to be a centralized helper for that sort of thing, since doing it properly on across different platforms might be tricky, and that trickiness ought to be in one place. There are a couple of "TBD"s below that I need to spend more time on. ------------------------------------------------------------------------------ Sprinkling lots of files with the following seems like a bad idea. #if _MSC_VER >= 1900 #pragma warning( disable : 4091 ) // typedef ignored on left when no variable is declared #endif Especially since these warnings may indicate actual bugs. https://msdn.microsoft.com/en-us/library/eehkcz60.aspx ------------------------------------------------------------------------------ hotspot/src/share/vm/utilities/globalDefinitions.hpp 1062 #define badAddress ((address)(intptr_t)::badAddressVal) Change the type of badAddressVal to intptr_t instead. ------------------------------------------------------------------------------ hotspot/src/share/vm/runtime/os.cpp 127 #elif defined(_WIN32) && _MSC_VER > 1800 128 const time_t zone = _timezone; Why does (recent) Windows need special handling here? ------------------------------------------------------------------------------ hotspot/src/share/vm/utilities/globalDefinitions_visCPP.hpp 198 #if _MSC_VER <= 1800 Shouldn't that be "<" the version that introduced the missing function? ------------------------------------------------------------------------------ hotspot/src/share/vm/prims/whitebox.cpp 1286 return (jlong)(uintptr_t)ikh->constants(); What??? ------------------------------------------------------------------------------ hotspot/src/share/vm/opto/type.cpp 53 { Bad, T_ILLEGAL, "bad", false, (int)Node::NotAMachineReg, relocInfo::none }, // Bad 61 { Bad, T_ILLEGAL, "tuple:", false, (int)Node::NotAMachineReg, relocInfo::none }, // Tuple 62 { Bad, T_ARRAY, "array:", false, (int)Node::NotAMachineReg, relocInfo::none }, // Array These are narrowing conversions in brace initializers, which are forbidden by C++11. The type of the member is int, while the initialization expressions are non-literal uint. In my opinion, it would be better to figure out how to fix the type mismatch than to sprinkle with casts. A way to look for these that doesn't require VS2015 would be to use g++ -Wnarrowing. ------------------------------------------------------------------------------ hotspot/src/share/vm/opto/split_if.cpp 258 Node *prior_n = (Node*)(uintptr_t)0xdeadbeef; 305 prior_n = (Node*)(uintptr_t)0xdeadbeef; // Reset IDOM walk What??? ------------------------------------------------------------------------------ hotspot/src/share/vm/opto/gcm.cpp 1448 _node_latency = (GrowableArray *)(uintptr_t)0xdeadbeef; What??? ------------------------------------------------------------------------------ hotspot/src/share/vm/opto/compile.cpp 2398 _cfg = (PhaseCFG*)(uintptr_t)0xdeadbeef; 2399 _regalloc = (PhaseChaitin*)(uintptr_t)0xdeadbeef; What??? ------------------------------------------------------------------------------ hotspot/src/share/vm/opto/buildOopMap.cpp 618 Block *pred = (Block*)(uintptr_t)0xdeadbeef; What??? ------------------------------------------------------------------------------ hotspot/src/share/vm/oops/typeArrayOop.hpp 132 *long_at_addr(which) = (jlong)contents; Yes! Fortunately, it looks like metadata_at_put is never called. ------------------------------------------------------------------------------ hotspot/src/share/vm/memory/allocation.hpp 38 #if defined _WINDOWS && _MSC_VER >= 1900 39 // 'noexcept' used with no exception handling mode specified; termination on exception is not guaranteed. Specify /EHsc 40 #pragma warning( disable : 4577 ) 41 #endif Another C++11 change. Dynamic exception specifications (e.g. "throw(TYPELISTopt)" were deprecated by C++11. I think MSVC++ has always implemented "throw()" as "throwing an exception invokes undefined behavior". C++11 introduced "noexcept". I think it would be better to turn this off in the build system, rather than with with this conditional #pragma. Alternatively, perhaps replace existing uses of "throw()" with a VM_NOEXCEPT macro (or some other name) which expands into "throw()" or "noexcept" depending on the compiler and options. ------------------------------------------------------------------------------ hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp -- many, many lines -- Ouch! I'm not looking at this in detail... ------------------------------------------------------------------------------ hotspot/src/share/vm/adlc/arena.hpp 74 // Usual (non-placement) deallocation function to allow placement delete use size_t 75 // See 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2. 76 void operator delete(void* p); and associated code in the .cpp file. --- TBD ------------------------------------------------------------------------------ hotspot/agent/src/share/native/sadis.c 96 return (int)strlen(buf); --- TBD ------------------------------------------------------------------------------ From ioi.lam at oracle.com Sat Dec 19 05:09:26 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 18 Dec 2015 21:09:26 -0800 Subject: RFR(XS): 8145828: JPRT hotspot push jobs should allow merge on push In-Reply-To: <567486B3.4010808@oracle.com> References: <567486B3.4010808@oracle.com> Message-ID: <5674E686.4060305@oracle.com> Looks good. Thanks - Ioi On 12/18/15 2:20 PM, Mikael Vidstedt wrote: > > Please review this small change which relaxes the check made in JPRT > at the time when a hotspot push job has finished successfully, and the > changes are about to be pushed. > > Currently the job will be marked as failed if a merge is needed, even > if an automatic merge would complete successfully. This "safety > mechanism" was reasonable when all pushes were made using JPRT, but > since we started allowing direct pushes the failure rate has gone up. > The assumption here is that the code changes will very rarely overlap, > and even more rarely conflict, so if the automatic merge is successful > then it's highly likely that the resulting code would (also) pass the > JPRT testing. > > This change enables the automatic merge to be attempted, and if it is > successful the resulting changes will be pushed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145828 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8145828/webrev.00/webrev/ > > Cheers, > Mikael > From david.holmes at oracle.com Sat Dec 19 05:42:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 Dec 2015 15:42:16 +1000 Subject: RFR(XS): 8145828: JPRT hotspot push jobs should allow merge on push In-Reply-To: <567486B3.4010808@oracle.com> References: <567486B3.4010808@oracle.com> Message-ID: <5674EE38.500@oracle.com> This may be too late but I'd prefer to see an explicit: # Allow concurrent changes to be merged in prior to pushing jprt.sync.push=true both so that: a) it is visible that this happens and we can control it; and b) because "sync" is misleading - we always "sync" ie pull in any new changes, but what we don't do is merge if there is a conflict with those changes. Thanks, David On 19/12/2015 8:20 AM, Mikael Vidstedt wrote: > > Please review this small change which relaxes the check made in JPRT at > the time when a hotspot push job has finished successfully, and the > changes are about to be pushed. > > Currently the job will be marked as failed if a merge is needed, even if > an automatic merge would complete successfully. This "safety mechanism" > was reasonable when all pushes were made using JPRT, but since we > started allowing direct pushes the failure rate has gone up. The > assumption here is that the code changes will very rarely overlap, and > even more rarely conflict, so if the automatic merge is successful then > it's highly likely that the resulting code would (also) pass the JPRT > testing. > > This change enables the automatic merge to be attempted, and if it is > successful the resulting changes will be pushed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145828 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8145828/webrev.00/webrev/ > > Cheers, > Mikael > From christian.thalinger at oracle.com Mon Dec 21 16:25:51 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 21 Dec 2015 06:25:51 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <57F69528-F768-4BBE-AE87-8FE4FDDD814D@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5670B659.7040000@oracle.com> <0FC1E0E8-8F34-4199-A2DF-3F6911211F08@oracle.com> <56726E7B.2070006@oracle.com> <56738D94.30107@oracle.com> <57F69528-F768-4BBE-AE87-8FE4FDDD814D@oracle.com> Message-ID: <42D8D64E-197F-4EC7-AED6-C8B0BAEA2A26@oracle.com> > On Dec 17, 2015, at 9:33 PM, Christian Thalinger wrote: > >> >> On Dec 17, 2015, at 6:37 PM, David Holmes > wrote: >> >> On 18/12/2015 3:29 AM, Christian Thalinger wrote: >>> >>>> On Dec 16, 2015, at 10:12 PM, David Holmes > >>>> >>> wrote: >>>> >>>> >>>> >>>> On 17/12/2015 3:45 AM, Christian Thalinger wrote: >>>>> >>>>>> On Dec 15, 2015, at 2:54 PM, David Holmes > >>>>>> >>> wrote: >>>>>> >>>>>> Hi Christian, >>>>>> >>>>>> os_posix.cpp: >>>>>> >>>>>> tl;dr: the new assert is wrong, don't add it. >>>>>> >>>>>> os::sleep has two paths: >>>>>> >>>>>> 1. interruptible sleeps >>>>>> >>>>>> This is the implementation of java.lang.Thread.sleep and should only >>>>>> be called by JavaThreads using that API (but see below) >>>>>> >>>>>> 2. non-interruptible sleep >>>>>> >>>>>> Used for 'incidental' sleeps within the VM, primarily by >>>>>> non-JavaThreads. If a JavaThread uses this it will delay safepoints, >>>>>> so the sleep should be very small. >>>>>> >>>>>> As you have discovered the Windows implementation of os::sleep >>>>>> actually asserts that JavaThreads don't take the second path. That's >>>>>> not correct. There are two existing cases where this will trigger today. >>>>>> >>>>>> The first is a historical usage of ConvertYieldToSleep: >>>>>> >>>>>> JVM_ENTRY(void, JVM_Yield(JNIEnv *env, jclass threadClass)) >>>>>> JVMWrapper("JVM_Yield"); >>>>>> if (os::dont_yield()) return; >>>>>> HOTSPOT_THREAD_YIELD(); >>>>>> >>>>>> // When ConvertYieldToSleep is off (default), this matches the >>>>>> classic VM use of yield. >>>>>> // Critical for similar threading behaviour >>>>>> if (ConvertYieldToSleep) { >>>>>> os::sleep(thread, MinSleepInterval, false); >>>>>> } else { >>>>>> os::naked_yield(); >>>>>> } >>>>>> JVM_END >>>>>> >>>>>> Then in JVM_Sleep itself: >>>>>> >>>>>> if (millis == 0) { >>>>>> if (ConvertSleepToYield) { >>>>>> os::naked_yield(); >>>>>> } else { >>>>>> ThreadState old_state = thread->osthread()->get_state(); >>>>>> thread->osthread()->set_state(SLEEPING); >>>>>> os::sleep(thread, MinSleepInterval, false); >>>>>> thread->osthread()->set_state(old_state); >>>>>> } >>>>>> >>>>>> This would also blow up on Windows - if ConvertSleepToYield is >>>>>> turned off (it is on by default on x86 - in fact all platforms >>>>>> except sparc - which really should be a Solaris setting as it will >>>>>> now affect the Linux/sparc port (which would then crash with your >>>>>> proposed additional assert in os_posix.cpp!). >>>>>> >>>>>> So adding the assert to os::sleep on Posix is not correct, and >>>>>> arguably the assertion should be removed from the windows code. >>>>> >>>>> I?ll let you guys take care of that. >>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> os_windows.cpp: >>>>>> runtime/os.hpp" >>>>>> >>>>>> If you grep you will find about a 50-50 split between interruptible >>>>>> and interruptable through the codebase, so unless you want to file a >>>>>> cleanup bug to make it consistent I would just drop this change. >>>>> >>>>> It?s a cleanup and it?s already done but I?m not arguing for this. >>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> java.cpp >>>>>> >>>>>> It is not at all clear to me will be in a position to print the >>>>>> exception information correctly at this stage of the termination >>>>>> logic. I would argue that any errors during JVMCIRuntime::shutdown >>>>>> should be handled internally and logged using the logging mechanism, >>>>>> not via exceptions and exception printing. >>>>> >>>>> I disagree. We are shutting down the VM and while doing that we are >>>>> running Java code. If the Java code throws an exception the user >>>>> wants to see that exception. >>>> >>>> But it is not the user's Java code it is an internal implementation >>>> artifact. I have no doubt this is helping you with debugging JVMCI but >>>> I don't think it is the correct way to handle an internal JVMCI error >>>> during termination. Ditto for the use of the sleep mechanism. >>> >>> I?m not sure I understand. Are you saying that users should not see >>> exceptions that are thrown from system code when the VM starts up and >>> shuts down? That doesn?t make any sense. >> >> I think logging plus use of fatal error handler is preferable. I'm genuinely concerned that the VM may not be in any position to print exception stacktraces at late stages of VM termination. > > It is. Perhaps I should have mentioned that I tried to throw an exception and it works perfectly fine. All this is very theoretical because in practice this will never happen. Are you ok with the change as it is? > >> >> David >> ----- >> >>> Also, remember that JVMCI is an experimental feature in 9. It is not >>> turned on by default. >>> >>>> >>>> David >>>> ------ >>>> >>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> src/share/vm/jvmci/jvmciCompiler.cpp >>>>>> >>>>>> typo: >>>>>> >>>>>> + // Give other aborting threads to also print their stack traces. >>>>>> >>>>>> should be: >>>>>> >>>>>> + // Give other aborting threads a chance to also print their >>>>>> stack traces. >>>>>> >>>>>> though I am dubious about the need for this and the use of the >>>>>> os::sleep that seemed to trigger this whole issue. Why aren't you >>>>>> using a normal vmError-based termination path for such fatal errors? >>>>> >>>>> As the comment says: >>>>> >>>>> + // This can be very useful when debugging class initialization >>>>> + // failures. >>>>> >>>>> Since multiple compiler threads can initialize the JVMCI subsystem we >>>>> need to print all of the exceptions to see the root cause. Doug >>>>> would know more about this but that?s the gist. >>>>> >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> On 16/12/2015 6:54 AM, Christian Thalinger wrote: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8145435 >>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/ >>>>>>> >>>>>>> The actual fix for the problem is passing true to os::sleep: >>>>>>> >>>>>>> + const bool interruptible = true; >>>>>>> + os::sleep(THREAD, 200, interruptible); >>>>>>> >>>>>>> since compiler threads are Java threads but I fixed a couple more >>>>>>> things... >>>>>>> >>>>>>> First, I?ve added the same assert to os_posix.cpp: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/os/posix/vm/os_posix.cpp.udiff.html >>>>>>> >>>>>>> because it?s odd to only hit this assert on Windows: >>>>>>> >>>>>>> Additionally I?ve changed the way we handle an exception in >>>>>>> before_exit: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html >>>>>>> >>>>>>> and moved abort_on_pending_exception into JVMCICompiler and made it >>>>>>> private. It?s used for one thing only now. >>>>>>> >>>>>>> Finally I replaced JVMCIRuntime::call_printStackTrace with calls to >>>>>>> java_lang_Throwable::print_stack_trace. From aph at redhat.com Mon Dec 21 17:07:40 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 21 Dec 2015 17:07:40 +0000 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <340D0241-C04C-4353-A995-054094989789@oracle.com> References: <56697E62.9030306@redhat.com> <56702E47.9090003@redhat.com> <5672BA7C.3000700@redhat.com> <9BDAB29C-BC4B-464D-98BB-7D7AF2B8CF7B@oracle.com> <5672F75B.50802@redhat.com> <340D0241-C04C-4353-A995-054094989789@oracle.com> Message-ID: <567831DC.5020600@redhat.com> I've analysed the last remaining changes and I'm now convinced that it's safe to make this change: --- a/src/share/vm/opto/mulnode.cpp +++ b/src/share/vm/opto/mulnode.cpp @@ -574,7 +574,8 @@ // Masking off high bits which are always zero is useless. const TypeLong* t1 = phase->type( in(1) )->isa_long(); if (t1 != NULL && t1->_lo >= 0) { - jlong t1_support = ((jlong)1 << (1 + log2_long(t1->_hi))) - 1; + int bit_count = log2_long(t1->_hi) + 1; + jlong t1_support = jlong(max_julong >> (BitsPerJavaLong - bit_count)); if ((t1_support & con) == t1_support) return usr; } Webrev at http://cr.openjdk.java.net/~aph/8145096-4/ Andrew. From christoph.langer at sap.com Mon Dec 21 22:17:31 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 21 Dec 2015 22:17:31 +0000 Subject: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER In-Reply-To: <98C2119538350A4E92B3DD08E7B4146801E207D8A2@DEWDFEMB14B.global.corp.sap> References: <98C2119538350A4E92B3DD08E7B4146801E207D8A2@DEWDFEMB14B.global.corp.sap> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F8EA00@DEWDFEMB12B.global.corp.sap> Hi Matthias, to me your change looks good. However, I'm no reviewer so you'll need sponsorship from someone else. Can someone please sponsor this? Should it maybe be posted in another list for better visibility? Best regards Christoph -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Baesken, Matthias Sent: Freitag, 18. Dezember 2015 14:30 To: hotspot-dev at openjdk.java.net Cc: Simonis, Volker Subject: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER Hello, can you please review and sponsor this change : https://bugs.openjdk.java.net/browse/JDK-8145740 http://cr.openjdk.java.net/~clanger/webrevs/8145740.0/ Some details : while Visual Studio pragmas in shared code are usually guarded with _MSC_VER in the hotspot codebase ( see for example taskqueue.hpp or compressedStream.cpp ) , the guarding is missing in src/share/vm/utilities/growableArray.hpp , which is not really a "good thing" for other compilers . Thanks and regards, Matthias From filipp.zhinkin at gmail.com Tue Dec 22 07:36:39 2015 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Tue, 22 Dec 2015 10:36:39 +0300 Subject: RFR (S): JDK-8066599: Add methods to check VM mode to c.o.j.t.Platform Message-ID: Hi all, please review a small change that adds VM mode checking methods to jdk.test.lib.Platform. I didn't touch Platform class from hotspot/test/testlibrary, because it is already deprecated and at some point of time all hs tests will be updated to use j.t.l.Platform instead. Update of hs tests that use own logic to check VM mode is tracked by JDK-8145848 [1]. Webrev: http://cr.openjdk.java.net/~fzhinkin/8066599/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8066599 Testing: on local machine with different VM modes. Regards, Filipp. [1] https://bugs.openjdk.java.net/browse/JDK-8145848 From david.holmes at oracle.com Tue Dec 22 12:16:03 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Dec 2015 22:16:03 +1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <42D8D64E-197F-4EC7-AED6-C8B0BAEA2A26@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5670B659.7040000@oracle.com> <0FC1E0E8-8F34-4199-A2DF-3F6911211F08@oracle.com> <56726E7B.2070006@oracle.com> <56738D94.30107@oracle.com> <57F69528-F768-4BBE-AE87-8FE4FDDD814D@oracle.com> <42D8D64E-197F-4EC7-AED6-C8B0BAEA2A26@oracle.com> Message-ID: <56793F03.4090409@oracle.com> Hi Christian, I'm abstaining from further comment on this. Cheers, David On 22/12/2015 2:25 AM, Christian Thalinger wrote: > >> On Dec 17, 2015, at 9:33 PM, Christian Thalinger >> > > wrote: >> >>> >>> On Dec 17, 2015, at 6:37 PM, David Holmes >> > wrote: >>> >>> On 18/12/2015 3:29 AM, Christian Thalinger wrote: >>>> >>>>> On Dec 16, 2015, at 10:12 PM, David Holmes >>>> >>>>> >> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On 17/12/2015 3:45 AM, Christian Thalinger wrote: >>>>>> >>>>>>> On Dec 15, 2015, at 2:54 PM, David Holmes >>>>>>> >>>>>> >>>>>>> >> >>>>>>> wrote: >>>>>>> >>>>>>> Hi Christian, >>>>>>> >>>>>>> os_posix.cpp: >>>>>>> >>>>>>> tl;dr: the new assert is wrong, don't add it. >>>>>>> >>>>>>> os::sleep has two paths: >>>>>>> >>>>>>> 1. interruptible sleeps >>>>>>> >>>>>>> This is the implementation of java.lang.Thread.sleep and should only >>>>>>> be called by JavaThreads using that API (but see below) >>>>>>> >>>>>>> 2. non-interruptible sleep >>>>>>> >>>>>>> Used for 'incidental' sleeps within the VM, primarily by >>>>>>> non-JavaThreads. If a JavaThread uses this it will delay safepoints, >>>>>>> so the sleep should be very small. >>>>>>> >>>>>>> As you have discovered the Windows implementation of os::sleep >>>>>>> actually asserts that JavaThreads don't take the second path. That's >>>>>>> not correct. There are two existing cases where this will trigger >>>>>>> today. >>>>>>> >>>>>>> The first is a historical usage of ConvertYieldToSleep: >>>>>>> >>>>>>> JVM_ENTRY(void, JVM_Yield(JNIEnv *env, jclass threadClass)) >>>>>>> JVMWrapper("JVM_Yield"); >>>>>>> if (os::dont_yield()) return; >>>>>>> HOTSPOT_THREAD_YIELD(); >>>>>>> >>>>>>> // When ConvertYieldToSleep is off (default), this matches the >>>>>>> classic VM use of yield. >>>>>>> // Critical for similar threading behaviour >>>>>>> if (ConvertYieldToSleep) { >>>>>>> os::sleep(thread, MinSleepInterval, false); >>>>>>> } else { >>>>>>> os::naked_yield(); >>>>>>> } >>>>>>> JVM_END >>>>>>> >>>>>>> Then in JVM_Sleep itself: >>>>>>> >>>>>>> if (millis == 0) { >>>>>>> if (ConvertSleepToYield) { >>>>>>> os::naked_yield(); >>>>>>> } else { >>>>>>> ThreadState old_state = thread->osthread()->get_state(); >>>>>>> thread->osthread()->set_state(SLEEPING); >>>>>>> os::sleep(thread, MinSleepInterval, false); >>>>>>> thread->osthread()->set_state(old_state); >>>>>>> } >>>>>>> >>>>>>> This would also blow up on Windows - if ConvertSleepToYield is >>>>>>> turned off (it is on by default on x86 - in fact all platforms >>>>>>> except sparc - which really should be a Solaris setting as it will >>>>>>> now affect the Linux/sparc port (which would then crash with your >>>>>>> proposed additional assert in os_posix.cpp!). >>>>>>> >>>>>>> So adding the assert to os::sleep on Posix is not correct, and >>>>>>> arguably the assertion should be removed from the windows code. >>>>>> >>>>>> I?ll let you guys take care of that. >>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> os_windows.cpp: >>>>>>> runtime/os.hpp" >>>>>>> >>>>>>> If you grep you will find about a 50-50 split between interruptible >>>>>>> and interruptable through the codebase, so unless you want to file a >>>>>>> cleanup bug to make it consistent I would just drop this change. >>>>>> >>>>>> It?s a cleanup and it?s already done but I?m not arguing for this. >>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> java.cpp >>>>>>> >>>>>>> It is not at all clear to me will be in a position to print the >>>>>>> exception information correctly at this stage of the termination >>>>>>> logic. I would argue that any errors during JVMCIRuntime::shutdown >>>>>>> should be handled internally and logged using the logging mechanism, >>>>>>> not via exceptions and exception printing. >>>>>> >>>>>> I disagree. We are shutting down the VM and while doing that we are >>>>>> running Java code. If the Java code throws an exception the user >>>>>> wants to see that exception. >>>>> >>>>> But it is not the user's Java code it is an internal implementation >>>>> artifact. I have no doubt this is helping you with debugging JVMCI but >>>>> I don't think it is the correct way to handle an internal JVMCI error >>>>> during termination. Ditto for the use of the sleep mechanism. >>>> >>>> I?m not sure I understand. Are you saying that users should not see >>>> exceptions that are thrown from system code when the VM starts up and >>>> shuts down? That doesn?t make any sense. >>> >>> I think logging plus use of fatal error handler is preferable. I'm >>> genuinely concerned that the VM may not be in any position to print >>> exception stacktraces at late stages of VM termination. >> >> It is. Perhaps I should have mentioned that I tried to throw an >> exception and it works perfectly fine. All this is very theoretical >> because in practice this will never happen. > > Are you ok with the change as it is? > >> >>> >>> David >>> ----- >>> >>>> Also, remember that JVMCI is an experimental feature in 9. It is not >>>> turned on by default. >>>> >>>>> >>>>> David >>>>> ------ >>>>> >>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> src/share/vm/jvmci/jvmciCompiler.cpp >>>>>>> >>>>>>> typo: >>>>>>> >>>>>>> + // Give other aborting threads to also print their stack traces. >>>>>>> >>>>>>> should be: >>>>>>> >>>>>>> + // Give other aborting threads a chance to also print their >>>>>>> stack traces. >>>>>>> >>>>>>> though I am dubious about the need for this and the use of the >>>>>>> os::sleep that seemed to trigger this whole issue. Why aren't you >>>>>>> using a normal vmError-based termination path for such fatal errors? >>>>>> >>>>>> As the comment says: >>>>>> >>>>>> + // This can be very useful when debugging class initialization >>>>>> + // failures. >>>>>> >>>>>> Since multiple compiler threads can initialize the JVMCI subsystem we >>>>>> need to print all of the exceptions to see the root cause. Doug >>>>>> would know more about this but that?s the gist. >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>> On 16/12/2015 6:54 AM, Christian Thalinger wrote: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8145435 >>>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/ >>>>>>>> >>>>>>>> The actual fix for the problem is passing true to os::sleep: >>>>>>>> >>>>>>>> + const bool interruptible = true; >>>>>>>> + os::sleep(THREAD, 200, interruptible); >>>>>>>> >>>>>>>> since compiler threads are Java threads but I fixed a couple more >>>>>>>> things... >>>>>>>> >>>>>>>> First, I?ve added the same assert to os_posix.cpp: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/os/posix/vm/os_posix.cpp.udiff.html >>>>>>>> >>>>>>>> because it?s odd to only hit this assert on Windows: >>>>>>>> >>>>>>>> Additionally I?ve changed the way we handle an exception in >>>>>>>> before_exit: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html >>>>>>>> >>>>>>>> and moved abort_on_pending_exception into JVMCICompiler and made it >>>>>>>> private. It?s used for one thing only now. >>>>>>>> >>>>>>>> Finally I replaced JVMCIRuntime::call_printStackTrace with calls to >>>>>>>> java_lang_Throwable::print_stack_trace. > From bertrand.delsart at oracle.com Tue Dec 22 13:48:04 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 22 Dec 2015 14:48:04 +0100 Subject: RFR: 8074457: Remove the non-Zero CPP Interpreter In-Reply-To: <56740ED5.4090700@oracle.com> References: <56740ED5.4090700@oracle.com> Message-ID: <56795494.5020902@oracle.com> Hi Coleen, Overall looks good. Thanks for the cleanup. A few minor issues. No showstoppers. Feel free to ignore them or handle them later. First issue in src/share/vm/interpreter/templateInterpreterGenerator.hpp, for instance for these lines : #ifdef TARGET_ARCH_aarch64 - # include "templateInterpreterGenerator_aarch64.hpp" - #endif + void bang_stack_shadow_pages(bool native_call); + void generate_transcendental_entry(AbstractInterpreter::MethodKind kind, int fpargs); + #endif // TARGET_ARCH_aarch64 Is there a reason to remove a CPU dependent file, which could be customized by any porting group, and instead directly add port-dependent methods in a shared file ? Similar problem for AbstractInterpreter::expr_offset_in_bytes, which was defined in CPU dependent files but is now defined in abstractInterpreter.hpp, requiring a PPC and SPARC ifdef. Should we instead define new abstractInterpreter_.hpp files, including the CPU specific part that was in interpreter_.hpp ? Regards, Bertrand. On 18/12/2015 14:49, Coleen Phillimore wrote: > Summary: Remove cppInterpreter assembly files and reorganize > InterpreterGenerator includes > > This change is mostly removal and removing the InterpreterGenerator > class and making class Interpreter a typedef. I removed conditional > includes from interpreter header files in favor of small sections with > ifdefs. Many interpreter functions are still in the wrong cpp files > but I want to leave that for a follow on, to not overwhelm reviewers. > This is Large but not difficult to review. There is also more purging > that can be done with Zero, but I also want to leave that as a follow on > RFE. > > This has been tested with RBT (most of runtime tests on x86 and sparc), > JPRT and builds zero with debug/fastdebug and product. > > There are changes and deletions to ppc and aarch64. Please let me know > if you want to test with this patch or leave for follow on fixes. > > open webrev at http://cr.openjdk.java.net/~coleenp/8074457/ > bug link https://bugs.openjdk.java.net/browse/JDK-8074457 > > Thanks, > Coleen > -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From coleen.phillimore at oracle.com Tue Dec 22 15:23:14 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Dec 2015 10:23:14 -0500 Subject: RFR: 8074457: Remove the non-Zero CPP Interpreter In-Reply-To: <56795494.5020902@oracle.com> References: <56740ED5.4090700@oracle.com> <56795494.5020902@oracle.com> Message-ID: <56796AE2.8020007@oracle.com> On 12/22/15 8:48 AM, Bertrand Delsart wrote: > Hi Coleen, > > Overall looks good. Thanks for the cleanup. > > A few minor issues. No showstoppers. Feel free to ignore them or > handle them later. > > First issue in > src/share/vm/interpreter/templateInterpreterGenerator.hpp, for > instance for these lines : > > #ifdef TARGET_ARCH_aarch64 > - # include "templateInterpreterGenerator_aarch64.hpp" > - #endif > + void bang_stack_shadow_pages(bool native_call); > + void generate_transcendental_entry(AbstractInterpreter::MethodKind > kind, int fpargs); > + #endif // TARGET_ARCH_aarch64 > > Is there a reason to remove a CPU dependent file, which could be > customized by any porting group, and instead directly add > port-dependent methods in a shared file ? > > Similar problem for AbstractInterpreter::expr_offset_in_bytes, which > was defined in CPU dependent files but is now defined in > abstractInterpreter.hpp, requiring a PPC and SPARC ifdef. Should we > instead define new abstractInterpreter_.hpp files, including the > CPU specific part that was in interpreter_.hpp ? Hi Bertrand, I was hoping for some comments on these changes in particular and I should have explained my reasoning in the RFR. I decided that a couple of ifdefs in the shared code were better than the cpu dependent inclusion of header files. Mostly because the cpu dependent header files had a lot of duplicated content and it was difficult to find exactly what the differences were between the cpu implementations. Also, it would make the interpreter easier to work on if the interfaces were similar (you can change the same named function in all the cpu files) and this is a mechanism for doing so. The example with expr_offset_in_bytes is the annoying difference in sparc, and now PPC, where the TOS points one past Lesp that we filed a cleanup bug for a long time ago. It would be nice not to have this difference! Lastly, I also dislike #include in the declaration of a class and so do many IDEs. Thank you for reviewing the code. Coleen > > Regards, > > Bertrand. > > > > On 18/12/2015 14:49, Coleen Phillimore wrote: >> Summary: Remove cppInterpreter assembly files and reorganize >> InterpreterGenerator includes >> >> This change is mostly removal and removing the InterpreterGenerator >> class and making class Interpreter a typedef. I removed conditional >> includes from interpreter header files in favor of small sections with >> ifdefs. Many interpreter functions are still in the wrong cpp files >> but I want to leave that for a follow on, to not overwhelm reviewers. >> This is Large but not difficult to review. There is also more purging >> that can be done with Zero, but I also want to leave that as a follow on >> RFE. >> >> This has been tested with RBT (most of runtime tests on x86 and sparc), >> JPRT and builds zero with debug/fastdebug and product. >> >> There are changes and deletions to ppc and aarch64. Please let me know >> if you want to test with this patch or leave for follow on fixes. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8074457/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8074457 >> >> Thanks, >> Coleen >> > > From christian.thalinger at oracle.com Tue Dec 22 18:35:19 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Dec 2015 08:35:19 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <56793F03.4090409@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5670B659.7040000@oracle.com> <0FC1E0E8-8F34-4199-A2DF-3F6911211F08@oracle.com> <56726E7B.2070006@oracle.com> <56738D94.30107@oracle.com> <57F69528-F768-4BBE-AE87-8FE4FDDD814D@oracle.com> <42D8D64E-197F-4EC7-AED6-C8B0BAEA2A26@oracle.com> <56793F03.4090409@oracle.com> Message-ID: <23A5F584-1763-4A23-A3A2-8E8A5ED19D22@oracle.com> > On Dec 22, 2015, at 2:16 AM, David Holmes wrote: > > Hi Christian, > > I'm abstaining from further comment on this. Fair enough. Thanks for your input. > > Cheers, > David > > On 22/12/2015 2:25 AM, Christian Thalinger wrote: >> >>> On Dec 17, 2015, at 9:33 PM, Christian Thalinger >>> >> > wrote: >>> >>>> >>>> On Dec 17, 2015, at 6:37 PM, David Holmes >>> > wrote: >>>> >>>> On 18/12/2015 3:29 AM, Christian Thalinger wrote: >>>>> >>>>>> On Dec 16, 2015, at 10:12 PM, David Holmes >>>>> >>>>>> >> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 17/12/2015 3:45 AM, Christian Thalinger wrote: >>>>>>> >>>>>>>> On Dec 15, 2015, at 2:54 PM, David Holmes >>>>>>>> >>>>>>> >>>>>>>> >> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Christian, >>>>>>>> >>>>>>>> os_posix.cpp: >>>>>>>> >>>>>>>> tl;dr: the new assert is wrong, don't add it. >>>>>>>> >>>>>>>> os::sleep has two paths: >>>>>>>> >>>>>>>> 1. interruptible sleeps >>>>>>>> >>>>>>>> This is the implementation of java.lang.Thread.sleep and should only >>>>>>>> be called by JavaThreads using that API (but see below) >>>>>>>> >>>>>>>> 2. non-interruptible sleep >>>>>>>> >>>>>>>> Used for 'incidental' sleeps within the VM, primarily by >>>>>>>> non-JavaThreads. If a JavaThread uses this it will delay safepoints, >>>>>>>> so the sleep should be very small. >>>>>>>> >>>>>>>> As you have discovered the Windows implementation of os::sleep >>>>>>>> actually asserts that JavaThreads don't take the second path. That's >>>>>>>> not correct. There are two existing cases where this will trigger >>>>>>>> today. >>>>>>>> >>>>>>>> The first is a historical usage of ConvertYieldToSleep: >>>>>>>> >>>>>>>> JVM_ENTRY(void, JVM_Yield(JNIEnv *env, jclass threadClass)) >>>>>>>> JVMWrapper("JVM_Yield"); >>>>>>>> if (os::dont_yield()) return; >>>>>>>> HOTSPOT_THREAD_YIELD(); >>>>>>>> >>>>>>>> // When ConvertYieldToSleep is off (default), this matches the >>>>>>>> classic VM use of yield. >>>>>>>> // Critical for similar threading behaviour >>>>>>>> if (ConvertYieldToSleep) { >>>>>>>> os::sleep(thread, MinSleepInterval, false); >>>>>>>> } else { >>>>>>>> os::naked_yield(); >>>>>>>> } >>>>>>>> JVM_END >>>>>>>> >>>>>>>> Then in JVM_Sleep itself: >>>>>>>> >>>>>>>> if (millis == 0) { >>>>>>>> if (ConvertSleepToYield) { >>>>>>>> os::naked_yield(); >>>>>>>> } else { >>>>>>>> ThreadState old_state = thread->osthread()->get_state(); >>>>>>>> thread->osthread()->set_state(SLEEPING); >>>>>>>> os::sleep(thread, MinSleepInterval, false); >>>>>>>> thread->osthread()->set_state(old_state); >>>>>>>> } >>>>>>>> >>>>>>>> This would also blow up on Windows - if ConvertSleepToYield is >>>>>>>> turned off (it is on by default on x86 - in fact all platforms >>>>>>>> except sparc - which really should be a Solaris setting as it will >>>>>>>> now affect the Linux/sparc port (which would then crash with your >>>>>>>> proposed additional assert in os_posix.cpp!). >>>>>>>> >>>>>>>> So adding the assert to os::sleep on Posix is not correct, and >>>>>>>> arguably the assertion should be removed from the windows code. >>>>>>> >>>>>>> I?ll let you guys take care of that. >>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> os_windows.cpp: >>>>>>>> runtime/os.hpp" >>>>>>>> >>>>>>>> If you grep you will find about a 50-50 split between interruptible >>>>>>>> and interruptable through the codebase, so unless you want to file a >>>>>>>> cleanup bug to make it consistent I would just drop this change. >>>>>>> >>>>>>> It?s a cleanup and it?s already done but I?m not arguing for this. >>>>>>> >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> java.cpp >>>>>>>> >>>>>>>> It is not at all clear to me will be in a position to print the >>>>>>>> exception information correctly at this stage of the termination >>>>>>>> logic. I would argue that any errors during JVMCIRuntime::shutdown >>>>>>>> should be handled internally and logged using the logging mechanism, >>>>>>>> not via exceptions and exception printing. >>>>>>> >>>>>>> I disagree. We are shutting down the VM and while doing that we are >>>>>>> running Java code. If the Java code throws an exception the user >>>>>>> wants to see that exception. >>>>>> >>>>>> But it is not the user's Java code it is an internal implementation >>>>>> artifact. I have no doubt this is helping you with debugging JVMCI but >>>>>> I don't think it is the correct way to handle an internal JVMCI error >>>>>> during termination. Ditto for the use of the sleep mechanism. >>>>> >>>>> I?m not sure I understand. Are you saying that users should not see >>>>> exceptions that are thrown from system code when the VM starts up and >>>>> shuts down? That doesn?t make any sense. >>>> >>>> I think logging plus use of fatal error handler is preferable. I'm >>>> genuinely concerned that the VM may not be in any position to print >>>> exception stacktraces at late stages of VM termination. >>> >>> It is. Perhaps I should have mentioned that I tried to throw an >>> exception and it works perfectly fine. All this is very theoretical >>> because in practice this will never happen. >> >> Are you ok with the change as it is? >> >>> >>>> >>>> David >>>> ----- >>>> >>>>> Also, remember that JVMCI is an experimental feature in 9. It is not >>>>> turned on by default. >>>>> >>>>>> >>>>>> David >>>>>> ------ >>>>>> >>>>>>> >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> src/share/vm/jvmci/jvmciCompiler.cpp >>>>>>>> >>>>>>>> typo: >>>>>>>> >>>>>>>> + // Give other aborting threads to also print their stack traces. >>>>>>>> >>>>>>>> should be: >>>>>>>> >>>>>>>> + // Give other aborting threads a chance to also print their >>>>>>>> stack traces. >>>>>>>> >>>>>>>> though I am dubious about the need for this and the use of the >>>>>>>> os::sleep that seemed to trigger this whole issue. Why aren't you >>>>>>>> using a normal vmError-based termination path for such fatal errors? >>>>>>> >>>>>>> As the comment says: >>>>>>> >>>>>>> + // This can be very useful when debugging class initialization >>>>>>> + // failures. >>>>>>> >>>>>>> Since multiple compiler threads can initialize the JVMCI subsystem we >>>>>>> need to print all of the exceptions to see the root cause. Doug >>>>>>> would know more about this but that?s the gist. >>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>> On 16/12/2015 6:54 AM, Christian Thalinger wrote: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8145435 >>>>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/ >>>>>>>>> >>>>>>>>> The actual fix for the problem is passing true to os::sleep: >>>>>>>>> >>>>>>>>> + const bool interruptible = true; >>>>>>>>> + os::sleep(THREAD, 200, interruptible); >>>>>>>>> >>>>>>>>> since compiler threads are Java threads but I fixed a couple more >>>>>>>>> things... >>>>>>>>> >>>>>>>>> First, I?ve added the same assert to os_posix.cpp: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/os/posix/vm/os_posix.cpp.udiff.html >>>>>>>>> >>>>>>>>> because it?s odd to only hit this assert on Windows: >>>>>>>>> >>>>>>>>> Additionally I?ve changed the way we handle an exception in >>>>>>>>> before_exit: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev/src/share/vm/runtime/java.cpp.udiff.html >>>>>>>>> >>>>>>>>> and moved abort_on_pending_exception into JVMCICompiler and made it >>>>>>>>> private. It?s used for one thing only now. >>>>>>>>> >>>>>>>>> Finally I replaced JVMCIRuntime::call_printStackTrace with calls to >>>>>>>>> java_lang_Throwable::print_stack_trace. >> From christian.thalinger at oracle.com Tue Dec 22 23:06:53 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Dec 2015 13:06:53 -1000 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT Message-ID: https://bugs.openjdk.java.net/browse/JDK-8146043 Running all JVMCI tests on my MacBook takes about 2 minutes: Test results: passed: 63; error: 3 Results written to /private/tmp/twisti Error: Some tests failed or other problems occurred. real 2m6.236s user 4m7.922s sys 0m14.363s Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least amount of time currently. diff -r 46122d93612d test/TEST.groups --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ compiler/inlining/ \ compiler/integerArithmetic/ \ compiler/interpreter/ \ + compiler/jvmci/ \ -compiler/codegen/7184394 \ -compiler/codecache/stress From ioi.lam at oracle.com Tue Dec 22 23:12:43 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 22 Dec 2015 15:12:43 -0800 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT In-Reply-To: References: Message-ID: <5679D8EB.5040809@oracle.com> Looks good to me. Thanks - Ioi On 12/22/15 3:06 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8146043 > > Running all JVMCI tests on my MacBook takes about 2 minutes: > > Test results: passed: 63; error: 3 > Results written to /private/tmp/twisti > Error: Some tests failed or other problems occurred. > > real 2m6.236s > user 4m7.922s > sys 0m14.363s > > Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least amount of time currently. > > diff -r 46122d93612d test/TEST.groups > --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 > +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 > @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ > compiler/inlining/ \ > compiler/integerArithmetic/ \ > compiler/interpreter/ \ > + compiler/jvmci/ \ > -compiler/codegen/7184394 \ > -compiler/codecache/stress > > From christian.thalinger at oracle.com Tue Dec 22 23:35:58 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Dec 2015 13:35:58 -1000 Subject: RFR: 8074457: Remove the non-Zero CPP Interpreter In-Reply-To: <56796AE2.8020007@oracle.com> References: <56740ED5.4090700@oracle.com> <56795494.5020902@oracle.com> <56796AE2.8020007@oracle.com> Message-ID: <288AA4F4-15C9-44FC-8845-AB7B34A0F675@oracle.com> > On Dec 22, 2015, at 5:23 AM, Coleen Phillimore wrote: > > > > On 12/22/15 8:48 AM, Bertrand Delsart wrote: >> Hi Coleen, >> >> Overall looks good. Thanks for the cleanup. >> >> A few minor issues. No showstoppers. Feel free to ignore them or handle them later. >> >> First issue in src/share/vm/interpreter/templateInterpreterGenerator.hpp, for instance for these lines : >> >> #ifdef TARGET_ARCH_aarch64 >> - # include "templateInterpreterGenerator_aarch64.hpp" >> - #endif >> + void bang_stack_shadow_pages(bool native_call); >> + void generate_transcendental_entry(AbstractInterpreter::MethodKind kind, int fpargs); >> + #endif // TARGET_ARCH_aarch64 >> >> Is there a reason to remove a CPU dependent file, which could be customized by any porting group, and instead directly add port-dependent methods in a shared file ? >> >> Similar problem for AbstractInterpreter::expr_offset_in_bytes, which was defined in CPU dependent files but is now defined in abstractInterpreter.hpp, requiring a PPC and SPARC ifdef. Should we instead define new abstractInterpreter_.hpp files, including the CPU specific part that was in interpreter_.hpp ? > > Hi Bertrand, I was hoping for some comments on these changes in particular and I should have explained my reasoning in the RFR. I decided that a couple of ifdefs in the shared code were better than the cpu dependent inclusion of header files. Mostly because the cpu dependent header files had a lot of duplicated content and it was difficult to find exactly what the differences were between the cpu implementations. Also, it would make the interpreter easier to work on if the interfaces were similar (you can change the same named function in all the cpu files) and this is a mechanism for doing so. > > The example with expr_offset_in_bytes is the annoying difference in sparc, and now PPC, where the TOS points one past Lesp that we filed a cleanup bug for a long time ago. It would be nice not to have this difference! > > Lastly, I also dislike #include in the declaration of a class and so do many IDEs. Yes, these includes are nasty. I wish we would use inheritance for non-performance critical things like these. > > Thank you for reviewing the code. > Coleen > > >> >> Regards, >> >> Bertrand. >> >> >> >> On 18/12/2015 14:49, Coleen Phillimore wrote: >>> Summary: Remove cppInterpreter assembly files and reorganize >>> InterpreterGenerator includes >>> >>> This change is mostly removal and removing the InterpreterGenerator >>> class and making class Interpreter a typedef. I removed conditional >>> includes from interpreter header files in favor of small sections with >>> ifdefs. Many interpreter functions are still in the wrong cpp files >>> but I want to leave that for a follow on, to not overwhelm reviewers. >>> This is Large but not difficult to review. There is also more purging >>> that can be done with Zero, but I also want to leave that as a follow on >>> RFE. >>> >>> This has been tested with RBT (most of runtime tests on x86 and sparc), >>> JPRT and builds zero with debug/fastdebug and product. >>> >>> There are changes and deletions to ppc and aarch64. Please let me know >>> if you want to test with this patch or leave for follow on fixes. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8074457/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8074457 >>> >>> Thanks, >>> Coleen From mikael.vidstedt at oracle.com Wed Dec 23 02:19:25 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 22 Dec 2015 18:19:25 -0800 Subject: RFR(XS): 8145828: JPRT hotspot push jobs should allow merge on push In-Reply-To: <5674EE38.500@oracle.com> References: <567486B3.4010808@oracle.com> <5674EE38.500@oracle.com> Message-ID: <567A04AD.7020502@oracle.com> I could swear that I updated the webrev with exactly that before I sent out the review requests, but I must have messed it up some way... In either case I agree, and here's a new webrev: http://cr.openjdk.java.net/~mikael/webrevs/8145828/webrev.01/webrev/ Cheers, Mikael On 2015-12-18 21:42, David Holmes wrote: > This may be too late but I'd prefer to see an explicit: > > # Allow concurrent changes to be merged in prior to pushing > jprt.sync.push=true > > both so that: > > a) it is visible that this happens and we can control it; and > b) because "sync" is misleading - we always "sync" ie pull in any new > changes, but what we don't do is merge if there is a conflict with > those changes. > > Thanks, > David > > On 19/12/2015 8:20 AM, Mikael Vidstedt wrote: >> >> Please review this small change which relaxes the check made in JPRT at >> the time when a hotspot push job has finished successfully, and the >> changes are about to be pushed. >> >> Currently the job will be marked as failed if a merge is needed, even if >> an automatic merge would complete successfully. This "safety mechanism" >> was reasonable when all pushes were made using JPRT, but since we >> started allowing direct pushes the failure rate has gone up. The >> assumption here is that the code changes will very rarely overlap, and >> even more rarely conflict, so if the automatic merge is successful then >> it's highly likely that the resulting code would (also) pass the JPRT >> testing. >> >> This change enables the automatic merge to be attempted, and if it is >> successful the resulting changes will be pushed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145828 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8145828/webrev.00/webrev/ >> >> Cheers, >> Mikael >> From david.holmes at oracle.com Wed Dec 23 04:28:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Dec 2015 14:28:16 +1000 Subject: RFR(XS): 8145828: JPRT hotspot push jobs should allow merge on push In-Reply-To: <567A04AD.7020502@oracle.com> References: <567486B3.4010808@oracle.com> <5674EE38.500@oracle.com> <567A04AD.7020502@oracle.com> Message-ID: <567A22E0.1030706@oracle.com> Ship it! :) Thanks, David On 23/12/2015 12:19 PM, Mikael Vidstedt wrote: > > I could swear that I updated the webrev with exactly that before I sent > out the review requests, but I must have messed it up some way... In > either case I agree, and here's a new webrev: > > http://cr.openjdk.java.net/~mikael/webrevs/8145828/webrev.01/webrev/ > > Cheers, > Mikael > > On 2015-12-18 21:42, David Holmes wrote: >> This may be too late but I'd prefer to see an explicit: >> >> # Allow concurrent changes to be merged in prior to pushing >> jprt.sync.push=true >> >> both so that: >> >> a) it is visible that this happens and we can control it; and >> b) because "sync" is misleading - we always "sync" ie pull in any new >> changes, but what we don't do is merge if there is a conflict with >> those changes. >> >> Thanks, >> David >> >> On 19/12/2015 8:20 AM, Mikael Vidstedt wrote: >>> >>> Please review this small change which relaxes the check made in JPRT at >>> the time when a hotspot push job has finished successfully, and the >>> changes are about to be pushed. >>> >>> Currently the job will be marked as failed if a merge is needed, even if >>> an automatic merge would complete successfully. This "safety mechanism" >>> was reasonable when all pushes were made using JPRT, but since we >>> started allowing direct pushes the failure rate has gone up. The >>> assumption here is that the code changes will very rarely overlap, and >>> even more rarely conflict, so if the automatic merge is successful then >>> it's highly likely that the resulting code would (also) pass the JPRT >>> testing. >>> >>> This change enables the automatic merge to be attempted, and if it is >>> successful the resulting changes will be pushed. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145828 >>> Webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8145828/webrev.00/webrev/ >>> >>> Cheers, >>> Mikael >>> > From ioi.lam at oracle.com Wed Dec 23 05:19:03 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 22 Dec 2015 21:19:03 -0800 Subject: Adding help information to log tags Message-ID: <567A2EC7.6070801@oracle.com> Now there are a lot of log tags [1], and it looks like many more will be added. I start to wonder what 'ihop' or 'rt' would do ... Would it make sense to add help information that can be printed to the user, like #define LOG_TAG_LIST \ LOG_TAG(alloc, "this prints something about alloc") \ LOG_TAG(age, "blah blah") \ $ java -Xlog:help=alloc alloc - this prints something about alloc $ java -Xlog:help=all alloc - this prints something about alloc age - blah blah ----------------- [1] The list of log tags as of today in jdk9/hs-rt/hotspot #define LOG_TAG_LIST \ LOG_TAG(alloc) \ LOG_TAG(age) \ LOG_TAG(barrier) \ LOG_TAG(bot) \ LOG_TAG(census) \ LOG_TAG(classhisto) \ LOG_TAG(classinit) \ LOG_TAG(comp) \ LOG_TAG(compaction) \ LOG_TAG(cpu) \ LOG_TAG(cset) \ LOG_TAG(defaultmethods) \ LOG_TAG(ergo) \ LOG_TAG(exceptions) \ LOG_TAG(exit) \ LOG_TAG(freelist) \ LOG_TAG(gc) \ LOG_TAG(heap) \ LOG_TAG(humongous) \ LOG_TAG(ihop) \ LOG_TAG(jni) \ LOG_TAG(liveness) \ LOG_TAG(logging) \ LOG_TAG(marking) \ LOG_TAG(metaspace) \ LOG_TAG(monitorinflation) \ LOG_TAG(phases) \ LOG_TAG(plab) \ LOG_TAG(promotion) \ LOG_TAG(ref) \ LOG_TAG(refine) \ LOG_TAG(region) \ LOG_TAG(remset) \ LOG_TAG(rt) \ LOG_TAG(safepoint) \ LOG_TAG(scavenge) \ LOG_TAG(scrub) \ LOG_TAG(start) \ LOG_TAG(state) \ LOG_TAG(stats) \ LOG_TAG(stringdedup) \ LOG_TAG(survivor) \ LOG_TAG(svc) \ LOG_TAG(sweep) \ LOG_TAG(task) \ LOG_TAG(tlab) \ LOG_TAG(time) \ LOG_TAG(verify) \ LOG_TAG(vmoperation) From christian.tornqvist at oracle.com Wed Dec 23 12:11:08 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 23 Dec 2015 07:11:08 -0500 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT In-Reply-To: References: Message-ID: <04c701d13d7b$01b388f0$051a9ad0$@oracle.com> Hi Chris, This looks good. Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Christian Thalinger Sent: Tuesday, December 22, 2015 6:07 PM To: hotspot-dev developers Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT https://bugs.openjdk.java.net/browse/JDK-8146043 Running all JVMCI tests on my MacBook takes about 2 minutes: Test results: passed: 63; error: 3 Results written to /private/tmp/twisti Error: Some tests failed or other problems occurred. real 2m6.236s user 4m7.922s sys 0m14.363s Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least amount of time currently. diff -r 46122d93612d test/TEST.groups --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ compiler/inlining/ \ compiler/integerArithmetic/ \ compiler/interpreter/ \ + compiler/jvmci/ \ -compiler/codegen/7184394 \ -compiler/codecache/stress From dmitry.samersoff at oracle.com Wed Dec 23 12:28:34 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 23 Dec 2015 15:28:34 +0300 Subject: JDK-8067194: FYI, SA sources moved to jdk.hotspot.agent Message-ID: <567A9372.2070506@oracle.com> Everybody, FYI, I just pushed JDK-8067194 that move SA sources to modules-ready location: from hotspot/agent to hotspot/src/jdk.hotspot.agent Please, make sure you WS is updated correctly and if you have fixes that touch SA code in a queue, please re-merge it. -Dmitry -- 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 christian.tornqvist at oracle.com Wed Dec 23 12:40:53 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 23 Dec 2015 07:40:53 -0500 Subject: RFR(XXS): 8146098 - Visual Studio build fails after SA restructure Message-ID: <04d601d13d7f$29fb6fe0$7df24fa0$@oracle.com> Hi everyone, Please review this small change that fixes a Visual Studio build issue caused by the recent SA restructure. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8146098/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8146098 Tested locally by building 32/64-bit Hotspot Thanks, Christian From dmitry.samersoff at oracle.com Wed Dec 23 12:56:07 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 23 Dec 2015 15:56:07 +0300 Subject: RFR(XXS): 8146098 - Visual Studio build fails after SA restructure In-Reply-To: <04d601d13d7f$29fb6fe0$7df24fa0$@oracle.com> References: <04d601d13d7f$29fb6fe0$7df24fa0$@oracle.com> Message-ID: <567A99E7.9040401@oracle.com> Christian, Looks good for me! -Dmitry On 2015-12-23 15:40, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that fixes a Visual Studio build issue > caused by the recent SA restructure. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8146098/webrev.00/ > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8146098 > > > > Tested locally by building 32/64-bit Hotspot > > > > Thanks, > > Christian > -- 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 harold.seigel at oracle.com Wed Dec 23 12:59:46 2015 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 23 Dec 2015 07:59:46 -0500 Subject: RFR(XXS): 8146098 - Visual Studio build fails after SA restructure In-Reply-To: <567A99E7.9040401@oracle.com> References: <04d601d13d7f$29fb6fe0$7df24fa0$@oracle.com> <567A99E7.9040401@oracle.com> Message-ID: <567A9AC2.20808@oracle.com> Looks good to me, also. Harold On 12/23/2015 7:56 AM, Dmitry Samersoff wrote: > Christian, > > Looks good for me! > > -Dmitry > > > On 2015-12-23 15:40, Christian Tornqvist wrote: >> Hi everyone, >> >> >> >> Please review this small change that fixes a Visual Studio build issue >> caused by the recent SA restructure. >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8146098/webrev.00/ >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8146098 >> >> >> >> Tested locally by building 32/64-bit Hotspot >> >> >> >> Thanks, >> >> Christian >> > From goetz.lindenmaier at sap.com Wed Dec 23 13:39:49 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 23 Dec 2015 13:39:49 +0000 Subject: RFR(XXS): 8146098 - Visual Studio build fails after SA restructure In-Reply-To: <04d601d13d7f$29fb6fe0$7df24fa0$@oracle.com> References: <04d601d13d7f$29fb6fe0$7df24fa0$@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EF418C@DEWDFEMB12A.global.corp.sap> Looks good! Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Christian Tornqvist > Sent: Wednesday, December 23, 2015 1:41 PM > To: 'hotspot-dev developers' > Subject: RFR(XXS): 8146098 - Visual Studio build fails after SA restructure > > Hi everyone, > > > > Please review this small change that fixes a Visual Studio build issue > caused by the recent SA restructure. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8146098/webrev.00/ > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8146098 > > > > Tested locally by building 32/64-bit Hotspot > > > > Thanks, > > Christian From rachel.protacio at oracle.com Wed Dec 23 20:45:34 2015 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 23 Dec 2015 15:45:34 -0500 Subject: Adding help information to log tags In-Reply-To: <567A2EC7.6070801@oracle.com> References: <567A2EC7.6070801@oracle.com> Message-ID: <567B07EE.3050500@oracle.com> That seems like a good idea to me! It'd be helpful for the user and also anyone looking at the actual code in logTag.hpp Rachel On 12/23/2015 12:19 AM, Ioi Lam wrote: > Now there are a lot of log tags [1], and it looks like many more will > be added. I start to wonder what 'ihop' or 'rt' would do ... > > Would it make sense to add help information that can be printed to the > user, like > > #define LOG_TAG_LIST \ > LOG_TAG(alloc, "this prints something about alloc") \ > LOG_TAG(age, "blah blah") \ > > $ java -Xlog:help=alloc > alloc - this prints something about alloc > > $ java -Xlog:help=all > alloc - this prints something about alloc > age - blah blah > > > ----------------- > > [1] The list of log tags as of today in jdk9/hs-rt/hotspot > > #define LOG_TAG_LIST \ > LOG_TAG(alloc) \ > LOG_TAG(age) \ > LOG_TAG(barrier) \ > LOG_TAG(bot) \ > LOG_TAG(census) \ > LOG_TAG(classhisto) \ > LOG_TAG(classinit) \ > LOG_TAG(comp) \ > LOG_TAG(compaction) \ > LOG_TAG(cpu) \ > LOG_TAG(cset) \ > LOG_TAG(defaultmethods) \ > LOG_TAG(ergo) \ > LOG_TAG(exceptions) \ > LOG_TAG(exit) \ > LOG_TAG(freelist) \ > LOG_TAG(gc) \ > LOG_TAG(heap) \ > LOG_TAG(humongous) \ > LOG_TAG(ihop) \ > LOG_TAG(jni) \ > LOG_TAG(liveness) \ > LOG_TAG(logging) \ > LOG_TAG(marking) \ > LOG_TAG(metaspace) \ > LOG_TAG(monitorinflation) \ > LOG_TAG(phases) \ > LOG_TAG(plab) \ > LOG_TAG(promotion) \ > LOG_TAG(ref) \ > LOG_TAG(refine) \ > LOG_TAG(region) \ > LOG_TAG(remset) \ > LOG_TAG(rt) \ > LOG_TAG(safepoint) \ > LOG_TAG(scavenge) \ > LOG_TAG(scrub) \ > LOG_TAG(start) \ > LOG_TAG(state) \ > LOG_TAG(stats) \ > LOG_TAG(stringdedup) \ > LOG_TAG(survivor) \ > LOG_TAG(svc) \ > LOG_TAG(sweep) \ > LOG_TAG(task) \ > LOG_TAG(tlab) \ > LOG_TAG(time) \ > LOG_TAG(verify) \ > LOG_TAG(vmoperation) > > From christian.thalinger at oracle.com Wed Dec 23 22:15:54 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 23 Dec 2015 12:15:54 -1000 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT In-Reply-To: <04c701d13d7b$01b388f0$051a9ad0$@oracle.com> References: <04c701d13d7b$01b388f0$051a9ad0$@oracle.com> Message-ID: <8A31C5F6-4DED-475E-975E-F664784FB364@oracle.com> David Holmes said he wanted a JPRT run to see the impact. Did you look at the times I put in the bug? > On Dec 23, 2015, at 2:11 AM, Christian Tornqvist wrote: > > Hi Chris, > > This looks good. > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of > Christian Thalinger > Sent: Tuesday, December 22, 2015 6:07 PM > To: hotspot-dev developers > Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT > > https://bugs.openjdk.java.net/browse/JDK-8146043 > > Running all JVMCI tests on my MacBook takes about 2 minutes: > > Test results: passed: 63; error: 3 > Results written to /private/tmp/twisti > Error: Some tests failed or other problems occurred. > > real 2m6.236s > user 4m7.922s > sys 0m14.363s > > Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least > amount of time currently. > > diff -r 46122d93612d test/TEST.groups > --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 > +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 > @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ > compiler/inlining/ \ > compiler/integerArithmetic/ \ > compiler/interpreter/ \ > + compiler/jvmci/ \ > -compiler/codegen/7184394 \ > -compiler/codecache/stress > > > From christian.tornqvist at oracle.com Wed Dec 23 22:27:23 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 23 Dec 2015 17:27:23 -0500 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT In-Reply-To: <8A31C5F6-4DED-475E-975E-F664784FB364@oracle.com> References: <04c701d13d7b$01b388f0$051a9ad0$@oracle.com> <8A31C5F6-4DED-475E-975E-F664784FB364@oracle.com> Message-ID: <060301d13dd1$187e3ac0$497ab040$@oracle.com> Yes, looked at the JPRT logs as well, the JVMCI tests seems quick enough to run in JPRT. Thanks, Christian -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Wednesday, December 23, 2015 5:16 PM To: Christian Tornqvist Cc: hotspot-dev developers Subject: Re: RFR (XXS): 8146043: run JVMCI tests in JPRT David Holmes said he wanted a JPRT run to see the impact. Did you look at the times I put in the bug? > On Dec 23, 2015, at 2:11 AM, Christian Tornqvist wrote: > > Hi Chris, > > This looks good. > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Christian Thalinger > Sent: Tuesday, December 22, 2015 6:07 PM > To: hotspot-dev developers > Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT > > https://bugs.openjdk.java.net/browse/JDK-8146043 > > Running all JVMCI tests on my MacBook takes about 2 minutes: > > Test results: passed: 63; error: 3 > Results written to /private/tmp/twisti > Error: Some tests failed or other problems occurred. > > real 2m6.236s > user 4m7.922s > sys 0m14.363s > > Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least > amount of time currently. > > diff -r 46122d93612d test/TEST.groups > --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 > +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 > @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ > compiler/inlining/ \ > compiler/integerArithmetic/ \ > compiler/interpreter/ \ > + compiler/jvmci/ \ > -compiler/codegen/7184394 \ > -compiler/codecache/stress > > > From christian.thalinger at oracle.com Wed Dec 23 22:34:55 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 23 Dec 2015 12:34:55 -1000 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT In-Reply-To: <060301d13dd1$187e3ac0$497ab040$@oracle.com> References: <04c701d13d7b$01b388f0$051a9ad0$@oracle.com> <8A31C5F6-4DED-475E-975E-F664784FB364@oracle.com> <060301d13dd1$187e3ac0$497ab040$@oracle.com> Message-ID: <50375950-8C1D-4BA0-A209-973FBE2ABA14@oracle.com> Great, thanks! > On Dec 23, 2015, at 12:27 PM, Christian Tornqvist wrote: > > Yes, looked at the JPRT logs as well, the JVMCI tests seems quick enough to > run in JPRT. > > Thanks, > Christian > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Wednesday, December 23, 2015 5:16 PM > To: Christian Tornqvist > Cc: hotspot-dev developers > Subject: Re: RFR (XXS): 8146043: run JVMCI tests in JPRT > > David Holmes said he wanted a JPRT run to see the impact. Did you look at > the times I put in the bug? > >> On Dec 23, 2015, at 2:11 AM, Christian Tornqvist > wrote: >> >> Hi Chris, >> >> This looks good. >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Christian Thalinger >> Sent: Tuesday, December 22, 2015 6:07 PM >> To: hotspot-dev developers >> Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT >> >> https://bugs.openjdk.java.net/browse/JDK-8146043 >> >> Running all JVMCI tests on my MacBook takes about 2 minutes: >> >> Test results: passed: 63; error: 3 >> Results written to /private/tmp/twisti >> Error: Some tests failed or other problems occurred. >> >> real 2m6.236s >> user 4m7.922s >> sys 0m14.363s >> >> Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least >> amount of time currently. >> >> diff -r 46122d93612d test/TEST.groups >> --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 >> +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 >> @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ >> compiler/inlining/ \ >> compiler/integerArithmetic/ \ >> compiler/interpreter/ \ >> + compiler/jvmci/ \ >> -compiler/codegen/7184394 \ >> -compiler/codecache/stress >> >> >> > > From gary.collins at oracle.com Wed Dec 23 22:36:01 2015 From: gary.collins at oracle.com (Gary Collins) Date: Wed, 23 Dec 2015 14:36:01 -0800 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT In-Reply-To: <060301d13dd1$187e3ac0$497ab040$@oracle.com> References: <04c701d13d7b$01b388f0$051a9ad0$@oracle.com> <8A31C5F6-4DED-475E-975E-F664784FB364@oracle.com> <060301d13dd1$187e3ac0$497ab040$@oracle.com> Message-ID: What are the number for all platforms? I believe this is what DavidH is looking for.. We are looking to optimize the JPRT machines. Having an understanding of this change for all plats would be helpful before we push. Thanks Gary > On Dec 23, 2015, at 2:27 PM, Christian Tornqvist wrote: > > Yes, looked at the JPRT logs as well, the JVMCI tests seems quick enough to > run in JPRT. > > Thanks, > Christian > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Wednesday, December 23, 2015 5:16 PM > To: Christian Tornqvist > Cc: hotspot-dev developers > Subject: Re: RFR (XXS): 8146043: run JVMCI tests in JPRT > > David Holmes said he wanted a JPRT run to see the impact. Did you look at > the times I put in the bug? > >> On Dec 23, 2015, at 2:11 AM, Christian Tornqvist > wrote: >> >> Hi Chris, >> >> This looks good. >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Christian Thalinger >> Sent: Tuesday, December 22, 2015 6:07 PM >> To: hotspot-dev developers >> Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT >> >> https://bugs.openjdk.java.net/browse/JDK-8146043 >> >> Running all JVMCI tests on my MacBook takes about 2 minutes: >> >> Test results: passed: 63; error: 3 >> Results written to /private/tmp/twisti >> Error: Some tests failed or other problems occurred. >> >> real 2m6.236s >> user 4m7.922s >> sys 0m14.363s >> >> Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least >> amount of time currently. >> >> diff -r 46122d93612d test/TEST.groups >> --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 >> +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 >> @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ >> compiler/inlining/ \ >> compiler/integerArithmetic/ \ >> compiler/interpreter/ \ >> + compiler/jvmci/ \ >> -compiler/codegen/7184394 \ >> -compiler/codecache/stress >> >> >> > > From christian.thalinger at oracle.com Wed Dec 23 22:53:18 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 23 Dec 2015 12:53:18 -1000 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT In-Reply-To: References: <04c701d13d7b$01b388f0$051a9ad0$@oracle.com> <8A31C5F6-4DED-475E-975E-F664784FB364@oracle.com> <060301d13dd1$187e3ac0$497ab040$@oracle.com> Message-ID: > On Dec 23, 2015, at 12:36 PM, Gary Collins wrote: > > What are the number for all platforms? Look at the numbers in the bug. > I believe this is what DavidH is looking for.. We are looking to optimize the JPRT machines. > Having an understanding of this change for all plats would be helpful before we push. > > Thanks > Gary >> On Dec 23, 2015, at 2:27 PM, Christian Tornqvist wrote: >> >> Yes, looked at the JPRT logs as well, the JVMCI tests seems quick enough to >> run in JPRT. >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Wednesday, December 23, 2015 5:16 PM >> To: Christian Tornqvist >> Cc: hotspot-dev developers >> Subject: Re: RFR (XXS): 8146043: run JVMCI tests in JPRT >> >> David Holmes said he wanted a JPRT run to see the impact. Did you look at >> the times I put in the bug? >> >>> On Dec 23, 2015, at 2:11 AM, Christian Tornqvist >> wrote: >>> >>> Hi Chris, >>> >>> This looks good. >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>> Behalf Of Christian Thalinger >>> Sent: Tuesday, December 22, 2015 6:07 PM >>> To: hotspot-dev developers >>> Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT >>> >>> https://bugs.openjdk.java.net/browse/JDK-8146043 >>> >>> Running all JVMCI tests on my MacBook takes about 2 minutes: >>> >>> Test results: passed: 63; error: 3 >>> Results written to /private/tmp/twisti >>> Error: Some tests failed or other problems occurred. >>> >>> real 2m6.236s >>> user 4m7.922s >>> sys 0m14.363s >>> >>> Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least >>> amount of time currently. >>> >>> diff -r 46122d93612d test/TEST.groups >>> --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 >>> +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 >>> @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ >>> compiler/inlining/ \ >>> compiler/integerArithmetic/ \ >>> compiler/interpreter/ \ >>> + compiler/jvmci/ \ >>> -compiler/codegen/7184394 \ >>> -compiler/codecache/stress >>> >>> >>> >> >> > From gary.collins at oracle.com Wed Dec 23 23:12:51 2015 From: gary.collins at oracle.com (Gary Collins) Date: Wed, 23 Dec 2015 15:12:51 -0800 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT In-Reply-To: References: <04c701d13d7b$01b388f0$051a9ad0$@oracle.com> <8A31C5F6-4DED-475E-975E-F664784FB364@oracle.com> <060301d13dd1$187e3ac0$497ab040$@oracle.com> Message-ID: Thanks, What was the before and after for each plat? Do you have the data? With your change what is the before or rather the delta change? solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(26m 28s) > On Dec 23, 2015, at 2:53 PM, Christian Thalinger wrote: > > >> On Dec 23, 2015, at 12:36 PM, Gary Collins wrote: >> >> What are the number for all platforms? > > Look at the numbers in the bug. > >> I believe this is what DavidH is looking for.. We are looking to optimize the JPRT machines. >> Having an understanding of this change for all plats would be helpful before we push. >> >> Thanks >> Gary >>> On Dec 23, 2015, at 2:27 PM, Christian Tornqvist wrote: >>> >>> Yes, looked at the JPRT logs as well, the JVMCI tests seems quick enough to >>> run in JPRT. >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Wednesday, December 23, 2015 5:16 PM >>> To: Christian Tornqvist >>> Cc: hotspot-dev developers >>> Subject: Re: RFR (XXS): 8146043: run JVMCI tests in JPRT >>> >>> David Holmes said he wanted a JPRT run to see the impact. Did you look at >>> the times I put in the bug? >>> >>>> On Dec 23, 2015, at 2:11 AM, Christian Tornqvist >>> wrote: >>>> >>>> Hi Chris, >>>> >>>> This looks good. >>>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Christian Thalinger >>>> Sent: Tuesday, December 22, 2015 6:07 PM >>>> To: hotspot-dev developers >>>> Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8146043 >>>> >>>> Running all JVMCI tests on my MacBook takes about 2 minutes: >>>> >>>> Test results: passed: 63; error: 3 >>>> Results written to /private/tmp/twisti >>>> Error: Some tests failed or other problems occurred. >>>> >>>> real 2m6.236s >>>> user 4m7.922s >>>> sys 0m14.363s >>>> >>>> Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least >>>> amount of time currently. >>>> >>>> diff -r 46122d93612d test/TEST.groups >>>> --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 >>>> +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 >>>> @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ >>>> compiler/inlining/ \ >>>> compiler/integerArithmetic/ \ >>>> compiler/interpreter/ \ >>>> + compiler/jvmci/ \ >>>> -compiler/codegen/7184394 \ >>>> -compiler/codecache/stress >>>> >>>> >>>> >>> >>> >> > From christian.thalinger at oracle.com Wed Dec 23 23:22:58 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 23 Dec 2015 13:22:58 -1000 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT In-Reply-To: References: <04c701d13d7b$01b388f0$051a9ad0$@oracle.com> <8A31C5F6-4DED-475E-975E-F664784FB364@oracle.com> <060301d13dd1$187e3ac0$497ab040$@oracle.com> Message-ID: > On Dec 23, 2015, at 1:12 PM, Gary Collins wrote: > > Thanks, > > What was the before and after for each plat? Do you have the data? Sure. Any successful JPRT should do: linux_i586_2.6-fastdebug-c1-hotspot_compiler_1 success(19m 58s) linux_i586_2.6-fastdebug-c1-hotspot_compiler_2 success(04m 49s) linux_i586_2.6-fastdebug-c1-hotspot_compiler_3 success(09m 45s) linux_i586_2.6-fastdebug-c1-hotspot_compiler_closed success(04m 00s) linux_i586_2.6-fastdebug-c2-hotspot_compiler_1 success(04m 02s) linux_i586_2.6-fastdebug-c2-hotspot_compiler_2 success(04m 59s) linux_i586_2.6-fastdebug-c2-hotspot_compiler_3 success(07m 38s) linux_i586_2.6-fastdebug-c2-hotspot_compiler_closed success(06m 06s) linux_x64_2.6-fastdebug-c2-hotspot_compiler_1 success(03m 26s) linux_x64_2.6-fastdebug-c2-hotspot_compiler_2 success(16m 14s) linux_x64_2.6-fastdebug-c2-hotspot_compiler_3 success(40m 09s) linux_x64_2.6-fastdebug-c2-hotspot_compiler_closed success(03m 40s) macosx_x64_10.9-fastdebug-c2-hotspot_compiler_1 success(07m 02s) macosx_x64_10.9-fastdebug-c2-hotspot_compiler_2 success(05m 09s) macosx_x64_10.9-fastdebug-c2-hotspot_compiler_3 success(22m 46s) macosx_x64_10.9-fastdebug-c2-hotspot_compiler_closed success(10m 38s) solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_1 success(12m 40s) solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_2 success(15m 53s) solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(49m 52s) solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_closed success(16m 35s) solaris_x64_5.11-fastdebug-c2-hotspot_compiler_1 success(04m 24s) solaris_x64_5.11-fastdebug-c2-hotspot_compiler_2 success(05m 25s) solaris_x64_5.11-fastdebug-c2-hotspot_compiler_3 success(10m 48s) solaris_x64_5.11-fastdebug-c2-hotspot_compiler_closed success(04m 47s) windows_i586_6.2-fastdebug-c1-hotspot_compiler_1 success(11m 04s) windows_i586_6.2-fastdebug-c1-hotspot_compiler_2 success(09m 52s) windows_i586_6.2-fastdebug-c1-hotspot_compiler_3 success(16m 37s) windows_i586_6.2-fastdebug-c1-hotspot_compiler_closed success(18m 32s) windows_i586_6.2-fastdebug-c2-hotspot_compiler_1 success(09m 43s) windows_i586_6.2-fastdebug-c2-hotspot_compiler_2 success(09m 53s) windows_i586_6.2-fastdebug-c2-hotspot_compiler_3 success(22m 19s) windows_i586_6.2-fastdebug-c2-hotspot_compiler_closed success(15m 34s) windows_x64_6.2-fastdebug-c2-hotspot_compiler_1 success(11m 19s) windows_x64_6.2-fastdebug-c2-hotspot_compiler_2 success(10m 33s) windows_x64_6.2-fastdebug-c2-hotspot_compiler_3 success(17m 12s) windows_x64_6.2-fastdebug-c2-hotspot_compiler_closed success(14m 40s) > > With your change what is the before or rather the delta change? > solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(26m 28s) I?ve added the tests to hotspot_compiler_2 so this one shouldn?t be relevant. > > > > >> On Dec 23, 2015, at 2:53 PM, Christian Thalinger > wrote: >> >> >>> On Dec 23, 2015, at 12:36 PM, Gary Collins > wrote: >>> >>> What are the number for all platforms? >> >> Look at the numbers in the bug. >> >>> I believe this is what DavidH is looking for.. We are looking to optimize the JPRT machines. >>> Having an understanding of this change for all plats would be helpful before we push. >>> >>> Thanks >>> Gary >>>> On Dec 23, 2015, at 2:27 PM, Christian Tornqvist > wrote: >>>> >>>> Yes, looked at the JPRT logs as well, the JVMCI tests seems quick enough to >>>> run in JPRT. >>>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com ] >>>> Sent: Wednesday, December 23, 2015 5:16 PM >>>> To: Christian Tornqvist > >>>> Cc: hotspot-dev developers > >>>> Subject: Re: RFR (XXS): 8146043: run JVMCI tests in JPRT >>>> >>>> David Holmes said he wanted a JPRT run to see the impact. Did you look at >>>> the times I put in the bug? >>>> >>>>> On Dec 23, 2015, at 2:11 AM, Christian Tornqvist >>>> > wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> This looks good. >>>>> >>>>> Thanks, >>>>> Christian >>>>> >>>>> -----Original Message----- >>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net ] On >>>>> Behalf Of Christian Thalinger >>>>> Sent: Tuesday, December 22, 2015 6:07 PM >>>>> To: hotspot-dev developers > >>>>> Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8146043 >>>>> >>>>> Running all JVMCI tests on my MacBook takes about 2 minutes: >>>>> >>>>> Test results: passed: 63; error: 3 >>>>> Results written to /private/tmp/twisti >>>>> Error: Some tests failed or other problems occurred. >>>>> >>>>> real 2m6.236s >>>>> user 4m7.922s >>>>> sys 0m14.363s >>>>> >>>>> Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least >>>>> amount of time currently. >>>>> >>>>> diff -r 46122d93612d test/TEST.groups >>>>> --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 >>>>> +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 >>>>> @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ >>>>> compiler/inlining/ \ >>>>> compiler/integerArithmetic/ \ >>>>> compiler/interpreter/ \ >>>>> + compiler/jvmci/ \ >>>>> -compiler/codegen/7184394 \ >>>>> -compiler/codecache/stress >>>>> >>>>> >>>>> >>>> >>>> >>> >> > From gary.collins at oracle.com Wed Dec 23 23:43:28 2015 From: gary.collins at oracle.com (Gary Collins) Date: Wed, 23 Dec 2015 15:43:28 -0800 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT In-Reply-To: References: <04c701d13d7b$01b388f0$051a9ad0$@oracle.com> <8A31C5F6-4DED-475E-975E-F664784FB364@oracle.com> <060301d13dd1$187e3ac0$497ab040$@oracle.com> Message-ID: <253B1D93-DEB0-415B-9092-2C5F2194BF16@oracle.com> Looks good.. Thanks for the Data. The reason I asked about the differences is related to all the performance bugs about job times in the JPRT queue. A small change like this one is GREAT to help with coverage yet will impact the overall job completion time as a whole. Keep adding tests, this is what the tool is designed to do. Helps ensure we have solid set of bits. Cumulative changes overtime will add up. With the perception something is wrong with the JPRT. Cheers, Gary > On Dec 23, 2015, at 3:22 PM, Christian Thalinger wrote: > > >> On Dec 23, 2015, at 1:12 PM, Gary Collins > wrote: >> >> Thanks, >> >> What was the before and after for each plat? Do you have the data? > > Sure. Any successful JPRT should do: > > linux_i586_2.6-fastdebug-c1-hotspot_compiler_1 success(19m 58s) > linux_i586_2.6-fastdebug-c1-hotspot_compiler_2 success(04m 49s) > linux_i586_2.6-fastdebug-c1-hotspot_compiler_3 success(09m 45s) > linux_i586_2.6-fastdebug-c1-hotspot_compiler_closed success(04m 00s) > linux_i586_2.6-fastdebug-c2-hotspot_compiler_1 success(04m 02s) > linux_i586_2.6-fastdebug-c2-hotspot_compiler_2 success(04m 59s) > linux_i586_2.6-fastdebug-c2-hotspot_compiler_3 success(07m 38s) > linux_i586_2.6-fastdebug-c2-hotspot_compiler_closed success(06m 06s) > linux_x64_2.6-fastdebug-c2-hotspot_compiler_1 success(03m 26s) > linux_x64_2.6-fastdebug-c2-hotspot_compiler_2 success(16m 14s) > linux_x64_2.6-fastdebug-c2-hotspot_compiler_3 success(40m 09s) > linux_x64_2.6-fastdebug-c2-hotspot_compiler_closed success(03m 40s) > macosx_x64_10.9-fastdebug-c2-hotspot_compiler_1 success(07m 02s) > macosx_x64_10.9-fastdebug-c2-hotspot_compiler_2 success(05m 09s) > macosx_x64_10.9-fastdebug-c2-hotspot_compiler_3 success(22m 46s) > macosx_x64_10.9-fastdebug-c2-hotspot_compiler_closed success(10m 38s) > solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_1 success(12m 40s) > solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_2 success(15m 53s) > solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(49m 52s) > solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_closed success(16m 35s) > solaris_x64_5.11-fastdebug-c2-hotspot_compiler_1 success(04m 24s) > solaris_x64_5.11-fastdebug-c2-hotspot_compiler_2 success(05m 25s) > solaris_x64_5.11-fastdebug-c2-hotspot_compiler_3 success(10m 48s) > solaris_x64_5.11-fastdebug-c2-hotspot_compiler_closed success(04m 47s) > windows_i586_6.2-fastdebug-c1-hotspot_compiler_1 success(11m 04s) > windows_i586_6.2-fastdebug-c1-hotspot_compiler_2 success(09m 52s) > windows_i586_6.2-fastdebug-c1-hotspot_compiler_3 success(16m 37s) > windows_i586_6.2-fastdebug-c1-hotspot_compiler_closed success(18m 32s) > windows_i586_6.2-fastdebug-c2-hotspot_compiler_1 success(09m 43s) > windows_i586_6.2-fastdebug-c2-hotspot_compiler_2 success(09m 53s) > windows_i586_6.2-fastdebug-c2-hotspot_compiler_3 success(22m 19s) > windows_i586_6.2-fastdebug-c2-hotspot_compiler_closed success(15m 34s) > windows_x64_6.2-fastdebug-c2-hotspot_compiler_1 success(11m 19s) > windows_x64_6.2-fastdebug-c2-hotspot_compiler_2 success(10m 33s) > windows_x64_6.2-fastdebug-c2-hotspot_compiler_3 success(17m 12s) > windows_x64_6.2-fastdebug-c2-hotspot_compiler_closed success(14m 40s) > >> >> With your change what is the before or rather the delta change? >> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(26m 28s) > > I?ve added the tests to hotspot_compiler_2 so this one shouldn?t be relevant. > >> >> >> >> >>> On Dec 23, 2015, at 2:53 PM, Christian Thalinger > wrote: >>> >>> >>>> On Dec 23, 2015, at 12:36 PM, Gary Collins > wrote: >>>> >>>> What are the number for all platforms? >>> >>> Look at the numbers in the bug. >>> >>>> I believe this is what DavidH is looking for.. We are looking to optimize the JPRT machines. >>>> Having an understanding of this change for all plats would be helpful before we push. >>>> >>>> Thanks >>>> Gary >>>>> On Dec 23, 2015, at 2:27 PM, Christian Tornqvist > wrote: >>>>> >>>>> Yes, looked at the JPRT logs as well, the JVMCI tests seems quick enough to >>>>> run in JPRT. >>>>> >>>>> Thanks, >>>>> Christian >>>>> >>>>> -----Original Message----- >>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com ] >>>>> Sent: Wednesday, December 23, 2015 5:16 PM >>>>> To: Christian Tornqvist > >>>>> Cc: hotspot-dev developers > >>>>> Subject: Re: RFR (XXS): 8146043: run JVMCI tests in JPRT >>>>> >>>>> David Holmes said he wanted a JPRT run to see the impact. Did you look at >>>>> the times I put in the bug? >>>>> >>>>>> On Dec 23, 2015, at 2:11 AM, Christian Tornqvist >>>>> > wrote: >>>>>> >>>>>> Hi Chris, >>>>>> >>>>>> This looks good. >>>>>> >>>>>> Thanks, >>>>>> Christian >>>>>> >>>>>> -----Original Message----- >>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net ] On >>>>>> Behalf Of Christian Thalinger >>>>>> Sent: Tuesday, December 22, 2015 6:07 PM >>>>>> To: hotspot-dev developers > >>>>>> Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146043 >>>>>> >>>>>> Running all JVMCI tests on my MacBook takes about 2 minutes: >>>>>> >>>>>> Test results: passed: 63; error: 3 >>>>>> Results written to /private/tmp/twisti >>>>>> Error: Some tests failed or other problems occurred. >>>>>> >>>>>> real 2m6.236s >>>>>> user 4m7.922s >>>>>> sys 0m14.363s >>>>>> >>>>>> Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least >>>>>> amount of time currently. >>>>>> >>>>>> diff -r 46122d93612d test/TEST.groups >>>>>> --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 >>>>>> +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 >>>>>> @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ >>>>>> compiler/inlining/ \ >>>>>> compiler/integerArithmetic/ \ >>>>>> compiler/interpreter/ \ >>>>>> + compiler/jvmci/ \ >>>>>> -compiler/codegen/7184394 \ >>>>>> -compiler/codecache/stress >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From christian.thalinger at oracle.com Thu Dec 24 00:01:01 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 23 Dec 2015 14:01:01 -1000 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT In-Reply-To: <253B1D93-DEB0-415B-9092-2C5F2194BF16@oracle.com> References: <04c701d13d7b$01b388f0$051a9ad0$@oracle.com> <8A31C5F6-4DED-475E-975E-F664784FB364@oracle.com> <060301d13dd1$187e3ac0$497ab040$@oracle.com> <253B1D93-DEB0-415B-9092-2C5F2194BF16@oracle.com> Message-ID: <4F6F7B49-67FF-457A-94BE-730D20D820D2@oracle.com> Thanks, Gary. > On Dec 23, 2015, at 1:43 PM, Gary Collins wrote: > > Looks good.. Thanks for the Data. > > The reason I asked about the differences is related to all the performance bugs about job times in the > JPRT queue. A small change like this one is GREAT to help with coverage yet will impact the overall job > completion time as a whole. Keep adding tests, this is what the tool is designed to do. Helps ensure we > have solid set of bits. > > Cumulative changes overtime will add up. With the perception something is wrong with the JPRT. > > Cheers, > Gary > > > >> On Dec 23, 2015, at 3:22 PM, Christian Thalinger wrote: >> >> >>> On Dec 23, 2015, at 1:12 PM, Gary Collins > wrote: >>> >>> Thanks, >>> >>> What was the before and after for each plat? Do you have the data? >> >> Sure. Any successful JPRT should do: >> >> linux_i586_2.6-fastdebug-c1-hotspot_compiler_1 success(19m 58s) >> linux_i586_2.6-fastdebug-c1-hotspot_compiler_2 success(04m 49s) >> linux_i586_2.6-fastdebug-c1-hotspot_compiler_3 success(09m 45s) >> linux_i586_2.6-fastdebug-c1-hotspot_compiler_closed success(04m 00s) >> linux_i586_2.6-fastdebug-c2-hotspot_compiler_1 success(04m 02s) >> linux_i586_2.6-fastdebug-c2-hotspot_compiler_2 success(04m 59s) >> linux_i586_2.6-fastdebug-c2-hotspot_compiler_3 success(07m 38s) >> linux_i586_2.6-fastdebug-c2-hotspot_compiler_closed success(06m 06s) >> linux_x64_2.6-fastdebug-c2-hotspot_compiler_1 success(03m 26s) >> linux_x64_2.6-fastdebug-c2-hotspot_compiler_2 success(16m 14s) >> linux_x64_2.6-fastdebug-c2-hotspot_compiler_3 success(40m 09s) >> linux_x64_2.6-fastdebug-c2-hotspot_compiler_closed success(03m 40s) >> macosx_x64_10.9-fastdebug-c2-hotspot_compiler_1 success(07m 02s) >> macosx_x64_10.9-fastdebug-c2-hotspot_compiler_2 success(05m 09s) >> macosx_x64_10.9-fastdebug-c2-hotspot_compiler_3 success(22m 46s) >> macosx_x64_10.9-fastdebug-c2-hotspot_compiler_closed success(10m 38s) >> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_1 success(12m 40s) >> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_2 success(15m 53s) >> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(49m 52s) >> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_closed success(16m 35s) >> solaris_x64_5.11-fastdebug-c2-hotspot_compiler_1 success(04m 24s) >> solaris_x64_5.11-fastdebug-c2-hotspot_compiler_2 success(05m 25s) >> solaris_x64_5.11-fastdebug-c2-hotspot_compiler_3 success(10m 48s) >> solaris_x64_5.11-fastdebug-c2-hotspot_compiler_closed success(04m 47s) >> windows_i586_6.2-fastdebug-c1-hotspot_compiler_1 success(11m 04s) >> windows_i586_6.2-fastdebug-c1-hotspot_compiler_2 success(09m 52s) >> windows_i586_6.2-fastdebug-c1-hotspot_compiler_3 success(16m 37s) >> windows_i586_6.2-fastdebug-c1-hotspot_compiler_closed success(18m 32s) >> windows_i586_6.2-fastdebug-c2-hotspot_compiler_1 success(09m 43s) >> windows_i586_6.2-fastdebug-c2-hotspot_compiler_2 success(09m 53s) >> windows_i586_6.2-fastdebug-c2-hotspot_compiler_3 success(22m 19s) >> windows_i586_6.2-fastdebug-c2-hotspot_compiler_closed success(15m 34s) >> windows_x64_6.2-fastdebug-c2-hotspot_compiler_1 success(11m 19s) >> windows_x64_6.2-fastdebug-c2-hotspot_compiler_2 success(10m 33s) >> windows_x64_6.2-fastdebug-c2-hotspot_compiler_3 success(17m 12s) >> windows_x64_6.2-fastdebug-c2-hotspot_compiler_closed success(14m 40s) >> >>> >>> With your change what is the before or rather the delta change? >>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(26m 28s) >> >> I?ve added the tests to hotspot_compiler_2 so this one shouldn?t be relevant. >> >>> >>> >>> >>> >>>> On Dec 23, 2015, at 2:53 PM, Christian Thalinger > wrote: >>>> >>>> >>>>> On Dec 23, 2015, at 12:36 PM, Gary Collins > wrote: >>>>> >>>>> What are the number for all platforms? >>>> >>>> Look at the numbers in the bug. >>>> >>>>> I believe this is what DavidH is looking for.. We are looking to optimize the JPRT machines. >>>>> Having an understanding of this change for all plats would be helpful before we push. >>>>> >>>>> Thanks >>>>> Gary >>>>>> On Dec 23, 2015, at 2:27 PM, Christian Tornqvist > wrote: >>>>>> >>>>>> Yes, looked at the JPRT logs as well, the JVMCI tests seems quick enough to >>>>>> run in JPRT. >>>>>> >>>>>> Thanks, >>>>>> Christian >>>>>> >>>>>> -----Original Message----- >>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com ] >>>>>> Sent: Wednesday, December 23, 2015 5:16 PM >>>>>> To: Christian Tornqvist > >>>>>> Cc: hotspot-dev developers > >>>>>> Subject: Re: RFR (XXS): 8146043: run JVMCI tests in JPRT >>>>>> >>>>>> David Holmes said he wanted a JPRT run to see the impact. Did you look at >>>>>> the times I put in the bug? >>>>>> >>>>>>> On Dec 23, 2015, at 2:11 AM, Christian Tornqvist >>>>>> > wrote: >>>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> This looks good. >>>>>>> >>>>>>> Thanks, >>>>>>> Christian >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net ] On >>>>>>> Behalf Of Christian Thalinger >>>>>>> Sent: Tuesday, December 22, 2015 6:07 PM >>>>>>> To: hotspot-dev developers > >>>>>>> Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146043 >>>>>>> >>>>>>> Running all JVMCI tests on my MacBook takes about 2 minutes: >>>>>>> >>>>>>> Test results: passed: 63; error: 3 >>>>>>> Results written to /private/tmp/twisti >>>>>>> Error: Some tests failed or other problems occurred. >>>>>>> >>>>>>> real 2m6.236s >>>>>>> user 4m7.922s >>>>>>> sys 0m14.363s >>>>>>> >>>>>>> Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least >>>>>>> amount of time currently. >>>>>>> >>>>>>> diff -r 46122d93612d test/TEST.groups >>>>>>> --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 >>>>>>> +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 >>>>>>> @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ >>>>>>> compiler/inlining/ \ >>>>>>> compiler/integerArithmetic/ \ >>>>>>> compiler/interpreter/ \ >>>>>>> + compiler/jvmci/ \ >>>>>>> -compiler/codegen/7184394 \ >>>>>>> -compiler/codecache/stress >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From igor.ignatyev at oracle.com Thu Dec 24 18:24:38 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 24 Dec 2015 21:24:38 +0300 Subject: RFR (S): JDK-8066599: Add methods to check VM mode to c.o.j.t.Platform In-Reply-To: References: Message-ID: Hi Filipp, could you please move TestMutuallyExclusivePlatformPredicates and TestPlatformIsTieredSupported from hotspot/testlibrary_tests/ to test/lib-test and update it according to your changes? please note that we started to use packages in our tests. otherwise looks good to me. Thanks, ? Igor > On Dec 22, 2015, at 10:36 AM, Filipp Zhinkin wrote: > > Hi all, > > please review a small change that adds VM mode checking methods to > jdk.test.lib.Platform. > I didn't touch Platform class from hotspot/test/testlibrary, because > it is already deprecated and at some point of time all hs tests will > be updated to use j.t.l.Platform instead. > Update of hs tests that use own logic to check VM mode is tracked by > JDK-8145848 [1]. > > Webrev: http://cr.openjdk.java.net/~fzhinkin/8066599/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8066599 > Testing: on local machine with different VM modes. > > Regards, > Filipp. > > [1] https://bugs.openjdk.java.net/browse/JDK-8145848 From filipp.zhinkin at gmail.com Fri Dec 25 07:41:29 2015 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Fri, 25 Dec 2015 10:41:29 +0300 Subject: RFR (S): JDK-8066599: Add methods to check VM mode to c.o.j.t.Platform In-Reply-To: References: Message-ID: Hi Igor, thanks for looking at this change. On Thu, Dec 24, 2015 at 9:24 PM, Igor Ignatyev wrote: > Hi Filipp, > > could you please move TestMutuallyExclusivePlatformPredicates and TestPlatformIsTieredSupported from hotspot/testlibrary_tests/ to test/lib-test and update it according to your changes? please note that we started to use packages in our tests. Sure, I'll move it. Do I need to pass any specific options to jtreg to make '@library /test/lib' work? At the moment jtreg can't locate it unless I specify '/../../test/lib/share/classes'. Does it make sense to also move ClassFileInstaller to jdk.test.lib? Thanks, Filipp. > > otherwise looks good to me. > > Thanks, > ? Igor > >> On Dec 22, 2015, at 10:36 AM, Filipp Zhinkin wrote: >> >> Hi all, >> >> please review a small change that adds VM mode checking methods to >> jdk.test.lib.Platform. >> I didn't touch Platform class from hotspot/test/testlibrary, because >> it is already deprecated and at some point of time all hs tests will >> be updated to use j.t.l.Platform instead. >> Update of hs tests that use own logic to check VM mode is tracked by >> JDK-8145848 [1]. >> >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066599/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8066599 >> Testing: on local machine with different VM modes. >> >> Regards, >> Filipp. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8145848 > From vladimir.kozlov at oracle.com Tue Dec 29 10:04:08 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Dec 2015 02:04:08 -0800 Subject: RFR: 8145096: Undefined behaviour in HotSpot In-Reply-To: <567831DC.5020600@redhat.com> References: <56697E62.9030306@redhat.com> <56702E47.9090003@redhat.com> <5672BA7C.3000700@redhat.com> <9BDAB29C-BC4B-464D-98BB-7D7AF2B8CF7B@oracle.com> <5672F75B.50802@redhat.com> <340D0241-C04C-4353-A995-054094989789@oracle.com> <567831DC.5020600@redhat.com> Message-ID: <56825A98.5020603@oracle.com> Looks fine to me too. I am pushing it. Thanks, Vladimir On 12/21/15 9:07 AM, Andrew Haley wrote: > I've analysed the last remaining changes and I'm now convinced that > it's safe to make this change: > > --- a/src/share/vm/opto/mulnode.cpp > +++ b/src/share/vm/opto/mulnode.cpp > @@ -574,7 +574,8 @@ > // Masking off high bits which are always zero is useless. > const TypeLong* t1 = phase->type( in(1) )->isa_long(); > if (t1 != NULL && t1->_lo >= 0) { > - jlong t1_support = ((jlong)1 << (1 + log2_long(t1->_hi))) - 1; > + int bit_count = log2_long(t1->_hi) + 1; > + jlong t1_support = jlong(max_julong >> (BitsPerJavaLong - bit_count)); > if ((t1_support & con) == t1_support) > return usr; > } > > Webrev at http://cr.openjdk.java.net/~aph/8145096-4/ > > Andrew. > From christian.thalinger at oracle.com Tue Dec 29 18:58:48 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 29 Dec 2015 08:58:48 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <56730A4E.3020204@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> <2AE2D2D0-87ED-4794-A50F-818C1B05A373@oracle.com> <393F4221-839F-4BBE-8FBE-2BEF8E974BCB@oracle.com> <2E250702-A55C-43C0-B549-6E5D39A9DB4D@oracle.com> <56730A4E.3020204@oracle.com> Message-ID: > On Dec 17, 2015, at 9:17 AM, Coleen Phillimore wrote: > > > > On 12/17/15 2:08 PM, Christian Thalinger wrote: >>> On Dec 17, 2015, at 9:03 AM, Tom Rodriguez wrote: >>> >>> >>>> On Dec 17, 2015, at 10:53 AM, Christian Thalinger wrote: >>>> >>>> >>>>> On Dec 17, 2015, at 8:28 AM, Tom Rodriguez wrote: >>>>> >>>>> I think the ttyLocker should be in print_stack_trace. >>>> Well, the problem is that ttyLocker only locks defaultStream::instance (whatever that is) but print_stack_trace can take any outputStream. >>> Well maybe it shouldn?t. No one uses that flexibility but having a ttyLocker would be practically useful. >> True. I?m tempted to make that change but I see more bike-shedding coming up. Maybe if Coleen is okay with that? ;-) > > No, just leave it where it was.... With logging the ttyLocker doesn't work anyway. Well, turns out that we can?t hold the tty lock when calling out to Java: https://bugs.openjdk.java.net/browse/JDK-8146246 Either we give up the lock completely or we call out to Java code to do the printing for us (which was there in the first place). Since we are already calling out to Java (to Throwable.getCause) calling Java code at that point must work. > > Coleen >> >>> Anyway, it?s ok as is too. >>> >>> tom >>> >>>>> A short comment on print_stack_trace explaining that it prints the exception message along with the exception chain wouldn?t hurt. Otherwise looks good. >>>> Sure. >>>> >>>>> tom >>>>> >>>>>> On Dec 17, 2015, at 9:46 AM, Christian Thalinger wrote: >>>>>> >>>>>>> On Dec 17, 2015, at 3:56 AM, Doug Simon > wrote: >>>>>>> >>>>>>>> On 17 Dec 2015, at 08:20, Tom Rodriguez wrote: >>>>>>>> >>>>>>>>>>> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? >>>>>>>>>> >>>>>>>>>> There are two issues with java_lang_Throwable::print_stack_trace: >>>>>>>>>> >>>>>>>>>> 1. It doesn?t print the exception message, just the stack. >>>>>>>>> I?m printing the message separately: >>>>>>>>> >>>>>>>>> java_lang_Throwable::print(exception, tty); >>>>>>>>> tty->cr(); >>>>>>>>> java_lang_Throwable::print_stack_trace(exception(), tty); >>>>>>>> There are already 3 other copies of this idiom. Throwable should probably have a single method for this. Or maybe print_stack_trace itself should do this? >>>>>>> +1 >>>>>>> >>>>>>>> That would better parallel Throwable.printStackTrace(). >>>>>>> Makes sense to me! >>>>>> It does. Here it goes: >>>>>> >>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev.02/ >>>>>> >>>>>> I?ve made java_lang_Throwable::print_stack_trace to take a Handle instead of an oop and removed the unneeded copy of java_lang_Throwable::print. >>>>>> >>>>>>> -Doug From filipp.zhinkin at gmail.com Tue Dec 29 19:16:27 2015 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Tue, 29 Dec 2015 22:16:27 +0300 Subject: RFR (S): JDK-8066599: Add methods to check VM mode to c.o.j.t.Platform In-Reply-To: References: Message-ID: Ping 25 ???. 2015 ?. 10:41 ???????????? "Filipp Zhinkin" < filipp.zhinkin at gmail.com> ???????: > Hi Igor, > > thanks for looking at this change. > > On Thu, Dec 24, 2015 at 9:24 PM, Igor Ignatyev > wrote: > > Hi Filipp, > > > > could you please move TestMutuallyExclusivePlatformPredicates and > TestPlatformIsTieredSupported from hotspot/testlibrary_tests/ to > test/lib-test and update it according to your changes? please note that we > started to use packages in our tests. > > Sure, I'll move it. > > Do I need to pass any specific options to jtreg to make '@library > /test/lib' work? > At the moment jtreg can't locate it unless I specify > '/../../test/lib/share/classes'. > > Does it make sense to also move ClassFileInstaller to jdk.test.lib? > > > Thanks, > Filipp. > > > > > otherwise looks good to me. > > > > Thanks, > > ? Igor > > > >> On Dec 22, 2015, at 10:36 AM, Filipp Zhinkin > wrote: > >> > >> Hi all, > >> > >> please review a small change that adds VM mode checking methods to > >> jdk.test.lib.Platform. > >> I didn't touch Platform class from hotspot/test/testlibrary, because > >> it is already deprecated and at some point of time all hs tests will > >> be updated to use j.t.l.Platform instead. > >> Update of hs tests that use own logic to check VM mode is tracked by > >> JDK-8145848 [1]. > >> > >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066599/webrev.00/ > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8066599 > >> Testing: on local machine with different VM modes. > >> > >> Regards, > >> Filipp. > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8145848 > > > From gustav.r.akesson at gmail.com Thu Dec 31 13:26:29 2015 From: gustav.r.akesson at gmail.com (=?UTF-8?Q?Gustav_=C3=85kesson?=) Date: Thu, 31 Dec 2015 14:26:29 +0100 Subject: Class preloading Message-ID: Hi, I hope this is the appropriate mailing list, if not please advise. I'm working in a telco system and in one of our R&D projects we experienced significant problems when the system processed its' first request. The first request took 1600ms and the second 50ms, and the latency of the first request was unacceptable especially in case an unexpected restart is performed during peak hours. Quite obviously, classloading was to blame. The problem we saw was not classloading itself, but the static initializers and initialization of static fields. Both our own code and 3PPs make use of static, heavy and reusable objects in order to improve performance - which of course are initialized by the classloader. And to my experience, this idiom is quite frequent. One common example is the thread-safe Holder idiom for singleton instantiation. Even though this issue is well-known, we had to come up with a remedy. What I did is hatching the idea that before JVM shutdown, we store the currently loaded classes on disk. At next start, before the JVM accepts any requests, these classes are loaded again. The main idea is that classes which have been loaded by a previous JVM lifecycle is likely to be loaded in the subsequent. This trick resulted in the first request taking 50ms, i.e. as short/long as the second one. We had no choice but to move forward with this solution, which I think is sort of sad since this is somewhat of an inherited issue with the dynamic classloading of Java. Reason for sharing this scenario here is that I'd like to explore the opportunity of bringing this as an optional JVM feature (-XX flag), but obviously as a more builtin and refined construct. I reckon more folks have similar kind of issues, but before proceeding with a JEP I'd like to get some input and views on the matter. In case the above proposal as such is not the way forward for the JVM as a product, I think we need to figure out something else because we Java server folks are really suffering because of classloading. Happy new year & cheers, Gustav ?kesson